AI Infra：榨干每一块 GPU | blog

把 GPU 榨到最后一滴：AI 大模型时代，真正的战争为何发生在 AI Infra？

本文缘起于“硅谷101”关于 AI Infra 的一期视频。
视频链接：https://youtu.be/cB_X6AImPjQ?si=vMerY1unkFzPdKcE

如果你只把今天的 AI 竞争理解成“谁家的模型参数更多”“谁买的 GPU 更多”，那很可能只看到了冰山露出水面的那一小截。

水面以下，还有一场更加残酷、更加工程化、也更加接近计算机科学本质的战争：

【如何让一块几十万元人民币的 GPU，不要在那里装忙？】

---

引子：GPU 都快买断货了，为啥它们还在大量“摸鱼”？

AI 时代最荒诞的场面：一边喊“缺 GPU”，一边让 GPU 干等

过去几年，AI 行业出现了一个乍看非常矛盾的现象。

一方面，各家 AI 公司疯狂购买 GPU。

H100、H200、B200、GB200……

几乎每一代高端 GPU 一出来，都会迅速进入供不应求状态。

微软、Google、Meta、Amazon，以及大量所谓 Frontier Labs，每年在数据中心、GPU、网络和电力上的投入，都已经是一个非常惊人的数字。

于是媒体形成了一套非常简单粗暴的叙事：

AI 的瓶颈就是算力。

这句话当然不算错。

问题在于，它只说对了一半。

因为【拥有算力】和【真正使用算力】，压根不是一回事。

举一个很俗但很好理解的例子。

假设你花 500 万买了一辆顶级赛车。

理论极速 350 km/h。

结果你每天开着它在北京市中心晚高峰堵车。

此时你能不能说：

“俺的汽车性能不足，所以俺应该再买一辆更快的车。”

当然很荒唐。

真正的问题可能根本不是发动机马力，而是：

• 红绿灯；
• 堵车；
• 道路规划；
• 调度混乱；
• 司机反应慢；
• 每隔 500 米还要停车等人。

GPU 集群其实也有类似的问题。

GPU 的理论浮点运算能力可能极其恐怖。

但是如果数据没送过来，它就得等。

如果 CPU 调度没跟上，它也得等。

如果另一个 GPU 没同步完，它还得等。

如果网络通信没结束，继续等。

如果 KV Cache 被搞得乱七八糟，又得重新计算。

于是最后你会看到一种极其喜感的场面：

【几十亿美元的数据中心，里面放着世界上最昂贵的一批计算设备，然后这些设备相当一部分时间正在等待。】

CMU 等研究者在 2026 年发表的一项 GPU 集群遥测研究，把一种状态称为 execution-idle。

研究观察到：

• execution-idle 大约占 GPU 执行期间的 19.7%；
• 却消耗了大约 10.7% 的能源。

换句话说，视频里说的“大约 20% 执行时间、11% 能耗”基本是准确的。

更加蛋疼的是：

GPU 就算什么有效工作都没有干，也不意味着功耗立刻变成零。

于是你花的钱不仅体现在购买设备，还体现在：

电费、散热、机房、网络、维护……

所有这些东西都在继续烧钱。

这就是所谓的【GPU 假忙碌】问题。

---

先纠正一个常见误区：GPU 利用率不是一个简单的百分数

为了避免有人抬杠，俺有必要说明一下：

所谓“GPU 没跑满”，并不等价于：

nvidia-smi 上显示的 GPU Utilization 小于 100%。

这是一个非常容易被媒体报道搞混的概念。

GPU 可以有很多不同意义上的“忙”。

比如：

1. SM 是否有 kernel 正在执行；
2. Tensor Core 是否充分使用；
3. HBM 显存带宽有没有接近饱和；
4. 算术单元有没有接近理论 FLOPS；
5. GPU 是否等待网络；
6. GPU 是否等待 CPU 发起新的 kernel；
7. GPU 是否处于 memory-bound；
8. GPU 是否真的在做【有用工作】。

假设有一个程序。

GPU utilization：

99%

看起来牛逼得不得了。

但是它实际上可能在不停做：

重复计算
重复搬运
无意义同步
低效率 kernel

这种情况下：

【GPU 很忙，但系统很蠢。】

所以真正应该关心的不是：

GPU 忙不忙？

而是：

每一焦耳能源、每一秒时间、每一 GB 显存，最终产生了多少有用 token？

这两个问题完全不是一个层次。

---

为什么这个问题到了大模型时代突然变得极其重要？

原因其实很简单：

【大模型把原来“小损耗”的问题放大了几个数量级。】

如果你只有一台电脑，一张 GPU 每小时浪费 10 分钟，问题没那么严重。

但是如果有：

100,000 张 GPU

每张卡平均浪费：

20%

那么等价于什么？

近似相当于：

20,000 张 GPU

长期没有产生足够有效工作。

这里先忽略各种非线性因素，只看最粗糙的数量级。

如果一张卡和配套基础设施的总体拥有成本非常高，那么这就不是“代码写得不够漂亮”这么简单。

它直接变成了：

【资本开支问题。】

这也是为什么 AI Infra 在今天突然从幕后跑到了舞台中央。

过去很多软件工程师觉得：

编译器？

通信库？

调度器？

内存管理？

kernel fusion？

太底层了，跟俺没关系。

现在不好意思。

当一次 10% 的系统优化可能意味着少买几千块昂贵 GPU 的时候，这些所谓“底层细节”突然就变成了真金白银。

---

AI Infra 到底在干啥？

如果用一句话概括：

【AI Infra 的任务，就是尽可能消灭 GPU 等待和无效工作。】

当然，这是高度简化滴。

更严格地说，它至少试图解决四类问题：

1. 不要重复算
2. 不要排队等
3. 不要搬来搬去
4. 不要让不同硬件互相拖后腿

后面你会发现：

KV Cache

RadixAttention

Continuous Batching

PagedAttention

Prefill-Decode Disaggregation

Speculative Decoding

FP8

INT4

……

看起来名词很多。

但把所有花里胡哨的论文标题扒开之后，本质上都绕不开上面四件事情。

这也是本文真正要讲的东西。

---

基本概念：先把大模型推理这台“计算机器”拆开

一次 ChatGPT 式请求，到底发生了什么？

假设俺输入一句：

请详细解释为什么罗马帝国会衰落。

大模型并不是看到整个句子，然后“灵光一现”，一下子把几千字答案吐出来。

对于典型的自回归 Transformer，它大致经历两个阶段：

Prompt
  │
  ▼
Prefill
  │
  ▼
KV Cache
  │
  ▼
Decode token 1
  │
Decode token 2
  │
Decode token 3
  │
...

其中最关键的两个阶段：

Prefill
Decode

这俩虽然都跑同一个 Transformer，但计算特征完全不同。

---

Prefill：模型先把你的问题“读一遍”

假如 Prompt 长度是：

L = 4000 tokens

模型必须首先处理这 4000 个 token。

这一步就是：

Prefill

它的特点是：

【一次可以处理大量 token。】

因此这里会产生大量矩阵乘法。

而 GPU 最喜欢什么？

就是规模足够大的矩阵乘法。

所以在许多场景下：

Prefill 更偏向【compute-bound】。

翻成人话：

GPU 的计算单元有多强，很重要。

此时 Tensor Core 可以开足马力干活。

---

Decode：真正麻烦的是一个字一个字往外蹦

完成 Prefill 之后，模型开始生成答案。

比如：

罗
罗马
罗马帝
罗马帝国
...

当然模型内部操作的是 token，不是汉字。

每生成一个 token，大致需要：

读取模型权重
读取历史 KV
执行 Transformer
产生下一个 token

然后：

再来一次

再来一次。

再来一次。

假如最终输出：

2000 tokens

你就要重复大量类似过程。

关键的问题来了。

生成单个 token 时，参与矩阵运算的数据规模往往没有 Prefill 那么大。

于是 GPU 很可能无法充分利用自己的巨大计算能力。

此时瓶颈经常变成：

【显存带宽。】

也就是说：

不是“算不过来”。

而是：

“数据搬得不够快。”

---

为什么要有 KV Cache？

这里就要理解 Transformer 的 Attention。

（注：技术菜鸟可以跳过这个小节）

Self-Attention 里面，每个 token 会产生：

Q = Query
K = Key
V = Value

当你生成第 1000 个 token 时，它需要和前面大量 token 的 K、V 做 Attention。

问题是：

前面 999 个 token 的 K、V 已经算过了。

那么下一轮怎么办？

一种脑残方案是：

全部重新算。

显然非常浪费。

所以系统把之前的：

K
V

保留下来。

这就是：

KV Cache

于是第 1001 个 token 出现时，只需要算新增部分。

这相当于程序里面的 memoization：

f(x) 算过一次
→ 缓存结果
→ 下次直接复用

从算法角度看，这是一个很正常的【空间换时间】。

但麻烦也马上来了：

KV Cache 很大。

而且：

请求越长，它越大。

用户越多，总量越大。

于是大模型推理逐渐变成一场：

【显存管理战争。】

---

核心剖析：AI Infra 如何把 GPU 一层层“榨干”

先看整个系统：GPU 从来都不是孤立工作的

“硅谷101”的视频把 AI Infra 粗略分成四层。

这个框架作为科普非常好理解：

┌───────────────────────────┐
│ ④ 服务编排 / Serving      │
│ Scheduler / Inference     │
├───────────────────────────┤
│ ③ 系统软件                │
│ Compiler / Kernel / Comm  │
├───────────────────────────┤
│ ② 计算硬件                │
│ GPU / CPU / HBM / Network │
├───────────────────────────┤
│ ① 能源基础设施            │
│ Power / Cooling           │
└───────────────────────────┘

不过为了避免概念过度简化，俺补一句：

这不是一个类似 OSI 七层协议那样严格统一的行业标准。

现实里面：

网络
存储
调度
通信
运行时

经常跨越多层。

但这个模型非常适合理解一个问题：

【GPU 为什么会停？】

---

没有电，所有算法都是扯淡

现在经常有人讨论：

GPU 数量
参数量
训练 token

却忽略最物理的一层：

【电。】

GPU 本质上是个把电变成计算，同时顺便大量制造热量的机器。

如果一个数据中心理论上可以安装：

100,000 块 GPU

但电网只能供：

60,000 块 GPU

那么剩下的性能都是 PPT。

同样。

如果散热系统跟不上，芯片过热以后：

降频

于是理论算力又没了。

这就是复杂系统里面很经典的【木桶效应】。

最终吞吐不是由最强的模块决定。

而是由：

【最差的约束决定。】

用程序员熟悉的方式写就是：

System Performance
≈ min(
    Power,
    Cooling,
    Compute,
    Memory,
    Network,
    Software,
    Scheduler
)

当然这个公式只是帮助理解，不是数学模型。

但其哲学很重要：

【局部最优 ≠ 系统最优。】

---

算力真正的敌人往往不是 FLOPS，而是数据移动

GPU 厂商特别喜欢宣传：

XXX PFLOPS

因为数字大，宣传效果好。

可是现代计算机体系结构里面，一个越来越重要的问题是：

【搬数据比算数据贵。】

例如：

数据可能要从：

SSD
 ↓
CPU RAM
 ↓
GPU HBM
 ↓
Cache
 ↓
Register

一路往计算单元送。

模型巨大以后，权重甚至放不进一张 GPU。

于是又出现：

GPU 0
 ↕
GPU 1
 ↕
GPU 2
 ↕
GPU 3

通过：

NVLink

InfiniBand

RoCE

……

疯狂交换数据。

所以今天判断一个 AI workload 的性能瓶颈，经常会使用一个非常经典的思路：

【Arithmetic Intensity】

也就是：

做了多少计算
÷
搬了多少数据

如果每搬 1 byte 数据就能做大量计算：

偏 compute-bound。

反过来：

偏 memory-bound。

这正是 Prefill 和 Decode 性格完全不同的根本原因之一。

---

kernel 写得烂，再贵的 GPU 也能跑成拖拉机

GPU 最终并不会执行：

model.generate(...)

这种高级代码。

真正落到底层，需要经过大量步骤：

Python
 ↓
Framework
 ↓
Graph
 ↓
CUDA kernel
 ↓
GPU instruction

中间涉及：

PyTorch

CUDA

Triton

cuBLAS

NCCL

FlashAttention

以及各种 fused kernel。

如果本来需要：

Kernel A
写回 HBM

Kernel B
再读 HBM

Kernel C
又写 HBM

而实际上这些操作可以融合：

Kernel ABC

那么就可能少很多数据搬运和 kernel launch。

这就是：

【Kernel Fusion】

类似的优化还有：

CUDA Graph
FlashAttention
Custom All-Reduce
Tensor Parallel
Expert Parallel
Pipeline Parallel

等等。

于是你会发现：

一个“同样的模型”跑在“同样的 GPU”上。

因为 runtime 不同：

性能可能完全不同。

这就是软件定义硬件有效性能。

---

别重复算——KV Cache 与 RadixAttention

为什么 Prompt 重复特别严重？

现在的大模型应用，用户输入里面经常只有一小部分是真正新的。

例如一个 Agent 系统，每次都带：

System Prompt
+
几十个工具定义
+
安全规则
+
Few-shot Examples
+
用户真正的问题

假设：

System Prompt       3000 tokens
Tool Schema         5000 tokens
Examples            2000 tokens
User Input           100 tokens

总共：

10100 tokens

下一位用户来了：

前 10000 token 可能一模一样。

只有最后：

100 tokens

变了。

如果你每次从头 Prefill：

是不是觉得有点牛头不对马嘴？

---

普通 KV Cache 为什么还不够？

传统 cache 当然可以保存结果。

问题是请求之间存在复杂的前缀关系。

比如：

Request A:
You are ChatGPT.
Please solve math problem A.

Request B:
You are ChatGPT.
Please solve math problem B.

Request C:
You are ChatGPT.
Please translate sentence C.

三个请求共享：

You are ChatGPT.
Please

A 和 B 又进一步共享：

solve math problem

于是最自然的数据结构是什么？

树。

更加具体来说：

【Radix Tree】

假设 token 序列如下：

root
 └── You are ChatGPT
      ├── solve math
      │    ├── A
      │    └── B
      │
      └── translate
           └── C

公共前缀只保存一次。

这就是 RadixAttention 背后极其漂亮的思想之一。

---

RadixAttention 到底干了啥？

SGLang 最早的核心卖点之一就是 RadixAttention。

它把不同请求之间的前缀 KV Cache 放进 radix tree 进行组织，使共享前缀对应的 cache 可以被自动复用。

SGLang 论文报告，在其测试的复杂 LLM program workloads 上，相比当时的系统最高获得了约 6.4 倍吞吐提升；当然，这不是说所有普通聊天请求都会获得 6.4 倍。

这里尤其要注意：

【收益和 workload 高度相关。】

如果你的请求都是：

完全不同的随机 Prompt

没有前缀复用。

那么 radix tree 再牛逼也不能凭空创造共享内容。

但如果你是：

Agent
RAG
Few-shot
Multi-turn Chat
批量评测
重复 System Prompt
大型 Tool Schema

共享前缀可能非常巨大。

收益自然完全不同。

---

一个视频里容易让人误会的地方：RadixAttention 不等于天然的“跨机器全球缓存”

这里俺特别打一个补丁。

基础的 RadixAttention，核心是：

【在推理 runtime 中利用 radix tree 组织并复用 prefix KV。】

到了大规模集群以后，问题又变成：

某个请求应该发到哪台机器？

假设：

GPU Server A

已经缓存了：

10000 tokens

的前缀。

而：

GPU Server B

啥都没有。

如果负载均衡器傻乎乎地随机把请求发给 B：

缓存优势就没了。

于是你还需要：

【Cache-Aware Routing】

现在 SGLang 的 gateway/router 已经支持 cache-aware 策略，会综合 prefix locality 和 worker load 进行路由。

再往后还有：

HiCache

把 cache 层级扩展为类似：

L1 = GPU memory
L2 = CPU memory
L3 = distributed storage

官方设计文档明确描述了这种多级层次，并指出原始 RadixAttention 主要利用 GPU 侧的 prefix KV reuse，而 HiCache 进一步扩展到 host memory 和 distributed storage。

所以更准确的关系应该是：

RadixAttention
      │
      ├── 本地 Prefix KV 复用
      │
      └── Radix Tree 元数据
              │
              ▼
      Cache-Aware Routing
              │
              ▼
        Hierarchical Cache
              │
              ▼
       跨实例 / 跨机器复用

不要把整个系统都叫成 RadixAttention。

否则概念就串味了。

---

别让请求互相等——Continuous Batching

传统 batch 为什么会产生“全车等一个人”？

假设同时来了 4 个用户：

A：生成 10 tokens
B：生成 100 tokens
C：生成 500 tokens
D：生成 2000 tokens

传统静态 batch 可以想象成：

四个人一起坐一辆车。

问题是：

A 到站了。

不能下。

B 到站了。

也不能释放资源。

C 结束了。

还得等。

因为 D 特别能写。

于是：

A ─────┐
B ───────────────┐
C ───────────────────────────┐
D ───────────────────────────────────────────────┐

整个 batch 的生命周期被最长请求拖住。

这个现象在计算机系统里面有一个非常经典的味道：

【Head-of-Line Blocking】

头部阻塞。

---

Continuous Batching 的妙处：把调度单位从 Request 改成 Iteration

真正关键的变化是：

不要把：

一个请求

当作不可拆分的调度单位。

而是每生成一个 token，就重新考虑 batch。

于是：

Step 1:
A B C D

Step 2:
A B C D

...

A 完成

下一 step:
E B C D

有新请求 E？

马上进来。

这就是所谓：

Continuous Batching

其思想和早期 ORCA 的 iteration-level scheduling 一脉相承。

ORCA 的核心贡献之一，就是把调度粒度从整个 request 下沉到 iteration，让已完成请求退出、新请求进入，而不用死等整个 batch。

可以把它理解成：

静态 batching 是：

【旅游大巴。】

全员集合才能走。

而 continuous batching 更像：

【地铁。】

有人下车：

马上空出位置。

有人上车：

继续跑。

---

为什么经常有人说能快 2～4 倍？

这里也要防止数字滥用。

例如 vLLM 的 PagedAttention 论文确实报告，在其测试 workload 中，相比当时系统可以达到约 2～4 倍 throughput。

但这个数字来源于整个系统：

PagedAttention
+
更好的 KV memory management
+
batching
+
request scheduling

不是说：

只要把某个开关从 static batching 改成 continuous batching，所有业务必然 4 倍。

vLLM 的论文指出，其核心优势之一是显著减少 KV Cache 内存碎片和冗余，使系统能够容纳更大的 batch。

所以正确理解应该是：

【调度优化 + 内存管理优化共同扩大有效 batch，最终提高 throughput。】

而不是迷信某一个 magic switch。

---

这里其实是在解决一个经典排队论问题

假设单位时间到达请求数量：

λ

系统单位时间能够处理的请求：

μ

只要：

λ → μ

队列延迟通常就会开始急剧恶化。

不是线性恶化。

而是可能突然炸掉。

所以在线推理系统特别关心：

P50 latency
P95 latency
P99 latency

原因就在这里。

平均值好看没有用。

如果某些特别长的请求不断把 batch 拖死：

tail latency 会爆炸。

Continuous Batching 的真正意义并不只是：

【更快。】

而是：

【让异质请求之间更少互相伤害。】

---

为什么还要把 Prefill 和 Decode 拆开？

因为它们压根是两种性格完全不同的 workload

前面已经讲了：

Prefill

倾向：

Compute Intensive

而 Decode

倾向：

Memory Bandwidth Intensive

那么问题来了：

为啥一定要让它们挤在同一种服务器、同一种调度逻辑里面捏？

这就好比一个工厂有两种任务：

任务 A：需要大型机器高强度加工
任务 B：需要仓库高速搬货

结果老板为了“统一管理”，非要把两种任务混在同一条生产线上。

最后谁都不舒服。

---

统一调度会出现什么问题？

例如 GPU 正在执行很多 decode 请求：

D D D D D D

突然来了一个巨大 Prompt：

Prefill = 100k tokens

如果这个大 prefill 插进去：

可能直接拖慢正在生成 token 的用户。

于是你聊天时会感觉：

token
token
token
……
突然卡一下
……
token
token

这就是所谓 interference。

SGLang 的 PD Disaggregation 文档明确指出，在统一引擎里，新来的 prefill batch 会干扰 decode，增加生成延迟，同时还可能产生 data-parallel attention 的负载不平衡。

---

Prefill-Decode Disaggregation：厨房和传菜分开

因此一个很自然的办法是：

             ┌───────────────┐
Request ───► │ Prefill GPUs  │
             └───────┬───────┘
                     │
                  KV Cache
                     │
                     ▼
             ┌───────────────┐
             │ Decode GPUs   │
             └───────────────┘

不同 GPU 集群承担不同工作。

于是可以针对：

Prefill

配置更适合大规模计算的资源。

针对：

Decode

配置更适合高显存带宽、KV handling 的资源。

还可以分别调度、扩容。

比如业务突然出现大量长 Prompt：

增加 prefill capacity。

如果大量用户开始生成巨长答案：

增加 decode capacity。

这就像把一个 monolith 拆成两个服务。

从架构思想上非常像微服务：

【资源可以按不同 workload 独立扩缩容。】

---

但是别高兴太早：拆服务会产生网络税

这里马上出现另一个经典系统问题：

【Local computation 变成 distributed communication。】

Prefill 算完以后产生的 KV Cache 怎么办？

得送给 Decode GPU。

如果 KV 巨大：

GPU A
  │
  │ 巨量 KV
  ▼
Network
  │
  ▼
GPU B

网络不够快？

完蛋。

于是你又需要：

NVLink

InfiniBand

RDMA

NIXL

Mooncake

以及各种 KV transfer 优化。

这就是分布式系统最经典的规律之一：

你解决一个瓶颈，就会制造下一个瓶颈。

所以 P-D Disaggregation 不是免费午餐。

如果 workload 不适合：

拆开以后可能反而更差。

这就是为什么俺一直强调：

【系统优化不能脱离 workload。】

---

别让 GPU 一次只干一个 token——Speculative Decoding

自回归生成有一个先天缺陷：串行依赖

大模型生成：

token 1

以后，才能知道：

token 2

然后：

token 3

数学上近似：

P(x1, x2, ... xn)
=
P(x1)
P(x2|x1)
P(x3|x1,x2)
...

所以 decode 天生串行。

这非常讨厌。

因为 GPU 是一个特别擅长：

【并行】

的东西。

结果你却让它：

一次猜一个 token
一次猜一个 token
一次猜一个 token

简直像请了 1000 个工人，然后让大家排队轮流拧一颗螺丝。

---

Speculative Decoding 的脑洞：让一个小模型先瞎猜

办法是什么？

找一个便宜的小模型：

Draft Model

假设它先生成：

The Roman Empire fell because

然后大模型：

Target Model

不再一个 token 一个 token 生成。

而是一次性检查这一串候选 token。

如果前几个都符合 target model 的采样结果：

直接接受。

于是一次大模型 forward：

可能推进多个 token。

经典 Speculative Decoding 工作表明，在特定配置下可实现大约 2～3 倍加速，同时通过相应的接受/拒绝采样机制保持目标模型的输出分布。

---

一个通俗比喻：教授和研究生

假设有一个教授：

水平很高。

但每小时收费：

$1000

研究生：

水平没那么高。

但每小时：

$50

脑残做法：

教授亲自：

查资料
打字
排版
检查

聪明做法：

研究生先写草稿：

A B C D E

教授一次检查：

A ✓
B ✓
C ✓
D ×

那么：

A、B、C 直接通过。

从 D 开始重来。

如果研究生猜得特别准：

教授每次检查就能批准很多 token。

于是效率极高。

反过来。

如果 draft model 天天瞎猜：

第一个 token 就错

那你白养了一个研究生。

不仅没有加速：

还增加额外开销。

所以这里最关键的一个指标是：

【Acceptance Rate】

---

今天的投机解码已经远不止“一大一小两个模型”

现在 SGLang 支持的 speculative decoding 已经包括：

EAGLE-2

EAGLE-3

MTP

独立 Draft Model

N-gram speculation

等多种路线。

例如其当前文档给出的一个 Llama-3.1-8B-Instruct 示例里，EAGLE-3 从约 158 tokens/s 提升至约 373 tokens/s，即约 2.36 倍；这个数字当然依赖具体模型和测试条件，不能当作普遍常数。

所以今天的核心问题已经逐渐变成：

如何 cheaply predict multiple future tokens
+
如何 cheaply verify them

本质仍然是一件事：

【用额外的便宜计算，减少昂贵计算的串行次数。】

这其实和 CPU 里面的 speculative execution 有非常浓烈的思想亲缘关系。

---

低精度为什么可以让 GPU 跑得更快？

模型参数真的需要那么多精度吗？

假设一个权重原本用：

FP32

保存。

每个参数：

32 bit

换成：

FP16

变成：

16 bit

再进一步：

FP8

8 bit

甚至：

INT4

4 bit

那么同样一组参数占用的空间显著下降。

于是：

显存占用 ↓
内存带宽压力 ↓
一次可以装更多数据 ↑

而某些 GPU 的低精度 Tensor Core throughput 还明显更高。

于是低精度有机会同时改善：

【容量】

和：

【速度】

---

为什么减少 bit 数会特别帮助 Decode？

别忘了：

Decode 经常是 memory-bandwidth bound。

假设模型每生成一个 token，都要搬大量模型参数。

原来每个参数：

16 bits

现在：

8 bits

理论上数据量接近减半。

如果 workload 真的是带宽瓶颈：

收益就可能非常明显。

这就像运输货物。

卡车速度没变。

但是每个产品的包装体积缩小一半。

一次能运的数量自然更多。

---

代价是什么？数值误差

天下没有免费午餐。

精度下降意味着：

表示范围、有效数字、量化误差都会发生变化。

因此才出现各种技术：

PTQ

QAT

AWQ

GPTQ

以及不同的：

weight-only quantization
activation quantization
KV quantization

目标无非是在三者之间做 trade-off：

速度
显存
质量

不可能闭着眼睛：

FP16 → INT4

然后宣布：

性能翻四倍，质量完全不变。

如果真这么容易，大家早干完了。

---

为什么“理论 bit 减半”不等于“速度翻倍”？

这又是系统工程里面的老坑。

假设：

memory traffic ↓ 50%

但是新的瓶颈变成：

dequantization
kernel overhead
communication
scheduler

那么整体性能不会翻倍。

这就是著名的：

【Amdahl’s Law】

如果程序总时间：

T = A + B

你把 A 优化 100 倍。

但 B 占 80%。

最后性能依然被 B 卡住。

所以任何宣传：

“我们某个 kernel 快了 5 倍！”

俺都会继续问：

它占 end-to-end latency 的百分之多少捏？

这是搞性能分析最基本的条件反射。

---

为什么后训练时代，训练和推理越来越难分家？

传统训练和今天的 RL workload 有什么区别？

传统预训练可以粗略理解为：

Dataset
  ↓
Forward
  ↓
Loss
  ↓
Backward
  ↓
Update

不停重复。

这种 workload 非常规整。

但是强化学习式后训练复杂得多。

例如：

当前 Policy
    │
    ▼
生成大量 Rollout
    │
    ▼
Reward / Judge
    │
    ▼
计算 Advantage
    │
    ▼
Policy Update
    │
    ▼
新的 Policy

问题来了。

生成 rollout：

本质上是【推理】。

Policy update：

本质上又是【训练】。

于是系统不停在：

Inference Mode
     ↓
Training Mode
     ↓
Inference Mode
     ↓
Training Mode

之间切换。

---

为什么这种切换很昂贵？

假设你有：

1024 张 GPU

训练阶段非常忙。

但是 rollout 阶段：

某些训练资源可能利用不足。

反过来。

推理集群生成完以后：

又可能等训练。

与此同时还涉及：

权重同步
模型版本切换
GPU memory layout 变化
worker 重启
通信组重构

甚至 rollout 长度还不一致。

例如：

Sample A: 300 tokens
Sample B: 2000 tokens
Sample C: 8000 tokens

最后又出现：

【长尾等待。】

所以 RL Infra 并不是：

训练框架 + 推理框架

简单拼起来就完事。

它本质上已经是：

【一个动态异构分布式系统。】

---

Miles 想解决什么？

RadixArk 的 Miles 将自己定位成面向大规模模型强化学习的框架，重点包括：

High-performance rollout
Low-precision training
Production stability

其配置体系同时涉及：

Megatron

FSDP

SGLang

以及 RL 算法参数等。

与此同时，SGLang 面向 RL 的文档也把大规模 rollout、异步路由、动态负载均衡、训练/推理一致性列为核心能力。

如果把这些花哨名词全部去掉：

它们试图解决的核心矛盾其实是：

【别把训练和推理当成两个互不相干的世界。】

因为在现代 RL post-training 中：

它们本来就是同一条流水线的不同阶段。

---

这其实意味着 AI Infra 正在“向上吞”

以前 Infra 主要管：

GPU
Network
Kernel
Serving

后来开始管：

KV Cache
Request Routing
Model Parallelism

现在继续往上：

Rollout
Reward
RL Training
Weight Sync

于是 Infra 和算法之间的边界越来越模糊。

算法研究者提出一个新的训练范式。

Infra 工程师马上会问：

这个范式 GPU utilization 怎么样？

Infra 工程师发明新的 runtime。

算法研究者又会问：

那俺是不是可以训练以前训不起的模型？

两边于是形成：

【正反馈。】

---

真正理解 AI Infra，要用“复杂系统”的眼光

局部优化为什么经常会失败？

想象：

GPU Compute 提升 2×

结果：

Memory bandwidth 没变。

于是整体：

1.1×

再优化 memory。

结果：

network 成瓶颈。

于是：

1.2×

继续优化 network。

结果：

scheduler 撑不住。

这种现象叫：

【Bottleneck Migration】

瓶颈迁移。

哪个地方最慢：

整个系统就卡在哪里。

你把那里修好：

瓶颈就会跑到别处。

所以 Infra 永远没有所谓：

“彻底优化完成。”

只会有：

“目前 workload 下，主要瓶颈已经转移。”

---

KV Cache 其实和操作系统的虚拟内存非常像

这也是俺觉得大模型 Infra 最有趣的地方之一。

你看：

CPU 操作系统几十年前就在解决：

物理内存很贵
程序需要更多内存
如何分页？
如何淘汰？
如何提高 locality？

今天 LLM Infra 在解决：

HBM 很贵
KV Cache 很大
如何分页？
如何淘汰？
如何提高 locality？

于是出现：

PagedAttention

它连名字都已经非常直白了。

论文明确说明，它受经典操作系统 virtual memory / paging 思想启发。

再比如：

RadixAttention

实际上是在利用：

【prefix locality】

现在 HiCache：

GPU
CPU
Distributed Storage

有没有觉得似曾相识？

很像：

L1
L2
L3
RAM
Disk

历史不是简单重复。

但计算机科学里的很多基本矛盾：

一直没变。

---

为什么缓存一定会遇到淘汰问题？

因为：

【缓存永远不够大。】

假设所有请求都缓存。

最终：

OOM

所以必须删。

删谁？

最简单的：

LRU

最近最少使用。

于是问题变成：

什么值得缓存？
缓存多久？
复制几份？
应该放 GPU 还是 CPU？
要不要跨机器？

这其实和 CDN 一模一样。

热门网页：

多放几份。

没人看的：

删掉。

所以 KV Cache 最终会逐渐变成一种：

【分布式内容缓存系统。】

只不过 CDN 缓存的是：

图片
视频
HTML

LLM Infra 缓存的是：

Attention State

---

系统越复杂，反馈环越重要

例如：

请求增加。

导致：

Queue ↑

队列增加导致：

Batch Size ↑

Batch 增大可能让：

GPU efficiency ↑

GPU efficiency 提高可能使：

Throughput ↑

于是队列又下降。

这是一个：

【负反馈。】

但是另一种情况：

请求增加：

Queue ↑

导致：

KV memory pressure ↑

于是：

cache eviction ↑

cache eviction 又导致：

recompute ↑

recompute 导致：

latency ↑

latency 导致：

queue 更长

这就变成：

【正反馈。】

最终系统可能突然：

雪崩

所以 Infra 研究绝对不只是：

“把某个矩阵乘快一点”。

它最终涉及：

【复杂系统稳定性。】

---

AI Infra 的终极指标其实是“每美元多少智能”

为什么软件优化可以等价于“虚拟 GPU”？

假设公司有：

10,000 张 GPU

优化前：

100 tokens/s/GPU

优化后：

150 tokens/s/GPU

那么总吞吐：

100万 tokens/s
→
150万 tokens/s

从 capacity 角度看：

相当于原来的 10,000 张 GPU 变成：

15,000 张

当然物理上没有凭空出现 5,000 张卡。

但业务 capacity 达到了近似效果。

这就是为什么 Infra software 极其值钱。

一段代码如果能让全球几十万张 GPU 提升几个百分点：

经济价值可能极其惊人。

---

为什么 Frontier Labs 曾经拥有巨大的 Infra 护城河？

因为真正做到这些事情需要：

Compiler Engineer
CUDA Engineer
Distributed System Engineer
Networking Engineer
Kernel Engineer
ML Researcher
Scheduler Engineer

等等。

一家普通创业公司可能总共才：

20 人

你让它养：

50 个 Infra 专家

显然不现实。

于是 OpenAI、Google、Meta 等巨头可以投入庞大团队，把：

5%
5%
10%
20%

一点一点抠出来。

最后叠加以后：

成本差异可能非常明显。

这是一种典型的：

【规模经济。】

---

为什么 SGLang、vLLM 这类开源项目意义很大？

它们在干的一件事情是：

【把 Frontier Lab 内部 Infra 能力商品化。】

以前：

只有超级大厂才能做：

高级调度
Paged KV
Prefix Cache
Speculative Decoding
Quantization
Distributed Serving

现在：

普通团队安装开源 runtime：

就可以直接吃掉其中相当一部分红利。

SGLang 当前公开框架已经集成 RadixAttention、continuous batching、paged attention、P-D Disaggregation、speculative decoding、量化及多种并行机制。

这就是开源最有价值的地方：

不是“免费软件”。

而是：

【把少数公司的工程知识扩散成公共基础设施。】

---

这会不会把所有 Infra 护城河都消灭？

不会。

为了避免有人抬杠，俺再说明一次：

开源一个 framework：

不意味着所有公司突然拥有了 Google 级别基础设施。

因为生产系统还有：

Observability
Capacity Planning
Failure Recovery
Multi-region
Security
Cost Control
Autoscaling
Custom Kernel
Hardware Integration
Traffic Prediction

等等。

而且新的 Frontier Labs 依然可以：

比开源社区早半年甚至一年找到下一轮优化。

所以更准确的说法是：

【开源降低 Infra 优化的最低门槛，但不会消灭最顶尖 Infra 团队的优势。】

---

俺的点评：AI Infra 热潮里面，有哪些东西值得警惕？

俺最反感的指标：GPU Utilization 100%

现在很多管理层特别喜欢看一个数字：

GPU Utilization

然后问：

为什么不是 100%？

这和当年某些老板问程序员：

你为什么不每天写 5000 行代码？

是一个智力水平。

GPU utilization 高不等于有用 throughput 高。

你完全可以通过：

制造垃圾计算
增大无意义 batch
重复计算

让 GPU 特别忙。

真正应该看的至少包括：

Tokens / second
Tokens / dollar
Tokens / joule
TTFT
TPOT
P95 latency
P99 latency
Cache hit rate
HBM utilization
Network utilization

以及业务层：

每个有效任务的总成本

否则容易把系统优化成：

【一台高效制造垃圾的机器。】

---

俺警惕的东西：所有“X 倍加速”都必须看 baseline

Infra 圈特别喜欢：

2×
3×
6×
10×

看起来很刺激。

俺看到这种数字，第一反应从来不是：

牛逼！

而是：

Baseline 是谁？
Model 是啥？
Prompt 多长？
Output 多长？
Batch 多大？
Hardware 是啥？
Latency constraint 是啥？
有没有 prefix sharing？
有没有 quantization？

比如：

RadixAttention

对于大量共享 Prompt 的 workload：

可能非常爽。

如果完全没有共享：

收益明显降低。

Speculative Decoding

draft 准：

很快。

draft 不准：

收益下降。

P-D Disaggregation

网络快、流量合适：

很好。

传 KV 成了瓶颈：

可能适得其反。

所以性能工程里面最危险的一句话就是：

“这个技术能够提升 X 倍。”

更严谨的说法永远应该是：

【在某些硬件、模型、流量和约束条件下，观察到 X 倍。】

---

俺要泼冷水的点：软件优化不会推翻物理定律

现在有一种宣传逻辑：

GPU 很贵。

软件可以提高效率。

所以只需要优化软件。

这也是扯淡。

Infra 能优化：

冗余
调度
locality
资源浪费

但它不可能让：

HBM bandwidth = ∞
Network bandwidth = ∞
Power = 0
Latency = 0

模型越大：

权重就得存。

上下文越长：

状态就得保存。

跨机器：

数据就得搬。

信息论和物理定律不会因为 VC 投了 1 亿美元就突然取消。

所以软件 Infra 的真正价值不是：

【消灭成本。】

而是：

【逼近物理极限。】

这是两个完全不同的概念。

---

俺不太认同的说法：Infra 优化“必然加速 AGI”

视频最后把 Infra 进步进一步连接到：

AGI

俺觉得这个说法可以理解，但需要非常谨慎。

Infra 优化可以明确做到：

推理更便宜
实验更多
训练更便宜
部署门槛下降

这会扩大研究者能够尝试的搜索空间。

从这个意义上：

当然可能推动 AI 能力进步。

但是：

算力效率 ↑

并不能逻辑必然推出：

AGI 出现

这中间至少还缺：

算法突破
数据
训练范式
泛化机制
世界模型
长期记忆
Agent reliability

甚至我们对“AGI”本身都没有一个统一的工程定义。

所以俺更愿意说：

【AI Infra 提高了探索未知算法空间的预算。】

这个说法更加准确。

---

俺的点评：这场战争真正有意思的地方是什么？

AI 正把计算机系统的“老知识”重新推到聚光灯下

俺觉得特别有意思的一件事情是：

很多所谓最新的 AI Infra 创新。

扒开以后。

你会看到一堆几十年前就出现过的思想：

Caching
Paging
Scheduling
Speculative Execution
Load Balancing
Data Locality
Batching
Pipeline
Prefetch

AI 并没有让计算机科学的基本规律失效。

恰恰相反：

【AI 把这些规律放大到了一个前所未有的经济规模。】

以前：

一个 cache miss 多几十纳秒。

现在：

一次 cache 策略设计失误可能浪费几百万美元 GPU capacity。

所以过去课堂里的：

OS
Computer Architecture
Distributed Systems
Algorithms
Queueing Theory

突然全部复活了。

---

未来 AI 工程师可能会越来越像“系统工程师”

过去几年很多人学 AI 的路径是：

PyTorch
Transformer
Fine-tuning
Prompt Engineering

以后如果你想进入真正硬核的 AI Infra：

可能还需要：

CUDA
Triton
Compiler
Operating System
Distributed System
Networking
Performance Modeling

因为模型越来越不像：

【一个神经网络。】

而更像：

【运行在全球数据中心上的分布式计算系统。】

---

最值钱的优化往往不是算法更聪明，而是“不做无用功”

把本文所有技术再看一次：

RadixAttention

本质：

算过的不要再算

KV Cache

本质：

算过的不要再算

Continuous Batching

本质：

空出来的位置别浪费

PagedAttention

本质：

显存别碎片化浪费

P-D Disaggregation

本质：

不同任务不要互相拖累

Speculative Decoding

本质：

昂贵模型少跑几次

Quantization：

没必要用那么多 bit 就别用

你会发现一个特别朴素的规律：

【最强的优化，经常就是消灭浪费。】

这和 Unix 哲学其实很像。

不是先问：

怎么增加更多资源？

而是先问：

为什么现有资源没有被正确使用？

---

这也是为什么俺看好开源 Infra

过去的软件史已经不断证明：

一旦基础设施技术被开源、标准化：

它就会迅速从：

【竞争优势】

变成：

【行业基础能力】。

Linux 是这样。

LLVM 是这样。

Kubernetes 是这样。

数据库生态也是这样。

今天：

vLLM

SGLang

Triton

以及大量开源 kernel 和通信组件正在做类似的事情。

真正深远的影响可能不是：

某个 benchmark 快了 30%。

而是几年以后：

一个只有十几个工程师的创业团队，也可以使用以前只有超级实验室拥有的推理优化能力。

这才是开源带来的：

【能力扩散。】

---

引申阅读：如果想真正搞懂 AI Infra，应该读什么？

先补操作系统

强烈推荐：

《Operating Systems: Three Easy Pieces》

简称：

OSTEP

重点看：

Virtual Memory
Paging
Scheduling
Concurrency

读完以后再看：

PagedAttention

你会产生一种非常强烈的感觉：

哦，原来你们又把操作系统那套东西搬过来了。

这是好事。

优秀的工程，本来就经常是旧思想在新约束下的重新组合。

---

然后补计算机体系结构

推荐：

《Computer Architecture: A Quantitative Approach》

重点理解：

Memory Hierarchy
Bandwidth
Latency
Arithmetic Intensity
Amdahl's Law
Parallelism

如果不懂这些，你看：

FP8
FlashAttention
Kernel Fusion
Decode Memory Bound

很容易停留在背名词。

真正搞懂以后，你会自动开始问：

数据在哪？

要搬多少？

算多少？

谁在等谁？

这四个问题几乎可以审问所有 Infra 系统。

---

然后读几个关键论文

第一篇：

ORCA

核心关键词：

Iteration-Level Scheduling

它帮助理解为什么生成模型不能继续使用传统静态 batching 的思路。

第二篇：

vLLM / PagedAttention

核心关键词：

KV Cache
Memory Fragmentation
Paging

这是把 OS 虚拟内存思想重新应用到 LLM serving 的代表性工作。

第三篇：

SGLang

核心关键词：

RadixAttention
Prefix Reuse
Structured LLM Programs

尤其值得看看为什么复杂 LLM applications 会产生大量可复用 prefix。

第四篇：

Speculative Decoding

核心关键词：

Draft
Verify
Rejection Sampling

它非常漂亮地展示了：

【用便宜模型预测，用昂贵模型批量验证】

这个思想。

---

最后，俺留几个问题给诸位读者

问题一：

假设你有一个 AI Agent。

每次请求：

20,000 tokens System Prompt
+
100 tokens User Query

那么：

是优先优化模型 FLOPS，

还是优先优化 prefix cache？

为什么？

---

问题二：

假设未来 HBM bandwidth 提升 10 倍。

但是 FLOPS 只提升 2 倍。

那么：

Prefill

和：

Decode

两个阶段的瓶颈会怎样变化？

---

问题三：

假设你已经实现：

99% GPU Utilization

但是 cost/token 反而变高。

这说明什么？

你的 GPU 到底是在：

【高效工作】

还是：

【高效浪费】？

---

问题四：

如果 KV Cache 最终可以：

GPU
↓
CPU
↓
Remote Memory
↓
SSD

多层存储。

那么未来 LLM serving runtime 会不会越来越像一个：

【专门为 Transformer 设计的操作系统】？

---

问题五：

如果推理框架负责：

Scheduling
Memory
Network
Cache
Load Balancing
Fault Recovery

训练框架又开始负责：

Rollout
Serving
Reward
Weight Sync

那么最终所谓：

AI Framework

和：

Operating System

之间的边界到底在哪里？

---

结语：AI 的下一场战争，可能不是谁买的 GPU 更多，而是谁浪费得更少

过去两年，人们习惯用一个非常简单的公式理解 AI：

更大的模型
+
更多的数据
+
更多的 GPU
=
更强的 AI

这个公式以后恐怕要改。

至少应该变成：

Model
×
Algorithm
×
Data
×
Hardware
×
Infrastructure Efficiency

这里最值得注意的是：

【乘法。】

如果 Infra 效率特别差：

硬件再多，也会被浪费。

而当算力投入已经进入千亿美元级别以后：

哪怕只是：

5%

的系统效率变化。

背后都可能对应：

极其庞大的资本差异。

这就是为什么今天：

KV Cache

这种听起来无比枯燥的东西，会成为 AI 行业最重要的战场之一。

这也是为什么：

RadixAttention

Continuous Batching

PagedAttention

P-D Disaggregation

Speculative Decoding

FP8

以及类似 Miles 的训练—推理协同系统，会获得如此高的关注。

它们解决的看似是不同问题。

实际上都指向同一个目标：

【尽量减少昂贵计算资源的无效状态。】

换句话说：

过去 AI 行业主要在问：

俺还能买多少 GPU？

未来越来越多人会问：

俺已经买来的这些 GPU，到底有多少时间在真正干活？

这两个问题之间的区别，非常重要。

前者是：

【堆资源。】

后者是：

【做系统。】

而计算机工业几十年的历史反复告诉俺们：

真正能够把一个技术从实验室玩具变成全民基础设施的，往往不是某一次漂亮的 Demo。

而是后面那群默默研究：

缓存
调度
内存
网络
编译器
容错

的人。

他们的工作没有聊天机器人那么吸睛。

甚至绝大多数普通用户一辈子都不会知道：

RadixAttention

或者：

PagedAttention

是什么东西。

但是当某一天：

AI 推理价格下降 90%；

普通电脑也能跑强模型；

创业公司不再需要养几十个人的 Infra 团队；

大规模 Agent 真正进入生产环境；

你看到的表面现象可能是：

“AI 又进步了。”

而水面下面真正发生的事情，很可能只是：

【终于有人想办法，让那些价值几万美元一张的 GPU 少摸了一点鱼。】

这，才是 AI Infra 最有意思滴地方。