适用场景与目标

2026 年，本地部署大语言模型已成工程团队的标配挑战——GPU 昂贵且稀缺，如何在有限硬件上榨出最大吞吐量、同时保持低延迟，是落地成败的分水岭。

当前三大主流推理引擎：

• vLLM：通用首选，OpenAI-compatible，上手最快，社区最活跃
• SGLang：structured output 和 agentic 场景（多轮对话、工具调用、链式推理）性能更优
• TensorRT-LLM：极高吞吐场景的专用武器，但工程复杂度最高

本文目标：帮你根据实际工作负载选对引擎，并给出最小可行落地路径（3 小时内跑通 MVP）。

---

最小可行方案（MVP）步骤

硬件前提

配置级别	GPU	适用场景
入门	单卡 RTX 3090/4090 (24GB)	跑 7B~14B 模型，Q4 量化
进阶	单卡 A100 40GB / H100 80GB	跑 70B 模型，FP16
生产	多卡 A100/H100 集群	多节点分散式推理

第一步：安装 vLLM（推荐先跑通）

# Python 3.10+，推荐 conda 环境
conda create -n llm-inference python=3.10 -y
conda activate llm-inference

pip install vllm>=0.8.0

# 验证安装
python -c "import vllm; print(vllm.__version__)"

第二步：跑通第一个模型

# Qwen2.5-7B-Instruct 示例（BF16，FP16）
vllm serve Qwen/Qwen2.5-7B-Instruct \
  --dtype half \
  --gpu-memory-utilization 0.85 \
  --max-model-len 8192 \
  --port 8000

服务启动后，验证 API：

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen2.5-7B-Instruct",
    "messages": [{"role": "user", "content": "1+1等于几？"}]
  }'

第三步：切换到 SGLang（如需 structured output）

pip install sglang[sglang-native]>=0.4.0

# 启动 SGLang server
python -m sglang.launch_server \
  --model-path Qwen/Qwen2.5-7B-Instruct \
  --port 3000 \
  -- dtype half \
  --mem_fraction_static 0.85

第四步：生产级部署到 Kubernetes（KServe）

# inference-service.yaml
apiVersion: serving.kserve.io/v1alpha1
kind: InferenceService
metadata:
  name: vllm-qwen-server
spec:
  predictor:
    minReplicas: 1
    maxReplicas: 3
    containers:
    - name: predictor
      image: vllm/vllm-openai:latest
      args:
        - "--model"
        - "Qwen/Qwen2.5-7B-Instruct"
        - "--dtype"
        - "half"
        - "--gpu-memory-utilization"
        - "0.85"
      resources:
        requests:
          nvidia.com/gpu: "1"
        limits:
          nvidia.com/gpu: "1"

---

关键实现细节

1. Speculative Decoding 加速（vLLM 0.6+）

speculative decoding 将吞吐提升 1.5x~2.5x，成本几乎为零：

vllm serve Qwen/Qwen2.5-7B-Instruct \
  --dtype half \
  --speculative-model "Qwen/Qwen2.5-1.5B-Instruct" \
  --num-speculative-tokens 5

draft model 选型建议：

• Llama-3.2-1B-Instruct / Qwen2.5-1.5B-Instruct：通用
• 代码场景：选同系列 larger draft（如 Qwen2.5-3B 作为 Qwen2.5-7B 的 draft）

2. 量化落地（AWQ / GPTQ）

无需 A100 也能跑 70B，用 4-bit 量化：

# 使用 AutoAWQ 量化
pip install awq

python -c "
from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer
model = AutoAWQForCausalLM.from_pretrained('Qwen/Qwen2.5-7B-Instruct')
tokenizer = AutoTokenizer.from_pretrained('Qwen/Qwen2.5-7B-Instruct')
quantizer = AutoAWQForCausalLM.quantize(model, tokenizer, quant_config={'zero_point': True, 'q_group_size': 128, 'w_bit': 4})
model.save_quantized('./qwen-7b-awq')
tokenizer.save_pretrained('./qwen-7b-awq')
"

# 启动量化模型
vllm serve ./qwen-7b-awq --dtype float16 --gpu-memory-utilization 0.9

3. SGLang 强制 structured output（Jina格式）

import sglang as sgl

@sgl.gen(stream=False)
def answer(question: str) -> str:
    sgl.select_schema([
        {"type": "object", "properties": {"answer": {"type": "string"}, "confidence": {"type": "number"}}, "required": ["answer"]}
    ])
    return question

result = answer("解释量子纠缠")
print(result)

4. 多 LoRA 同时服务（vLLM）

vllm serve Qwen/Qwen2.5-7B-Instruct \
  --enable-lora \
  --lora-modules=module_a=/path/to/lora_a,module_b=/path/to/lora_b

调用时指定 loRA：

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "Qwen2.5-7B-Instruct", "messages": [...], "lora_name": "module_a"}'

5. AMD MI300X 支持（生产多vendor）

# 使用 ROCm 版本 vLLM（需要 rocblas 和 hipblas）
pip install vllm --index-url https://wheels.vllm.ai/rocm

注意：AMD MI300X 上 vLLM 仍有偶发 hang 问题，官方建议在调度层加 timeout 重试。

---

常见坑与规避清单

🔴 坑1：GPU 显存估算错误导致 OOM

症状：CUDA out of memory 在模型加载后才出现，难以排查。

原因：没算上 KV cache 和 context window 的显存需求。

规避：

# 启动前估算需要的显存
python -c "
import vllm
print('Estimated memory:', vllm.get_gpu_memory('NVIDIA'))
"
# 保守配置：--gpu-memory-utilization 0.8 而非 0.95
# max-model-len 不要超过 32768（除非真的需要长上下文）

🔴 坑2：TensorRT-LLM 编译时间过长

症状：编译 70B 模型耗时 6+ 小时，CI/CD 完全卡死。

规避：

• 预编译 engine，保存为二进制文件，不在容器内编译
• 使用官方预编译的 TensorRT-LLM engine（支持 LLaMA、Qwen、Mistral）
• 优先用 vLLM，除非你有专职 infra 工程师维护 TRT

🔴 坑3：SGLang 的 RadixAttention prefix caching 配置错误

症状：相同 system prompt 的多请求没有被缓存，每次都重新 prefill，延迟忽高忽低。

规避：

# 启动时明确开启 prefix caching
python -m sglang.launch_server \
  --model-path Qwen/Qwen2.5-7B-Instruct \
  --enable-cache-report \
  --chunked-prefill-size 2048

生产环境监控 prefix cache hit rate，低于 60% 说明配置有问题。

🟡 坑4：vLLM 多实例竞争 GPU 内存

症状：跑多个 vLLM 实例时，第二个实例启动失败或很不稳定。

原因：GPU 内存碎片化。vLLM 默认贪婪占用 GPU。

规避：

• 一个 GPU 只跑一个 vLLM 实例
• 使用 Kubernetes node selector + taint 确保独占
• 或者用 CUDA_VISIBLE_DEVICES 隔离 GPU

🟡 坑5：Speculative decoding 内存估算不准

症状：加了 speculative model 后 OOM。

原因：draft 模型也要加载到 GPU，且 KV cache 翻倍。

规避：减小 --gpu-memory-utilization 到 0.6~0.7，或换更小的 draft 模型（如 0.5B）。

---

成本 / 性能 / 维护权衡

维度	vLLM	SGLang	TensorRT-LLM
上手难度	⭐ 低	⭐⭐ 中	⭐⭐⭐ 高
吞吐量（相对）	基准	+10~30%（structured）	+20~50%（特定场景）
延迟（P99）	良好	更好（chunked prefill）	最佳
多 LoRA 支持	支持（中等）	支持（更好）	需额外配置
AMD GPU 支持	基本可用	良好	优秀
社区活跃度	最高	高	中
维护成本	低	中	高（需要 TRTX 组）
适合团队	绝大多数团队	Agent/CoT 场景	超大规模独立 infra 团队

选型决策树：

通用推理 + 快速交付 → vLLM（选这个不会错）
structured output 为主 + agentic 工作流 → SGLang
日 token 量 > 1 亿 + 有专职 infra → TensorRT-LLM
AMD GPU 集群 → 优先 SGLang，次 vLLM

---

一周内可执行行动清单

• Day 1：在单卡 GPU 上用 vLLM 跑通 Qwen2.5-7B-Instruct，完成 curl API 验证
• Day 2：测试 speculative decoding（draft model = Qwen2.5-1.5B），测量 throughput 提升
• Day 3：如有 structured output 需求，部署 SGLang，对比延迟
• Day 4：用 AWQ 量化一个模型，跑通并验证质量损失可接受
• Day 5：写 Kubernetes Deployment YAML，CI/CD 中加入 vLLM 健康检查
• Day 7：压测 1000 并发请求，记录 P50/P95/P99 延迟，建立基线

核心原则：先用 vLLM 跑通业务，不要过早优化。等 QPS 真实达到瓶颈时再切换到 SGLang 或 TRT-LLM——那时候你才有足够数据指导选型决策。