9 篇博文 含有标签「gpu」

在你的推理集群中的某个地方，可能有一块芯片正在计算错误答案。不是崩溃 —— 而是错误答案。它通过了制造测试，通过了健康检查，但在指令序列、数据值、电压和温度的特定组合下，它会返回一个完全错误的数字。超大规模云服务商已经在大规模范围内记录了这一现象：大约每千台设备中就有一台会发生静默数据损坏（Silent Data Corruption），这一比率比我们过去担心的宇宙射线导致的比特翻转（bit flip）要高出几个数量级。

五十年来，软件拥有一种针对此情况的免疫系统：确定性（Determinism）。相同的输入，相同的输出 —— 因此你可以进行校验和（checksum）、回放，并与基准结果（golden results）进行对比，撒谎的硬件最终会被抓获。LLM 推理是第一个失去这种免疫系统的主要工作负载。当模型给出一个略差的答案时，是因为采样器的随机性，还是因为退化的 GPU 在你的 KV 缓存中翻转了比特？没人能通过检查来判断。一个不稳定的加速器可以在所有仪表盘显示正常的情况下，静默地拉低你的质量指标数周之久。

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

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

集群完全按照我们的指令行事。流量在 45 秒内降至零，队列深度指标也归于平寂，KEDA 将副本数从 1 改为 0，90 秒后，节点自动扩缩容工具回收了 H100 Pod。图表看起来很干净。Slack 频道一片寂静。成本看板上的数字跳低了半美分。

一小时十二分钟后，一封客户支持工单送达：一个长时间运行的文档分析任务——一个预算为 28 分钟解码时间的 180k-token 推理任务——消失了。客户端 SDK 没报错。应用程序日志没异常。只有网关访问日志中埋着的一行 499，时间戳大致就在调度器判定 Pod 空闲并将其回收的时候。

每晚的微调任务在 UTC 时间 02:00 开始。它进入共享 GPU 池，占用它能找到的每一个槽位并持续持有。到 09:30，当工作日的首波推理流量到达时，自动扩缩器（autoscaler）试图声明已被连续占用七个半小时的容量。早晨的前 90 分钟，系统运行在约为基准 p99 延迟四倍的水平上。仪表盘报告了一个“喧闹的早晨尾部（noisy morning tail）”，推理团队将其归因于用户行为，因为实际的资源争用发生在一个推理团队并不拥有的任务队列中。

这是你在容量评审的成本归因幻灯片中无法捕捉到的 GPU 共享失败模式。共享被宣传为利用率的胜利——晚上训练，白天服务，填补低谷。实际交付的却是直到池按延迟类别（而非按团队或按时间）进行分区之前，你都无法摆脱的延迟长尾。

十四个月前，在你公司的某个角落，一位财务总监和一位平台负责人签署了一份为期数年的算力加速器资源承诺协议。他们根据前一个季度的遥测数据构建了一个峰值负载模型，谈到了比按需计费价格低 40% 到 70% 的折扣，并锁定了集群的规格——而你现在的产品路线图必须去适应这个规格。产品团队中没有人参与过那次会议。应用工程团队中也没有人见过那份电子表格。这份合同具有法律约束力，只有在履行承诺的前提下才能享受折扣，而它买下的容量边界，现在成了产品经理们正在规划的每一个第三季度功能的隐形天花板。

大多数团队直到第二年才会察觉到这个差距：容量合同本质上是路线图决策，但它们是由那些看不见路线图的人，使用不包含路线图信息的输入数据做出的。产品“三人组”认为他们正从一个清晰的优先级积压任务中挑选功能。财务部门认为他们正在优化一个固定的预算边界。在各自的语境下他们都是正确的，而冲突则会在规划会议上显现——当架构师提议为新的助手功能使用 700 亿参数模型时，平台负责人会平静地说，集群使用率已经达到 85%，如果不挤掉其他项目，这个模型根本放不下。

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

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

大多数运行 LLM 推理的 GPU 集群正在浪费 30% 到 50% 的可用算力。这并非因为工程师粗心，而是因为调度问题本身极为困难——而大多数团队首先想到的工具根本不是为此设计的。

标准做法是搭建 Kubernetes，为每个 Pod 申请完整的 GPU，然后让调度器自行处理。这对训练任务运行良好。但对于处理异构模型集合的推理场景，这种方式会悄悄摧毁利用率。一个运行三个不同 7B 模型且流量稀疏的集群，每个 GPU 的实际繁忙时间可能不足 15%，同时却处于完全"已分配"状态，拒绝调度任何新任务。

根本原因在于 Kubernetes 理解 GPU 的方式与 LLM 推理实际需求之间的错配。

大多数决定自托管 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 倍。