大模型推理入门：从原理到实践

写给谁看的？ 听说过 ChatGPT、DeepSeek、通义千问，想搞明白"大模型到底是怎么回答问题的"、想了解本地部署和推理框架区别的同学。不要求你有 AI 背景，我尽量用人话讲清楚。

一、先搞懂：什么是"推理"？

你用 ChatGPT 提问，它"思考"几秒钟后给你一段回答------这个过程就叫推理（Inference）。

"推理"这个词听起来很玄，其实本质就是：输入一段文本，输出一段文本。和你在键盘上打字差不多，只是大模型"打字"的速度是每秒钟几十到几百个字。

一次推理 = 两个阶段：预填充 + 解码

很多人以为模型"回答"是一步完成的，其实内部被切成了两个画风完全不同的阶段。理解这两个阶段，后面所有内容（优化技术、选框架、买服务器）都会豁然开朗。

阶段一：预填充（Prefill）------"读题"

你发过去的所有内容（提示词 + 对话历史 + 问题），模型要一次性全部读完，理解上下文，并"想好"第一个字该输出什么。

特点：并行计算 ，几千上万个 Token 同时处理，吃的是算力（FLOPS）
决定的指标：TTFT（首字延时）------你按下回车后，等待第一个字蹦出来的时间
你输入越长（比如贴一篇 8 万 Token 的文档），预填充越久，首字等得越久

阶段二：解码（Decode）------"答题"

想好第一个字之后，模型开始一个 Token 接一个 Token 往外蹦，直到生成结束。

特点：串行生成 ，每生成一个 Token 都要把模型权重从显存里读一遍，吃的是显存带宽（GB/s）
决定的指标：TPS（输出吞吐）------你看到回答往外"打字"的快慢
模型越大，每次要读的权重越多，单流速度越慢

💡 一句话心法（后面反复用到） ：

算力决定首字延时，带宽决定输出速度。

这就是为什么同一张显卡，跑同一个模型，"首字快但打字慢"或"首字慢但打字快"都可能出现------两个阶段卡的是不同的资源。

用考试类比：预填充是把 100 道题的题干一口气读完（考验阅读速度），解码是逐题写答案（考验写字速度）。题干越长，读题越久；答案越长，写得越久。两件事瓶颈完全不同。

理解了这两个阶段，你就能回答这些现实问题：

为什么有的模型"等半天才出第一个字，出来之后刷刷刷"？------TTFT 慢但 TPS 快，卡在预填充算力。
为什么有的模型"秒回第一个字，但后面半天蹦一个字"？------TPS 慢，卡在解码带宽。
为什么本地跑 7B 模型只要 8GB 显存，跑 70B 要 80GB？------权重显存和参数量成正比。
为什么 vLLM、Ollama 这些框架能让推理快好几倍？------它们优化的正是这两个阶段的资源利用。

下面我们就一层层拆开看。

二、大模型推理的完整流程

一次完整的推理，大致要经历 6 个阶段：

📌 图注：从输入到输出的完整 6 步流程一览------先把你的问题变成 Token，模型逐个计算概率，采样选出下一个 Token，循环往复直到生成结束。下面逐个阶段拆开讲。

阶段 1：接收输入（Prompt）

你发给大模型的所有内容------系统提示词、对话历史、当前问题------都叫输入（Prompt）。比如：

复制代码

系统：你是一个友好的助手
用户：介绍一下大模型推理

阶段 2：分词（Tokenization）

大模型看不懂中文、英文，它只认数字。所以第一步是把文字切成一个个Token（词元），再把 Token 映射成整数 ID。

举个例子：

复制代码

原文：   "介绍一下大模型推理"
分词后： [介绍, 一下, 大, 模型, 推理]
Token ID：[21435, 7812, 19205, 5128, 9245]

为什么要切？ 因为大模型的"字典"是有限的（一般 10-20 万词），它只能处理字典里有的 Token。这样既能压缩文本，又方便后续用数学计算。

💡 小知识：1 个中文字 ≈ 1.5 个 Token，1 个英文单词 ≈ 1-2 个 Token。一句话 "Hello world" 大约是 2 个 Token。

阶段 3：模型前向计算

这一步是真正"烧显卡"的环节。Token ID 序列被喂给一个深度神经网络 （一般是 Transformer 架构），经过几十上百层的数学运算，输出一个向量------本质上是一串浮点数，代表"模型对下一个 Token 的预测"。

你可以把它理解为：模型看完前面所有 Token，给每个候选 Token 打一个分数。

阶段 4：选择下一个 Token（采样）

模型算完分数后，不能直接选分数最高的字（那样太死板，回答会很无聊）。通常会用一个采样策略来决定下一个 Token：

贪心解码（Greedy）：永远选分数最高的。最快但最无聊。
Top-K 采样：从分数最高的 K 个 Token 里随机选。K=50 比较常见。
Top-P 采样（Nucleus Sampling）：从累计概率达到 P 的 Token 里随机选。P=0.9 比较常用。
温度（Temperature）：参数越大越"放飞自我"，越小越"稳重"。

比如设置 temperature=0.7 + top_p=0.9，模型既不会胡说八道，也不会每次回答都一模一样。

阶段 5：循环生成（自回归）

关键来了 ：大模型是一个 Token 一个 Token 往外蹦的。

它生成第 1 个 Token 后，会把这个 Token 拼到原文后面，再喂给模型算第 2 个 Token；然后再拼，再算第 3 个......直到生成特殊的"结束符"（<EOS>）才停下来。

这个"生成一个、拼回去、再生成"的过程叫自回归（Autoregressive）。

对应回第一章的两阶段：阶段 1-3 处理你的输入，就是"预填充"（一次并行算完，产出第一个 Token）；阶段 4-5 循环往外蹦字，就是"解码"（每次只算一个 Token）。

💡 这就是为什么大模型回答有"打字机效果"------它确实是一个字一个字生成的，只不过算得快，所以看起来像一口气说完。

阶段 6：还原成文字（Detokenization）

生成的 Token ID 序列要重新映射回文字，拼成完整回答返回给你。比如：

复制代码

Token ID：[21435, 7812, 19205, 5128, 9245, 233, 8845]
还原为： "介绍一下大模型推理的过程"

整个推理流程就完成了。

三、推理的底层原理：4 个关键概念

光知道流程还不够，要真正理解推理为什么慢、为什么能优化，必须搞懂下面 4 个核心概念。

1. Token：大模型的"原子单位"

前面说过，Token 是大模型的最小处理单位。但你可能要问：为什么不直接按字/词切？

答案是：效率和泛化性的平衡。

按字切：字典小（中文就 6000+ 字），但每个字的信息量低，序列会很长。
按词切：信息量大，但字典巨大（几十万个词），训练时很多词出现次数太少，学不好。
按 Token 切（子词）：取中间值。常见字/词切成 1 个 Token，生僻词切成多个 Token。平衡得最好。

主流的 Tokenizer 算法有：

算法	代表模型	特点
BPE	GPT 系列	按频率合并字符
WordPiece	BERT	类似 BPE，按似然合并
SentencePiece	LLaMA、通义千问	直接从文本训练，不依赖预分词

2. 自回归（Autoregressive）：为什么不能并行？

自回归有个明显缺点：每次只能算一个 Token。生成 1000 字就要跑 1000 次模型，这显然很慢。

那为什么不一次算完？因为下一个 Token 取决于前面所有 Token。模型要先知道你前面说了什么，才能决定下一个字最可能是什么。

这就像写作文------你得先写完第一句，才能想第二句写什么；不能 100 句话同时写出来。

💡 不过研究人员发明了**投机解码（Speculative Decoding）**等技巧，可以让推理"看起来"并行，速度能提 2-3 倍。后文会讲。

3. KV Cache：推理加速的核心

自回归有个隐藏的重复计算：每次算第 N 个 Token 时，模型都要重新"看一遍"前 N-1 个 Token。但前面 N-1 个 Token 的计算结果其实没变啊？

这就是 KV Cache（键值缓存） 解决的问题：

📌 图注：上面是「无 KV Cache」------每个 Token 的 Query 都要和前面所有 Token 的 Key/Value 重新算一遍，复杂度 O(n²d)；下面是「有 KV Cache」------把算过的 Key/Value 缓存起来，只算新 Token 的 Query，K/V 直接从缓存复用，复杂度降为 O(nd)。KV Cache 通过复用已存储的 K/V 避免冗余计算，让推理更快、更省显存。

KV Cache 让推理速度快了几十倍，是现代推理框架的标配。

但 KV Cache 也不是没有代价------它非常吃显存。一个 7B 模型生成 2048 个 Token 的 KV Cache 大约要 2-3GB 显存。生成越长，KV Cache 越大。这就是为什么长上下文推理特别烧显存。

4. 采样策略：决定回答"性格"

前面提到温度、Top-K、Top-P。这些参数到底怎么影响输出？

参数	值小	值大
Temperature	输出保守、可预测	输出多样、有创意
Top-K	候选少、质量稳	候选多、可能跑偏
Top-P	候选少、聚焦	候选多、灵活

经验组合：

代码生成、数学题：temperature=0, top_p=0（要确定性答案）
创意写作：temperature=0.8, top_p=0.95（要多样性）
通用对话：temperature=0.7, top_p=0.9（平衡）

四、推理优化技术：让模型跑得更快

光搞懂原理还不够，工程师们还开发了一系列优化技术让模型跑得更快、更省资源。下面这 4 个是绕不开的。

1. 量化（Quantization）：压缩模型体积

模型权重本来是 FP32（32 位浮点数） 存储的，一个参数占 4 字节。7B 模型就有 28GB，根本塞不进普通显卡。

量化就是把高精度数字用低精度表示，比如：

精度	每参数字节	7B 模型大小	推理速度	质量损失
FP32	4	28 GB	1x	无
FP16/BF16	2	14 GB	2x	几乎无
FP8	1	7 GB	3-4x	几乎无感
INT8	1	7 GB	3-4x	轻微
NVFP4/INT4	0.5	3.5 GB	5-8x	可控

主流的量化方法：

GPTQ：训练后量化，针对 GPU 优化
AWQ：激活感知量化，保持重要通道的精度
FP8 / NVFP4 ：NVIDIA Hopper/Blackwell 架构原生支持的精度格式，不需要软件转译，是当前生产环境的主力选择
GGUF（llama.cpp）：CPU/Apple Silicon 友好，社区主流格式

💡 经验之谈：个人玩用 INT4/GGUF 就够了；生产部署在 Blackwell/Hopper 卡上优先用 FP8（质量稳妥）和 NVFP4（吞吐更高），第七章有实测数据支撑。

2. PagedAttention：vLLM 的看家本领

要搞懂 PagedAttention，先得明白它解决的是什么问题。

问题从哪来？ 回忆一下 KV Cache：每个请求的对话越长，KV Cache 越大。麻烦在于------你事先不知道用户会聊多长。

传统做法：预订一整层房间

传统推理框架把每个请求的 KV Cache 放在一段连续的显存里，而且要按"最坏情况"预留。就像酒店接待一个旅行团：

你不知道客人实际要住几晚，干脆按"最多可能住 7 晚"预留 7 间房
而且这 7 间房必须是同一层连着的一排（连续显存）
结果客人只住了 2 晚，剩下 5 间空着，别的客人也住不进来
更糟的是：想找一排连着的 7 间空房越来越难（显存碎片化），明明酒店还有 40% 空房，新客人却被拒之门外

实测下来，传统方式只有 30-50% 的 KV Cache 显存真正被利用，剩下全是预留浪费 + 碎片浪费。

PagedAttention：按间分配，住几间开几间

vLLM 的做法借鉴了操作系统"虚拟内存分页"的思想，变成这样：

房间不再要求连着------201 房、507 房、1203 房都可以分给同一个客人
住 1 晚开 1 间，退房立刻还给酒店，分给下一个客人
酒店前台有个小本子（页表），记录"每位客人住的是哪几间房"，要用时随时查

效果立竿见影：

复制代码

传统方式：按最大长度连续预留 → 显存利用率 30-50%，长对话容易被拒
PagedAttention：按需分页 + 页表索引 → 显存碎片接近零，利用率 80%+

实际收益 ：同样一张显卡，能同时服务的请求数翻了几倍，吞吐量提升 2-4 倍。这就是 vLLM 火遍全球的核心原因。

3. Continuous Batching：动态批处理

先说清楚"批处理（Batching）"是什么：GPU 一次只服务 1 个请求时大量算力在闲着，同时服务 8 个、16 个请求反而效率更高------就像公交车拉 1 个人和拉 30 个人，油耗差不多。所以推理服务会把多个请求凑成一批一起算。

但传统的凑批方式有个尴尬。

传统静态批处理：大巴包车

就像旅行社包一辆 30 座大巴：

凑满 30 个游客才发车（等凑批）
中途不停车------就算有游客到站了，也得坐在车上，等全车人跑完全程一起回
大模型这边对应：请求 A 只需要生成 50 个 Token，早就生成完了，但必须等批里最长的请求（比如要生成 2000 个 Token 的）全部跑完，整批才能结束
结果：GPU 大部分时间在给"已经下车的乘客"空跑座位，利用率极低

Continuous Batching：地铁

vLLM、TGI 这些框架改成了"地铁模式"：

列车到站，生成完的请求随时下车（立即返回结果）
新请求随时上车（立刻插入当前批，补上空位）
车厢始终保持满载运行，GPU 一刻不闲

📌 图注：静态批处理像大巴，要等凑满才发车，最长的请求拖累全车；Continuous Batching 像地铁，生成完的请求随时下车，新请求立刻补位，GPU 接近时刻满载。

实际收益 ：多用户并发场景下吞吐量提升 2-10 倍 ，而且每个请求的等待时间大幅缩短（不用等凑批）。这也是为什么企业级服务几乎都选 vLLM / TGI / LMDeploy 这类支持 Continuous Batching 的框架，而不是直接用 transformers 的 generate()。

4. Speculative Decoding：用小模型"猜"大模型

前面提到自回归"不能并行"的缺陷。投机解码的思路很巧妙：

用一个小模型快速预测接下来的 K 个 Token（比如 K=5）

把这 K 个 Token 一次性喂给大模型验证

大模型并行算出每个 Token 的分数，能接受的留下，不能接受的丢弃

至少能"白嫖" 1-3 个 Token

复制代码

┌─────────────────────────────────────────┐
│ 小模型先猜 5 个 Token：                  │
│ "今天 / 天气 / 真 / 好 / 适合"          │
├─────────────────────────────────────────┤
│ 大模型一次验证：                         │
│ ✅ "今天" ✅ "天气" ✅ "真" ❌ "好"      │
│ → 接受 3 个，从"好"开始重新猜           │
└─────────────────────────────────────────┘

速度提升 2-3 倍，质量与大模型完全一致（数学上严格等价）。这是当前最受关注的优化方向之一。

五、主流推理框架对比

搞懂了原理和优化技术，现在来聊聊"工具"。市面上的推理框架挺多，选哪个取决于你的场景。

整体生态

📌 图注：横轴代表易用性，纵轴代表性能------没有"最好"的框架，只有"最适合你的场景"的框架。

详细对比

1. vLLM ------ 性能王者

官网：https://github.com/vllm-project/vllm
定位：生产级高并发推理服务
核心特性 ：
- PagedAttention（显存利用率高）
- Continuous Batching（吞吐量高）
- 支持几乎所有主流开源模型
适用场景：企业级 API 服务、高并发在线推理
上手难度：⭐⭐（需要懂 Python 和 CUDA 环境）

bash 复制代码

# 一行命令启动服务
python -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2.5-7B-Instruct \
    --port 8000

💡 优点：吞吐王者，社区活跃。

缺点：对新手不友好，依赖复杂（需要装 CUDA、PyTorch）。

2. Ollama ------ 小白首选

官网：https://ollama.com
定位：本地一键运行大模型
核心特性 ：
- 内置 llama.cpp，无需懂技术
- 一行命令拉模型：ollama pull qwen2.5:7b
- 自动提供 REST API
- macOS/Linux/Windows 全平台
适用场景：本地体验、个人学习、原型开发
上手难度：⭐（超简单）

bash 复制代码

# 安装后三步搞定
ollama pull qwen2.5:7b        # 下载模型
ollama run qwen2.5:7b         # 命令行对话
# 或者直接访问 http://localhost:11434 的 API

💡 优点：零配置、跨平台、社区模型多。

缺点：高并发性能不如 vLLM。

3. llama.cpp ------ 极客玩具

官网：https://github.com/ggerganov/llama.cpp
定位：CPU/边缘设备推理的鼻祖
核心特性 ：
- 纯 C++ 实现，几乎零依赖
- GGUF 格式量化模型（GGML 的继任者）
- 支持 CPU、Apple Silicon、GPU
适用场景：无独立显卡的玩家、低配电脑、嵌入式设备
上手难度：⭐⭐⭐（需要编译）

💡 优点：极致轻量，能在树莓派、手机上跑。

缺点：要自己编译，没有 vLLM 那么"开箱即用"。

4. TGI（Text Generation Inference）------ HuggingFace 出品

官网：https://github.com/huggingface/text-generation-inference
定位：HuggingFace 官方推理服务
核心特性 ：
- Rust + Python 混合实现，性能接近 vLLM
- 与 HuggingFace 生态无缝集成
- 内置 Prometheus 监控
适用场景：已经用 HuggingFace 模型、需要生产部署
上手难度：⭐⭐

💡 优点：HF 生态友好、监控完善。

缺点：模型支持面比 vLLM 稍窄。

5. TensorRT-LLM ------ NVIDIA 亲儿子

官网：https://github.com/NVIDIA/TensorRT-LLM
定位：NVIDIA GPU 上的极致性能
核心特性 ：
- 基于 NVIDIA TensorRT 深度优化
- 支持 FP8 推理（H100/H200 专属）
- 性能通常比 vLLM 还快 10-20%
适用场景：有 NVIDIA 高端卡、追求极致性能
上手难度：⭐⭐⭐⭐（需要编译引擎，门槛高）

💡 优点：NVIDIA 卡上的性能天花板。

缺点：仅支持 NVIDIA 卡、配置复杂、迭代慢。

6. LMDeploy ------ 国产之光

官网：https://github.com/InternLM/lmdeploy
定位：书生·浦语团队开发的高性能推理框架
核心特性 ：
- Persistent Batch（比 Continuous Batching 更进一步）
- 对国产模型（Qwen、InternLM、DeepSeek）支持好
- 支持量化、TurboMind 引擎
适用场景：国内企业部署国产模型
上手难度：⭐⭐

框架选择速查表

你的情况	推荐框架	理由
我就想本地玩玩	Ollama	一键安装，零配置
我电脑没有 N 卡	llama.cpp / Ollama	CPU 也能跑
我要给业务做 API	vLLM	高并发首选
我只用 HuggingFace 模型	TGI	生态最顺
我有 H100 想榨干性能	TensorRT-LLM	极致性能
我部署国产开源模型	LMDeploy	国产适配好

六、上手指南：5 分钟跑起来一个模型

理论看再多不如实际跑一下。这里用最简单的方式演示：

方案 A：用 Ollama（推荐新手）

bash 复制代码

# 1. 下载安装（macOS / Linux）
curl -fsSL https://ollama.com/install.sh | sh

# 2. 拉一个模型
ollama pull qwen2.5:7b

# 3. 开始对话
ollama run qwen2.5:7b
# > 你好，请介绍一下自己
# 你好！我是通义千问...

方案 B：用 vLLM（进阶）

bash 复制代码

# 1. 安装
pip install vllm

# 2. 启动 OpenAI 兼容服务
python -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2.5-7B-Instruct

# 3. 用任何 OpenAI 客户端连接
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen2.5-7B-Instruct",
    "messages": [{"role": "user", "content": "你好"}]
  }'

方案 C：用 HuggingFace Transformers（最基础）

python 复制代码

from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

model = AutoModelForCausalLM.from_pretrained(
    "Qwen/Qwen2.5-7B-Instruct",
    torch_dtype=torch.float16,
    device_map="auto"
)
tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B-Instruct")

prompt = "介绍一下大模型推理"
inputs = tokenizer(prompt, return_tensors="pt").to("cuda")
outputs = model.generate(**inputs, max_new_tokens=200)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

💡 选哪个？

个人学习 → Ollama

二次开发 → Transformers

部署服务 → vLLM

七、部署最佳实践：从原理到选型落地

前面讲了那么多原理，最后回答一个最实际的问题：我要部署模型，到底该怎么选硬件、选精度、选模型？

这一节我们把前面的原理串起来用：预填充/解码两阶段决定了你要看的指标，KV Cache 决定了显存怎么算，量化决定了模型能塞进多大的卡。

第一步：算显存------部署前必做的一道算术题

部署任何模型之前，先算三笔账：

复制代码

所需显存 ≈ ① 模型权重 + ② KV Cache + ③ 运行开销（约为前两项的 10%-20%）

① 模型权重：取决于参数量和精度，这是大头。

模型规模	FP16/BF16（2字节）	FP8（1字节）	NVFP4/INT4（0.5字节）
7B	14 GB	7 GB	3.5 GB
14B	28 GB	14 GB	7 GB
27B~32B	54~64 GB	27~32 GB	~16 GB
70B	140 GB	70 GB	35 GB
MoE 总参 671B（如 DeepSeek 系列）	放不下	放不下	~336 GB（多机）

💡 MoE 模型注意 ：像 Qwen3.6-35B-A3B 这种名字里带 A3B 的，是"总参数 35B、每次激活 3B"的 MoE 模型------权重显存按总参数算 （35B 全都要装进显存），但解码速度按激活参数算（每次只读 3B 的权重，所以带宽压力小、速度快）。这就是 MoE 模型"又大又快"的秘密。

② KV Cache ：取决于上下文长度和并发数。经验公式很复杂，给你一个直观感受------一个 27B 级模型开满 256K 上下文，单路 KV Cache 就可能吃掉 10-20GB；8 路并发就是 80-160GB。这就是为什么长上下文场景对显存的需求经常超过模型本身。

③ 运行开销：CUDA 上下文、激活值、框架本身，预留 10%-20% 比较稳妥。

实操建议：显存按"权重 × 1.5~2 倍"规划，留足 KV Cache 和长上下文的余量。例如单张 72GB 显存的卡，部署 27B 模型建议用 FP8（权重 27GB），剩余 40GB+ 全部留给 KV Cache 和并发，是舒服的配置。

第二步：选精度------生产环境的现实选择

精度选择的权衡就一句话：精度越低 → 权重越小 → 能装的模型更大、带宽读取更快 → 但能力有损。

当前（2026 年）生产环境的主流选择：

精度	适用场景	说明
BF16/FP16	效果验证、基准测试	显存翻倍，生产很少用
FP8	主力生产精度	Blackwell/Hopper 卡原生支持，损失几乎无感
NVFP4/INT4	追求吞吐和并发	实测多数场景吞吐更高，个别复杂推理任务略有下降

📌 实测参考（来自 1Panel AI 一体机单卡 RTX Pro 5000 72GB 部署 Qwen3.8-27B 的对比测试）：

NVFP4 精度在多数并发区间下 TTFT（首字延时）优于 FP8，长上下文场景优势更明显；

整机吞吐 NVFP4 高于 FP8，尤其长上下文场景；

智能体/编程等超长上下文（84K 输入）场景，两种精度吞吐接近（80-100 tokens/s），人均并发 4 路是体验甜点。

结论：日常知识库问答、办公场景放心用 NVFP4 榨吞吐；对复杂推理质量要求极高的场景用 FP8 保底。

第三步：对照硬件------你手上的卡能跑什么

结合 1Panel AI 一体机（1panel.cn/ai-appliance.html）的官方配置和实测数据，给你一张"卡 ↔ 模型"对照表：

硬件配置	显存/内存	合适的模型与精度	定位
消费级 8-12GB（4070/4080 等）	8-12 GB	7B INT4、3-4B FP8	个人尝鲜
单张 RTX Pro 5000	72 GB	27B FP8/NVFP4、35B-A3B MoE	小团队主力
双张 RTX Pro 5000	144 GB	27B + 35B-A3B 双模型，或单模型高并发	部门级
四张 RTX Pro 5000	288 GB	Flash 级 MoE 旗舰模型（DeepSeek-V4-Flash 等）	企业旗舰
单/双 GB10	128/256 GB 统一内存	MoE 模型（FP4 原生）、视频生成模型	桌面级入门

案例 A：GB10 能部署什么？------先读懂这颗"小钢炮"的脾气

NVIDIA GB10（Grace Blackwell 超级芯片，即 DGX Spark 同款）是 CPU+GPU 二合一的桌面级 SoC：128GB LPDDR5x 统一内存 、约 1 PFLOP 的 FP4 稀疏算力、但内存带宽只有约 273GB/s（对比数据中心卡的 HBM 动辄 3-8TB/s）。

用第一章的心法来分析它：

预填充（吃算力）：GB10 算力富余，预填充速度可达 1500-2000 tokens/s，TTFT 不虚；
解码（吃带宽） ：273GB/s 是硬天花板------稠密模型每生成一个 Token 要读全部权重 ，跑 27B 稠密模型解码会明显偏慢；而 MoE 模型每次只读激活的少量专家，带宽压力骤减。

所以 GB10 的最佳搭档是 MoE 稀疏模型。官方实测（双 GB10 节点 / 256GB 统一内存 / 200Gbps ConnectX 互联，部署 DeepSeek-V4-Flash 原生 FP8+FP4 混合精度，vLLM 引擎）：

指标	实测数据
整机解码吞吐	100-120 tokens/s（短/中/长/超长上下文）
OpenClaw、WorkBuddy 真实办公负载（2 并发）	> 60 tokens/s，两周稳定运行
整机功耗	< 80W（放办公室桌面就能跑，年电费几百块）

选型结论 ：GB10 版适合数据敏感、预算受限的中小团队 做"数据不出域"的合规闭环，以及夜间批处理副机（批量总结、建索引）；不适合秒级响应的实时高并发客服场景------带宽瓶颈决定了它是"专精特工"，不是"全能主力"。

案例 B：2 张 RTX Pro 5000（144GB 显存）怎么部署？

这是 1Panel AI 一体机的方案三（旗舰工作站配置，CPU 为 Core Ultra 9 285K）。基于 144GB 显存，有两种典型打法：

打法一：双模型分卡部署（官方预置方案）

卡 1：Qwen3.8-27B（FP8，权重约 27GB，剩余显存跑并发）
卡 2：Qwen3.6-35B-A3B（MoE，激活 3B，解码快）
通过 1Panel AI 网关做统一接入和智能路由：常规任务走 27B，长上下文/轻任务走 MoE

好处：一机两模型互为备份，覆盖不同场景，单模型故障不宕机。

打法二：单模型双卡并行，堆并发

两张卡通过张量并行跑同一个 27B 模型（FP8），显存合并 144GB 全部给 KV Cache
适合并发量大的部门级场景（几十人同时用），单模型吞吐上限显著高于分卡部署

怎么选？ 团队小于 30 人、场景多样 → 打法一；团队大于 50 人、集中在知识库问答 → 打法二。

单卡 Pro 5000 的能力边界（实测）：短对话峰值吞吐 700-857 tokens/s；超长上下文（84K 输入，Prefix Cache 命中 90%）时整机 80-100 tokens/s，人均 4 并发是甜点。超长上下文与高并发不可兼得，重负载要么限并发，要么扩卡。

进阶：企业级的"分级算力池"架构

内部 300+ 人团队的真实实践（供参考）：

📌 图注：通过 1Panel AI 网关统一接入后，流量按任务特征智能路由到三类算力池：本地主力池负责高频常规任务，本地精锐池负责复杂推理，云端兜底池承担突发峰值。

实测数据：周请求 20 万次、周 Token 消耗超 100 亿、本地模型承担 70% 流量、Prefix Cache 命中率 85%、高峰并发 23。整体推理成本相比纯云端方案大幅降低。

部署心法总结

把这一节浓缩成四句话：

先算账：显存 = 权重 × 精度 + KV Cache（按上下文和并发）+ 20% 余量
精度务实：生产 FP8 起步，吞吐敏感用 NVFP4，别用 FP16 烧显存
匹配瓶颈：算力决定首字延时（看 TTFT），带宽决定输出速度（看 TPS）------选硬件先想清楚你的业务卡在哪一头
架构兜底：本地主力 + 云端弹性，用 AI 网关统一路由，别把所有鸡蛋放一张卡里

八、常见问题（FAQ）

Q1：为什么大模型回答有快有慢？

主要看 三个因素：

生成的 Token 数：回答越长越慢
模型大小：70B 比 7B 慢约 10 倍
硬件：H100 比 4090 快 3-5 倍

Q2：本地跑 7B 模型需要什么配置？

最低：8GB 显存（INT4 量化）或 16GB 内存（CPU）
推荐：16GB 显存（RTX 4090/5090），可以跑 FP16
舒适：24GB 显存（RTX 4090D），还能跑 13B

如果是团队级使用（几十人共享、知识库问答），建议直接看第七章的部署最佳实践------单张 72GB 的 RTX Pro 5000 跑 27B 模型（FP8）是当前性价比很高的起步配置。

Q3：为什么我的 GPU 利用率只有 30%？

大概率是 静态批处理 在浪费资源。换用支持 Continuous Batching 的框架（vLLM、TGI、LMDeploy）就能解决。

Q4：上下文越长，为什么越慢？

因为 KV Cache 与上下文长度成正比。4096 Token 的 KV Cache 是 1024 Token 的 4 倍大，既占显存又拖慢速度。

Q5：模型量化后效果会变差吗？

INT8：几乎无感
INT4：轻微可感知（个别细节可能丢失）
INT3 及以下：明显下降，不推荐

九、总结与进阶路径

一句话总结

大模型推理 = 预填充（一次读完全部输入，算力定首字延时）+ 解码（一个 Token 一个 Token 蹦，带宽定输出速度）+ KV Cache 缓存加速 + 采样策略定"性格"。

理解了这个过程，再看 vLLM、Ollama 这些框架就不会觉得神秘------它们做的事情就是让预填充和解码这两个阶段跑得更快、显存用得更省 ；选硬件也就有了依据------先看业务卡在算力（首字慢）还是带宽（打字慢），再按"权重 × 精度 + KV Cache"算显存。

✨ 写在最后：推理是连接"训练好的模型"和"用户"的桥梁------它决定了 AI 应用的体验上限。希望这篇文章能帮你建立从原理到部署的完整认知框架。如果觉得有帮助，欢迎点赞、收藏、转发支持～