主流模型部署配置：从"需要多少卡"到"为什么这样配"¶

更新日期：2026-04-17

一、模型部署的核心约束¶

部署一个 LLM 需要回答三个问题：

放得下吗？ — 模型权重 + KV Cache 能否装进 GPU 显存
够快吗？ — 吞吐量和延迟是否满足业务需求
划算吗？ — 每百万 token 成本是否可接受

这三个问题的答案取决于：模型大小、精度、GPU 型号、并行策略、KV Cache 大小。下面每个配置都会解释"为什么"。

二、显存计算公式¶

推理显存由三部分组成：

\(\text{Total} = \text{Weights} + \text{KV Cache} + \text{Overhead}\)

Weights = 参数量 × bytes/param（FP16=2, INT4=0.5, FP8=1）
KV Cache = \(2 \times L \times H_{kv} \times d_h \times \text{seq\_len} \times \text{batch} \times \text{dtype}\)
Overhead ≈ 2-4 GB（框架、激活、通信 buffer）

KV Cache 经常比权重还大！LLaMA-70B 在 8K 上下文 batch=32 时，KV Cache ≈ 86 GB，权重只有 140 GB。所以并发数受限于 KV Cache，不是权重。

三、主流模型部署速查¶

3.1 轻量模型（单卡部署）¶

7B 模型是"甜点区"：单卡 4090/A5000 就能跑，质量接近 2023 年的 GPT-3.5。

3.2 中型模型（1-4 卡）¶

为什么 TP=2 而不是 PP=2？因为 TP 的延迟更低——每层并行，不需要等流水线。PP 适合训练（隐藏气泡），推理优先 TP。

3.3 大型模型（8+ 卡）¶

MoE 模型的陷阱：激活参数 37B 但总参数 671B。推理 FLOPs 按 37B 算（快），但显存按 671B 算（大）。这就是为什么 MoE 推理需要比你预期更多的 GPU。

3.4 DeepSeek-V3 的特殊部署策略¶

DeepSeek-V3 不用 TP！改用 EP。为什么？

# DeepSeek-V3 推理配置 (SGLang)
model: deepseek-ai/DeepSeek-V3
tensor_parallel_size: 1    # 不用 TP!
expert_parallel_size: 8
dtype: fp8
max_total_tokens: 200000

四、典型部署配置详解¶

4.1 Qwen2.5-72B¶

# 方案 A: FP16 高质量
tensor_parallel_size: 2   # 2×A100 80GB, TP=2 因为 144GB > 80GB
max_model_len: 131072     # 128K 上下文
gpu_memory_utilization: 0.92
enable_prefix_caching: true  # RAG 场景必开

为什么 gpu_memory_utilization: 0.92？默认 0.9 太保守——0.92 多给 KV Cache 分配 ~3GB 显存，能多支撑 ~20% 并发请求。但不要超过 0.95，否则 OOM 风险高。

# 方案 B: INT4 低成本
quantization: awq
tensor_parallel_size: 1   # 单 48GB GPU (L40S)
# 权重 72B × 0.5 = 36GB, 加 KV Cache 和 overhead ≈ 45GB
# 质量: ~98% of FP16
# 成本: 1/4 of 方案 A

4.2 LLaMA-3 70B 高吞吐¶

tensor_parallel_size: 4    # 4×H100, 比 TP=2 更多 batch 空间
dtype: fp8                  # H100 原生 FP8, 质量几乎无损
max_num_seqs: 256
enable_chunked_prefill: true  # 防止长 prompt 阻塞 decode
speculative_model: meta-llama/Meta-Llama-3.1-8B-Instruct
num_speculative_tokens: 5    # 投机解码加速 2x

为什么 TP=4 而不是 2？TP=2 权重放得下，但 KV Cache 空间不够支撑 256 并发。TP=4 多出 2 卡的显存给 KV Cache，并发能力翻倍。

五、性能对比与成本¶

5.1 LLaMA-70B 不同配置的吞吐¶

为什么 batch=1 只有 30 tok/s 但 batch=128 有 2000 tok/s？因为 decode 是内存带宽密集型——每 token 都要读全部权重。batch=1 时，读 140GB 权重只做 1 个 token 的计算 → GPU 算力严重浪费。batch 增大后，读一次权重做 N 个 token → 算力利用率提升。

5.2 成本效率¶

\(\text{成本/百万 token} = \frac{n_{\text{gpus}} \times \text{GPU 小时费}}{(\text{吞吐} \times 3600) / 10^6}\)

六、端侧部署¶

6.1 手机端¶

手机端 LLM 的实际体验：第一个 token 延迟 2-5 秒（prefill 慢），后续 token 还算流畅。适合离线场景（无网络时的助手功能），不适合替代云端 API。

6.2 端侧推理工具¶

七、部署 Checklist¶

上线前必须完成： 1. 压测确认实际 QPS：不要相信理论数字，用真实 prompt 长度分布测

KV Cache OOM 保护：设置 max_model_len 和 max_num_seqs 上限
量化质量验证：跑一遍核心 eval，确认量化后质量可接受
Prompt Caching 配置：如果有共享 system prompt（RAG/chatbot），开 prefix caching 省 50%+ prefill
投机解码评估：如果 draft 模型可用，测试加速比（通常 2x）
监控：GPU 利用率、HBM 占用、每请求延迟、token 成本
降级策略：如果 FP16 OOM → 自动降到 INT4；如果超时 → 返回缓存结果
安全过滤：输入/输出都需要过滤层
成本追踪：按用户/任务记录 token 消耗

参考文献¶

[1] vLLM Documentation
[2] SGLang Documentation
[3] TensorRT-LLM
[4] llama.cpp
[5] Ollama
[6] MLC-LLM
[7] Apple MLX
[8] DeepSeek-V3 Deployment. HuggingFace
[9] Artificial Analysis (API 成本和速度对比)

↑ 上级 · G. 推理与部署