两周时间把推理吞吐拉高三倍还要扛住十万卡级别的集群规模——这个数字组合放在任何一家做大模型推理的团队面前都足够让人停下来多看两眼。智谱这次公开的《GLM如何自建推理基础设施》里最抓人的其实不是三倍这个结果而是他们选择了一条和主流拿来即用完全不同的路自建推理引擎、自研调度、自己啃底层。我前后把这份材料翻了几遍结合自己在推理服务上踩过的坑聊聊这套东西到底解决了什么问题、哪些思路可以直接抄、哪些地方是别人学不来的。如果你正在做推理服务的性能优化或者纠结要不要从现成方案切换到自建栈又或者只是好奇十万卡这种规模下推理到底难在哪这篇解读应该能给你一些能落地的参考。我会尽量把里面涉及的核心技术点——推理引擎、调度、并行策略、Infra Agent 这些——拆开讲清楚同时补上原文没细说但实操中一定会遇到的东西。1. 为什么两周三倍这个说法值得认真对待先把结论摆前面推理吞吐提升三倍在已经调优过的生产系统上是一件非常难的事。很多人对推理优化的想象是换个更快的引擎就行但真实情况是当一个推理服务已经跑在成熟框架上、显存打满、batch 也调过之后你能榨出来的空间通常只有百分之十几到几十。三倍这个量级意味着不是某个单点优化而是整条链路上多个环节同时被重新设计过。1.1 吞吐这个指标本身就有很多坑聊优化之前得先对齐吞吐到底指什么。业内常见的口径有这么几种混着用很容易得出错误结论指标口径含义容易被误用的地方tokens/s总整个集群每秒产出的 token 数忽略延迟堆 batch 就能刷高tokens/s/user单用户视角的生成速度和总吞吐经常互相矛盾requests/s每秒完成的请求数长短请求混合时失真严重goodput满足 SLO 前提下的有效吞吐最接近真实业务价值但最难测智谱提到的三倍吞吐从上下文看更接近在满足延迟约束下的有效吞吐goodput而不是单纯把 batch 拉大刷出来的数字。这个区别很关键如果你只追总 tokens/s把 batch size 从 64 拉到 512数字确实会涨但首 token 延迟TTFT和单用户生成速度会崩掉线上体验直接完蛋。所以看到三倍的时候第一反应应该是问一句在什么延迟约束下测的1.2 两周的时间尺度说明了什么两周不是一个从零开始搭系统的周期而是一个在已有基础上做集中攻坚的周期。这暗示了几件事基础设施集群、网络、存储、监控是现成的团队对业务负载特征有清晰认知优化目标是明确的而不是探索性的。换句话说这两周花在把已知的瓶颈逐个打掉而不是摸索该做什么。我自己做性能攻坚的经验是真正耗时间的从来不是改代码而是定位瓶颈。一个推理服务慢可能是计算瓶颈、可能是显存带宽瓶颈、可能是调度排队、可能是网络通信、也可能是 Python 层的 GIL 或者序列化开销。在没有完善 profiling 的情况下你可能花一周都在猜。所以两周出结果背后大概率有一套成熟的性能观测体系在支撑——这点原文没展开但它是前提。1.3 十万卡规模把问题性质改变了单机 8 卡和十万卡集群完全是两个物种的问题。规模上去之后会出现一些在小规模下根本不存在或者可以忽略的现象通信占比飙升张量并行、流水线并行、专家并行带来的 all-reduce、all-to-all 通信在万卡级别会吃掉大量时间通信和计算的重叠overlap做不好GPU 利用率直接腰斩。故障成为常态十万卡意味着每天都有卡在坏。推理服务不能像训练那样 checkpoint 重启必须做到故障时快速摘除、请求重路由用户几乎无感。调度复杂度爆炸请求怎么分配到不同节点、如何做负载均衡、如何处理热点专家MoE 场景这些在单机上是 trivial 的问题在集群级别是核心难题。显存碎片与 KV Cache 管理长上下文场景下 KV Cache 会吃掉大量显存十万卡级别的显存管理策略直接决定能跑多长的上下文、能并发多少请求。理解了这三点再看自建推理基础设施这个选择就顺理成章了——通用框架很难同时满足这种规模和这种定制化需求。2. 自建推理栈 vs 现成方案这笔账怎么算这是很多人最关心的问题市面上已经有 SGLang、vLLM 这些成熟的开源推理引擎为什么还要自建我先把这个问题拆成什么时候该用现成的和什么时候该自建两个子问题。2.1 现成引擎已经解决了 80% 的问题必须承认SGLang 和 vLLM 这类项目已经把推理引擎的通用问题解决得相当好了。它们提供的核心能力包括PagedAttention / RadixAttention这类显存管理机制把 KV Cache 的碎片问题基本解决连续批处理continuous batching让不同长度的请求可以动态拼批大幅提升 GPU 利用率前缀缓存prefix caching对多轮对话、few-shot 场景效果显著张量并行单机多卡开箱即用OpenAI 兼容 API接入成本极低。对绝大多数团队来说直接用 SGLang 或 vLLM 是性价比最高的选择。你不需要懂 CUDA kernel不需要懂通信原语配好参数就能跑出一个相当不错的服务。我见过不少团队一上来就想着自研结果半年过去性能还不如调好的 vLLM这是典型的重复造轮子。2.2 什么情况下自建才划算自建的门槛很高但确实有几类场景是现成方案覆盖不好的第一类是规模极端。十万卡这种量级通用框架的调度器、通信策略、故障处理往往不是为这个规模设计的。比如默认的负载均衡策略在几千卡上够用到万卡级别可能因为元数据同步延迟导致热点。第二类是负载特征特殊。如果你的业务是超长上下文比如几十万 token、或者 MoE 模型专家分布极不均匀、或者有非常严格的延迟 SLO通用框架的默认策略可能不是最优的而框架本身又不允许你改到那么深。第三类是成本敏感。当推理量足够大时哪怕 10% 的效率提升换算成 GPU 成本都是天文数字。这时候自建带来的定制化收益能覆盖掉研发和维护成本。第四类是技术自主。这个不用多说核心链路上依赖外部框架在极端情况下会有风险。智谱的情况基本是这几类的叠加。所以他们的选择不是为了自建而自建而是规模、负载、成本三者共同把自建推到了划算的那一侧。2.3 一个务实的判断框架我给一个自己常用的判断表你可以对照自己的情况打分维度倾向用现成方案倾向自建集群规模千卡以内万卡以上负载特征通用对话、常规 RAG超长上下文、MoE、特殊 SLO团队能力无底层优化经验有 CUDA/通信/调度积累成本压力推理量中等推理量巨大效率即成本迭代节奏快速上线优先长期优化优先如果五个维度里你有三个以上落在右边自建才值得认真考虑。否则把 SGLang 调优到极致收益往往比自研更大。3. 推理引擎里真正决定性能的几个环节不管自建还是用现成的性能瓶颈总是出在那么几个地方。这部分我把推理引擎的核心环节拆开讲顺便说说智谱这类自建方案通常会在哪里做文章。3.1 显存管理KV Cache 是主战场推理服务的显存基本被三样东西占着模型权重、KV Cache、激活值。其中KV Cache 是变量最大、最值得优化的部分。它的计算公式大致是KV Cache 大小 2 × 层数 × 注意力头数 × head_dim × 序列长度 × batch_size × 精度字节数以常见的 70B 模型、FP16 为例单 token 的 KV Cache 大概在几百 KB 量级。如果并发 100 个请求、每个请求上下文 8K光 KV Cache 就要吃掉几十 GB。这就是为什么长上下文和高并发很难同时满足。优化 KV Cache 的常见手段有这么几层分页管理把 KV Cache 切成固定大小的 block按需分配避免预分配造成的浪费。PagedAttention 就是这个思路。前缀共享多个请求如果有相同前缀比如同一个 system prompt可以共享这部分 KVRadixAttention 做的是这件事。量化把 KV Cache 从 FP16 压到 INT8 甚至更低显存直接减半代价是精度损失需要评估。驱逐与换出把不活跃的 KV 换到 CPU 内存甚至 SSD需要时再换回来适合超长上下文。自建方案在这里的优势是可以针对自己的负载特征定制策略。比如你的业务里前缀重复率特别高就可以把前缀缓存的粒度做得更细、命中率做得更高如果你的请求长度分布很集中block size 就可以调得更贴合。3.2 批处理策略连续批处理是基础调度才是上限连续批处理现在已经是标配了它的核心思想是不等一个 batch 里所有请求都结束只要有请求完成就立刻把新请求塞进去让 GPU 始终有活干。这个机制把 GPU 利用率从等最慢的请求提升到了动态填满。但连续批处理只是基础真正拉开差距的是调度策略。几个关键决策点请求优先级交互式请求和批处理请求混在一起时怎么保证交互式的延迟抢占与恢复显存不够时抢占哪个请求被抢占的请求怎么恢复长度感知调度长请求和短请求怎么搭配才能既填满 batch 又不让短请求被长请求拖死chunked prefill把长请求的 prefill 阶段切成小块和 decode 阶段交错执行避免长 prefill 阻塞其他请求的 decode。智谱在调度上大概率做了不少定制因为调度是自建栈里收益最直接、也最依赖业务理解的部分。通用框架的调度器要照顾所有场景往往偏保守自建可以针对自己的流量模型做激进优化。3.3 并行策略TP、PP、EP 怎么选大模型推理绕不开并行。三种主要并行方式各有适用场景并行方式切分维度优点缺点适用场景张量并行 TP切权重矩阵延迟低通信频繁跨机损耗大单机内多卡流水线并行 PP切层通信少有气泡延迟高跨机、大模型专家并行 EP切 MoE 专家适合 MoEall-to-all 通信重MoE 模型实际部署里通常是组合使用比如单机内 TP8跨机用 PP 或 EP。关键难点在于通信和计算的重叠——如果通信不能藏在计算后面GPU 就会空等。这需要精细的流水线设计和通信原语优化也是自建栈能做出差异的地方。MoE 模型还有个特殊问题专家负载不均。热门专家会被打爆冷门专家闲着。解决思路包括专家复制、请求路由时的负载感知、以及动态调整专家分布。这些在通用框架里支持有限自建可以做得更细。3.4 一个容易被忽略的点Python 开销很多人优化推理只盯着 GPU忽略了 CPU 侧。实际上在高速推理场景下Python 的调度开销、序列化开销、GIL 争用都可能成为瓶颈。尤其是当单步计算时间被压到很短之后CPU 侧的调度如果跟不上GPU 就会周期性空转。常见的应对手段把关键路径用 C/Rust 重写、用异步 IO 减少阻塞、把 tokenizer 和采样逻辑移出主循环、用零拷贝减少数据搬运。这些工作在通用框架里往往不是重点但自建栈可以针对性地做。4. Infra Agent把运维经验变成自动化能力Infra Agent这个词在材料里出现值得单独拎出来讲。我的理解是它指的是用智能化的方式管理推理基础设施把过去靠人盯、靠脚本处理的运维工作变成自动化的决策和执行。4.1 十万卡规模下人工运维是不可能的先算一笔账十万卡集群假设每天有 0.5% 的卡出现各种异常这个比例在超大规模下不算夸张那就是每天 500 张卡需要处理。如果每张卡都要人工介入运维团队直接崩溃。所以故障的检测、隔离、恢复必须自动化。推理场景比训练更苛刻的地方在于训练可以 checkpoint 重启推理不行。用户请求正在处理中节点挂了请求怎么办必须做到快速检测秒级发现节点异常而不是等心跳超时请求重路由把受影响请求转到健康节点尽量不丢状态恢复如果用了 KV Cache 换出等机制要能恢复上下文优雅降级实在恢复不了也要给用户明确反馈而不是卡死。4.2 Agent 化运维的几个层次我把这类 Infra Agent 的能力分成几个层次从低到高第一层是监控告警。这是基础把指标采集、异常检测、告警通知做扎实。看起来简单但在十万卡规模下指标的量级和采集频率本身就是工程挑战。第二层是自动修复。检测到问题后自动执行预案比如重启服务、摘除节点、切换流量。这一层需要预案足够完备且执行要幂等、可回滚。第三层是根因分析。不只是发现问题还要定位问题。比如吞吐下降是哪个环节的问题是某批节点通信异常还是某个专家过载还是上游流量突增这需要把全链路的可观测性打通。第四层是预测与优化。基于历史数据预测容量需求、提前扩容、动态调整资源分配。这一层最接近智能也最难做。智谱提到的 Infra Agent我猜至少覆盖了前两层可能在某些场景做到了第三层。对大多数团队来说先把前两层做扎实收益就已经很大了不必一上来就追求智能。4.3 一个实操建议从可观测性开始如果你也想往这个方向走我的建议是先把可观测性做透。具体来说指标要全GPU 利用率、显存占用、通信耗时、队列长度、TTFT、TPOT每 token 输出时间、请求成功率一个都不能少粒度要细能下钻到单卡、单请求级别否则定位问题时会抓瞎采样要合理全量采集成本太高关键指标高频、次要指标低频做好聚合链路要通从请求入口到 GPU 执行整条链路能串起来看否则你只能看到慢看不到哪里慢。这套东西搭起来之后很多优化机会会自己浮现出来——你会发现瓶颈根本不用猜数据直接告诉你。5. 从这份材料里能抄走的具体做法前面讲了不少原理这部分我挑几个可以直接借鉴的点说说怎么落地。5.1 先建立性能基线再谈优化任何优化都要有基线。我见过太多团队优化了半天最后说不清到底提升了多少因为一开始就没测准。建立基线的要点固定测试集用真实流量的采样或者构造有代表性的合成数据覆盖长短请求、不同并发固定环境同样的硬件、同样的模型、同样的参数否则对比没意义多轮测量性能测试波动很大单次结果不可信至少跑三轮取稳定值记录完整指标不只是吞吐还有延迟分布P50/P90/P99、GPU 利用率、显存峰值。基线建好之后每次优化都对照基线看才能知道方向对不对。5.2 用 profiling 找瓶颈而不是靠猜性能优化的第一原则是测量优先于猜测。常用的 profiling 手段PyTorch Profiler看算子级别的耗时找出热点Nsight Systems / Nsight Compute看 GPU 侧的 kernel 执行、通信、空转自定义埋点在关键路径上打时间戳看各阶段耗时占比。一个典型的发现是你以为瓶颈在计算结果 profiling 显示 GPU 有 30% 时间在等通信或者 20% 时间在等 CPU 调度。不测就改大概率改错地方。5.3 优化要有优先级先啃大头优化机会通常符合二八定律少数几个环节贡献了大部分损耗。我的排序经验是先看 GPU 利用率如果利用率低于 70%说明有大量空转先找空转原因再看通信占比并行场景下通信往往是隐形杀手尤其是跨机通信然后看调度效率队列是否经常空、batch 是否经常填不满最后看单算子优化kernel 融合、量化这些收益相对小但确定性高。按这个顺序通常能快速拿到第一波收益再逐步深入。5.4 故障处理要当成一等公民在规模上去之后故障处理不是锦上添花而是决定能不能用。几个实操要点健康检查要快心跳间隔、超时阈值要调优太慢发现不了问题太快误报多摘除要果断宁可误摘不可漏摘因为一个坏节点可能拖垮整个 batch恢复要幂等重试逻辑要保证重复执行不出错演练要定期主动注入故障验证预案是否有效别等真出事才发现预案是纸上谈兵。6. 这套打法不适合谁以及常见的误判最后聊聊边界。自建推理基础设施不是万能药有几类情况我建议谨慎。6.1 规模不够时自建是负收益如果你的推理量还没到效率提升能覆盖研发成本的程度自建就是纯亏。研发一个能打的推理引擎投入是几十人月起步还要持续维护。在规模不够的时候把这些人力投到业务上回报高得多。6.2 团队没有底层能力时别硬上推理引擎涉及 CUDA、通信、分布式系统、编译优化等多个硬核领域。如果团队里没有相关积累自建的结果往往是能跑但很慢还不如调好的开源方案。先招人或者先积累再谈自建。6.3 别把自建当成目标我见过一些团队把自研推理引擎当成技术实力的象征为了自建而自建。这是本末倒置。自建是手段不是目的。目的是更低的成本、更好的体验、更强的可控性。如果现成方案能达到目的就没必要自建。6.4 一个常见的误判以为优化是一次性的性能优化不是做完就完了而是持续的过程。业务在变、模型在变、硬件在变今天的优化明天可能就失效了。所以自建栈必须配套持续的观测和迭代机制否则很快会退化。这也是为什么 Infra Agent 这类自动化能力很重要——它让持续优化变得可持续。回头看智谱这份材料两周三倍和十万卡这两个数字背后是一整套从引擎到调度到运维的体系化能力。单看任何一个点都不新鲜难的是把它们组合起来、在极端规模下跑通。对大多数团队来说不必照搬全套但里面关于性能观测、调度定制、故障自动化的思路是可以直接借鉴的。我自己在做推理优化时最大的体会就是先把数据测准再谈优化先把故障处理好再谈性能。顺序反了做多少都是白费。
智谱GLM自建推理基础设施：两周吞吐提升三倍与十万卡集群实践
两周时间把推理吞吐拉高三倍还要扛住十万卡级别的集群规模——这个数字组合放在任何一家做大模型推理的团队面前都足够让人停下来多看两眼。智谱这次公开的《GLM如何自建推理基础设施》里最抓人的其实不是三倍这个结果而是他们选择了一条和主流拿来即用完全不同的路自建推理引擎、自研调度、自己啃底层。我前后把这份材料翻了几遍结合自己在推理服务上踩过的坑聊聊这套东西到底解决了什么问题、哪些思路可以直接抄、哪些地方是别人学不来的。如果你正在做推理服务的性能优化或者纠结要不要从现成方案切换到自建栈又或者只是好奇十万卡这种规模下推理到底难在哪这篇解读应该能给你一些能落地的参考。我会尽量把里面涉及的核心技术点——推理引擎、调度、并行策略、Infra Agent 这些——拆开讲清楚同时补上原文没细说但实操中一定会遇到的东西。1. 为什么两周三倍这个说法值得认真对待先把结论摆前面推理吞吐提升三倍在已经调优过的生产系统上是一件非常难的事。很多人对推理优化的想象是换个更快的引擎就行但真实情况是当一个推理服务已经跑在成熟框架上、显存打满、batch 也调过之后你能榨出来的空间通常只有百分之十几到几十。三倍这个量级意味着不是某个单点优化而是整条链路上多个环节同时被重新设计过。1.1 吞吐这个指标本身就有很多坑聊优化之前得先对齐吞吐到底指什么。业内常见的口径有这么几种混着用很容易得出错误结论指标口径含义容易被误用的地方tokens/s总整个集群每秒产出的 token 数忽略延迟堆 batch 就能刷高tokens/s/user单用户视角的生成速度和总吞吐经常互相矛盾requests/s每秒完成的请求数长短请求混合时失真严重goodput满足 SLO 前提下的有效吞吐最接近真实业务价值但最难测智谱提到的三倍吞吐从上下文看更接近在满足延迟约束下的有效吞吐goodput而不是单纯把 batch 拉大刷出来的数字。这个区别很关键如果你只追总 tokens/s把 batch size 从 64 拉到 512数字确实会涨但首 token 延迟TTFT和单用户生成速度会崩掉线上体验直接完蛋。所以看到三倍的时候第一反应应该是问一句在什么延迟约束下测的1.2 两周的时间尺度说明了什么两周不是一个从零开始搭系统的周期而是一个在已有基础上做集中攻坚的周期。这暗示了几件事基础设施集群、网络、存储、监控是现成的团队对业务负载特征有清晰认知优化目标是明确的而不是探索性的。换句话说这两周花在把已知的瓶颈逐个打掉而不是摸索该做什么。我自己做性能攻坚的经验是真正耗时间的从来不是改代码而是定位瓶颈。一个推理服务慢可能是计算瓶颈、可能是显存带宽瓶颈、可能是调度排队、可能是网络通信、也可能是 Python 层的 GIL 或者序列化开销。在没有完善 profiling 的情况下你可能花一周都在猜。所以两周出结果背后大概率有一套成熟的性能观测体系在支撑——这点原文没展开但它是前提。1.3 十万卡规模把问题性质改变了单机 8 卡和十万卡集群完全是两个物种的问题。规模上去之后会出现一些在小规模下根本不存在或者可以忽略的现象通信占比飙升张量并行、流水线并行、专家并行带来的 all-reduce、all-to-all 通信在万卡级别会吃掉大量时间通信和计算的重叠overlap做不好GPU 利用率直接腰斩。故障成为常态十万卡意味着每天都有卡在坏。推理服务不能像训练那样 checkpoint 重启必须做到故障时快速摘除、请求重路由用户几乎无感。调度复杂度爆炸请求怎么分配到不同节点、如何做负载均衡、如何处理热点专家MoE 场景这些在单机上是 trivial 的问题在集群级别是核心难题。显存碎片与 KV Cache 管理长上下文场景下 KV Cache 会吃掉大量显存十万卡级别的显存管理策略直接决定能跑多长的上下文、能并发多少请求。理解了这三点再看自建推理基础设施这个选择就顺理成章了——通用框架很难同时满足这种规模和这种定制化需求。2. 自建推理栈 vs 现成方案这笔账怎么算这是很多人最关心的问题市面上已经有 SGLang、vLLM 这些成熟的开源推理引擎为什么还要自建我先把这个问题拆成什么时候该用现成的和什么时候该自建两个子问题。2.1 现成引擎已经解决了 80% 的问题必须承认SGLang 和 vLLM 这类项目已经把推理引擎的通用问题解决得相当好了。它们提供的核心能力包括PagedAttention / RadixAttention这类显存管理机制把 KV Cache 的碎片问题基本解决连续批处理continuous batching让不同长度的请求可以动态拼批大幅提升 GPU 利用率前缀缓存prefix caching对多轮对话、few-shot 场景效果显著张量并行单机多卡开箱即用OpenAI 兼容 API接入成本极低。对绝大多数团队来说直接用 SGLang 或 vLLM 是性价比最高的选择。你不需要懂 CUDA kernel不需要懂通信原语配好参数就能跑出一个相当不错的服务。我见过不少团队一上来就想着自研结果半年过去性能还不如调好的 vLLM这是典型的重复造轮子。2.2 什么情况下自建才划算自建的门槛很高但确实有几类场景是现成方案覆盖不好的第一类是规模极端。十万卡这种量级通用框架的调度器、通信策略、故障处理往往不是为这个规模设计的。比如默认的负载均衡策略在几千卡上够用到万卡级别可能因为元数据同步延迟导致热点。第二类是负载特征特殊。如果你的业务是超长上下文比如几十万 token、或者 MoE 模型专家分布极不均匀、或者有非常严格的延迟 SLO通用框架的默认策略可能不是最优的而框架本身又不允许你改到那么深。第三类是成本敏感。当推理量足够大时哪怕 10% 的效率提升换算成 GPU 成本都是天文数字。这时候自建带来的定制化收益能覆盖掉研发和维护成本。第四类是技术自主。这个不用多说核心链路上依赖外部框架在极端情况下会有风险。智谱的情况基本是这几类的叠加。所以他们的选择不是为了自建而自建而是规模、负载、成本三者共同把自建推到了划算的那一侧。2.3 一个务实的判断框架我给一个自己常用的判断表你可以对照自己的情况打分维度倾向用现成方案倾向自建集群规模千卡以内万卡以上负载特征通用对话、常规 RAG超长上下文、MoE、特殊 SLO团队能力无底层优化经验有 CUDA/通信/调度积累成本压力推理量中等推理量巨大效率即成本迭代节奏快速上线优先长期优化优先如果五个维度里你有三个以上落在右边自建才值得认真考虑。否则把 SGLang 调优到极致收益往往比自研更大。3. 推理引擎里真正决定性能的几个环节不管自建还是用现成的性能瓶颈总是出在那么几个地方。这部分我把推理引擎的核心环节拆开讲顺便说说智谱这类自建方案通常会在哪里做文章。3.1 显存管理KV Cache 是主战场推理服务的显存基本被三样东西占着模型权重、KV Cache、激活值。其中KV Cache 是变量最大、最值得优化的部分。它的计算公式大致是KV Cache 大小 2 × 层数 × 注意力头数 × head_dim × 序列长度 × batch_size × 精度字节数以常见的 70B 模型、FP16 为例单 token 的 KV Cache 大概在几百 KB 量级。如果并发 100 个请求、每个请求上下文 8K光 KV Cache 就要吃掉几十 GB。这就是为什么长上下文和高并发很难同时满足。优化 KV Cache 的常见手段有这么几层分页管理把 KV Cache 切成固定大小的 block按需分配避免预分配造成的浪费。PagedAttention 就是这个思路。前缀共享多个请求如果有相同前缀比如同一个 system prompt可以共享这部分 KVRadixAttention 做的是这件事。量化把 KV Cache 从 FP16 压到 INT8 甚至更低显存直接减半代价是精度损失需要评估。驱逐与换出把不活跃的 KV 换到 CPU 内存甚至 SSD需要时再换回来适合超长上下文。自建方案在这里的优势是可以针对自己的负载特征定制策略。比如你的业务里前缀重复率特别高就可以把前缀缓存的粒度做得更细、命中率做得更高如果你的请求长度分布很集中block size 就可以调得更贴合。3.2 批处理策略连续批处理是基础调度才是上限连续批处理现在已经是标配了它的核心思想是不等一个 batch 里所有请求都结束只要有请求完成就立刻把新请求塞进去让 GPU 始终有活干。这个机制把 GPU 利用率从等最慢的请求提升到了动态填满。但连续批处理只是基础真正拉开差距的是调度策略。几个关键决策点请求优先级交互式请求和批处理请求混在一起时怎么保证交互式的延迟抢占与恢复显存不够时抢占哪个请求被抢占的请求怎么恢复长度感知调度长请求和短请求怎么搭配才能既填满 batch 又不让短请求被长请求拖死chunked prefill把长请求的 prefill 阶段切成小块和 decode 阶段交错执行避免长 prefill 阻塞其他请求的 decode。智谱在调度上大概率做了不少定制因为调度是自建栈里收益最直接、也最依赖业务理解的部分。通用框架的调度器要照顾所有场景往往偏保守自建可以针对自己的流量模型做激进优化。3.3 并行策略TP、PP、EP 怎么选大模型推理绕不开并行。三种主要并行方式各有适用场景并行方式切分维度优点缺点适用场景张量并行 TP切权重矩阵延迟低通信频繁跨机损耗大单机内多卡流水线并行 PP切层通信少有气泡延迟高跨机、大模型专家并行 EP切 MoE 专家适合 MoEall-to-all 通信重MoE 模型实际部署里通常是组合使用比如单机内 TP8跨机用 PP 或 EP。关键难点在于通信和计算的重叠——如果通信不能藏在计算后面GPU 就会空等。这需要精细的流水线设计和通信原语优化也是自建栈能做出差异的地方。MoE 模型还有个特殊问题专家负载不均。热门专家会被打爆冷门专家闲着。解决思路包括专家复制、请求路由时的负载感知、以及动态调整专家分布。这些在通用框架里支持有限自建可以做得更细。3.4 一个容易被忽略的点Python 开销很多人优化推理只盯着 GPU忽略了 CPU 侧。实际上在高速推理场景下Python 的调度开销、序列化开销、GIL 争用都可能成为瓶颈。尤其是当单步计算时间被压到很短之后CPU 侧的调度如果跟不上GPU 就会周期性空转。常见的应对手段把关键路径用 C/Rust 重写、用异步 IO 减少阻塞、把 tokenizer 和采样逻辑移出主循环、用零拷贝减少数据搬运。这些工作在通用框架里往往不是重点但自建栈可以针对性地做。4. Infra Agent把运维经验变成自动化能力Infra Agent这个词在材料里出现值得单独拎出来讲。我的理解是它指的是用智能化的方式管理推理基础设施把过去靠人盯、靠脚本处理的运维工作变成自动化的决策和执行。4.1 十万卡规模下人工运维是不可能的先算一笔账十万卡集群假设每天有 0.5% 的卡出现各种异常这个比例在超大规模下不算夸张那就是每天 500 张卡需要处理。如果每张卡都要人工介入运维团队直接崩溃。所以故障的检测、隔离、恢复必须自动化。推理场景比训练更苛刻的地方在于训练可以 checkpoint 重启推理不行。用户请求正在处理中节点挂了请求怎么办必须做到快速检测秒级发现节点异常而不是等心跳超时请求重路由把受影响请求转到健康节点尽量不丢状态恢复如果用了 KV Cache 换出等机制要能恢复上下文优雅降级实在恢复不了也要给用户明确反馈而不是卡死。4.2 Agent 化运维的几个层次我把这类 Infra Agent 的能力分成几个层次从低到高第一层是监控告警。这是基础把指标采集、异常检测、告警通知做扎实。看起来简单但在十万卡规模下指标的量级和采集频率本身就是工程挑战。第二层是自动修复。检测到问题后自动执行预案比如重启服务、摘除节点、切换流量。这一层需要预案足够完备且执行要幂等、可回滚。第三层是根因分析。不只是发现问题还要定位问题。比如吞吐下降是哪个环节的问题是某批节点通信异常还是某个专家过载还是上游流量突增这需要把全链路的可观测性打通。第四层是预测与优化。基于历史数据预测容量需求、提前扩容、动态调整资源分配。这一层最接近智能也最难做。智谱提到的 Infra Agent我猜至少覆盖了前两层可能在某些场景做到了第三层。对大多数团队来说先把前两层做扎实收益就已经很大了不必一上来就追求智能。4.3 一个实操建议从可观测性开始如果你也想往这个方向走我的建议是先把可观测性做透。具体来说指标要全GPU 利用率、显存占用、通信耗时、队列长度、TTFT、TPOT每 token 输出时间、请求成功率一个都不能少粒度要细能下钻到单卡、单请求级别否则定位问题时会抓瞎采样要合理全量采集成本太高关键指标高频、次要指标低频做好聚合链路要通从请求入口到 GPU 执行整条链路能串起来看否则你只能看到慢看不到哪里慢。这套东西搭起来之后很多优化机会会自己浮现出来——你会发现瓶颈根本不用猜数据直接告诉你。5. 从这份材料里能抄走的具体做法前面讲了不少原理这部分我挑几个可以直接借鉴的点说说怎么落地。5.1 先建立性能基线再谈优化任何优化都要有基线。我见过太多团队优化了半天最后说不清到底提升了多少因为一开始就没测准。建立基线的要点固定测试集用真实流量的采样或者构造有代表性的合成数据覆盖长短请求、不同并发固定环境同样的硬件、同样的模型、同样的参数否则对比没意义多轮测量性能测试波动很大单次结果不可信至少跑三轮取稳定值记录完整指标不只是吞吐还有延迟分布P50/P90/P99、GPU 利用率、显存峰值。基线建好之后每次优化都对照基线看才能知道方向对不对。5.2 用 profiling 找瓶颈而不是靠猜性能优化的第一原则是测量优先于猜测。常用的 profiling 手段PyTorch Profiler看算子级别的耗时找出热点Nsight Systems / Nsight Compute看 GPU 侧的 kernel 执行、通信、空转自定义埋点在关键路径上打时间戳看各阶段耗时占比。一个典型的发现是你以为瓶颈在计算结果 profiling 显示 GPU 有 30% 时间在等通信或者 20% 时间在等 CPU 调度。不测就改大概率改错地方。5.3 优化要有优先级先啃大头优化机会通常符合二八定律少数几个环节贡献了大部分损耗。我的排序经验是先看 GPU 利用率如果利用率低于 70%说明有大量空转先找空转原因再看通信占比并行场景下通信往往是隐形杀手尤其是跨机通信然后看调度效率队列是否经常空、batch 是否经常填不满最后看单算子优化kernel 融合、量化这些收益相对小但确定性高。按这个顺序通常能快速拿到第一波收益再逐步深入。5.4 故障处理要当成一等公民在规模上去之后故障处理不是锦上添花而是决定能不能用。几个实操要点健康检查要快心跳间隔、超时阈值要调优太慢发现不了问题太快误报多摘除要果断宁可误摘不可漏摘因为一个坏节点可能拖垮整个 batch恢复要幂等重试逻辑要保证重复执行不出错演练要定期主动注入故障验证预案是否有效别等真出事才发现预案是纸上谈兵。6. 这套打法不适合谁以及常见的误判最后聊聊边界。自建推理基础设施不是万能药有几类情况我建议谨慎。6.1 规模不够时自建是负收益如果你的推理量还没到效率提升能覆盖研发成本的程度自建就是纯亏。研发一个能打的推理引擎投入是几十人月起步还要持续维护。在规模不够的时候把这些人力投到业务上回报高得多。6.2 团队没有底层能力时别硬上推理引擎涉及 CUDA、通信、分布式系统、编译优化等多个硬核领域。如果团队里没有相关积累自建的结果往往是能跑但很慢还不如调好的开源方案。先招人或者先积累再谈自建。6.3 别把自建当成目标我见过一些团队把自研推理引擎当成技术实力的象征为了自建而自建。这是本末倒置。自建是手段不是目的。目的是更低的成本、更好的体验、更强的可控性。如果现成方案能达到目的就没必要自建。6.4 一个常见的误判以为优化是一次性的性能优化不是做完就完了而是持续的过程。业务在变、模型在变、硬件在变今天的优化明天可能就失效了。所以自建栈必须配套持续的观测和迭代机制否则很快会退化。这也是为什么 Infra Agent 这类自动化能力很重要——它让持续优化变得可持续。回头看智谱这份材料两周三倍和十万卡这两个数字背后是一整套从引擎到调度到运维的体系化能力。单看任何一个点都不新鲜难的是把它们组合起来、在极端规模下跑通。对大多数团队来说不必照搬全套但里面关于性能观测、调度定制、故障自动化的思路是可以直接借鉴的。我自己在做推理优化时最大的体会就是先把数据测准再谈优化先把故障处理好再谈性能。顺序反了做多少都是白费。
