适用场景与目标

谁需要这个方案

• 已有 LLM API 调用规模（日均 token 消耗超过 100M）
• 自建推理服务的团队（VLLM / SGLang / TensorRT-LLM）
• 需要控制 AI 成本的初创公司和成长型产品

目标收益

优化方向	典型收益
推理引擎（vLLM PagedAttention）	吞吐量提升 3~5 倍
量化（AWQ / GPTQ）	显存降低 60%，延迟降低 40%
Continuous Batching	GPU 利用率 20% → 80%+
KV Cache 复用	重复 prompt 成本降低 90%+
speculative decoding	首 token 延迟降低 50%

收益前提：GPU 为 H100/A100/A10G，模型 7B~72B 参数，无重度前缀缓存场景。

---

最小可行方案（MVP）

第一步：部署 vLLM（推荐起步引擎）

# 安装 vLLM（>= 0.6.0）
pip install vllm>=0.6.0

# 启动 OpenAI 兼容服务（bf16）
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3-8b-Instruct \
  --gpu-memory-utilization 0.92 \
  --tensor-parallel-size 2 \
  --max-num-seqs 256 \
  --enforce-eager

关键参数说明：

参数	作用	推荐值
--gpu-memory-utilization	每卡显存预留比例	0.90~0.92（留空间给 KV Cache）
--tensor-parallel-size	多卡并行	GPU 数量（如 2 表示 2 卡）
--max-num-seqs	伯航并发请求上限	根据显存和模型大小调优
--enforce-eager	禁用 CUDA Graph	调试时开启，生产建议关闭

第二步：开启量化（4bit AWQ）

# 安装 awq
pip install awq

# 量化模型（离线执行，约 10~30 分钟）
python -m vllm.engine.arg_utils \
  --model meta-llama/Llama-3-8b-Instruct \
  --quantization awq \
  --save_quantized_weights

AWQ 4bit 量化后，8B 模型显存需求从 ~16GB 降至 ~6GB，同一张 A10G 可跑两路并发。

第三步：配置 Continuous Batching

vLLM 默认开启，无需额外配置。关注 max-num-seqs 和 --block-size：

python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3-8b-Instruct \
  --block-size 16   # KV Cache 块大小，越大浪费越多、越小开销越大

第四步：API 层接入与成本埋点

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="dummy"  # vLLM local mode
)

# 请求时记录 token 消耗
import time, uuid

def chat_with_cost(model, messages):
    req_id = str(uuid.uuid4())
    start = time.time()
    
    response = client.chat.completions.create(
        model=model,
        messages=messages,
        max_tokens=512
    )
    
    usage = response.usage
    latency_ms = (time.time() - start) * 1000
    
    # 写入成本日志（可接入 Prometheus/Grafana）
    print(f"[{req_id}] tokens={usage.total_tokens}, "
          f"latency={latency_ms:.0f}ms, "
          f"cost_usd={usage.total_tokens * 0.00002:.4f}")
    
    return response

---

关键实现细节

KV Cache 复用（重复请求场景）

如果业务中有大量相似 prompt（如客服机器人的系统前缀），开启 prefix caching：

python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3-8b-Instruct \
  --enable-prefix-caching

注意：prefix caching 在 prompt 重复率高时效果显著（成本降 70%+），但在随机用户输入场景收益有限。

Speculative Decoding（降低首 token 延迟）

python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3-8b-Instruct \
  --num-speculative-tokens 5   # 每次预测 5 tokens

适用于对交互延迟敏感的场景（如对话机器人），但会增加单次推理的计算量。

多模型路由（成本分层）

简单版基于 prompt 长度路由：

def route_model(prompt_tokens: int, required_quality: str) -> str:
    # 简单规则（实际可用 LLM 做意图分类）
    if prompt_tokens < 128 and required_quality != "high":
        return "gpt-4o-mini"   # 便宜模型处理简单任务
    elif prompt_tokens < 512:
        return "gpt-4o"
    else:
        return "claude-sonnet-4-20250514"  # 大 context 走强模型

---

常见坑与规避清单

坑 1：CUDA OOM（显存溢出）

原因：gpu-memory-utilization 设太高 + max-num-seqs 过大

规避：

# 保守启动，观察 vLLM 日志中的 KV Cache 大小
nvidia-smi --query-gpu=memory.used,memory.total --format=csv

如果显存使用率 > 95%，降低 --gpu-memory-utilization 至 0.85。

坑 2：量化后质量下降

原因：AWQ/GPTQ 默认使用 4bit，在某些任务（代码生成、结构化输出）上会出现repeat或factuality退化

规避：

• 生产环境建议使用 W4A16（权重 4bit，激活值保持 fp16）
• 上线前用业务 benchmark 对比量化前后的质量差异
• 代码/数学任务慎用 4bit，考虑 8bit GPTQ

坑 3：Continuous Batching 的公平性问题

原因：vLLM 的迭代级调度可能导致某些请求长期被”饿死”

规避：设置 disable-async-output-precessing 关闭异步输出处理，减少延迟毛刺

坑 4：prefix caching 命中率低

原因：用户 prompt 随机性高，共享前缀少

规避：不要在所有场景都开 prefix caching。只在 prompt 结构固定（如带固定 system prompt + 变量部分）时开启。

坑 5：模型版本更新后量化权重不兼容

规避：量化后保存 quant_config.json，更新模型时重新量化，不要跨版本复用量化权重。

---

成本/性能/维护权衡

量化 vs 精度

方案	精度损失	显存节省	适用场景
BF16（无量化）	无	0	高质量要求的推理任务
FP16	极低	50%	默认选项
GPTQ 8bit	略低	60%	代码生成、创意写作
AWQ 4bit	中等	75%	大批量、低延迟场景

自建 vs API 成本对比

假设日均 100M tokens：

方案	月成本（估算）	适用规模
GPT-4o API	~$2000	< 500M tokens/月
自建 vLLM（H100×2）	~$3000（硬件折旧）	> 500M tokens/月
自建 + 量化	~$1800	> 1B tokens/月

结论：月均 token 超过 5 亿时，自建推理开始具备成本优势；超过 10 亿时，量化自建几乎必然更优。

维护成本

• vLLM：升级频繁（双周 release），需要同步更新模型权重格式
• 量化模型：每次 base model 更新需重新量化（耗时 10~60 分钟）
• 监控：建议接入 Prometheus，vLLM 原生支持 /metrics 端点

---

一周内可执行行动清单

Day 1~2：本地压测基线

1. 在 GPU 服务器上安装 vLLM
2. 启动 bf16 基准推理服务
3. 用 wrk / locust 跑压测，记录 QPS、延迟 P99、显存使用

Day 3~4：量化上线

1. 用 AWQ 量化当前主力模型
2. 对比量化前后 benchmark 质量（用业务测试集）
3. 质量可接受则上线量化版本

Day 5：成本埋点与监控

1. 接入 Prometheus metrics（vLLM 内置 /metrics）
2. 配置 Grafana dashboard：QPS、token 消耗、GPU 利用率
3. 设置告警：GPU 利用率 < 30% 或延迟 P99 > 2s

Day 6~7：路由层实现

1. 实现简单 prompt 长度路由
2. 如有条件，训练一个轻量分类器做意图路由
3. 全链路压测验证路由正确率和延迟变化

---

参考工具链：vLLM、SGLang、AWQ、GPTQ、TensorRT-LLM、Prometheus + Grafana

核心原则：先压测基线，再量化降本，最后路由分层。不要跳步直接上量化，否则出问题难以定位根因。