一、模型名称拆解（选型第一步）

格式：系列-版本-参数量-后缀

部分	示例	含义
系列	Qwen, Gemma, Llama	研发团队
版本	3, 2.5, 4	代际，数字越大越新
参数量	0.6B, 8B, 26B	B=10亿参数，决定智商与资源
后缀	见下表	优化方式

---

二、精度与显存换算（理解后缀的前提）

模型权重显存 = 参数量(B) × 每参数字节数

精度	每参数字节	示例：8B模型权重
FP16 / BF16	2	16 GB
FP8	1	8 GB
INT4 / NVFP4	0.5	4 GB

量化后缀（如AWQ、NVFP4、FP8）的本质就是降低每参数的字节数，从而减少显存占用。

---

三、常见后缀速查（2026·详细版）

后缀	本质	精度/格式	显存占比（相对FP16）	适用场景	注意事项
AWQ / GPTQ	INT4整数量化	4bit整数	25%（4GB/8B）	通用首选，兼容性最好	vLLM/Ollama均完美支持
NVFP4	NVIDIA FP4浮点量化	4bit浮点	25%（4GB/8B）	RTX 50系专属，速度最快	需TensorRT-LLM或vLLM≥0.9
FP8	FP8浮点量化	8bit浮点	50%（8GB/8B）	长上下文首选，精度损失极小	40系/50系均支持，KV Cache压缩标配
GGUF	CPU/GPU混合推理	可调（常用Q4_K_M等）	灵活（可设层数）	显存<8GB 或 Mac 用户必选	用Ollama/llama.cpp，非vLLM
A4B / MoE	混合专家架构	总参数不变	总参数×精度（26B约13GB FP16）	推理快（激活少），显存不省	26B-A4B仍需加载26B权重，勿被“A4B”误导
Distill	知识蒸馏小模型	独立训练的小模型	原生小模型大小（如1.7B约3.4GB FP16）	低配设备的高质量选择	不是压缩，是“徒弟学师傅”

⚠️ 关键辨析：量化 vs 蒸馏

维度	量化 (Quantization)	蒸馏 (Distillation)
通俗类比	高清照片压成JPG，文件变小，画质微损	老师傅带徒弟，徒弟用更少脑细胞学会本事
模型参数数量	不变（8B量化后还是8B个参数）	大幅减少（8B → 1.7B）
是否需要训练	❌ 不需要，下载即用	✅ 需要大量数据重新训练
智商影响	4bit几乎无损（差距<1%）；极端压缩才变笨	取决于学生容量，可能接近甚至超越同尺寸原生模型
解决什么问题	显存不够装原版，想省显存、提速	设备太弱跑不动大模型，想造出更强的小模型

实战组合：

• 显存不够跑某个特定模型？ → 找它的量化版（Qwen3-8B-AWQ）
• 设备太弱，连量化版都跑不动？ → 找蒸馏小模型（Qwen3-1.7B-Distill）
• 既要小又要强？ → 蒸馏模型的量化版（Qwen3-1.7B-Distill-AWQ）

---

四、显存估算（模型权重 + KV Cache）

总显存 ≈ 模型权重 + KV Cache + 预留1~2GB

模型权重

直接由参数量和精度决定（见第二部分）。

KV Cache（键值缓存）

实际作用：大模型生成文字是一个字一个字往外蹦的。如果没有KV Cache，每生成一个新字，模型都要把前面所有的对话重新计算一遍——相当于写作文时每写一个字都要从头重读整篇文章，效率极低。KV Cache 会把之前已处理过的内容（Key和Value）缓存起来，每次只计算当前新字与前面内容的关联，用显存空间换生成速度。

关键参数：

• --max-model-len：设上限（超出截断）
• --quantization-kv-cache fp8：显存减半
• --enable-prefix-caching：自动复用，省30-60%

实测占用（FP8，每万token）：

模型类型	注意力机制	占用
Qwen3-8B / Llama-3-8B	GQA	~0.25 GB
Gemma-4-26B-A4B	MQA	~0.18 GB
老款模型	MHA	0.50.7 GB

建议：不要手算，用 vllm estimate --model <path> --max-model-len 32768 或在线计算器。

---

五、推理引擎选择（决策树）

你的显卡？
├─ RTX 50系 → TensorRT-LLM 或 vLLM≥0.9（NVFP4）
├─ RTX 30/40系 → vLLM（FP8/AWQ）
├─ 显存≤8GB / Mac / CPU → Ollama + GGUF
└─ AMD → vLLM (ROCm) 或 LM Studio

引擎定位：

• TensorRT-LLM：NVIDIA 官方优化引擎，RTX 50系 NVFP4 性能最佳。
• vLLM：服务端引擎，适合 API 调用和高并发。
• Ollama：桌面工具，适合个人对话和快速体验。

---

⚙️ TensorRT-LLM 的特殊说明（量化模型 & 蒸馏模型 & Gemma-4）

• 对量化模型：TensorRT-LLM 原生支持 AWQ、FP8、NVFP4 等量化格式，但需要使用 NVIDIA ModelOpt 工具生成其专用的引擎格式，社区直接下载的量化模型（如 HuggingFace 上的 AWQ 模型）可能无法直接加载。
• 对蒸馏模型：TensorRT-LLM 可以部署蒸馏后的小模型（如 Qwen3-1.7B-Distill），但蒸馏过程本身由 ModelOpt 或其他工具完成，TensorRT-LLM 只负责推理加速。
• 关于 nvidia/Gemma-4-26B-A4B-NVFP4：目前不能直接使用 TensorRT-LLM 加载（因其后端兼容性问题），但 TensorRT-LLM 本身支持 Gemma-4 架构和 NVFP4 量化，正确做法是下载基础模型 google/gemma-4-26B-A4B-it，在 TensorRT-LLM 环境下使用 ModelOpt 自行量化为 NVFP4 格式并编译。简而言之：TensorRT-LLM 不是不能跑，而是需要“亲手转换”。

---

六、vLLM 部署：模型大小与并发数的关系（新增核心章节）

6.1 核心逻辑：显存是连接模型与并发的桥梁

vLLM 将显存划分为：

1. 模型权重（固定）：模型参数占用的静态显存。
2. KV Cache（动态）：每个并发请求都会消耗 KV Cache 来存储上下文。
3. 其他开销：激活值、框架开销等。

可用 KV Cache 显存 = (总显存 × gpu_memory_utilization) – 模型权重 – 其他开销

模型越大，权重占用越多，留给 KV Cache 的显存就越少，从而限制并发能力。

6.2 链条影响：模型大小 → 并发上限

• 大模型（如 70B）权重可能需要 140GB 显存（FP16），即便量化后也占用巨大。
• KV Cache 总量决定了可同时处理的 Token 总数，进而决定了最大并发序列数（max_num_seqs）。
• 每个并发请求消耗的 KV Cache 由 max_model_len（上下文长度）决定，长度越长，单个请求占用越多，并发数就越低。

6.3 关键参数与调控

参数	作用	对并发的直接影响
max_num_seqs	最大并发序列数	直接上限，每增加1，KV Cache 线性增加
max_model_len	最大上下文长度	越大，每个请求占用 KV Cache 越多，减少可并发数
gpu_memory_utilization	vLLM 可用显存比例	调高增加可用显存，但需预留系统缓冲
tensor_parallel_size	张量并行度（多卡）	增加总显存，为 KV Cache 腾出空间
quantization (如 AWQ/FP8)	模型量化	减少权重显存，间接增加 KV Cache 可用空间
--kv-cache-dtype fp8	KV Cache 压缩	直接减半 KV Cache 占用，提升并发能力

6.4 调优建议与估算工具

• 启动时观察日志：vLLM 会打印 # GPU blocks: XXX 和 GPU KV cache size，可评估当前配置下的并发潜力。
• 使用官方 Colab 计算器：输入模型、上下文长度、批处理大小，估算所需显存和建议的 max_num_seqs。
• 显存不足抢救顺序（与之前章节一致）：
  1. 开启 --enable-prefix-caching（零成本）
  2. KV Cache FP16 → FP8 → NVFP4（50系）
  3. 换 AWQ/GPTQ 量化模型
  4. 降低 --max-model-len
  5. 换 GGUF + Ollama 开启 CPU offload（牺牲速度）

---

七、实战落地：选型与排错（综合推荐）

7.1 根据显卡推荐

硬件	推荐模型	引擎	体验
≤8GB / Mac	Qwen3-0.6B-Distill 或 Qwen2.5-3B-GGUF	Ollama	日常流畅
RTX 30/40 12-24GB	Qwen3-8B-AWQ	vLLM	速度智商平衡
RTX 50 24GB+	Gemma-4-26B-A4B-NVFP4（需自行转换）	vLLM≥0.9 或 TensorRT-LLM	极致速度

7.2 显存不足抢救顺序（通用）

1. 开启 --enable-prefix-caching（零成本）
2. KV Cache FP16 → FP8 → NVFP4（50系）
3. 换 AWQ/GPTQ 量化模型
4. 降低 --max-model-len（每减半省约一半KV Cache）
5. 换 GGUF + Ollama 开启 CPU offload（牺牲速度）

7.3 并发能力不足（vLLM）抢救顺序

1. 降低 max_num_seqs（直接减少并发数）
2. 降低 max_model_len（减少每个请求的上下文长度）
3. 启用 KV Cache 量化（--kv-cache-dtype fp8）
4. 考虑多卡并行（增大 tensor_parallel_size）
5. 换更小的模型或量化版本

---

📌 总结

这份笔记覆盖了从模型名称解读到量化与蒸馏辨析、显存估算、KV Cache 原理、推理引擎选择（含 TensorRT-LLM 的特殊性），最后新增了 vLLM 并发与模型大小的内在关系，形成了一个完整的闭环。无论你是个人开发者还是团队部署，都可以按图索骥，快速定位问题并优化配置。

如有未尽之处，欢迎随时补充完善！