20 篇博文 含有标签「llm-inference」

在几乎每一个发布 AI 功能的团队中，都会上演这样一种“仪式”：有人运行负载测试，看着 p99 延迟攀升并超过 2 秒，然后提交了一个工单：“让它快一点。”这个工单落到了基建（infra）团队手中。他们调整批处理大小（batch sizes），增加 GPU，争论调度器（scheduler），最终费尽心思将这个数字降到了 1.4 秒。每个人都点头认可。p99 被“解决”了。

整个过程都建立在一个错误的前提之上。这个前提认为延迟目标是系统的一个既定事实——是基建团队发现并为之优化的一个物理常数。事实并非如此。目标是一个选择，而且是一个产品层面的选择。什么才算“足够快”，完全取决于用户等待时界面的表现，而界面并不在基建团队的设计范围内。

当一个团队的推理端点开始无法达到延迟目标时，他们做的第一件事通常是购买更多的 GPU。一个月后，他们会发现第二件事：p99 延迟几乎没变，而账单却翻了一倍。显卡利用率徘徊在 40%，而尾部延迟依然很难看。有人添加了自动扩缩容（autoscaler）。自动扩缩容频繁震荡。现在有了更多的显卡，更高的成本，以及来自同一批用户的同样抱怨。

错误在于将推理缓慢视为容量不足。事实几乎从未如此。你面临的是一个披着容量问题外衣的排队问题。LLM 端点的尾部延迟取决于大小迥异的请求如何随时间共享固定的计算池——这是典型的调度问题，而非资源配置问题。在你理解服务栈实际运行的排队规则（queue discipline）之前，你添加的每一块 GPU 都只是更昂贵的变慢方式。

一个团队将 fp16 模型更换为 int4 量化模型，以将推理成本减半。评估套件在精心挑选的测试集上的得分与原始模型相比差距不到一个百分点。于是，在“基准测试表现无差异”的理由下，模型正式发布。六个星期后，支持团队收到了受监管客户关于灾难性故障的反馈——生成的代码完全是胡言乱语，低资源语言的回复漂移到了另一种文字，多步算术运算自信地给出了偏差一个数量级的数字。基准测试没有撒谎。它只是测量了中位数，而量化并不是对中位数的均匀征税，它是对长尾分布的非均匀征税。

这就是量化质量悬崖：你的评估套件、发布纪律和成本节约叙事同时崩溃，因为你用来批准更换的指标，对于你所摧毁的能力完全没有信号反馈。最近的基准测试让这种影响变得具体。在长上下文任务中，8-bit 量化保留了准确性，仅下降了约 0.8%，而 4-bit 方法在相同工作负载下损失高达 59%——这种退化对于任何没有对长尾输入进行过采样（oversample）的测试集来说都是不可见的。中位数移动了一个点，而长尾移动了十五、三十甚至五十个点。

我曾合作过的一个团队发布了一个他们称之为 “小规模” 的功能：一个供几百名分析师使用的内部研究助手。他们的容量模型认为一次用户请求等于一次模型调用，因此他们根据峰值用户 QPS，并预留了标准的 30% 突发余量来设定预置吞吐量（provisioned throughput）的大小。发布当天，他们在不到一小时内就遇到了 429 错误，原本应该只消耗 40% 预留容量的流量却让容量达到了 100% 的饱和状态。事后复盘发现了一个之前没有人算进去的数字：平均每个请求触发了 11 次模型调用，而不是 1 次。

这是我在 Agent 推广过程中看到的最常见的容量估算失误。其中的数学逻辑并不复杂，失败模式也并不罕见。团队问错了单位问题——他们以用户请求为单位进行规划，而计费表是按模型调用次数计次的——他们支付真金白银买下的预留容量，在一种如果换成聊天产品本应被视为轻负载的压力下化为乌有。

当 Agent 平台第一次崩溃时，事后分析报告（Postmortem）通常包含这样一句话：“周五我们还有八周的冗余容量。到了周一下午，我们已经达到了已配置容量的 140%。”没有人撒谎。容量模型本身是正确的，只是被应用到了一个它从未被设计用来应对的工作负载上。传统的容量规划假设需求沿着一条平滑曲线增长，周季节性是主导信号，最坏的情况是可以提前六个月规划的“黑色星期五”。Agent 工作负载彻底打破了这一假设。

Agent 需求的形态不是曲线，而是悬崖。有三件事造成了这种悬崖效应，并且它们会产生复合影响。一个企业级客户的入驻，就能根据你已经签署的合同通知，在通宵之间将基线移动 10 倍。一个 Agent 循环可以将微小的用户活动增长放大为扇出倍增的浪潮，对推理端的冲击比面向用户的图表显示的要高出 30 倍。单个产品变更——例如启用工具调用、延长上下文、切换到更大的模型——可以在用户数量不变的情况下，将单个任务的 Token 消耗提高一个数量级。

如果你的容量规划以 QPS 为单位，且你的冗余预算是“75% 的利用率是健康的”，那么你不是在规划。你是在赌这三个“悬崖”不会在同一个星期降临。

你的延迟仪表盘显示一切正常。p95 的首字延迟（TTFT）低于 800ms 的目标。p99 的总生成时间也在 4 秒的预算之内。然而，一位资深 PM 转发了一个支持线程：“助手在回答中途卡住了大约三秒钟”，“它停顿了一下，然后突然吐出一整段文字”，“我以为它死机了”。本周有三位用户因为同样的投诉卸载了应用。团队中没人能在笔记本电脑上重现这个问题，而且你记录的每一项指标都显示系统运行健康。

能解释这个 Bug 的指标正是你没在测量的那个：连续 Token 之间时间间隔的分布。一个看起来很完美的 p95 总时长可能会掩盖这样一种流：其中 8% 的响应在生成中途包含一个 2.5 秒的停顿。对于一个看着字符实时出现的用户来说，这种停顿意味着系统出故障了，而不仅仅是慢。你的仪表盘测量的是电影的总时长，而你的用户正在观看电影。

每一篇关于投机解码（Speculative Decoding）的论文中提到的“等效输出”保证，其实是对 token 分布的保证，而不是对用户所见内容的保证。仔细阅读证明过程，你会发现一个纯粹的数学等效性：拒绝采样的接受标准旨在确保投机后的输出分布与目标模型（target model）独立生成的分布完全一致。这一保证约束的是离开推理引擎的字节流，而对于五百毫秒前已经到达用户屏幕、现在却必须收回的字节，它只字未提。

如果你在小模型生成草稿 token 的那一刻就将其流式传输给客户端，那么每当验证器拒绝某个后缀时，你实际上是在对自己的用户进行 A/B 测试。半个段落会自行重写。函数名在 IDE 已经完成语法高亮后发生改变。语音合成（TTS）可能已经读出了“答案很可能是否定的”，随后验证器却将其替换为“答案是肯定的，但有几点需要注意”。数学逻辑上，最终分布与慢速路径一致；但从用户体验来看，他们亲眼目睹了模型在公开场合“反悔”。

这是投机解码中未被计入加速倍数的部分。它也将所谓的“免费 3 倍吞吐量”变成了一个没人预料到的、长达一个半季度的流式协议开发工作。

你的仪表盘显示 GPU 状态健康。利用率维持在 80% 左右，每秒生成的 token 吞吐量看起来很正常，冷启动很少见，而且模型也是你要求的那个。然而，你的报警器响了，因为 p99 延迟翻了三倍，少数用户遇到了超时，支持工单都在描述同一件事：“应用冻结了 20 秒，然后又恢复了。” 你调取了一个追踪（trace），发现一个毫不相关的客户发送的 28,000 个 token 的推理请求，正与每一个停滞的调用处在同一个批次（batch）中。某个租户的深度思考提示词刚刚抢走了其他所有人的机会。

这就是队头阻塞（head-of-line blocking），它是推理模型进入流量组合后，破坏共享 LLM 推理的典型故障模式。这种模式并不新鲜 —— 存储系统和网络栈已经与之斗争了几十年 —— 但由于连续批次（continuous batching）和 KV 缓存固定（KV-cache pinning）的工作方式，它在 GPU 上呈现出一种特定的形态。大多数团队针对平均负载进行设计，却太晚才发现，一旦请求大小不再相似，“共享推理更便宜”就不再成立了。

大多数 LLM 推理瓶颈归结于一个令人不安的事实：GPU 在等待内存带宽，而非计算资源。每生成一个 token，都需要从 HBM 加载整个模型权重，这一传输过程主导了运行时间。投机解码正是为了利用这一空隙而设计的——但其收益取决于你的基准测试几乎肯定没有测试过的条件。

将投机解码部署到生产环境的团队，往往发现其实际表现比实验室数据低 40–60%。这不是因为该技术存在缺陷，而是因为工作负载特征以重要的方式发生了变化：更大的批量、更短的输出、更严格的输出约束。理解投机解码何时真正有效、何时会悄然造成伤害，是负责任部署的前提。

一个在单张 RTX 4090 上运行的经过微调的 7B 参数模型，可以在特定领域任务上超越 GPT-4，同时在初始硬件投资之后每个 token 的成本为零。这不是理论上的说法——Diabetica-7B，一个专注于糖尿病的模型，在临床查询上达到了 87.2% 的准确率，在同一基准测试中击败了 GPT-4 和 Claude 3.5。但前提是什么？你需要准确理解边缘推理何时有意义，何时只是昂贵的干扰。

大多数团队默认使用云端 API，因为它们简单。你发送一个 HTTP 请求，就能得到 token 返回。但这种简单性有一个成本，它的扩展方式是许多工程师在为时已晚之前没有预料到的——而且成本并不总是以金钱来衡量的。

一个通过了 90% HumanEval 测试的代码智能体 (code agent) 并不算是一个可靠的代码智能体。它只是一个在那些设计为可以单次生成 (single-pass) 解决的问题上表现良好的智能体。如果给它一个带有严格约束的竞赛编程问题，或者一个具有微妙相互依赖关系的多文件重构任务，你会看到通过率骤降至 20–30%。模型失败并不是因为它缺乏知识，而是因为贪婪的单次生成策略会锁定在第一个看起来合理的 Token 序列上，并且永不回头。

解决方案不在于更好的模型，而在于更好的生成策略。最近的研究表明，将树状探索 (tree exploration) 应用于代码生成——在多个候选解决方案中进行分支、对部分程序进行评分并剪掉没有希望的路径——在处理难题时可以将通过率提高 30–130%，而无需更改底层的模型权重。

大多数团队都会面临选择：要么在云端运行一切，要么压缩模型以适配设备端。这两种选择都会造成成本浪费和性能损失。在 2025-2026 年获得最佳效果的团队两者都不选 —— 他们正在构建混合架构，根据复杂度、延迟预算和数据敏感性，将每个推理请求路由到合适的层级。

核心洞见简单但被低估了：70-80% 的生产查询并不需要前沿模型。它们需要来自靠近用户的模型提供的快速回答。剩下的 20-30% 则真正受益于云端托管的重量级模型。工程上的挑战在于构建路由层，使这种切分对用户无感。