看到MLSys 2026上PIKE这个标题，第一反应是“多智能体 + 推理加速 + 2.88倍”这几个词组合在一起，确实有点反差感。PyTorch推理优化在业内早不是新话题，torch.compile、TensorRT、CUDAGraphs哪一个拿出来都能讲一堆，但“多智能体”这个定语在这里不是加个噱头，而是代表了一套新的优化思路：不再由人手工指定融合规则、也不靠单一编译器做端到端变换，而是把“分析计算图、找瓶颈、生成算子、验证收益”这些环节拆给不同角色的智能体分工协作，让优化过程本身具备自适应和可扩展性。
这篇文章我不想复述论文摘要，而是把PIKE这类系统拆开揉碎：先看Eager模式推理到底慢在哪，再看多智能体为什么适合干这件事，然后分析2.88倍这个数字背后都来自哪些优化空间，最后落到实际操作——即使你暂时用不上完整的智能体框架，也能从这套思路里提炼出一份能直接用在自研推理服务上的优化优先级清单。顺便把我自己在做推理加速benchmark时踩过的坑也一起交代清楚。
1. Eager模式为什么慢：一次推理调用里的大部分时间都去哪了
要理解PIKE这类系统的价值，先得理解它对比的基线——PyTorch Eager模式——为什么慢。很多人一听到“PyTorch推理慢”就直觉归因于“Python循环慢”“GIL锁”“算子没有融合”，这个方向没错，但不够精确。你只有把Eager模式下时间消耗的构成拆到微秒级，才能明白2.88倍到底从哪来。
1.1 每一次算子的“完整旅程”远比你想象的长
在Eager模式下，你调用self.conv(x)时发生的完整链路大致是：
- Python层的
nn.Module.__call__进入forward，这里已经有Python函数调用开销； - 进入底层C++ dispatcher，根据tensor的device、dtype、layout等属性做dispatch逻辑判断；
- 根据dispatch key解析到对应的kernel实现；
- 完成必要的shape、stride推导，检查尺寸合法性；
- kernel实际执行。如果是GPU算子，这一步内部还包含CPU端launch操作，由CPU向GPU提交kernel launch命令；
- 返回结果，如果产生了中间tensor且没有显存复用，还会涉及缓存的分配/释放。
一个conv算子的GPU kernel实际执行时间在几微秒到几十微秒之间（取决于输入尺寸），但CPU端的launch开销、Python层调用开销、dispatch开销加起来，往往和kernel执行时间处于同一数量级，甚至更高。这就导致一个后果：模型层数越深、算子越小、batch越小，计算时间占比越低，Eager模式引入的固定开销占比越高。很多小模型在GPU上推理时实际GPU利用率不到30%，剩下的时间都在等待CPU指令和kernel提交。
1.2 内存分配是被严重低估的隐形杀手
另一个容易被忽略的点是中间tensor的分配。Eager模式中每个算子都产生新的输出tensor，如果把PyTorch的caching allocator比作一个缓存仓库，它的“命中”并不总是完美。动态shape、不同分支、padding变化都会导致缓存块不匹配，产生新的cudaMalloc调用。一个典型的ResNet推理中可能有几百次tensor分配，cudaMalloc的代价比大多数人想的高一个量级。
这就解释了两个常见现象：一是为什么把torch.no_grad()加上、又开了torch.inference_mode()，提升仍然有限——你只是少了一部分自动求导相关的bookkeeping，但dispatch和alloc开销还在；二是为什么在显存足够的情况下反复推理，时间也不稳定——分配器缓存状态不同。
1.3 编译器模式解决了一部分，但没有解决全部
torch.compile的出现就是为了解决Eager模式的这些固定开销，通过图捕获、算子融合、Triton kernel生成等方式减少launch次数、消除中间tensor。它的效果在小模型和小batch上非常显著，实测确实能达到1.5到3倍。但torch.compile也有它的边界：编译时间不可控、某些动态控制流不兼容、自定义算子支持有限，而且它本质上是“人来定义优化规则、编译器去匹配执行”。当规则覆盖不到你的网络结构时，收益就上不去。
PIKE这类多智能体系统的核心差异就在这里：它不再是“规则匹配 + 模板生成”的固定管线，而是把整个优化过程变成多角色分工协作的“团队任务”，每个角色负责一块优化空间，互相提供信息、验证结果，形成一个持续搜索和迭代的闭环。这是我在看到这个标题时觉得最值得展开的部分。
2. 多智能体优化的逻辑：PIKE把优化问题拆成了什么
多智能体在推理加速上的用法，不是一个“大模型agent”在帮你写代码，而是典型的“master-worker”协作范式。每个智能体有自己的观察空间、动作空间和评价指标，多个智能体围绕同一个计算图协同工作，最终产出一个优化后的执行计划。
2.1 五类角色划分与各自的职责边界
从我看到的系统设计思路来推断，PIKE这类框架大概率会把优化流程拆成下面五类角色，分别对应推理优化链条的不同环节：
| 智能体角色 | 核心职责 | 输入信息 | 输出产物 |
|---|---|---|---|
| Profiler/分析智能体 | 找出瓶颈算子、定位时间热点 | 计算图、profiling数据、硬件信息 | 瓶颈清单、热点排名 |
| Pattern/融合智能体 | 发现可融合的计算子图模式 | 计算图结构、算子语义 | 融合候选子图 |
| CodeGen/算子生成智能体 | 为特定子图生成高性能kernel | 融合后子图、硬件特性、Triton/CUDA模板 | 新kernel代码 |
| Scheduler/调度智能体 | 处理执行顺序、stream并行、内存复用、CUDA Graph捕获 | 依赖关系、kernel耗时估计、显存约束 | 执行计划 |
| Verifier/验证智能体 | 校验正确性与收益 | 原始输出、新kernel输出、benchmark结果 | 验证报告、是否采纳的决策 |
这五个角色不是流水线跑一遍就结束，而是多轮迭代。分析智能体发现问题后，融合智能体提出候选，CodeGen生成kernel，Verifier给出“这次改动快了多少、结果是否符合精度要求”的结论，然后分析智能体基于新状态继续找下一个瓶颈。整条链路更像一个持续搜索过程，而不是跑完一篇论文中的静态优化pass。
2.2 为什么多智能体分工比单一编译器更有优势
单一编译器（比如TorchScript的早期实现）最大的痛点是“所有规则都写在同一个代码库里”，新增一种优化策略就要改编译器核心逻辑，而且不同优化pass之间的交互非常复杂。多智能体的分工从架构上规避了这个问题：
- 每个智能体可以独立演进。我已经有了一个更好的Triton kernel模板，不需要重写整个编译器，只需要更新CodeGen智能体的策略库。
- 失败隔离。CodeGen生成的kernel如果验证不通过，Verifier直接打回，不会影响其他已经完成的优化。
- 自适应搜索。同一个模型在不同硬件上的瓶颈可能完全不同（A100上可能launch开销是瓶颈，华为昇腾上可能内存带宽约束更突出），多智能体系统可以根据profiling结果动态调整搜索方向。
2.3 多智能体不是“大模型跑一遍”，关键在评估机制
这里我要特别强调一点：多智能体框架能不能落地，关键不在每个智能体的“智力”，而在智能体之间的通信协议和评估机制。如果Verifier给不出可靠的收益评估，CodeGen就失去了反馈信号；如果Profiler的瓶颈定位不够准，后面所有智能体都在白忙活。
实际系统中，最常看到的做法是为每个候选优化方案维护一张评测表：正确性是否通过、kernel耗时、显存占用、编译时间、鲁棒性（换一个batch size是否仍然成立），然后由调度层按加权分数决定最终执行计划。这种机制带来的好处是，即使某个智能体的判断不完美，只要验证闭环是可靠的，整体系统仍然能收敛到较优解。
3. 2.88倍加速的组成：哪些优化贡献了最大收益
我平时做推理服务优化时会先算一笔账：在调整任何代码之前，先用profiler把这个模型Eager模式下的时间分布拆出来，分成几大类：Python层调度开销、kernel启动开销、kernel计算时间、数据搬运时间、内存分配时间、kernel之间无法重叠的空档。这样做了之后，“2.88倍”这个数字就不再神秘，它本质上等价于把这六类开销里的绝大部分压掉之后的结果。
3.1 第一个大头：kernel启动次数怎么降下来
Eager模式下，一个卷积网络跑一次forward，需要launch的数量等于算子数量加一些辅助操作。对一个ResNet-50来说，这个数字在100个左右。而kernel launch本身就有一个固定成本——把kernel参数、grid/block配置从CPU传到GPU驱动层。
如果把“kernel launch”类比成一次快递发货，单个小算子的计算时间相当于实际路上的运输时间，而launch开销相当于每次发货都要填面单、过安检。100个算子就是100次发货流程，哪怕每个算子只花1微秒执行，10微秒的launch开销也会让整体变成1000微秒。降低这个开销最直接的方式就是算子融合：把多个算子合并成一个kernel，一次launch完成多次计算。比如conv + batch_norm + relu合并成一个kernel，三到四个算子的launch开销变成一次。一个融合充分的网络，launch次数可以从100降到30甚至20。
我推断PIKE这一类系统在2.88倍的贡献里，算子融合带来的收益是第一位的。这不仅是经验判断，也是基本的结构逻辑：Eager模式最固定的开销就是逐算子调度，而融合直接把调度次数降到最低。
3.2 第二个大头：缓存分配和中间张量的消除
融合之后，由于不需要在算子之间传递中间tensor，内存分配次数也同步下降。在Eager模式下，conv -> relu -> pooling这个序列至少产生两次中间tensor分配（conv的输出、relu的输出），融合后直接在kernel内部完成，分配次数降到一次，甚至为零（如果输出可以被预分配buffer复用）。
对显存紧张或是需要高频推理的场景，这一项的收益甚至超过kernel融合本身。因为连续分配释放会打断GPU流水线，让SM的利用率降下来。消除中间tensor后，kernel间的流水线更顺，GPU的吞吐也能拉高。
3.3 第三个大头：CUDA Graph消除kernel launch的剩余抖动
就算做了算子融合，kernel的数量仍然有几十个。CUDA Graph把整张计算图捕获成一个graph，然后通过一次graph launch完成所有kernel的提交。这个模式用在推理场景，等于把成百上千的CPU端调度工作全部在GPU端以图结构编排好，CPU不需要逐个launch。
PIKE这类系统如果把CUDA Graph的捕获环节做得足够好（自动处理动态shape、自动处理显存复用），单单这一项就能让总延迟再降20%到40%。尤其对于batch size固定的在线推理服务，CUDA Graph是所有优化手段里性价比最高的一项。我自己在项目里用CUDA Graph优化一个多分支的推荐模型，延迟下降31%，几乎零代码改动。
3.4 2.88倍适合哪类模型：算力密集度越低，加速比越高
需要明确的是，2.88倍不是一个能套到所有模型上的常数。从标题看，这个数据对应的应该是“有代表性的推理负载”，而不是大模型的极端场景。一个规律我踩过之后记得很清楚：模型计算量越小、算子越短、batch越小，Eager模式的固定开销占比就越高，优化空间越大，加速比越接近2.88倍甚至更高；反过来，如果模型本身是满计算量的卷积网络连续跑很久，kernel计算时间占绝对主导，那么即使调度开销全部清零，加速比也到不了2倍。
所以拿到一个系统宣称的加速比，首先要看它基准模型是什么。如果你的推理任务本身算力密集型已经很高，那不要指望复现它的全部数字；如果你的模型恰好是那种“算子琐碎、每层计算都很轻”的小模型，那么加速比会接近甚至超过论文里的数字。
4. 把PIKE的思路带进自研推理服务：优先级明确的改造路线
我知道多数人看完这种论文标题后最关心的问题还是：我不可能立刻搭一套多智能体系统出来，但能不能从它的思路上提炼出一些马上能做的事情？能，而且优先级非常明确。其实PIKE这套多智能体系统的本质逻辑就是“先定位瓶颈，再针对瓶颈选优化手段”，这个逻辑完全可以手工复刻，只是它把它自动化了。
4.1 第一步：用profiler找到你的Top 10耗时算子
先不要急着上任何优化工具，先搞清楚你的模型在Eager模式下时间花在哪里。我用的是torch.profiler.profile，每次都把activities打开CUDA相关的profiling，同时记录CPU time和GPU time。核心看几个指标：
Self CPU time：CPU端调度耗时，反映Python/dispatch/launch开销；CUDA time：GPU端kernel实际耗时；CUDA activity里kernel的launch次数；- 每个tensor的
alloc/free次数，对应内存分配开销。
这个过程相当重要。我见过一个项目团队花了两个星期在优化某个kernel实现上，最后profiling发现那个kernel只占整体延迟的6%，真正的瓶颈是一个在循环里反复执行的小张量拷贝。连问题都没定位对，后面所有优化都是在做无用功。
4.2 第二步：按收益排序的优化手段清单
完成profiling之后，按照优先级把下面的优化手段逐个应用，每做完一个就重新profiling确认收益：
- 开启
torch.inference_mode：这是成本最低的一步，省去autograd相关的tracking开销。如果你还在用torch.no_grad()，建议换成inference_mode，两者在推理加速上的差异在Eager模式下实测可以差到5%以上。 - 用
torch.compile做无脑版本：先直接model = torch.compile(model)看收益。对多数常见模型，这一两步就能拿到1.5到2.5倍的提升。如果编译失败或收益不明显，说明模型里有动态shape或者自定义算子阻断了图优化，这时候进入下一步。 - 手动算子融合：把最具连续性的算子组合（
conv + bn + act、linear + act、multi-head attention内部的matmul + softmax + matmul）写成自定义的Triton kernel或直接用已有的融合库。注意，这一步只做高频热点，别把整个网络都手工重写。 - CUDA Graph捕获：如果你的模型输入shape固定、无动态分支，直接调用
torch.cuda.graphs.CUDAGraph捕获完整推理过程。这是收益最大也最容易实现的一项，替换后推理延迟能再降20%到40%。 - 服务侧连续batch与显存预分配：在在线服务场景下，确保请求能够连续执行，batch内部不出现频繁的显存增长/释放。用静态显存池，而不是每次请求都重新分配。
下面给一个最简CUDA Graph迭代的代码骨架，方便直接复用：
import torch class CudaGraphInference: def __init__(self, model, sample_input): # 预热：确保caching allocator、cuDNN autotune状态就绪 for _ in range(10): model(sample_input) torch.cuda.synchronize() # 静态输入buffer要与捕获时完全一致 self.static_input = sample_input.clone() self.static_output = None self.graph = None # 捕获graph g = torch.cuda.CUDAGraph() with torch.cuda.graph(g): self.static_output = model(self.static_input) torch.cuda.synchronize() self.graph = g def infer(self, input_tensor): # 将真实输入拷贝到静态buffer，再回放graph self.static_input.copy_(input_tensor) self.graph.replay() return self.static_output注意几个容易踩的细节：捕获前必须保证分配器状态稳定（预热的目的就在于此）；copy_的输入shape必须和静态buffer完全一致，否则会触发重分配导致graph失效；多stream场景下还要注意torch.cuda.graph不能和其他stream混用。
4.3 第三步：针对“多智能体”思路的轻量级借鉴
如果想把PIKE的多智能体思路以手工方式沉淀到团队里，建议维护一份“优化知识库”，每个优化手段按以下字段沉淀：适用模型类型、预期收益范围、实现复杂度、依赖条件、验证方式。接着定义好profiling与优化手段之间的映射规则：热点是kernel launch次数过高？对应算子融合。热点是内存分配频繁？对应buffer复用或CUDA Graph。热点是kernel之间存在明显气泡？对应stream并行或图融合。
这么做一段时间后，你的团队实际上就在用一套“规则智能体”来加速推理优化决策了——每个成员依据知识库针对不同场景选择策略。等到规则积累到一定量级，再去尝试用自动化的智能体替代人工判断就有了基础。
5. 复现和验证加速比时的三个典型误区
最后这部分我特别想写，因为这两年我在优化推理服务时发现，很多人做的benchmark完全不可靠，甚至会把一个负优化当成正收益记录下来。下面三个误区是我自己在实践中踩过、也看同事反复踩的：
5.1 预热不充分，把CUDA缓存的冷启动成本算进“推理延迟”里
PyTorch的caching allocator和cuDNN autotune都有“冷启动”阶段。第一次执行时，cuDNN会跑多个候选算法做benchmark选择最优，caching allocator的缓存也没建立起来，此时测出的延迟会比稳定状态高很多，甚至高50%以上。
正确做法是：统一预热10次以上，torch.cuda.synchronize()后再记录时间；正式计时时多次运行取中位数或均值，并且至少跑50次以上。我个人的习惯是每次benchmark前先在单独进程里跑10次，确认GPU频率稳定之后再进行正式计时。
5.2 对比Eager模式时用了不同的精度或输出
这类问题更隐蔽。我自己就犯过一次：Eager模式下用FP32推理，优化后不小心切到了FP16，然后延迟确实降了接近一半，看起来像“优化成功”，实际上大部分收益来自精度降低。反过来也有风险：FP16的kernel在某些老GPU上反而比FP32慢。
正确做法是：在benchmark代码里显式断言优化前后输出张量的dtype和shape一致，并且对精度做一个校验（比如max_abs_error和cosine_similarity）。把精度校验写进自动化测试，比人肉盯有效得多。
5.3 只测batch=1和小shape，完全脱离线上真实情况
推理加速的效果和batch size高度相关。batch=1时launch overhead占比极高，CUDA Graph和算子融合能带来2倍以上收益；但batch增大到32以上时，kernel计算时间占比大幅提升，融合收益可能降到1.2倍。如果你的线上实际是batch=16的推理，却拿batch=1的benchmark来证明优化有效，那后面上线一定会被打脸。
正确做法是：同时测多组batch size和shape，覆盖线上真实分布，并且关注P99/P95延迟而不是只关注平均延迟。在线推理场景中，长尾延迟对用户体验的影响远大于平均值。
还有一个常被忽略的检查点：优化后的推理代码必须跑在真实推理框架中验证整体延迟，不要单独抽一个模型孤零零测。服务端的线程调度、CPU和GPU之间的数据搬运、前处理和后处理的耗时，都会直接影响优化收益能否落到线上。
6. 我自己在推理优化上的一些体会
回到PIKE这个系统本身，它的价值不只是“多了一个能加速2.88倍的框架”，更重要的是它示范了一种做推理优化时应该具备的工作范式：先精细度量，再自动化搜索，最后验证闭环。没有profiling就没有优化方向，没有验证就没有优化结论，这是我在实际项目里反复被证明的事情。
如果你短期内没有条件引入完整的多智能体系统，那就先把基础工作做扎实。把Eager模式的耗时构成摸清楚，用上一节里提到的全套优化手段跑一遍，大多数场景下你能拿到比2.88倍小一点但已经很可观的提升。而当你积累的优化规则越来越多，自然就会理解PIKE这类系统为什么要用多智能体来承担这些工作——因为人工维护几百条优化规则的组合逻辑，本身就是一件极其脆弱和费力的事情。
最后分享一个实用的小技巧：每次优化完成后，别只记录“延迟降低了多少”，要把完整的运行环境记下来，包括GPU型号、驱动版本、CUDA版本、PyTorch版本、batch size和输入shape。因为这些因素里任何一个变了，同样的优化手段可能换来完全不同的结果。我手上就有过一个案例：同样的CUDA Graph优化，A100下降31%，V100只下降12%，原因就是两个GPU的kernel launch架构差异。多记一点环境参数，后续排查问题时你会感谢自己。
