2 篇博文 含有标签「kv-cache」

你正在运行一个由 LLM 驱动的应用，你的 p99 延迟为 4 秒。你已经优化了提示词，减少了输出长度，并切换到了流式传输。但这个数字几乎没变。问题不在于你的代码——而是在你无法控制的黑盒内部运作的物理学和排队论。

每个推理服务商在你的第一次 API 调用之前，就已经通过数十项架构决策决定了你应用的性能上限。KV 缓存淘汰策略、连续批处理（continuous batching）调度、分块预填充（chunked prefill）块大小——文档中没有提到这些，你也无法配置，但它们决定了你不得不面对的延迟和成本曲线。

这篇文章将解释推理基础设施内部究竟发生了什么，为什么它会产生不可避免的延迟底线，以及你真正能做的少数几件事。

大多数运行 LLM 推理的团队将 GPU 配置视作一场猜谜游戏。他们看到模型在 FP16 精度下需要 “140 GB”，便感到恐慌，于是申请四张 A100-80GB 显卡，然后就觉得万事大吉了。他们没有计算的是 KV 缓存、并发和量化是如何相互作用并决定实际显存占用的——而这种误算通常意味着他们多支付了 3 倍的冤枉钱。

这套计算并不复杂。但在签署云服务合同之前，几乎没有人去计算。本文将详细介绍这些精确的公式，揭示隐藏的显存黑洞，并解释装箱（bin-packing）策略，让你能在原本只够运行一个模型的硬件预算下服务四个模型。