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

一个团队将 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% 则真正受益于云端托管的重量级模型。工程上的挑战在于构建路由层，使这种切分对用户无感。

大多数团队都会选择一个阵营：要么将所有任务运行在云端，要么将所有任务推向边缘。对于大多数生产负载来说，这两种做法都是错误的。有趣的工程挑战发生在它们之间的路由层（routing layer）——这个组件根据每个请求来决定：该查询是需要 H100 上的 70B 前沿模型，还是在本地芯片上运行的 3B 量化模型。

这种路由决策不仅仅关乎延迟。它是一个涉及成本、隐私和能力的三变量优化过程——而最优的分配方案会根据你的流量模式、监管环境以及对每种查询类型“足够好”的定义而改变。正确处理路由的团队在降低 60–80% 推理成本的同时，还能优化 p95 延迟。处理不当的团队要么在简单的查询上过度消耗云端 GPU，要么让无法处理复杂任务的边缘模型提供质量下降的回答。

大多数团队通过云端 API 运行每一次 LLM 调用。这是阻力最小的路径：无需管理硬件，无需优化模型，而且最新的前沿能力只需一个 HTTP 请求即可获得。但随着 AI 深入生产环境 —— 处理敏感文档、支持实时交互、在移动设备上运行 —— 云端始终是正确答案的假设开始出现裂痕。

裂痕同时出现在三个地方。时延：在聊天机器人中察觉不到的 200 ms 网络往返，在语音 AI 或实时代码补全中变得不可接受。隐私：离开设备的数据会产生合规风险，法律团队越来越不愿签字。成本：在请求量大且利用率波动低的情况下，你正在为你完全可以拥有的基础设施支付高额溢价。