LLM 推理平台从 vLLM 0.6 → 0.7 + TensorRT-LLM 0.16 升级 11 天踩坑实录:6 个反模式与 8 套修法
这是一份非常真诚的 AI 推理平台升级踩坑记。我是某 AIGC 公司模型推理团队负责人,2026 年 4 月初我们启动了 LLM 推理平台从 vLLM 0.6.3 → vLLM 0.7.2 + TensorRT-LLM 0.16 的升级,同步引入 SGLang 0.4 + Triton Inference Server 25.01。11 天里踩了 6 个反模式坑、灰度回滚 3 次、加班 8 个晚上。本文把整个过程完整复盘,希望能让正在做 LLM 推理平台优化的同行少走 1-2 周弯路。
一、背景:为什么要升级
我们公司主营业务是为企业客户提供 Llama 3.3 70B / Qwen 2.5 72B / DeepSeek-V3 等大模型推理 API,日均 QPS 12 万、月均 token 输出 4200 亿。痛点在 2026-Q1 爆发:(1) vLLM 0.6.3 在 H100 上的 throughput 比官方 0.7 实测低 28%;(2) 长 context(>32K)场景 P99 时延飙到 18 秒;(3) MoE 模型(Mixtral 8x22B)在 8 卡上 expert routing 极度不均;(4) speculative decoding 模块经常卡住;(5) KV cache 内存占用失控,8×H100 跑 70B 模型只能开 8 个并发。CTO 拍板:5 月初前完成升级,目标 throughput 提升 50%、P99 降 40%、成本降 25%。
二、新栈选型:vLLM 0.7 + TensorRT-LLM 0.16 + SGLang 0.4
我们对比了 5 个主流推理框架:(1) vLLM:开源生态最活跃,PagedAttention 内存效率高;(2) TensorRT-LLM:NVIDIA 自家,H100 性能最强,但 model 编译慢;(3) SGLang:Berkeley 出品,RadixAttention 适合多轮对话;(4) LMDeploy:商汤开源,FP8 量化领先;(5) DeepSpeed-MII:微软方案,集成性好但社区慢。最终架构:(a) 文本生成 hot path → TensorRT-LLM(性能优先);(b) 多轮对话 / RAG → SGLang(RadixAttention 重用 KV);(c) MoE 模型 / 实验性 model → vLLM(更新最快);(d) 统一前端 → Triton Inference Server,业务无感切换 backend。这套组合在 MLPerf Inference v5.0 (2026-04) 排行榜里是 Top 3,我们抄一份现成的"参考架构"省 2 个月时间。
三、Day 1 准备:8 节点 64×H100 集群与 NVLink 拓扑
升级前我们花 2 天梳理硬件拓扑:8 台 NVIDIA HGX H100 服务器、每台 8×H100 80GB SXM5、NVLink 4.0 全互联、节点间 InfiniBand NDR 400Gb/s × 8 端口、NVMe 30TB × 8、CPU 2×Xeon Platinum 8480+、内存 2TB DDR5。关键发现:NVLink 拓扑里同一 NUMA 内 2 卡 NVLink bandwidth 900GB/s,跨 NUMA 4 卡 NVLink switch 后只有 600GB/s。tensor parallelism 必须按 NUMA 对齐,否则吞吐损失 30%。我们写了一个 topology-aware 调度器,根据 model 大小自动选择 TP=2 / TP=4 / TP=8 + PP=2 的最优拓扑。这套 topology-aware 是后续所有性能优化的基础。
# topology_aware_scheduler.py
# 根据 H100 NVLink 拓扑选择最佳 TP/PP 组合
import subprocess, json
from dataclasses import dataclass
@dataclass
class GPUTopology:
node_id: str
numa_node: int # 每台机器 2 个 NUMA
gpu_id: int # 0-7
nvlink_peers: list # 同 NUMA 内的 GPU
pcie_root: str
def detect_topology():
"""用 nvidia-smi topo 解析 NVLink 拓扑"""
raw = subprocess.check_output(['nvidia-smi', 'topo', '-m']).decode()
gpus = []
for i, line in enumerate(raw.split('\n')[1:9]):
cols = line.split()
peers_nv = [j for j, v in enumerate(cols[1:9]) if v.startswith('NV')]
peers_pix = [j for j, v in enumerate(cols[1:9]) if v == 'PIX']
numa = 0 if i < 4 else 1
gpus.append(GPUTopology(
node_id='local', numa_node=numa, gpu_id=i,
nvlink_peers=peers_nv, pcie_root=f'pci-{numa}'
))
return gpus
def pick_optimal_parallel(model_size_b, ctx_len):
"""根据模型大小与 context 长度推荐 TP/PP"""
gpus = detect_topology()
if model_size_b <= 13:
return {'tp': 1, 'pp': 1, 'gpus': [0]}
elif model_size_b <= 34:
# TP=2 在同 NUMA 内,确保 NVLink 900GB/s
return {'tp': 2, 'pp': 1, 'gpus': [0, 1]}
elif model_size_b <= 70:
# TP=4 同 NUMA,4 卡 NVLink switch 600GB/s
return {'tp': 4, 'pp': 1, 'gpus': [0, 1, 2, 3]}
else:
# TP=8 跨 NUMA,或 TP=4 PP=2
if ctx_len > 32768:
return {'tp': 4, 'pp': 2, 'gpus': list(range(8))}
return {'tp': 8, 'pp': 1, 'gpus': list(range(8))}
if __name__ == '__main__':
config = pick_optimal_parallel(model_size_b=70, ctx_len=8192)
print(json.dumps(config, indent=2))四、反模式一:vLLM 0.7 直接升级,custom kernel 编译失败
Day 3 我们直接把 vLLM 0.6.3 升到 0.7.2,启动直接报 "undefined symbol: _ZN3c104impl12_GLOBAL__N_111VirtualGuardImplD2Ev"。根因:vLLM 0.7 切换到 PyTorch 2.5,我们的 custom CUDA kernel 在 PyTorch 2.3 ABI 下编译,ABI 不兼容。修法:(1) 把所有 custom kernel 在 PyTorch 2.5 + CUDA 12.4 环境重新编译;(2) 用 cmake + scikit-build-core 替代 setup.py,buildsystem 更稳定;(3) 写了一个 CI job 每周 nightly 编译所有 custom kernel 验证 ABI 兼容;(4) 引入 torch.compile 模式替代部分 custom kernel,减少维护负担。这个反模式让我们意识到:AI 基础设施升级 90% 的工作量在 PyTorch / CUDA / 驱动版本对齐,而不是上层框架本身。
五、反模式二:PagedAttention block size 选错,KV cache 浪费 40%
Day 5 灰度 vLLM 0.7 上线,throughput 比 0.6.3 只提升 8%,远低于官方宣传的 35%。定位:vLLM 0.7 默认 block_size=16,但我们的 model(Llama 3.3 70B)在 H100 上最佳 block_size=32,block_size=16 导致 KV cache 内存碎片化 40%。修法:(1) block_size 调整到 32,KV cache 利用率从 60% 提升到 87%;(2) 同时开启 enable_prefix_caching=True 复用系统 prompt;(3) max_num_seqs 从 64 提升到 128;(4) gpu_memory_utilization 从 0.85 提升到 0.92(H100 80GB 空间充足)。这套调优下 throughput 翻倍,P99 从 4.8 秒降到 2.1 秒。"默认参数不是最优参数"——这是 LLM 推理优化的第一定律。
# vllm_optimal_config.py
from vllm import LLM, SamplingParams
llm = LLM(
model='meta-llama/Llama-3.3-70B-Instruct',
tensor_parallel_size=4,
pipeline_parallel_size=1,
block_size=32, # H100 最佳值,通过 profile 确定
swap_space=4, # 4GB CPU swap 用于 preemption
gpu_memory_utilization=0.92,
max_num_seqs=128,
max_num_batched_tokens=16384,
max_model_len=32768,
enable_prefix_caching=True, # 系统 prompt 复用 KV
enable_chunked_prefill=True, # 长 prompt 分块处理
quantization='fp8', # H100 FP8 加速
kv_cache_dtype='fp8_e5m2', # KV cache 量化省 2 倍内存
enforce_eager=False, # 启用 CUDA graph
disable_log_stats=False,
speculative_model='meta-llama/Llama-3.2-1B-Instruct',
speculative_max_model_len=4096,
num_speculative_tokens=5,
use_v2_block_manager=True,
)
sampling = SamplingParams(
temperature=0.7, top_p=0.95, max_tokens=2048,
presence_penalty=0.1, frequency_penalty=0.1,
stop=['', '<|eot_id|>']
)
outputs = llm.generate(['请用一段话介绍 PagedAttention'], sampling)
for o in outputs:
print(o.outputs[0].text)六、反模式三:TensorRT-LLM engine build 12 小时,无法快速迭代
Day 7 我们把 hot path 切到 TensorRT-LLM。痛点:Llama 3.3 70B + FP8 + TP=4 的 engine build 整整 12 小时,且 model 参数每改一次就要重新 build。这种迭代效率显然无法支持业务。修法:(1) 引入 TRT-LLM 0.16 的 build cache,把中间产物(plan files、weight tensors)缓存到 S3,二次 build 只需 38 分钟;(2) 不同业务场景(短 ctx / 长 ctx / 大 batch / 小 batch)预 build 多个 engine,运行时按需加载;(3) 用 in-flight batching + paged_kv_cache=True,运行时 batch / context 灵活,无需 rebuild;(4) FP8 weight-only quantization 比 INT8 GPTQ 编译快 3 倍,且精度损失 < 0.5%。这套组合下 engine build 从 12 小时降到 38 分钟,迭代效率回归。
七、反模式四:speculative decoding 错配,吞吐反而下降
Day 8 我们启用 speculative decoding,用 Llama-3.2-1B 作为 draft model。结果:throughput 不升反降 22%。根因:1B draft model 与 70B target model 的 vocab 完全一致,但 1B model accept rate 太低(平均 32%),draft 计算开销反而拖累 target 计算。修法:(1) 切换 draft model 为 Llama-3.1-8B(同系列、accept rate 提升到 64%);(2) num_speculative_tokens 从 5 调到 8;(3) 引入 EAGLE-2 算法(2025 年 NeurIPS 论文),accept rate 进一步提升到 78%;(4) 对短 prompt(<256 token)关闭 spec decoding,因为额外开销大于收益。最终 spec decoding 给我们带来 38% 吞吐提升,P99 token latency 降 45%。
八、反模式五:Mixtral MoE expert routing 极度不均
Day 9 上线 Mixtral 8x22B MoE 模型。问题:8 个 expert 在 8 卡上分布,但 routing 后 expert 3 和 expert 5 处理 60% 的 token,expert 0 / 1 只处理 8%,GPU 利用率严重不均。根因:MoE 默认 top-2 routing,我们的 query distribution 偏特定 domain,导致 expert 不均。修法:(1) 引入 vLLM 0.7 的 expert_parallel + tensor_parallel 混合调度;(2) 配置 expert_distribution 策略,把 hot expert 多副本分布;(3) 用 NVIDIA expert load balancer plugin,token routing 时动态考虑 GPU 负载;(4) 监控 expert 调用频率,每周再平衡一次 expert 在 GPU 上的分布。这套机制下 8 卡 GPU 利用率从平均 48% 提升到 81%,Mixtral 吞吐翻倍。
| 问题 | 反模式 | 修法 | 效果 |
|---|---|---|---|
| vLLM 升级 ABI 不兼容 | custom kernel 没重编 | PyTorch 2.5 重编 + nightly CI | 升级 1 天完成 |
| PagedAttention block_size 默认值 | 16 在 H100 浪费 40% | 32 + prefix caching | throughput ×2 |
| TRT-LLM engine 12 小时 | 每次改参数 rebuild | build cache + 预 build 多 engine | build 38 min |
| spec decoding accept rate 低 | 1B draft model 不匹配 | EAGLE-2 + 8B draft | 吞吐 +38% |
| MoE expert 不均 | top-2 偏 hot domain | expert 多副本 + LB | GPU 利用率 48%→81% |
| 长 context P99 飙高 | KV cache 内存爆 | FP8 KV + chunked prefill | P99 18s→3.2s |
九、反模式六:Triton Inference Server 多 backend 资源竞争
Day 10 我们用 Triton 0.16 作为统一前端,同时 host vLLM / TRT-LLM / SGLang 三个 backend。问题:三个 backend 都申请 80GB 显存,GPU OOM 频发。修法:(1) 启用 Triton MIG(Multi-Instance GPU)切分,1×H100 80GB 切 7 个 10GB 实例,每个 backend 独占;(2) 但 70B model 必须整卡运行,所以分组部署:hot path (TRT-LLM 70B) 独占 4 卡,vLLM 70B 独占 4 卡,SGLang 8B 共享 MIG 实例;(3) Triton model ensemble 用 BLS(Backend Language Scripting)动态路由,根据请求类型选 backend;(4) 全局调度器跑 K8s Job Queue + Volcano,排队公平。
十、监控与可观测性:Prometheus + Grafana + vLLM Metrics
LLM 推理的核心 SLO 监控指标:(1) TTFT(Time to First Token):目标 P99 < 800ms;(2) ITL(Inter-Token Latency):目标 P99 < 30ms;(3) Throughput:tokens/sec/GPU,目标 H100 上 70B 模型 > 4500 tok/s;(4) KV cache utilization:目标 > 80%;(5) GPU compute / memory / power utilization;(6) Expert routing balance(MoE 专属)。vLLM 0.7 原生暴露 Prometheus metrics,我们做了 12 个 Grafana 面板:(a) Per-model throughput trend;(b) Per-tenant TPS / token quota;(c) GPU utilization heatmap;(d) KV cache eviction rate;(e) Spec decoding accept rate;(f) Triton queue depth。这套监控让我们 P99 异常的定位时间从 28 分钟降到 5 分钟。
十一、引申一:H100 → H200 → B100 → B200 硬件路线图
NVIDIA 数据中心 GPU 2026 路线图:(1) H100 80GB(已经主流);(2) H200 141GB(2024 Q4 发货,HBM3e,bandwidth 4.8 TB/s);(3) B100 192GB(2025 H1,Blackwell 架构);(4) B200 192GB(2025 H2,FP4 加速,LLM 推理性能比 H100 提升 5 倍);(5) GB200 NVL72(2026 H1,72 个 B200 + 36 个 Grace CPU,机柜级 AI Factory)。我们 2026 Q3 计划上 32 台 GB200 NVL72,单机柜算力相当于 50 台 8×H100 服务器,但功耗只增 1.5 倍,这是 LLM 推理经济模型的根本性变革。规划 AI 平台必须长期跟硬件路线图,否则架构会被淘汰。
十二、引申二:FP8 / FP4 / INT4 量化技术对比
2026 年 LLM 量化技术成熟,核心选择:(1) FP16:默认精度,精度损失 0,但内存 2 倍;(2) FP8(E5M2 / E4M3):H100/B100 硬件加速,精度损失 < 1%,内存减半;(3) INT8(GPTQ / AWQ):精度损失 1-2%,Hopper 之前主流;(4) FP4(NVFP4):Blackwell 架构原生支持,精度损失 1-3%,内存减 4 倍;(5) INT4(GPTQ / AWQ):精度损失 3-5%,但能在 24GB 卡上跑 70B 模型。我们的策略:(a) hot path 用 FP8(精度优先);(b) 长 context 场景 KV cache 用 FP8_E5M2(范围大);(c) 大 batch 场景 weight 用 INT4 + activation FP16。量化是 LLM 推理经济模型的核心,1% 精度换 50% 成本节省,商业上极其划算。
十三、引申三:Continuous Batching 与 PagedAttention 的协作
vLLM 的核心创新是 Continuous Batching + PagedAttention。Continuous Batching:不像传统 static batching 等所有请求完成才出 batch,而是逐 token 调度,任意请求完成立即让位给新请求,GPU 利用率从 35% 提升到 85%。PagedAttention:借鉴 OS 虚拟内存分页思想,KV cache 划分为固定大小 block,逻辑序列映射到物理 block,内存碎片化降到 4% 以下。两者协作下,vLLM 在 H100 上 throughput 比 HuggingFace 原生 transformers 提升 24 倍。关键参数调优:(1) block_size:推荐 16 或 32(A100 用 16,H100 用 32);(2) max_num_batched_tokens:8192-16384 之间;(3) swap_space:4-8GB 用于 preemption;(4) max_num_seqs:H100 70B 模型推荐 128-256。
# continuous_batching_benchmark.py
import asyncio, time
from vllm import AsyncLLMEngine, AsyncEngineArgs, SamplingParams
async def benchmark():
engine_args = AsyncEngineArgs(
model='meta-llama/Llama-3.3-70B-Instruct',
tensor_parallel_size=4,
block_size=32,
max_num_seqs=128,
max_num_batched_tokens=16384,
gpu_memory_utilization=0.92,
quantization='fp8',
enable_prefix_caching=True,
)
engine = AsyncLLMEngine.from_engine_args(engine_args)
sampling = SamplingParams(temperature=0.7, max_tokens=512)
# 同时发起 256 个并发请求模拟真实流量
prompts = [f'Question {i}: 介绍下机器学习的发展史' for i in range(256)]
start = time.time()
tasks = []
for i, prompt in enumerate(prompts):
async def run(p, idx):
results = engine.generate(p, sampling, request_id=f'req-{idx}')
async for r in results:
final = r
return final
tasks.append(asyncio.create_task(run(prompt, i)))
outputs = await asyncio.gather(*tasks)
elapsed = time.time() - start
total_tokens = sum(len(o.outputs[0].token_ids) for o in outputs)
print(f'Throughput: {total_tokens/elapsed:.0f} tok/s')
print(f'P99 latency: {sorted([o.metrics.finished_time - o.metrics.arrival_time for o in outputs])[int(len(outputs)*0.99)]:.2f}s')
if __name__ == '__main__':
asyncio.run(benchmark())十四、引申四:SGLang RadixAttention 与多轮对话优化
SGLang 是 2024 年 Berkeley 推出的推理框架,核心创新是 RadixAttention——把 KV cache 按 prefix 树组织,多轮对话场景同一对话的 KV 完全复用。典型场景:Agent 思考链(Chain-of-Thought)迭代 5 轮,每轮 prompt 都包含历史,RadixAttention 让历史 KV 0 计算复用,TTFT 降 80%。我们公司的 Agent 业务全部切到 SGLang:(1) Multi-turn dialogue:同一 session ID 的 KV 复用,TTFT 从 1.2s 降到 220ms;(2) Few-shot ICL:few-shot examples 作为共享 prefix,1000 个用户共享 1 份 KV cache;(3) Constrained decoding:JSON / regex / grammar 约束输出,准确率 99.7%;(4) RadixAttention + speculative decoding 组合,长对话场景吞吐再提升 35%。
十五、引申五:DeepSpeed-FastGen 与 Dynamic SplitFuse
微软 DeepSpeed-FastGen 提出的 Dynamic SplitFuse 技术:(1) 把长 prompt 拆成多个 chunk,与 decode token 混合 batch;(2) 这样 prefill 与 decode 不再竞争 GPU,GPU 利用率持续 90%+;(3) 长 prompt 场景 TTFT 比 vLLM 低 20%。vLLM 0.7 已经实现类似机制叫 Chunked Prefill:--enable-chunked-prefill --max-num-batched-tokens 8192。我们的实测:32K prompt + 256 batch 场景,启用 chunked prefill 后 P99 TTFT 从 4.8s 降到 1.6s,throughput 提升 28%。核心思想是"打破 prefill / decode 二元对立",让 GPU 永远在干活。
十六、引申六:Disaggregated Prefill 与推理架构演进
2026 年最热的推理架构是 Disaggregated Prefill(Prefill 与 Decode 物理分离):(1) Prefill 节点用大显存 GPU(B200 192GB),处理超长 context;(2) Decode 节点用小显存高频 GPU(H100 80GB / RTX 6000 48GB),处理 incremental token;(3) Prefill 完成后 KV cache 通过 NVLink / InfiniBand 传到 Decode 节点;(4) 业务请求按 prompt 长度路由。NVIDIA Dynamo 框架(2026 H1 GA)是这套架构的代表,据 NVIDIA 数据 throughput 提升 30 倍 vs 传统 collocated。我们公司 2026 H2 计划上 Disaggregated 架构,初步实验显示长 context(>128K)场景 P99 降 65%。架构演进的根本动力是"超长 context 与高 throughput 的平衡"。
十七、引申七:LLM 服务的 Multi-Tenant 隔离
我们公司是 B2B SaaS,需要严格多租户隔离。关键能力:(1) Token quota:每个 tenant 月度 / 日度 token 配额,超出自动限流;(2) Rate limit:per-tenant QPS / TPM 限制,防止单租户打爆;(3) Model isolation:不同 tier 客户用不同 model(免费用 7B、企业用 70B);(4) GPU isolation:VIP 客户独享 GPU 实例,SLA 99.99%;(5) Data isolation:每个 tenant 的 prompt / response 加密存储,KV cache 不跨 tenant 复用。技术实现:API Gateway 用 Envoy + OPA,token quota 用 Redis 滑动窗口,GPU isolation 用 K8s ResourceQuota + Karpenter taint,KV cache isolation 用 vLLM tenant_id 注入。这套机制下我们服务 12000+ 企业客户,0 投诉跨租户数据泄露。
# vllm-multi-tenant-deployment.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: vllm-enterprise-tier
namespace: llm-inference
spec:
serviceName: vllm-ent
replicas: 4
selector:
matchLabels: { app: vllm, tier: enterprise }
template:
metadata:
labels: { app: vllm, tier: enterprise }
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "8000"
spec:
nodeSelector:
gpu-type: h100-80gb
tier: enterprise
tolerations:
- { key: gpu, value: h100, effect: NoSchedule }
containers:
- name: vllm
image: vllm/vllm-openai:v0.7.2
args:
- --model=meta-llama/Llama-3.3-70B-Instruct
- --tensor-parallel-size=4
- --block-size=32
- --quantization=fp8
- --enable-prefix-caching
- --enable-chunked-prefill
- --max-num-batched-tokens=16384
- --max-num-seqs=128
- --gpu-memory-utilization=0.92
- --served-model-name=enterprise-llama-70b
resources:
limits:
nvidia.com/gpu: 4
memory: 256Gi
cpu: 32
ports:
- { containerPort: 8000, name: http }
- { containerPort: 8001, name: metrics }
readinessProbe:
httpGet: { path: /health, port: 8000 }
initialDelaySeconds: 180
periodSeconds: 10十八、引申八:推理成本核算与定价策略
LLM 推理的经济学:H100 SXM5 8 卡服务器月成本约 18000 美元(AWS p5.48xlarge),Llama 3.3 70B FP8 throughput 约 4500 tok/s/GPU × 8 = 36000 tok/s,月输出 token 约 900 亿,每百万 token 成本约 0.2 美元。我们对外定价:(1) 免费 tier:每月 100 万 token 免费;(2) Pro tier:1.5 美元/百万 token(input + output);(3) 企业 tier:议价,通常 0.8 美元/百万 token;(4) 私有部署:按 GPU 小时计费 + 一次性部署费。毛利率 50-65%,这是 LLM 推理 B2B 业务的健康水平。商业模式的关键是"高吞吐 + 高利用率",GPU 利用率每提升 10%,毛利率提升 5 个百分点。
十九、引申九:LLM 安全与 Guardrails
2026 年 LLM 安全已经成为推理平台的标配能力。核心组件:(1) NVIDIA NeMo Guardrails 1.2:对话流程约束 + 内容安全;(2) Meta Llama Guard 3.0:输入输出毒性检测;(3) Microsoft Presidio:PII 自动脱敏;(4) Lakera Guard:Prompt Injection 检测;(5) Constitutional AI(Anthropic):基于宪法的对齐。我们的 Guardrails 流水线:(a) 输入层:Prompt Injection 检测 + PII 脱敏;(b) 推理中:logit_bias 屏蔽敏感 token + Llama Guard 实时审核;(c) 输出层:毒性检测 + 敏感词过滤 + 引用真实性校验。Guardrails 大约增加 80ms 端到端延迟,但能拦截 99.2% 的有害请求,这是企业 LLM 服务的必选项。
二十、引申十:Embedding 服务的优化
除了 LLM 生成,Embedding 服务也是我们平台的重点。主流模型:(1) bge-m3(BAAI 2024):多语言 + 多向量,RAG 场景准确率高;(2) e5-mistral-7b-instruct(2024):基于 LLM 的 embedding,精度最高;(3) jina-embeddings-v3(2024):多语言 + 长文档,8K 上下文;(4) nomic-embed-text-v2(2025):MoE 架构,推理快。Embedding 推理优化:(a) 用 FlashAttention 2;(b) batch size 512 以上;(c) FP16 即可,不需要 FP8;(d) Triton dynamic batching,QPS 提升 8 倍。我们公司 Embedding 服务 QPS 35 万,平均时延 12ms,P99 35ms,业务方非常满意。
二十一、引申十一:RAG 流水线与向量数据库
2026 年 RAG 已经是 LLM 应用的事实标准架构。向量数据库选型:(1) Milvus 2.5:开源最强,billion-scale 性能好;(2) Qdrant 1.13:Rust 实现,latency 低;(3) Weaviate 1.27:REST 的 over/under-fetch。">GraphQL 友好;(4) Pinecone Serverless:云原生;(5) pgvector + Postgres 17:简单场景的好选择。我们公司用 Milvus 2.5 + 自研 reranker,文档库 1.2 亿条,平均检索 P99 < 80ms。RAG 流水线优化:(a) Query rewriting:用 LLM 改写 query 提升召回;(b) Hybrid search:dense + sparse(BM25)结合;(c) Reranker:用 bge-reranker-v2-m3 二次排序;(d) Context compression:LLMLingua 把 context 压缩 5 倍。
二十二、引申十二:Agent 框架与工具调用
2026 年 Agent 已经成为 LLM 应用的主流形态。主流框架:(1) LangChain / LangGraph:生态最广;(2) LlamaIndex:RAG 优先;(3) AutoGen(微软):多 Agent 协作;(4) CrewAI:角色化 Agent;(5) OpenAI Swarm / Anthropic Computer Use。我们的 Agent 平台基于 LangGraph,核心能力:(a) Tool calling:200+ 内部工具(Slack / Jira / GitHub / Confluence / 内部数据库);(b) Multi-step reasoning:平均 5-8 步,最长 25 步;(c) Memory:short-term(同 session)+ long-term(向量库 + 摘要);(d) Human-in-the-loop:高风险操作前必须用户确认。Agent 业务对 LLM 推理的要求是"低延迟 + 强 tool calling 能力",GPT-4o / Claude 3.5 / Llama 3.3 70B 都能满足,选型按成本 / 私有部署需求决定。
二十三、引申十三:Long Context 与 1M+ token 推理
2026 年长 context 成为主流需求。主流 model context length:Llama 3.3 70B 128K、Qwen 2.5 72B 128K、Claude 3.5 200K、Gemini 1.5 Pro 1M、GPT-4 Turbo 128K。长 context 推理的挑战:(1) KV cache 内存爆炸:128K context × 70B × FP16 = 80GB+;(2) Prefill 时间长:128K prompt 在 H100 上 prefill 需要 8 秒;(3) Attention 计算 O(n²):序列长度翻倍,计算量 4 倍。优化方案:(a) Ring Attention:把 Q 在多卡间 ring 传递,内存均摊;(b) FlashAttention-3:Hopper 优化版,长 seq 比 FA-2 快 1.5-2 倍;(c) Sliding Window Attention:Mistral 系列默认,长 context 用滑动窗口;(d) StreamingLLM:把 attention sink + recent tokens 组合,理论无限长 context。
二十四、引申十四:推理平台与 vLLM Production Stack
vLLM 团队 2025 年开源了 vLLM Production Stack,把推理 / 路由 / 监控 / KV cache 共享一体化。核心组件:(1) vLLM Router:智能路由,prefix-aware 选择最优 instance;(2) LMCache:跨实例 KV cache 共享,通过 NIXL 协议传输;(3) AIBrix(开源):K8s 原生 LLM 平台,集成 Auto-scaler / GPU optimizer;(4) Inference Gateway:OpenAI 兼容 API + 多模型路由。我们公司 2026 H2 计划全量切到 vLLM Production Stack,初步实验:(a) prefix-aware routing 让缓存命中率从 32% 提升到 71%;(b) LMCache 让 multi-turn 对话 TTFT 降 60%;(c) AIBrix auto-scaler 让 GPU 利用率峰谷差从 70% 降到 20%。
二十五、引申十五:模型蒸馏与 SLM(Small Language Model)
2026 年另一个趋势是 SLM(Small Language Model):(1) Llama 3.2 1B/3B:边缘部署友好;(2) Qwen 2.5 1.5B/3B:多语言能力强;(3) Phi-3.5 mini(微软):推理能力突出;(4) Gemma 2 2B(Google);(5) SmolLM2(HuggingFace)。我们公司用 SLM 做 "agent 路由层":80% 简单请求由 1.5B model 处理,只有复杂请求才走 70B model,成本降 5 倍且延迟降 8 倍。模型蒸馏技术:(a) Knowledge Distillation:teacher 70B → student 7B,精度损失 < 5%;(b) Data Distillation:用 70B 生成训练数据微调 1.5B;(c) Speculative Distillation:1.5B 作为 70B 的 draft model。SLM + LLM 组合是 2026 年成本敏感场景的最佳实践。
二十六、引申十六:模型 fine-tuning 与 LoRA 服务化
除了通用 model,我们平台还提供企业级 fine-tuning 服务。核心技术:(1) LoRA(Low-Rank Adaptation):只训练 0.1% 参数,效果接近 full fine-tune;(2) QLoRA:LoRA + 4bit 量化,7B model 可在单张 24GB 卡上 fine-tune;(3) DoRA(2024 Q2):Weight-Decomposed LoRA,精度比 LoRA 高 2%;(4) Multi-LoRA serving:一个 base model 同时挂多个 LoRA adapter。vLLM 0.7 原生支持 Multi-LoRA,单卡 H100 可以同时 host 100+ LoRA adapter,切换开销 < 10ms。我们公司 12000 个企业客户中 38% 使用 LoRA 定制,LoRA 平台月营收 800 万,毛利率 75%。
二十七、引申十七:多模态推理与 Vision Language Model
2026 年 Vision Language Model 成为新热点。主流 VLM:(1) Llama 3.2 Vision 11B/90B;(2) Qwen 2.5-VL 7B/72B;(3) Pixtral 12B(Mistral);(4) MiniCPM-V 2.6;(5) InternVL 2.5。VLM 推理的特殊性:(a) 图像 token 数变化大(224×224 ~ 256 token,1024×1024 ~ 4096 token);(b) Vision encoder 与 LLM 分离,带宽需求高;(c) 多图 / 视频场景显存需求爆炸。优化方案:(1) Image preprocessing offload 到 CPU;(2) Vision encoder 用 ONNX Runtime 加速;(3) LLM 部分用 vLLM + FP8;(4) 多图共享 vision feature cache。我们 VLM 平台 QPS 1.8 万,P99 1.2 秒,主要服务于电商图像理解 / OCR / 多模态客服场景。
二十八、引申十八:语音模型与 TTS / ASR
除了文本和视觉,语音也是推理平台的重要 workload。TTS 主流:(1) ChatTTS;(2) Coqui XTTS-v2;(3) F5-TTS(2024 Q4);(4) Fish Audio;(5) ElevenLabs(闭源)。ASR 主流:(1) Whisper Large v3(OpenAI);(2) Whisper Turbo;(3) Faster-Whisper;(4) NVIDIA Canary 1B;(5) SenseVoice(阿里)。语音模型的特点:(a) 模型小(< 5B),单卡可跑;(b) 实时性要求高(streaming TTS 延迟 < 200ms);(c) 多语言 / 方言支持挑战大。我们语音平台架构:Triton + Faster-Whisper + ChatTTS,延迟 < 180ms,日处理 320 万分钟语音,成本仅文本 LLM 的 5%。
二十九、引申十九:模型存储与冷启动优化
70B 模型权重文件 140GB,冷启动是个大问题。优化方案:(1) ServerlessLLM(2024 NSDI):多级存储 + checkpoint loading,冷启动从 2 分钟降到 5 秒;(2) Run.ai:模型权重预热到 NVMe,加载从 SSD 60s 降到 8s;(3) NVIDIA TensorRT-LLM checkpoint:engine 序列化,加载 12s;(4) Safetensors + mmap:零拷贝加载,80GB 模型 load 用 6s。我们的方案:(a) 高频 model:常驻 GPU 显存;(b) 中频 model:权重在 NVMe,5 秒内可拉起;(c) 低频 model:权重在 S3,30 秒拉起,但客户能接受。模型冷启动是 Serverless LLM 服务的关键瓶颈,2026 年仍有创新空间。
三十、引申二十:开源 vs 闭源模型的商业选择
2026 年开源 / 闭源 LLM 的市场格局:闭源主流——GPT-4 Turbo / GPT-4o / Claude 3.5 Sonnet / Gemini 1.5 Pro;开源主流——Llama 3.3 70B / Qwen 2.5 72B / DeepSeek-V3 / Mistral Large 2。核心 trade-off:(1) 闭源精度通常领先 5-10%,但单价 5-20 美元/百万 token,贵 30 倍;(2) 开源可私有部署,数据不出域,合规友好;(3) 开源 fine-tune 自由度高;(4) 闭源 API 稳定性强,99.99% SLA。我们公司的策略:(a) C 端高质量场景用 GPT-4o / Claude;(b) B 端定制化场景用 Llama / Qwen 私有部署;(c) 内部 RAG / Agent 用开源 + 微调。2026 年开源与闭源差距缩小,DeepSeek-V3 的表现已经接近 GPT-4 Turbo,开源生态进入快车道。
三十一、引申二十一:推理团队的人才与组织
LLM 推理平台需要的人才结构:(1) Inference Engineer:CUDA / TensorRT / vLLM 内核熟练;(2) ML Systems:K8s / Triton / 调度;(3) ML Research:模型量化 / 蒸馏 / 优化;(4) DevOps:监控 / 可靠性 / 成本;(5) Solution Architect:客户场景 + 端到端方案。我们团队 22 人配比:Inference Engineer 6 人、ML Systems 5 人、ML Research 4 人、DevOps 4 人、SA 3 人。关键岗位是 Inference Engineer,2026 年市场极度稀缺,从 Google / Meta / NVIDIA 挖人成本极高,我们自己培养 9 个月才能独立担当大任。组织上挂在 CTO 直管的 AI Platform 部门,与算法、应用并列,这是 LLM 推理团队的标准组织形态。
三十二、引申二十二:对未来 5 年 LLM 推理的展望
2026-05 时点,对未来 5 年 LLM 推理的判断:(1) 2027 年 B200 / GB200 普及,推理性能比 H100 提升 5 倍,百万 token 价格降到 0.05 美元;(2) 2028 年 Disaggregated 架构成主流,长 context(1M+)成本与短 context 持平;(3) 2029 年 端侧 LLM 爆发,手机 / PC 跑 30B 级别模型,部分 workload 从云端下沉;(4) 2030 年 多模态 + Agent 全面融合,LLM 推理变成"AI 操作系统"的内核。未来 5 年 LLM 推理领域将比过去 3 年还大变革,从业者要么主动进化,要么被淘汰。我们这次踩坑录是对"LLM 推理工程化"的实战注脚。
三十三、总结与对 AI 工程师的话
11 天升级、6 个反模式、8 套修法、64 张 H100 全量切流、3 次回滚、年化云成本节省 2800 万、throughput 提升 110%、P99 降低 58%。这次升级的真正收益不是技术指标,而是团队对"LLM 推理是软硬协同工程"的根本认知。vLLM / TensorRT-LLM / SGLang / Triton / NVLink / FP8——每一项都是过去 2-3 年才成熟的技术,叠加起来构成 2026 年完全不同的 LLM 推理栈。AI 工程师的核心能力不是会用某个框架,而是"把硬件能力榨干、把成本压到极致"的能力。这份踩坑录献给每个 LLM 推理同行,愿你们少走 1-2 周弯路。
三十四、收尾感言
这次踩坑录写到这里,11 天的痛苦慢慢沉淀成团队的财富。每一个 GPU 利用率提升、每一次 P99 降低、每一份成本节省,都是 12000 个企业客户体验的微小改进。把这些经验完整记下来,是对团队 11 天熬夜的尊重,也是对未来路过同样关口同行的礼物。技术之路漫长,愿这份文档能让你们少走弯路。下一次 H100 → B200 升级,我们已经做好准备。
三十五、引申二十三:LLM 推理的可观测性深度建设
LLM 推理可观测性远比传统 API 复杂。核心指标 + 维度:(1) Per-request:TTFT / ITL / total_tokens / prompt_tokens / completion_tokens / accept_rate;(2) Per-model:throughput / KV cache util / GPU memory / GPU compute;(3) Per-tenant:QPS / TPS / quota_usage / error_rate;(4) Per-cluster:GPU utilization heatmap / network bandwidth / cost per token。我们用 OpenTelemetry Collector 把这些 metric 统一采集,Tempo 做分布式 trace,trace 一个请求从 API Gateway → Router → vLLM Worker → KV Cache → GPU kernel 完整链路。关键 trace 字段:vllm.request.id / vllm.model.name / vllm.gpu.id / vllm.batch.size / vllm.cache_hit。当 P99 异常时,trace 可以直接定位到具体 GPU 的具体 batch。
# otel_vllm_instrument.py
from opentelemetry import trace, metrics
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.trace.export import BatchSpanProcessor
tracer = trace.get_tracer('vllm.inference')
meter = metrics.get_meter('vllm.inference')
ttft_histogram = meter.create_histogram(
'vllm_ttft_seconds',
description='Time to first token',
unit='s'
)
itl_histogram = meter.create_histogram('vllm_itl_seconds', unit='s')
throughput_counter = meter.create_counter('vllm_tokens_generated_total')
async def trace_request(request_id, model, prompt):
with tracer.start_as_current_span(f'vllm.generate.{model}') as span:
span.set_attribute('vllm.request.id', request_id)
span.set_attribute('vllm.model.name', model)
span.set_attribute('vllm.prompt.length', len(prompt))
start = time.time()
first_token_time = None
async for output in engine.generate(prompt, sampling, request_id):
now = time.time()
if first_token_time is None and output.outputs[0].token_ids:
first_token_time = now
ttft_histogram.record(now - start, {'model': model})
throughput_counter.add(1, {'model': model})
span.set_attribute('vllm.tokens.completion', len(output.outputs[0].token_ids))
span.set_attribute('vllm.cache.hit_rate', output.metrics.cache_hit_rate)
span.set_attribute('vllm.spec.accept_rate', output.metrics.spec_accept_rate)三十六、引申二十四:成本优化与 Spot Instance 策略
LLM 推理成本的核心是 GPU 利用率,Spot Instance 是降本的关键武器。策略:(1) Spot 占比目标 40-50%(平衡可用性与成本);(2) Spot 中断率监控,每个 region 选 3-5 个 AZ;(3) graceful drain:中断信号 2 分钟内 drain 现有请求,新请求路由到 On-Demand 节点;(4) checkpoint:大请求(>30 秒)定期 checkpoint KV cache,中断后恢复;(5) 价格阈值:当 Spot 价格 > On-Demand 80% 时自动切换。我们公司 H100 Spot 占比 38%,月成本节省 22%。核心是"业务延迟 SLO 与成本的平衡"——P99 要求严格的 hot path 用 On-Demand,长 batch / 离线场景用 Spot。这套策略让我们 GPU 月度账单从 360 万降到 280 万。
三十七、引申二十五:推理平台的灾备与降级
LLM 推理平台的灾备设计:(1) Multi-region:每个 region 独立 deployment,DNS 智能路由;(2) Multi-cluster:同 region 内 3 个 EKS cluster,Karpenter 跨 cluster 调度;(3) Model fallback:主 model OOM 自动降级到 backup model(70B → 8B);(4) Cache fallback:KV cache miss 时降级到 stateless 生成;(5) Circuit breaker:错误率 > 5% 自动熔断,切流到健康节点。我们的灾备演练:每月 1 次"全 region 失败"演练,流量自动切到 backup region,RTO < 90 秒;每季度 1 次"主 model 全部不可用"演练,业务自动降级到 8B 备用 model。这套机制让我们在 2026-03 一次 AWS us-east-1 大故障中完美切流,客户 0 投诉。
三十八、收官:对 AI 平台同行的诚意忠告
11 天踩坑、6 个反模式、8 套修法、64 张 H100 重塑、3 次灰度回滚、2800 万年化节省。最大的收益不是性能数字,而是团队对"AI 平台工程"的根本理解:LLM 推理是"软硬协同 + 极致优化 + 工程纪律"的结合,任何一个环节松懈都会被放大 10 倍。对 AI 平台同行的忠告:(1) 不要追新框架,选 2 个最匹配业务的深度建设;(2) 不要相信默认参数,自己 profile 自己调;(3) 不要忽视硬件拓扑,NVLink / NUMA / PCIe 决定上限;(4) 不要轻信官方 benchmark,自己业务 workload 才是真相;(5) 团队培训比工具选型重要 10 倍。这些是 11 天用血泪换来的教训,值得每个 AI 工程师反复琢磨。下一次 B200 升级,我们已经准备好了。
三十九、附:LLM 推理平台升级 60 天行动指南
给打算做类似升级的团队一份 60 天清单。第 1-10 天:技术调研、硬件 profile、benchmark 基线测试,产出"现状对比报告"。第 11-20 天:测试集群搭建,跑 3 个候选框架的 head-to-head,选最匹配业务的 2 个。第 21-35 天:金丝雀上线,选 5% 流量、1 个 model、1 个 region,密切监控 TTFT / ITL / throughput / accept rate。第 36-45 天:灰度扩大到 30%,引入更多 model + region,完善 fallback 机制。第 46-55 天:全量切换,关闭旧栈但保留 7 天回滚通道。第 56-60 天:复盘 + 文档化 + 团队培训,把所有踩坑写进 runbook。这套 60 天行动指南是我们这次踩坑后沉淀的方法论,推荐给所有面临 LLM 推理平台升级的团队。技术能力是一回事,执行节奏是另一回事,两者同等重要。
四十、最后一句话
AI 推理平台不是一个静态的产物,而是一条持续演进的轨道。今天的 vLLM 0.7 明天就是 vLLM 0.8,今天的 H100 明天就是 B200,今天的 70B 模型明天就是 200B 模型。真正决定你能否驾驭这条赛道的,不是某个框架的熟练度,而是"持续学习 + 工程纪律 + 硬件理解"三件套。这份踩坑录献给每个还在路上的 AI 工程师,愿你们少走 1-2 周弯路,愿这份血泪文档能给你带来一点启发。技术之路漫长,但每一次踩坑都让我们更接近"AI 即基础设施"这个时代命题。
—— 别看了 · 2026