两种不同的技巧用于快速 LLM 推理

发布: 3天前 (2026年2月15日 GMT+8 17:27)

14 分钟阅读

Source: Hacker News

快速模式对决：Anthropic 与 OpenAI

Anthropic 和 OpenAI 都宣布了 “快速模式”，这是一种以显著更高速度与它们最佳编码模型交互的方式。

这两种快速模式截然不同。Anthropic 的方案提供最高 2.5× 的每秒令牌数（≈ 170 t/s，较 Opus 4.6 的 65 t/s 提升）。OpenAI 的快速模式则提供 超过 1 000 t/s（相较于 GPT‑5.3‑Codex 的 65 t/s，约提升 15 倍）。因此，OpenAI 的快速模式大约 快六倍 于 Anthropic 的¹。

关键区别： Anthropic 使用的是 实际的 Opus 4.6 模型，而 OpenAI 的快速模式运行的是较小的 GPT‑5.3‑Codex‑Spark 模型——而非完整尺寸的 GPT‑5.3‑Codex。Spark 更快，但能力明显稍弱；它可能会出现混淆并错误处理工具调用，而原始模型则不会出现此类失误。

为什么会有差异？

实验室尚未披露其快速模式的确切机制，但一个合理的解释是：

Anthropic： 低批量大小推理。
OpenAI： 特殊的大规模 Cerebras 芯片。

下面深入探讨每种方法。

Anthropic 快速模式的工作原理

AI 推理经济学的核心权衡是 批处理，因为主要瓶颈是内存。GPU 本身很快，但将数据搬到 GPU 上并不快。每个推理请求必须在计算开始前把整个提示复制到 GPU 上²。将多个用户的请求合并批处理可以提升整体吞吐量，但代价是每个用户需要等待批次填满。

类比 – 公交系统

零批处理 就像一辆公交车在乘客上车的瞬间就出发。乘客的行程很快，但整体吞吐量受影响，因为公交车经常半空驶。

Anthropic 的快速模式本质上是一张 “公交通行证”，保证公交车在你上车后立即出发。它的成本大约是普通模式的六倍，因为你为本可以与其他乘客共享的容量付费，但你享受 零等待时间³。

编辑： 有读者指出，“等公交”的成本仅适用于 第一个 token，因此它不影响流式延迟（只影响每回合或工具调用的延迟）。因此，批量大小对性能的影响主要在于 更小的批次需要更少的 FLOP 并且完成得更快。在类比中，可以把它想象成 “更轻的公交车跑得更快”。

我不能 100 % 确定这个解释。Anthropic 可能拥有超高速计算资源或新颖的算法技巧。不过，引入一个更便宜的模型（正如 OpenAI 所做的）通常需要模型本身的改动，而 低批量大小 的方案可以解释观察到的 “费用提升六倍、速度提升 2.5 倍” 的比例。

OpenAI 快速模式的工作原理

OpenAI 的快速模式根本不同。它们推出了 新模型（Spark），这表明速度提升并非仅仅是批量大小的调节。官方博客明确指出了背后的硬件：Cerebras⁴。

Cerebras 合作伙伴关系

OpenAI 于 2024 年 1 月宣布与 Cerebras 合作。Cerebras 通过制造 巨型芯片 来实现 “超低延迟计算”。而 NVIDIA H100 只占约一平方英寸，Cerebras 的 wafer‑scale 引擎则跨越 ≈ 70 in²。

Cerebras wafer‑scale chip

这些芯片拥有巨大的片上 SRAM，使 整个模型 能够驻留在内存中。典型的 GPU SRAM 只有几十兆字节，推理时必须频繁从较慢的 DRAM 中流式读取权重⁵。拥有足够的 SRAM，推理可以 全内存 完成，从而实现约 15 倍的加速。

最新的 Cerebras wafer‑scale 引擎提供 44 GB 的 SRAM⁶。这足以容纳 小模型（约 20 B 参数的 fp16，或约 40 B 参数的 int8），但远不足以装下完整的 GPT‑5.3‑Codex。因此，OpenAI 推出了 GPT‑5.3‑Codex‑Spark，即大模型的蒸馏版⁷。

OpenAI 的版本在技术上令人印象深刻

两家实验室走了 截然不同的工程路线 来实现快速推理：

方面	Anthropic	OpenAI
速度提升	2.5× token/s（≈ 170 t/s）	15× token/s（≈ 1 000 t/s）
使用的模型	完整的 Opus 4.6（未蒸馏）	蒸馏版 GPT‑5.3‑Codex‑Spark
主要技术	低批量大小推理（减少等待）	Cerebras wafer‑scale 引擎（巨大的片上内存）
成本	每 token 成本约高 6 倍	每 token 成本约高 6 倍（比例相似）
Tr	（此处原文截断）

ade‑off	Slightly higher latency per turn (first token)	Reduced model capability
权衡	每回合（首个 token）稍高的延迟	模型能力下降

两种方法各有优点。Anthropic 的方法通过更智能的批处理在保持模型质量的同时降低延迟。OpenAI 的硬件中心策略大幅提升原始吞吐量，但以模型规模为代价。

脚注 (1‑7)

这可能是这样的

OpenAI 在一月中旬与 Cerebras 合作，显然是为了在快速的 Cerebras 芯片上部署 OpenAI 模型。
Anthropic 没有类似的方案，但他们知道 OpenAI 将在二月宣布某种超高速推理能力，他们希望在新闻周期中有相应的内容与之竞争。
因此，Anthropic 赶紧拼凑出他们能够提供的快速推理方式：仅仅是把现有推理堆栈的批量大小调小。
Anthropic（可能）会等到 OpenAI 完成其更为复杂的 Cerebras 实现的前几天才宣布，以制造 OpenAI 抄袭的假象。

显然，OpenAI 在此的成就技术上更为惊人。让模型在 Cerebras 芯片上运行并非易事，因为该硬件非常特殊。训练一个 20 B 或 40 B 参数的 GPT‑5.3‑Codex 蒸馏版，同时仍保持“相当可用”，同样并非轻松。

但我还是要赞赏 Anthropic 找到了一条狡猾的路，让它们在非技术人士几乎看不透的情况下抢先于公告。这让我想起 OpenAI 在 2025 年中期偷偷推出 Responses API，以帮助他们隐藏推理代币⁸。

快速 AI 推理是下一个大趋势吗？

看到两大实验室推出了这项功能，可能会让你觉得快速 AI 推理是它们正在追逐的新目标。我并不这么认为。如果我上面的理论成立，Anthropic 并不那么在乎快速推理；它们只是想避免在 OpenAI 之后出现。而 OpenAI 主要是在探索其与 Cerebras 的新合作的能力。

到底哪些模型能够装进这些巨型芯片、这些模型的实用性如何，以及经济性是否能站得住脚，仍然是一个很大的未解之谜。

我个人并不觉得 “快速、能力稍弱的推理” 特别有用。我在 Codex 中尝试过这种方式，感觉并不好。AI 代理的有用性主要取决于 它们出错的频率，而不是它们的原始速度。以 20 % 更多错误为代价换来 6 倍的速度是个糟糕的交易，因为用户的大部分时间都花在处理错误上，而不是等待模型⁹。

不过，快速、能力稍弱的推理完全有可能成为 AI 系统中的核心底层原语。Claude Code 已经在某些操作中使用了 Haiku¹⁰。也许 OpenAI 最终会以类似方式使用 Spark。

一些技术旁注

无论是用于先前 token 的 KV‑cache，还是在多 GPU 流水线推理时的大型中间激活张量，都会涉及到这点。我在 Why DeepSeek is cheap at scale but expensive to run locally 中有更详细的阐述，解释了为什么 DeepSeek 能以如此低的价格提供服务（大批量可以在巨型、昂贵的 GPU 上实现规模经济，但普通消费者根本无法获得这种规模）¹¹。
低批量大小意味着低吞吐量，这与 “快速通道” 系统为用户提供更高吞吐量是否矛盾？不矛盾。当一些用户使用 “快速模式” 时，GPU 的整体吞吐量会更低，但这些用户的 每用户 吞吐量却大幅提升¹²。
记住，GPU 本身很快，但将数据拷贝到 GPU 上并不快。每一次 “把这些权重拷贝到 GPU” 都是整体推理时间中不可忽视的一部分⁹。
“快速” 模型也可能是某个更强大基础模型（如 GPT‑5.3‑Codex）经过蒸馏后得到的更小的版本。我并不清楚各 AI 实验室的具体做法，它们对此保持高度保密。更多信息请参见这里¹³。
相关地，有趣的是 Cursor 的热度基本在它们发布自己的 “更快、稍弱” 代理模型的同时下降了¹⁴。当然，这在很大程度上是因为 Claude Code 吸走了所有的关注度，但拥有一个非常快的模型显然没有帮助。

如果你喜欢这篇文章…

考虑订阅以获取我的新文章的邮件更新。
或者 在 Hacker News 上分享。

Additional Footnotes (8‑15)

OpenAI 的快速模式（≈ 1 000 t/s）大约比 Anthropic 的（≈ 170 t/s）快六倍。 ↩
每个推理请求必须在计算开始前将整个提示复制到 GPU 上。 ↩
“六倍成本”指的是为本可以在批处理中与其他用户共享的容量付费。 ↩
OpenAI 关于与 Cerebras 合作的博客文章。 ↩
GPU SRAM 通常以数十兆字节计量；从 DRAM 流式传输权重会增加延迟。 ↩
Cerebras 硅片级引擎（WSE）SRAM 容量：44 GB。 ↩
Spark 是 GPT‑5.3‑Codex 的精简版，旨在适应 Cerebras 芯片上内存的限制。 ↩
参见 Sean Goedecke 对 Responses API 的讨论。 ↩
复制到 GPU 的延迟影响。 ↩ ↩²
Haiku issue 的评论。 ↩
参见上文引用的 DeepSeek 文章。 ↩
关于每用户吞吐量与整体 GPU 吞吐量的解释。 ↩
关于模型蒸馏实践的讨论。 ↩
Cursor 的快速、能力较弱的代理模型发布。 ↩