1. 从一个模型吃所有形状说起DynaCore 到底在解决什么麻烦大模型推理这件事做过部署的人都知道真正烧钱的地方不在训练而在推理。训练是一次性的投入推理是每天每时每刻都在发生的开销。所以过去两年围绕推理加速的工作层出不穷量化、蒸馏、稀疏化、KV Cache 优化、投机解码几乎每一条路都有人走。但有一个方向长期被低估那就是形状自适应——也就是让模型在推理时根据当前输入的实际形状序列长度、batch 大小、注意力头分布动态调整计算路径而不是死板地按训练时的固定形状跑。DynaCore 这篇工作核心就是干这件事。它提出的两相推理two-phase inference框架把一次完整的前向计算拆成两个阶段第一阶段做形状感知与路由决策第二阶段做实际的计算执行。听起来简单但真正落地时难点在于如何在几乎不增加额外开销的前提下完成形状判断和路径切换。因为一旦判断逻辑本身太重省下来的计算就被吃回去了。我最初看到这个标题时的第一反应是这不就是动态网络那一套吗但仔细读完摘要和关键词后意识到DynaCore 的切入点更偏系统层而不是纯算法层。它关注的不是要不要激活某个专家而是在给定的硬件约束下当前这个形状应该走哪条计算路径最划算。这个视角的转变很关键因为它把问题从模型结构设计拉到了推理调度优化的层面。适合读这篇解读的人我大致分三类一是做推理服务部署的工程师关心吞吐和延迟二是做模型压缩与加速的研究者关心方法论三是对 LLM 系统优化感兴趣的学生或转行者想了解当前工业界和学术界在推理加速上的真实思路。不管你属于哪一类理解 DynaCore 的两相设计都能帮你建立一个更系统的推理优化视角。2. 两相推理的拆解第一阶段到底在感知什么2.1 形状自适应的本质不是所有 token 都值得同等算力要理解 DynaCore 的第一相先得接受一个前提在真实推理场景中输入的形状分布是极度不均匀的。有的请求只有十几个 token有的请求几千个 token有的 batch 里全是短序列有的 batch 里长短混杂。如果模型对所有形状都用同一套计算图那短序列就被迫承担了长序列的计算开销长序列又因为 padding 浪费了大量算力。DynaCore 的第一相我把它理解为形状感知层。它做的事情不是直接算 attention 或 FFN而是先对当前输入的形状特征做一个快速评估输出一个路由信号。这个信号决定了第二相走哪条路径。关键词里提到的形状自适应架构核心就体现在这里——架构不是固定的而是根据形状动态选择的。具体来说第一相会关注几个维度的信息序列长度的分布、batch 内序列的方差、当前可用的显存带宽、以及历史请求的路径命中率。这几个维度组合起来形成一个轻量的决策向量。注意这里的关键是轻量——如果第一相本身就要跑一遍完整的前向那整个设计就失去意义了。2.2 路由决策的代价为什么不能用一个大模型来决定小模型怎么跑这里有一个很容易踩的坑也是我在实际做推理优化时反复遇到的决策逻辑的复杂度必须远低于被决策的计算本身。DynaCore 在第一相里用的不是另一个大网络而是一组基于统计特征的规则加轻量预测器。这个设计选择非常务实。我见过一些方案为了做动态路由专门训练一个 router 网络结果 router 本身的推理开销占了总开销的 15% 以上省下来的计算还不够补这个窟窿。DynaCore 显然吸取了这个教训它的第一相更像是一个查表加微调的机制先用形状特征去匹配预定义的路径模板再用一个极小的线性层做修正。这样第一相的额外开销可以控制在个位数百分比以内。提示如果你自己在做类似的动态推理系统第一相的 FLOPs 占比一定要压到 5% 以下否则整体收益会被吃掉。这是我在多个项目里验证过的经验阈值。2.3 两相之间的切换成本被大多数人忽略的隐性开销两相推理听起来很美但切换本身是有成本的。路径切换意味着 kernel 重新编译、显存重新分配、甚至 CUDA graph 失效。DynaCore 在论文里专门讨论了这个问题它的做法是预编译多条路径的计算图并在显存里预留切换缓冲区。这样切换时不需要重新编译只需要切换指针。这个细节很关键。很多动态推理方案在纸面上算得很好一上真实硬件就崩就是因为忽略了 kernel launch 和显存重分配的开销。DynaCore 把切换成本显式建模进了决策函数里只有当切换后节省的计算大于切换本身的开销时才会真正触发路径变更。这个阈值判断是两相推理能真正跑起来的关键。3. 第二相的计算路径形状自适应到底自适应在哪里3.1 路径池的设计不是无限动态而是有限枚举很多人对自适应有误解以为是要做到完全动态、每个输入都走独一无二的路径。DynaCore 的做法恰恰相反它维护一个有限的路径池每条路径对应一种典型的形状模式。比如短序列高并发走一条路径长序列低并发走另一条长短混合走第三条。第一相的任务就是判断当前输入最接近哪种模式。这个设计的好处是工程上可控。路径池的大小直接决定了预编译的复杂度和显存占用。DynaCore 在论文里给出的路径数量级是个位数到十几种这个范围在实际部署中是合理的。如果路径太多预编译和缓存管理会变得非常复杂如果太少自适应的收益又不够明显。我在实际调优时发现路径池的设计要结合具体业务的流量特征。如果你的业务 90% 的请求都是短序列那路径池就应该向短序列倾斜而不是平均分配。DynaCore 的自适应机制里其实隐含了这种流量感知的能力因为第一相会参考历史命中率。3.2 计算图的重组attention 和 FFN 如何按形状拆解第二相真正执行时DynaCore 会对计算图做重组。这里涉及两个核心模块attention 和 FFN。对于 attention短序列适合用标准的密集计算长序列则可能受益于分块或稀疏化策略。对于 FFNbatch 内序列长度方差大时按长度分桶计算比统一 padding 更划算。DynaCore 的重组逻辑不是简单的 if-else而是把 attention 和 FFN 的计算模式参数化然后根据第一相的路由信号选择参数组合。比如 attention 的 block size、FFN 的分桶策略、KV Cache 的布局方式都是可配置的参数。这种参数化设计让路径池的维护变得清晰每条路径就是一组参数配置。下面这张表是我根据论文描述和常见实践整理的路径参数对照方便你理解不同形状下参数怎么选形状特征attention 策略FFN 策略KV Cache 布局适用场景短序列高并发密集计算大 block统一 batch连续存储对话、问答长序列低并发分块计算小 block按长度分桶分页存储文档摘要、长文生成长短混合混合 block动态分桶混合布局通用服务极短序列融合 kernel小 batch 优化紧凑存储分类、embedding3.3 显存与带宽的权衡为什么形状自适应不只是算力问题很多人把推理加速等同于减少 FLOPs但在真实硬件上显存带宽往往比算力更早成为瓶颈。DynaCore 的形状自适应里有很大一部分决策其实是在权衡显存访问模式。比如长序列的 KV Cache 如果布局不合理带宽利用率会急剧下降这时候即使 FLOPs 没变实际延迟也会飙升。DynaCore 在第二相里会根据形状调整 KV Cache 的读写模式。短序列用连续存储访存效率高长序列用分页存储避免大块连续显存分配失败。这个细节在论文里可能只是一句话但在工程上非常关键。我自己在做长上下文推理时最头疼的就是 KV Cache 的显存碎片问题DynaCore 的分页思路和主流的分页注意力机制是一脉相承的。注意形状自适应如果只盯着 FLOPs 优化很容易在真实硬件上翻车。一定要把显存带宽和访存模式纳入决策维度。4. 实测视角DynaCore 在真实负载下的表现与边界4.1 吞吐提升的来源拆解哪些收益是真实的论文里通常会给出一个整体的吞吐提升数字比如相比基线提升 X%。但作为工程师我更关心这个提升是怎么来的。根据 DynaCore 的设计提升主要来自三个地方一是减少了 padding 浪费二是提高了显存带宽利用率三是降低了 kernel launch 的无效开销。这三者的贡献比例会随负载变化。在短序列为主的负载下padding 浪费的减少贡献最大在长序列负载下显存带宽利用率的提升更明显。理解这一点很重要因为它决定了你在自己的业务里能不能复现论文的收益。如果你的业务形状分布和论文实验差异很大收益可能打折扣。我自己的经验是形状自适应的收益在形状分布方差大的场景下最明显。如果所有请求长度都差不多那固定形状反而更高效因为省去了决策和切换的开销。DynaCore 的价值恰恰在于应对真实世界里那种参差不齐的请求分布。4.2 延迟的尾部问题P99 是否真的改善了吞吐提升不等于延迟改善尤其是尾部延迟。DynaCore 的两相设计里第一相的决策时间会加到每个请求的延迟上。如果第一相不够快P99 延迟可能反而变差。论文里应该讨论了这个问题我的理解是 DynaCore 通过预编译和缓存命中来摊薄第一相的开销。在实际部署中尾部延迟往往比平均延迟更重要因为用户体验由最慢的那批请求决定。DynaCore 的路径切换阈值判断本质上也是在控制尾部延迟——避免为了省一点计算而触发昂贵的切换。这个设计思路值得借鉴任何动态优化都要把尾部延迟纳入约束而不是只看平均值。4.3 什么情况下 DynaCore 反而不划算没有银弹。DynaCore 的形状自适应在以下场景可能不划算一是请求形状极度均匀决策开销纯属浪费二是硬件资源极度紧张预编译多条路径的显存开销承受不起三是请求量太小路径池的预热成本摊不开。我在小规模部署时遇到过类似问题动态路由的收益在低 QPS 下几乎为零因为路径切换的固定开销占比太高。DynaCore 的设计更适合中高 QPS 的服务场景这时候路径池能被充分利用决策开销也能被摊薄。所以如果你打算参考这个方案先评估自己的流量规模。5. 把 DynaCore 的思路搬到自己项目里可复现的落地步骤5.1 第一步摸清你的形状分布在动手之前先做一件事统计你线上请求的序列长度分布、batch 内长度方差、以及不同长度区间的请求占比。这个统计不需要多精确采样一周的日志就够了。有了这个分布你才能判断形状自适应值不值得做以及路径池应该怎么设计。我通常会把长度分成几个桶比如 0-128、128-512、512-2048、2048 以上然后看每个桶的请求占比和平均延迟。如果某个桶的请求占比超过 30%那它就值得单独一条路径。如果所有请求都集中在同一个桶里那形状自适应的收益就很有限。5.2 第二步设计路径池与决策规则路径池的设计要遵循覆盖主要形状、控制路径数量的原则。我建议先从 3-4 条路径起步覆盖最主要的形状模式然后根据实际效果再增减。决策规则可以先用简单的阈值判断比如序列长度超过某个值就走长序列路径batch 方差超过某个值就走混合路径。决策规则的关键是可解释、可调试。不要一上来就上机器学习模型做路由那样出了问题很难排查。先用规则跑通收集数据再考虑用轻量模型替换规则。DynaCore 的第一相本质上也是从规则起步的这个演进路径很务实。5.3 第三步预编译与缓存管理这一步是工程上的重头戏。你需要为每条路径预编译计算图并管理好显存缓存。预编译的时机可以放在服务启动时也可以放在首次命中该路径时。启动时预编译延迟高但运行稳定首次命中预编译启动快但首次请求慢。我一般选择启动时预编译主要路径次要路径按需编译。缓存管理要注意显存碎片问题。不同路径的 KV Cache 布局可能不同如果频繁切换显存容易碎片化。DynaCore 的做法是预留切换缓冲区这个思路可以直接借鉴。预留的缓冲区大小要根据路径切换频率来定切换越频繁预留越大。5.4 第四步监控与调优上线之后重点监控几个指标各路径的命中率、切换频率、第一相耗时占比、P99 延迟。如果某条路径命中率极低考虑合并或删除如果切换频率过高说明决策阈值需要调整如果第一相耗时占比超过 5%说明决策逻辑太重需要简化。调优是个持续过程因为业务流量会变。我习惯每周看一次路径命中分布根据变化调整路径池。这个习惯帮我避免了好几次因为流量漂移导致的性能退化。6. 几个容易踩的坑和我自己的体会第一个坑是过度动态化。我早期做动态推理时总想把路径做得越细越好结果路径数量爆炸预编译和缓存管理复杂度飙升收益却没增加多少。后来才明白形状自适应的收益是非线性的覆盖主要形状模式就能拿到大部分收益剩下的长尾不值得追。第二个坑是忽略第一相的开销。决策逻辑再轻也是有开销的。如果第一相用了复杂的特征提取那这个开销会直接加到每个请求上。我的经验是第一相的特征提取要尽量用现成的统计量比如序列长度、batch 大小而不是重新算一遍 attention。第三个坑是切换阈值拍脑袋定。切换阈值应该基于实测数据来定而不是凭感觉。我一般会做一个小实验测量不同形状下各路径的实际耗时然后算出切换的盈亏平衡点。这个点就是阈值。拍脑袋定的阈值往往不是太保守就是太激进。提示形状自适应的本质是用一点决策开销换大量计算节省所以决策开销和计算节省的比例关系是整个系统设计的核心。任何时候都要盯着这个比例。最后分享一个我在实际项目里验证过的小技巧把路径池的设计和业务的 SLA 绑定。比如你的 SLA 要求 P99 延迟低于某个值那路径池的设计就要以保证这个 SLA 为前提而不是单纯追求吞吐。DynaCore 的阈值判断里其实隐含了这种 SLA 意识因为切换决策会考虑延迟影响。这个视角的转变能让你的优化工作更有方向感也更贴近真实业务需求。
