Part V · 通往 AI 基建 · 第 14 章
14

云上的 GPU 与大规模 AI 推理

大模型推理是本书的终极应用题：昂贵 GPU、有限显存、突发请求、长尾延迟、多租户调度，所有云与 OS 的概念在这里汇合。

难度 前沿综合 用时 约 75 分钟 交互 LLM serving 流程 · batching/KV cache 取舍 路线 螺旋式：先抓大图，再深入机制

0先把地图摊开

大模型推理是本书的终极应用题：昂贵 GPU、有限显存、突发请求、长尾延迟、多租户调度，所有云与 OS 的概念在这里汇合。 本章不会把概念排成术语表，而是沿着一条真实系统路径走：先看它解决什么痛点，再看 OS/云平台怎样实现，最后回到工程取舍。

Prefill处理 prompt，生成第一批 KV cache 的阶段，计算密集。
Decode逐 token 生成输出的阶段，显存带宽和调度更关键。
KV cacheTransformer 为已处理 token 保存的 key/value 状态，是推理显存大头。
Continuous batching动态把不同请求的 decode 步骤交织成批，提高 GPU 利用率。
GPU 与 AI 推理上云 · 核心流程 分步动画 点击节点或用键盘 ← →
图 14.1核心机制路径。把这一章最容易散掉的流程压成可播放的五步。

14.1推理不是一次矩阵乘法

用户看到的是一个回答，系统看到的是排队、tokenization、prefill、decode、采样、流式返回、缓存回收。每一步都可能成为延迟或吞吐瓶颈。

14.2GPU 贵，所以空着就是事故

CPU 服务常担心线程太多，GPU 服务更怕 batch 太小。GPU 需要足够并行工作填满矩阵单元，但请求又有不同长度和到达时间。调度器必须把不整齐的用户流量整理成 GPU 喜欢的形状。

14.3KV cache 把显存变成调度资源

每个已生成 token 都留下 KV 状态。长上下文、多并发、长输出会迅速吃掉显存。PagedAttention、prefix caching、eviction、swap 都是在管理这块新型内存。

14.4连续批处理改变批的定义

传统静态 batching 等一组请求一起开始一起结束，容易被慢请求拖住。Continuous batching 让新请求不断加入，让已完成请求离开，GPU 每一步都尽量满。

14.5AI 基建是云计算的新压力测试

它需要 OS 的内存与调度直觉、云的多租户与伸缩、分布式的容错、Kubernetes 的编排、Serverless 的经济敏感。你学到的每章，都在这里用上。

GPU 与 AI 推理上云 · 取舍实验 可玩模拟器 切换策略，看指标怎么变
图 14.2工程取舍。云和 OS 的概念真正进入工程时，几乎都不是“选最好”，而是在约束之间找一个诚实的点。

↔云与 OS 的桥

这一章不是孤立知识点。下面这张表把它和前后章节接起来：你会看到，同一个机制在单机、云平台和 AI 基建里会换名字，但问题结构没变。

本章机制云上形态为什么重要
CPU 调度请求队列、优先级、preemption第 2 章的调度问题换成 GPU 版本。
虚拟内存PagedAttention、KV block manager第 3 章的 paging 直觉直接迁移到显存。
Kubernetes/伸缩GPU node pool、autoscaling、故障恢复模型服务必须被编排、观测、扩缩容和容错。
深潜 读完本章后，怎么确认自己真的懂了？›

不要只背定义。你应该能把一个线上现象翻译回机制：慢在哪里、谁在排队、哪个抽象漏了、哪个资源被过度承诺。下面三个检查点可以当成小作业。

本章收束 · 你现在握住了什么

  • 大模型推理是一条多阶段服务流水线，不是单次 forward。
  • GPU 利用率、TTFT、TPOT 和显存占用互相拉扯。
  • KV cache 是推理系统里的核心内存资源。
  • 连续批处理和分页式 KV 管理把 OS/云直觉带入 AI 基建。

全书到这里闭环：从一个请求出发，下挖到 OS，再盖回云与分布式，最终抵达大模型推理系统。