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

你的仪表盘显示 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 或实时代码补全中变得不可接受。隐私：离开设备的数据会产生合规风险，法律团队越来越不愿签字。成本：在请求量大且利用率波动低的情况下，你正在为你完全可以拥有的基础设施支付高额溢价。

你的 LLM 在云端生成的每一个 Token 都在产生费用，增加延迟，并跨越网络边界传输用户数据。在设备端生成的每一个 Token 都避开了这三个问题——但受限于手机或笔记本电脑 GPU 的处理能力。有趣的工程挑战发生在边界上：决定哪些查询值得调用云端的前沿能力，而哪些更适合由运行时间不到 20 毫秒的 3B 参数本地模型来处理。

混合云边推理模式并非理论。Apple Intelligence 在端侧模型和私有云计算 (Private Cloud Compute) 之间进行路由。Google 的 Gemini Nano 直接在 Pixel 和三星设备上运行，同时将复杂的请求升级到云端 Gemini。这些不是演示项目——它们正以数十亿设备的规模进行交付。而底层架构现在正被任何愿意仔细思考“延迟-隐私-成本”三角形的团队所采用。

你的负载均衡器将请求均匀地分配到你的 GPU 集群中。每个实例接收到的并发请求数量大致相同。一切看起来都很均衡。然而，一个实例的运行速度缓慢，仅为每秒 40 个 token，而另一个实例却能稳定在 200 个。仪表板显示请求数相等，但你的用户体验到的延迟却天差地别。

问题的根源在于：传统的负载均衡在请求层面运行，但 LLM 推理成本是随 token 数量扩展的。一个要求生成 4,000 个 token 文章的请求所消耗的 GPU 时间，是一个生成 80 个 token 分类结果请求的 50 倍。将它们视为同等单位，就像高速公路收费站只计算车辆数量而不区分摩托车和 18 轮大卡车一样。

这种请求层面的思维与 token 层面的现实之间的不匹配，正是古典排队论面临的最有趣的现代挑战。

基准测试告诉过你，运行 Mixtral 8x7B 的成本只有 46B 稠密模型的一半。但它们没告诉你的是，它需要的 GPU 显存大约是同等稠密模型的 8.6 倍，其响应延迟会因令牌命中哪个专家而产生剧烈波动，并且在中等批处理大小下会以难以诊断的方式崩溃。专家混合（MoE）架构已成为几乎所有前沿模型——DeepSeek-V3、Llama 4、Gemini 1.5、Grok、Mistral Large——的中流抵柱，但适用于稠密模型的推理假设在 MoE 上会以微妙且昂贵的方式失效。

如果你打算私有化部署或将流量路由到这些模型，以下是稠密模型直觉可能出错的地方。

大多数决定自托管 LLM 的工程师都会从同样的计算开始：模型有 70B 参数，FP16 每参数 2 字节，所以是 140 GB。他们检查发现两块 A100-80GB GPU 能容纳 160 GB，感到很满意，于是订购了硬件。然后进入生产环境，却发现还没服务一个真实用户，显存（VRAM）就已经耗尽了。

模型权重只是故事的一部分。让几乎每个团队都感到意外的部分是 KV 缓存（KV cache）—— 理解它会改变你的每一个决定，从量化选择到推理框架，再到你实际需要的 GPU 数量。

生产环境中大多数 LLM 推理基础设施的故障并不是模型故障——而是调度故障。团队部署了一个高性能模型，进行了压力测试，却发现用户在等待的同时，昂贵的 GPU 时间仅以 35% 的利用率在消耗。罪魁祸首几乎总是静态批处理（Static batching）：这是从传统深度学习中继承下来的默认设置，但根本不符合语言模型生成文本的方式。

持续批处理（Continuous batching）——也称为迭代级调度（Iteration-level scheduling）或飞行中批处理（In-flight batching）——是解决这一问题的核心机制。它不是一个微调旋钮，而是对推理循环运行方式的架构性改变。在使用相同硬件的情况下，使用该技术的系统与不使用的系统相比，吞吐量可能相差 4–8 倍。