过去几年，大模型推理优化常常围绕权重展开：量化、剪枝、蒸馏、稀疏化，本质上是在模型精度与计算效率之间做交换。但近期一组来自云服务、推理引擎、底层算子和服务架构的公开案例显示，另一类优化正在变得更重要——不动模型权重，也能显著降低延迟、提升吞吐。
在同一模型权重、同一批 GPU、同一请求分布下，仅仅调整“哪一个实例接收请求”，长上下文负载的 P50 首字延迟（TTFT）下降了 71%～77%，KV cache 命中率从约 25% 提升到最高 82%，吞吐提升 15%～16%。这个结果来自 AWS 在 2026 年 9 月为 SageMaker 推理新增的 PREFIX_AWARE 路由策略。配置层面只涉及 RoutingStrategy、PrefixLength、ConcurrencyThreshold 三个参数，不需要修改模型容器或服务框架。
类似的案例还包括：OpenAI 用两名工程师将核心在线存储服务 Habitat 从 Python 重写为 Rust，CPU 效率提升约 6 倍；佐治亚理工、NVIDIA Research 与斯坦福提出的 BOOST 方法让 vLLM 同时读写 HBM 与主机内存，吞吐平均提升 31%；NVIDIA 则通过 cuDNN Graph API 将 3×3 卷积、bias 与 ReLU 融合进同一个 kernel，减少两次中间张量写入。
这些优化路径看似分散，却指向同一个工程事实：大模型推理的瓶颈，已经不只取决于模型本身，而越来越取决于调度、内存搬运、算子执行和服务链路的组织方式。
首字延迟与 decode 阶段：推理为什么会被“搬运”卡住
要理解这些优化的价值，需要先拆开大模型推理的两个阶段。
第一阶段是 PREFILL，即处理输入。模型会一次性消化整段 prompt 中的所有 token，每个 token 都要参与注意力计算。这一阶段是大矩阵乘大矩阵，算术强度高，更接近算力受限（compute-bound）。
第二阶段是 DECODE，即逐 token 生成。每生成一个新 token，模型通常只处理上一个 token，但需要读取完整的模型权重。此时算术强度很低，瓶颈转向内存带宽（memory-bound）。
素材中给出了一个简化估算：在 batch=1 的 decode 阶段，每生成一个 token 大约需要 2N 次浮点运算，其中 N 是参数量；同时需要把 N 个参数完整读一遍。若使用 FP8，即每参数约 1 字节，算术强度大约只有 2 FLOPs/Byte。作为对照，H100 的 FP16 峰值算力与 HBM 带宽比值约在 3×10² FLOPs/Byte 量级，素材中举例为 989 TFLOPS / 3.35 TB/s ≈ 295。
两者相差接近两个数量级。这意味着在低 batch 的 decode 阶段，GPU 的计算单元大量时间可能处于等待数据的状态。换句话说，这一阶段减少延迟的关键，往往不是“算得更快”，而是“搬得更少、搬得更巧”。
这也解释了为什么近期一批推理优化没有选择继续压缩模型权重，而是转向缓存复用、内存并发、算子融合和服务层调度。它们处理的都是权重之外的搬运、等待和空转成本。
四条“不改权重”的提速路径
从素材披露的案例看，权重之外的推理优化大致可以归为四类：复用已经算过的结果、扩大可用内存带宽、减少中间结果写入，以及减少服务层调度空转。
- 前缀感知路由：把相同前缀的请求送往同一实例，提高 KV cache 命中率，减少重复 prefill 计算。
- HBM 与主机内存并发读取：让 GPU 同时利用两层内存带宽，而不是只依赖 HBM。
- 算子融合：将多个连续操作合并为一个 kernel，减少中间张量反复写入和读取。
- 服务层重写：解决连接池、配置刷新、调度抖动等非模型侧瓶颈，让 GPU 不再等待上游服务。
其中，前缀路由的收益最直观。大量 LLM 应用请求中都包含高度重复的长前缀，例如系统指令、检索文档、对话历史或代码文件。现代推理引擎可以缓存这些前缀对应的 KV，但只有当相同前缀的请求被调度到同一实例时，缓存才会真正生效。AWS 的做法是用请求前缀生成指纹，再尽量把相同前缀的请求分发到同一实例。在长上下文场景下，这种策略让 KV cache 命中率从约 25% 提升到最高 82%，并显著降低首字延迟。
BOOST 则瞄准另一种浪费：主机内存带宽未被充分利用。传统系统通常把 HBM 与主机内存当作层级关系使用，数据装得下就放在 HBM，装不下就先 prefetch 到 HBM。但 prefetch 会占用原本留给实际读取的 HBM 带宽。素材提到，论文中 prefetch 甚至让 TPOT，即每个输出 token 的时间，恶化了 6%。BOOST 的做法是让 GPU 的每一波 threadblock 同时、按带宽比例访问 HBM 与主机内存。在 vLLM 与 Grace Hopper 的实测中，该方法带来平均 31% 的吞吐提升。
NVIDIA 展示的算子融合则更贴近底层执行效率。以 Conv + Bias + ReLU 为例，将后两者折进同一个 kernel 后，可以减少两次中间张量写入。另一个例子是在矩阵乘的 epilogue 中内联缩放、bias、激活和 AMAX 归约。AMAX 是 FP8 场景中的关键原语，用于生成下一层所需的量化 scale factor。把这些操作放进同一个 kernel，可以避免为了取最大值再完整遍历一次输出。素材强调，这类优化的收益来自消除内存流量，而不是让 GEMM 核心算得更快。
OpenAI 的 Habitat 重写案例则提醒行业：推理服务的瓶颈有时根本不在 GPU。Habitat 是 ChatGPT、API、Codex 等产品背后的核心在线存储服务，每秒处理 7000 万+ 请求，管理 500PB 数据。两名工程师借助 Codex 和 GPT-5.5，用一个季度完成了从 Python 到 Rust 的重写。重写后，Rust 版本承担了 95% 的生产请求，CPU 效率约提升 6 倍，内存效率约提升 15 倍。
更关键的是素材列出的瓶颈清单：GIL 调度抖动、LIFO 连接池、配置解析风暴等。这些问题都属于服务层调度与运行时开销，并不是模型推理本身。服务层优化的意义，因此不是让模型算得更快，而是让模型计算不再空转。
收益明确，但边界也同样明确
这些方案的共同点是：它们都不通过牺牲模型精度来换性能，而是回收系统中已经存在的浪费，例如重复计算、未被利用的带宽、多余的中间写和调度等待。但每一项优化都有适用条件。
前缀路由的收益取决于“可复用前缀”的长度和比例。AWS 的基准显示，在长上下文负载下吞吐提升可达 15%～16%，但在短对话场景下只有 1.7%～2%。原因很直接：前缀越短、复用越少，跳过重复计算的价值就越低。若请求前缀高度随机，缓存命中率难以提升，该策略的收益也会迅速下降。
BOOST 的前提则是 HBM 带宽与主机内存带宽能够相加。这要求两者具备相对独立的访问通道。Grace Hopper 通过 NVLink-C2C 提供 CPU-GPU 一致性互联，HBM 与 LPDDR5X 分属不同介质，因此适合这种并发访问。但素材提到，在 GB10 这类统一内存、单池架构上，numactl -H 只显示一个 NUMA 节点，CPU 与 GPU 共享同一内存池，两层带宽相加的前提并不存在。此外，BOOST 对单个 token 的延迟收益并不突出，素材中给出的 per-token 收益为 4.3%，主要价值在于提升整体吞吐。
算子融合的边界在于图中是否还存在可省的中间写。已经完成融合的部分，第二次不能再带来同样收益。同时，相关 plan 序列化也可能带来新的依赖和运维成本。素材提醒，每次硬件或驱动升级后，可能需要重新 autotune，收益是一次性的，维护成本却不是。
OpenAI 的重写案例也容易被简单理解为“换语言就能提速”。但从披露的瓶颈看，真正的问题是服务层调度与资源利用，而不是模型计算本身。如果瓶颈不在这里，重写未必能带来同等收益。
NVIDIA 在 9 月 IFA 上公布的 PAIR（Personal AI Router）则代表了另一种请求级优化：通过透明代理发现局域网中的可用节点，把 agent 的独立推理请求整份分给不同机器。它不池化显存、不分片模型、不拆分单个请求，每个节点都需要持有完整模型副本。在五个子代理的 Hermes 任务中，五个独立调用分发到三台机器，理论上限是两波，即 2.5×，实测为 2.05×，达到上限的 82%。双 5090 场景下，翻倍硬件带来 1.66× 提升，已经开始出现衰减。NVIDIA 也明确说明，这些演示属于非官方、配置相关，不是通用基准，也不承诺线性扩展。
从买卡到清淤：推理工程的重心正在转移
这些案例放在一起，呈现出一个清晰趋势：推理优化正在从“压缩模型”扩展到“清理链路”。过去，行业习惯从权重中挤性能；现在，越来越多性能来自减少重复计算、降低内存搬运、消除中间写、提升调度效率。
这类优化的优势是不需要付出模型精度代价。它们不改变模型能力，却能让同一模型在同一硬件上服务更多请求、降低首字延迟或减少计算空转。对于企业级推理服务来说，这往往比进一步压缩模型更容易落地，也更容易保持输出质量稳定。
但这类优化也有天花板：它回收的是已经存在的浪费，而不是无中生有地创造算力。当重复前缀很少、内存通道无法并发、中间写已经消除、服务层瓶颈被清空后，收益就会下降。这也是为什么不同场景下的表现差异极大。
对于工程团队而言，更实际的做法是先明确指标：TTFT、TPOT 和吞吐。如果吞吐不足但延迟尚可，问题可能在排队与调度；如果首字延迟高，需要判断前缀是否高度重复；如果单 token 生成慢且 batch 较小，则更接近 memory-bound 问题；如果各项指标正常但成本偏高，则要检查 GPU 利用率和服务层等待。
云厂商也在把这些优化产品化。SageMaker 将前缀路由压缩为三个配置项，HyperPod 则将 KV cache 做成两级结构：节点 CPU 内存作为 L1，Redis 跨节点作为 L2。这意味着原本需要工程团队手工处理的缓存、路由和调度问题，正在被纳入基础设施层。
对中文 AI 行业来说，这种变化值得关注。大模型竞争不再只取决于模型参数、训练数据或芯片数量，也越来越取决于推理链路的工程细粒度。谁能在权重之外减少浪费，谁就能在同样的硬件条件下获得更低的延迟和更高的服务能力。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/tui-li-you-hua-zheng-zai-li-kai-mo-xing-quan-zhong-lu-you
