一段对话在同一个 Claude 会话里跑了四十分钟。十一轮回合，每轮平均首字延迟（TTFT）800ms，每轮都很便宜——因为那段 28,000 token 的前缀命中了提示词缓存。第十二轮到来，TTFT 飙到 3.4 秒。对话的形态没变，模型没切换，网络也正常。缓存输入 token 从 27,800 掉到 0。下一轮的 prefill 账单从第一个 token 起就全额计费。
你去追踪里找原因，没有任何一条日志写着"另一个租户的突发流量把你逐出了缓存"。对这次毛刺最诚实的解读是：在同一片 GPU 池的某处，另一个客户的 prompt 让调度器认为，丢掉你这段温热的前缀是代价最小的选择。你无法重放这一轮，无法证明那次逐出。那一刻的缓存状态是陌生人流量的函数，而那些流量不在你的追踪里，因为它们本来就不属于你。
你正在运行一个由 LLM 驱动的应用，你的 p99 延迟为 4 秒。你已经优化了提示词，减少了输出长度，并切换到了流式传输。但这个数字几乎没变。问题不在于你的代码——而是在你无法控制的黑盒内部运作的物理学和排队论。
每个推理服务商在你的第一次 API 调用之前，就已经通过数十项架构决策决定了你应用的性能上限。KV 缓存淘汰策略、连续批处理（continuous batching）调度、分块预填充（chunked prefill）块大小——文档中没有提到这些，你也无法配置，但它们决定了你不得不面对的延迟和成本曲线。
这篇文章将解释推理基础设施内部究竟发生了什么，为什么它会产生不可避免的延迟底线，以及你真正能做的少数几件事。
大多数运行 LLM 推理的团队将 GPU 配置视作一场猜谜游戏。他们看到模型在 FP16 精度下需要 “140 GB”，便感到恐慌，于是申请四张 A100-80GB 显卡，然后就觉得万事大吉了。他们没有计算的是 KV 缓存、并发和量化是如何相互作用并决定实际显存占用的——而这种误算通常意味着他们多支付了 3 倍的冤枉钱。
这套计算并不复杂。但在签署云服务合同之前，几乎没有人去计算。本文将详细介绍这些精确的公式，揭示隐藏的显存黑洞，并解释装箱（bin-packing）策略，让你能在原本只够运行一个模型的硬件预算下服务四个模型。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
