# 6.6 大模型的部署与推理：让模型跑起来

当我们在网页上向大模型提问，几秒钟后它就开始流利地回答我们时，你是否好奇过它在云端到底是怎样运行的？

在真实的工业级环境中，让大模型“跑起来”的过程被称为 **推理 (Inference)**。这并不是简单地在电脑上运行一段脚本程序，而是一个需要调用成千上万张昂贵显卡、极其复杂的系统工程。

## 6.6.1 算力与显存：谁更重要？

很多人以为大模型运行最耗费的是计算能力（算力），也就是 GPU 的处理速度。但在实际应用中，真正“卡脖子”的往往是 **显存容量** 和 **显存带宽**。

大模型在回答我们的问题时，它的工作可以分为截然不同的两个阶段：

1. **阅读阶段（预填充 Prefill）**：模型会把你发送的历史上下文和提示词一次性“吃”下去。这个阶段 **极度消耗算力（Compute-bound）**，GPU 会开足马力进行并发的矩阵运算。用户能否感受到秒回，取决于 **首字延迟（TTFT，Time to First Token）**。
2. **回答阶段（解码 Decode）**：模型像一台打字机一样，一个字一个字地往外蹦答案。因为必须等上一个字生成后才能去猜下一个字，这个阶段系统其实 **受限于内存带宽（Memory-bound）**。这时候 GPU 大部分时间处于等待数据的状态，主要时间都花在了从显存里把庞大的模型权重和历史记录来回搬运上。这就好比一个跑得飞快的厨师，却被狭窄的厨房运菜通道挡住了。这阶段的流畅体验取决于 **词间延迟（ITL，Inter-Token Latency）**。

## 6.6.2 吞噬显存的怪兽：KV Cache

为了不让模型在每生成一个新词时都必须把前面的整段话重新理解一遍，它会把读过和写过的字的中间计算结果存进这本记事本里。由于这段记录会随着对话的进行不断变长，因此 **上下文越长、并发用户越多，显存消耗也就急剧增加**。

> \[!NOTE] **显存占用的可计算规则**
>
> 在部署真实系统时，显存需要依靠明确的公式预估，而非仅靠直觉：
>
> **1. 纯权重显存** = 参数量 × 每参数所需字节数 比如知名的开源大模型 Llama 3 70B（700亿参数），在默认的半精度浮点数（FP16/BF16，即占 2 个字节）下：**$70 \times 10^9 \times 2 \text{ bytes} \approx 140\text{GB}$**。 这意味着，**如果直接用 FP16 加载，单张 80GB 的顶级显卡根本装不下哪怕仅仅是模型本身**，更别说进行推理对话了。书中过去关于“80GB 顶级显卡装几千亿参数的模型”的比喻在物理上是不成立的。 为此工程师们引入了 **量化技术（Quantization）**，把权重压缩成 INT8（1字节）或 INT4（0.5字节）。将其压缩至 INT4 后，纯权重只需大概不到 40GB，此时 80GB 的显卡才有充足的剩余空间装入。
>
> **2. KV Cache 显存** 模型在推理时还需要分配巨大的运行时显存来存放历史记忆 KV Cache。如果没有先进的内存分页技术（如基于 PagedAttention 思想的 **vLLM** 引擎），显存很快会碎片化导致崩溃（内存溢出 OOM）。

## 6.6.3 把显卡组装成超级大脑：分布式推理

既然单张甚至单台机器的显卡装不下，我们就必须用网络把十几台、甚至几百台服务器上的显卡连接起来一起算，这叫做 **分布式部署**。

它跑起来就像一家大型数据工厂在进行极其默契的流水线作业：

* **切分模型**：这半边神经网络交由显卡 A 计算，那半边交由显卡 B 计算。它们彼此之间通过极其昂贵且高速的内部网络（比如 NVLink 或专用的高速以太网）在微秒级别交换数据。
* **解耦工厂**：一些最前沿的 AI 公司，甚至会将整个数据中心切分为两波。一波机器纯粹负责“阅读长文”（计算集群），另一波机器纯粹负责“逐字打字”（显存带宽集群）。这就像餐厅的前台负责极速点单和备菜，后厨负责快速出餐，以此达到极高的接待效率。

**总结**：在几百亿、几千亿参数的巨兽面前，隐藏在幕后的“推理技术”决定了 AI 公司的成本底线与回答速度。当你每次惊叹于大模型一秒钟能写出几十个词的回复时，要知道，这背后是成百上千张昂贵显卡在高速光缆的连接下，进行着精妙绝伦的硬件接力赛。

## 6.6.4 思考题

为什么推理成本如此重要？如果推理成本降到现在的 1/100，会催生出什么样的新应用？


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/ai_beginner_guide/di-er-bu-fen-he-xin-ji-shu-jie-xi/06_llm/6.6_deployment.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.