2 篇博文 含有标签「llm-serving」

你的 700 亿参数模型在推理时大部分时间都在等待内存读取，而非进行计算。现代 GPU 每从内存读取一个字节就能执行数百次算术运算，但自回归 Transformer 解码每加载一个字节只进行寥寥数次运算。硬件在空转，而你的用户在等待。投机解码利用了这一差距：让一个小而快的模型提前起草多个 token，然后让大模型在一次并行传递中一并验证。承诺是延迟降低 2-3 倍，且输出质量在数学上完全一致。但现实远没有这么简单。

经过两年在 Google 搜索、编程助手和开源服务框架中的生产部署，投机解码已经从研究新奇事物毕业为标准优化手段。但"标准"并不意味着"即插即用"。该技术在草稿模型选择、批处理大小敏感性和内存开销方面有许多尖锐的边界条件，它们决定了你是获得 3 倍加速还是净减速。

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

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