大模型竞争下半场：推理速度成为新的竞争力

一、竞争重心正在迁移：从“能做什么”到“多快做到”

过去几年，大模型行业的主线叙事是能力竞赛：规模定律驱动参数量、数据量与算力持续攀升，各类评测榜单的分数被不断刷新。对开发者而言，最关心的问题始终是——模型究竟能做到什么程度？

但今年以来，一个过去不太显眼的指标开始频繁出现在新模型与新服务的发布信息中：输出速度。部分厂商开始提供“高速档位”服务，开发者可以通过支付更高费用换取明显更快的生成速度；从国际厂商到以百度智能云为代表的国内云平台，也都把推理性能优化作为服务能力的重要方向。换句话说，“速度”正在从一项内部工程指标，升格为一种独立的产品能力。

这一转变并非营销话术，而是行业发展到特定阶段的必然结果。当头部模型在多数通用任务上的能力差距逐渐缩小，“多快做到”就开始与“做到什么”同等重要。

二、速度为什么突然变得重要

agent-">1. 体验层面：流式输出早已“够用”，但 Agent 远远不够

对人类读者来说，中文阅读速度大致在每秒 5～10 个字。流式输出只要达到每秒 20～30 个 tokens，主观上就已经足够流畅，再快感知差异有限。这也是为什么在聊天场景中，速度问题长期不突出。

真正的变化来自 Agent 与编程场景。一次典型的智能体任务，往往包含几十轮“模型调用 → 工具执行 → 结果回填”的循环，每一轮都可能生成成百上千个 tokens。举个简化的算术：一个需要 20 轮调用、每轮输出约 2000 tokens 的任务，仅生成阶段就涉及 4 万 tokens——在每秒 50 tokens 的服务下需要约 13 分钟，而在每秒 1000 tokens 的服务下只要约 40 秒。对交互式编程、实时对话、自动化工作流而言，这个差距直接决定了产品可用性。

2. 商业层面：速度成为独立的付费维度

云服务的定价历来遵循“服务质量分层”的逻辑：带宽、内容分发、数据库都提供不同性能档位。大模型服务正在复制这一路径——同一个模型，标准档保证可用性，高速档保证低延迟，价格随性能上浮。速度第一次成为可以明码标价、独立售卖的能力，这本身就说明推理性能已经形成差异化竞争力。

3. 技术层面：推理优化的红利集中释放

更深层的背景是，推理系统工程在过去两年取得了实质性突破。从业界公开的测评观察看，数百 B 参数量级的模型，在深度优化的部署方案下，单路生成速度已可推进到每秒上千 tokens；而未经专门优化的通用服务，往往只有每秒几十 tokens。数量级的能力释放，让“卖速度”从设想变成了现实。

三、如何科学地度量推理速度

谈优化之前，先要把指标定义清楚。实践中最容易混淆的，是“单路速度”与“系统吞吐”。

1. 三个核心指标

• TTFT（首 token 延迟）：从发出请求到收到第一个 token 的时间，由提示词预填充时长与排队时间决定，对交互体验影响最大。
• 单路生成速度（tokens/s）：单个请求在解码阶段每秒产出的 token 数，反映“吐字”的连贯程度。
• 系统吞吐（tokens/s）：整个服务在并发状态下每秒产出的 token 总量，反映算力利用效率与单位成本。

三者并不等价，甚至常常互相制约：为拉高单路速度，系统可能限制批处理规模、投入更多算力，结果是吞吐下降、成本上升——这正是“高速档位”通常更贵的根本原因。

2. 示例：测量流式输出的 TTFT 与生成速度

# 伪代码：统计流式输出的首 token 延迟与单路生成速度
import time
def measure_streaming(llm_client, prompt: str, max_tokens: int = 512):
    t0 = time.perf_counter()
    ttft, n_tokens = None, 0
    for chunk in llm_client.stream(prompt, max_tokens=max_tokens):
        if ttft is None:                      # 收到第一个 token
            ttft = time.perf_counter() - t0
        n_tokens += 1
    total = time.perf_counter() - t0
    return {
        "TTFT(ms)": round(ttft * 1000, 1),
        "decode_speed(tokens/s)": round((n_tokens - 1) / (total - ttft), 1),
    }

注意上面把解码速度单独拆出来计算（扣除首 token 时间），这样得到的数字才真正反映解码阶段性能，而不是被预填充时间稀释。

四、推理速度的技术底座：解码为什么慢，又如何变快

1. 先理解瓶颈：解码阶段是“访存受限”的

自回归生成每产出一个 token，都要完整执行一次前向计算，把模型参数读一遍。以当前主流硬件的算力与显存带宽之比估算，解码阶段的算术强度远低于硬件算力峰值，瓶颈不在“算”，而在“搬数据”。理解了这一点，所有加速技术就可以归纳成三条主线：少搬数据、多复用、并行摊薄。

2. 关键加速技术盘点

• KV Cache 分页管理与前缀复用：把注意力计算的历史状态按固定大小的块分页管理，减少显存碎片、提升并发容量；对相同前缀（如系统提示词）做缓存复用，可直接削减预填充时间、压低 TTFT。
• IO 感知的融合注意力算子：通过算子融合与分块计算，避免中间注意力矩阵在显存中反复读写，是近两年推理提速的基石技术之一。
• 量化：对权重、激活值乃至 KV Cache 做低比特量化，直接减少每个 token 需要搬运的数据量，在精度可控的前提下是性价比最高的提速手段之一。
• 投机解码：用一个小得多的草稿模型快速猜出若干候选 token，再由大模型一次性并行验证，把“每个 token 一次前向”摊薄成“多个 token 一次前向”，在输出高度可预测的场景（如代码）收益尤为明显。
• 稀疏激活架构：混合专家架构每次推理只激活部分参数，既减少计算量，也减少需要读取的数据量，为高速解码提供架构层面的先天优势。
• 并行与互联：通过张量并行把单层权重切分到多卡、以高带宽卡间互联协同工作，让权重读取时间成倍缩短，这是大规模集群跑出极限单路速度的关键。
• 连续批处理与预填充/解码分离：请求随到随进、随完随出，避免批内互相等待；把计算特征迥异的两个阶段拆分到不同资源上分别优化，是当前高并发推理服务的标准形态。
• 编译与图优化：通过静态图捕获、算子融合、内核调优，减少框架调度开销，把硬件性能压榨到接近理论上限。

上述技术组合起来，大致对应这样一份部署配置（示意）：

# 伪配置：影响推理速度的常见部署选项（仅作示意）
deployment:
  parallelism:
    tensor_parallel_size: 8              # 张量并行：切分单层权重到多卡
  quantization:
    weights: "w8"                        # 权重量化，降低访存压力
    kv_cache: "kv8"                      # KV Cache 量化
  kv_cache:
    block_paging: true                   # 分页管理 KV Cache
    prefix_caching: true                 # 复用公共前缀
  scheduler:
    continuous_batching: true            # 连续批处理
    prefill_decode_disaggregation: true  # 预填充与解码分离
  decoding:
    speculative_decoding: true           # 投机解码

3. 同一个模型，速度为何能差十几倍

如果把主流大模型在不同部署方案下的“参数规模—单路速度”画成散点图，会发现一个规律：经过专门优化的部署方案连成一条清晰的“速度前沿”，同等参数规模下，前沿上的速度可达普通方案的十倍以上。同一个模型，通用公共服务可能只有每秒几十 tokens，而在大规模集群、定制内核与激进并行方案的加持下，可以逼近每秒上千 tokens。

这揭示了一个容易被忽视的事实：模型能力与服务体验是两回事。权重决定了“会什么”，推理系统决定了“多快交付”。速度前沿上的每一个点，背后都是调度、批处理、内核、互联、量化等全栈工程能力的结晶。也因此，推理速度本身正在成为模型厂商与云平台的核心竞争力之一——甚至出现了让 AI 参与 AI 研发、以自动化方式完成代码开发与系统调优的新研发范式，本质仍是为了更快地迭代这套全栈能力。

五、速度、成本与质量的三角权衡

1. 速度 vs 成本：高单路速度往往意味着更激进的并行、更保守的批处理或投机解码开销，单位 token 成本更高。延迟直接影响收入的场景适合高速档；离线批处理、数据加工等任务，用标准档把吞吐与成本做优更划算。
2. 速度 vs 质量：不要为了速度降级模型。能力不足但响应飞快的模型，在复杂任务上只会更快地产出错误结果。合理做法是先按任务难度选对模型档次，再在同等能力下比速度。
3. 单路速度 vs 吞吐：对外服务要同时看两个指标，避免“单请求很快、高峰期全体排队”的陷阱。建议以 P95/P99 分位数而非平均值评估延迟，并做有代表性的压力测试。

六、给开发者的实践建议

1. 先定义指标，再谈优化：明确业务敏感于 TTFT（交互体验）还是单路速度（Agent 效率），建立自己的基准测试，而非只看宣传的峰值数字。
2. 全面拥抱流式接口：凡是面向人的输出，一律使用流式返回，把首 token 延迟作为体验红线。
3. 用前缀缓存组织 Prompt：把稳定的系统提示词、工具定义、少样本示例放在前部并保持不变，可变内容放在后部，最大化命中前缀缓存，同时降低 TTFT 与费用。
4. 控制输出长度：通过明确的结构化输出要求与合理的 max_tokens 上限，避免冗余生成——最快的 token 是不需要生成的 token。
5. 分级调用：简单任务路由到小模型或标准档，延迟敏感与长链路任务使用高速档，让每一分速度预算花在刀刃上。
6. 持续压测与回归：推理性能会随版本、负载、配置变化，把速度基准纳入发布流程，防止体验悄悄变差。

结语

大模型竞争进入下半场，比拼重心正从“模型能做到什么”扩展到“系统能多快交付”。速度前沿的不断抬升，靠的不是单一技巧，而是架构、内核、调度、互联的全栈协同。对开发者而言，理解速度背后的技术逻辑，不仅能帮助自己选出更合适的服务与部署方案，也意味着掌握了一把衡量 AI 基础设施成熟度的新标尺——下一阶段的竞争，不只看谁更聪明，还要看谁能更快地把聪明交付到用户手中。