本地部署大模型：看懂名字、算清显存、选对工具
·
文章目录
一、模型名称拆解（选型第一步）
格式：系列-版本-参数量-后缀
| 部分 | 示例 | 含义 |
|---|---|---|
| 系列 | 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 将显存划分为：
- 模型权重（固定）：模型参数占用的静态显存。
- KV Cache（动态）：每个并发请求都会消耗 KV Cache 来存储上下文。
- 其他开销：激活值、框架开销等。
可用 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。 - 显存不足抢救顺序（与之前章节一致）：
- 开启
--enable-prefix-caching（零成本） - KV Cache FP16 → FP8 → NVFP4（50系）
- 换 AWQ/GPTQ 量化模型
- 降低
--max-model-len - 换 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 显存不足抢救顺序（通用）
- 开启
--enable-prefix-caching（零成本） - KV Cache FP16 → FP8 → NVFP4（50系）
- 换 AWQ/GPTQ 量化模型
- 降低
--max-model-len（每减半省约一半KV Cache） - 换 GGUF + Ollama 开启 CPU offload（牺牲速度）
7.3 并发能力不足（vLLM）抢救顺序
- 降低
max_num_seqs（直接减少并发数） - 降低
max_model_len（减少每个请求的上下文长度） - 启用 KV Cache 量化（
--kv-cache-dtype fp8） - 考虑多卡并行（增大
tensor_parallel_size） - 换更小的模型或量化版本
📌 总结
这份笔记覆盖了从模型名称解读到量化与蒸馏辨析、显存估算、KV Cache 原理、推理引擎选择（含 TensorRT-LLM 的特殊性），最后新增了 vLLM 并发与模型大小的内在关系，形成了一个完整的闭环。无论你是个人开发者还是团队部署，都可以按图索骥，快速定位问题并优化配置。
如有未尽之处，欢迎随时补充完善！
Agent 垂直技术社区，欢迎活跃、内容共建。
更多推荐
5
0- 0
已为社区贡献1条内容
所有评论(0)