企业官网建设流程全解析

LLM 推理部署实战：vLLM、TGI 与 TensorRT-LLM 的选型与落地

同一个模型，用不同的推理框架部署，成本和性能可以差出 4 到 10 倍。这不是夸张——一个 13B 模型用通用加载方式在 4 张 A100 上跑，吞吐量每卡 5 QPS、P99 延迟 800 毫秒、显存占用 240 GB；换成优化的推理引擎后单卡就能跑，吞吐量提升到 80 QPS、P99 延迟降到 200 毫秒、显存占用降到 20 GB。LLM 推理优化是回报率最高的工程投入之一。本文从推理瓶颈出发，对比当前主流的三个部署方案——vLLM、TGI 与 TensorRT-LLM——给出选型建议和落地要点。

一、LLM 推理的核心瓶颈

理解推理优化，先要理解推理的两个阶段。Prefill 预填充阶段并行计算所有输入 Token，是计算密集型任务，瓶颈在 GPU 算力，优化方向是张量并行。Decode 解码阶段逐 Token 生成，是访存密集型任务，每一步都要读取历史全部 KV 向量，瓶颈在显存带宽，优化方向是 KV Cache 管理。

三个核心瓶颈值得记住。第一，KV Cache 占显存：KV Cache 大小约等于两层数乘 KV 头数乘头维度乘序列长度乘批大小再乘两个系数，一个 13B 模型在序列长度 2048、批大小 10 时，KV Cache 就接近 17 GB。第二，解码阶段每生成一个 Token 要读全量 KV，显存带宽成为瓶颈。第三，请求长度差异大，短请求和长请求混在一起时，GPU 利用率不均。

二、vLLM：当前最主流的推理框架

vLLM 的核心创新是 PagedAttention。传统注意力把 KV Cache 存成连续张量，按序列长度预分配，浪费严重——预分配 2048 Token 实际只用了 50 Token，浪费两千个。PagedAttention 把 KV Cache 像操作系统虚拟内存一样分页，每个请求的 KV Cache 分成固定大小的"页"，用页表维护逻辑位置到物理位置的映射，按需分配零浪费。效果是显存利用率从三成提升到九五成，同等显存下吞吐量提升 2 到 4 倍。

vLLM 还集成了其他关键优化：连续批处理，不用等所有请求结束，新请求可以插队；分块预填充，长输入分块避免阻塞短请求；投机解码，用小模型预生成候选 Token、大模型并行验证，加速约 2 倍；量化支持，INT8 和 INT4 降低模型体积和显存；张量并行，多卡拆分模型。

部署方式也很直接：安装后以 OpenAI 兼容接口启动服务，指定模型、张量并行大小、显存利用率、最大模型长度和端口。启动后客户端可以用标准的 OpenAI SDK 调用，把 base_url 指向本地服务地址即可，这大大降低了接入成本。高级配置包括：量化推理指定量化方式；投机解码指定草稿模型和投机步数；多 LoRA 支持同时挂载多个领域适配器，按需切换。

三、TGI：HuggingFace 的工业级方案

TGI 是 HuggingFace 推出的生产级推理服务，Rust 实现性能好，内置 Prometheus 指标，支持多模型热加载，支持 FlashAttention、GPTQ、AWQ 等推理优化。部署方式以 Docker 为主，启动时指定模型 ID、最大输入长度、最大总 Token 数和量化方式。调用走独立的 generate 接口，也可以兼容 OpenAI 协议。

TGI 与 vLLM 的对比有几个维度：性能方面 vLLM 略胜一筹；协议方面 TGI 是自定义加兼容、vLLM 原生 OpenAI 兼容；多 LoRA 支持方面 vLLM 更完整；部署方式方面 TGI 走 Docker、vLLM 是 Python 环境；监控方面 TGI 内置 Prometheus 更省心。选型建议：性能优先选 vLLM，运维省心选 TGI，多 LoRA 切换选 vLLM。

四、TensorRT-LLM：极致性能

TensorRT-LLM 是 NVIDIA 官方的 LLM 推理优化器，核心特点是编译期优化——内核融合、调度优化，以及比连续批处理更激进的飞行中批处理，量化支持 FP8、INT8、INT4。性能上比 vLLM 高 15% 到 20%，但部署门槛也高一个数量级。

部署流程是典型的"先编译后服务"：先把模型权重转换并编译成引擎文件，指定批大小、最大输入长度、最大输出长度等编译参数，然后再启动服务。这个编译过程比较耗时，而且引擎与 GPU 架构强绑定，换硬件要重新编译。适合对性能有极致要求、团队有 TensorRT 经验的场景。

三套框架的性能对比可以作为选型参考：通用加载方式吞吐 5 QPS、P99 800 毫秒；vLLM 80 QPS、200 毫秒；TGI 70 QPS、230 毫秒；TensorRT-LLM 95 QPS、180 毫秒。值得注意的是，这套数据是特定硬件和模型下的结果，实际部署要在自己的负载上压测验证。

五、量化：用精度换显存

量化是最广泛使用的模型压缩技术。FP16 模型大小视为 100%，INT8 降到约 50%、精度损失小于 1%，INT4 降到约 25%、精度损失 1% 到 3%，FP8 约 50%、精度损失小于 0.5%。选型建议：通用场景选 AWQ INT4 精度损失小；极低显存场景选 bitsandbytes INT4；Hopper 架构硬件选 FP8 近乎无损。

量化的技术难点在于离群值处理。大模型的激活值中存在少量数值极大的离群通道，若与普通通道使用相同缩放系数，会导致大部分数值被压缩到极小范围而丢失信息。AWQ、SmoothQuant 等先进算法正是针对这一问题设计：前者对重要权重通道保留更高精度，后者把激活值的量化难度部分转移到权重上。

还有一个容易忽略的层次：KV Cache 本身也可以量化。传统情况下模型权重做量化而 KV Cache 保持 FP16，实际上 KV Cache 也可以低精度存储，从 FP16 降到 FP8 存储量减少一半。对长上下文高并发场景收益直接，但要关注输出质量退化风险。权重量化解决"模型装不下"的问题，KV Cache 量化解决"并发撑不住"的问题。

六、投机解码与前缀缓存

投机解码的思路是：用小模型先"猜"答案，大模型"验证"。请求到来后，小模型预生成几个候选 Token，大模型一次性并行计算这些 Token 的概率，接受匹配的、拒绝不匹配的重新生成。在输出内容较为确定的场景下，可将生成速度提升 1 到 2 倍，且输出结果与原模型完全一致——这是它比蒸馏更优雅的地方。

前缀缓存针对重复 Prompt。如果多个请求有相同的系统提示词，KV Cache 可以复用：请求 1 计算并保存前缀，请求 2 匹配相同前缀直接复用，只计算新增部分。对于固定系统提示、大量工具定义、多轮对话、RAG 场景，前缀命中时能省掉大量预填充计算，显著降低首 Token 延迟。相关框架通过启动参数开启。

七、监控与调优清单

上线后的调优是持续工作。关键指标包括：请求成功总数、端到端请求延迟、KV Cache 利用率、抢占次数、提示 Token 总量、生成 Token 总量、首 Token 延迟、逐 Token 生成时间。通过 Prometheus 采集这些指标，支撑自动扩缩容和容量规划。

一份实用的性能调优清单：模型是否量化；是否启用连续批处理；是否启用前缀缓存；并发请求数是否合理；显存利用率是否足够；是否启用投机解码；张量并行切分是否合理；量化方式是否选对。逐项过一遍，大多数性能问题都能定位。

常见性能问题与对策：P99 延迟高通常是队列堆积，减小并发请求数；吞吐量上不去通常是显存不够，量化加张量并行切分；抢占多说明 KV Cache 不够，减小并发请求数；首 Token 延迟慢说明 Prompt 太长，用分块预填充；逐 Token 生成时间慢说明模型太大，换更小的模型。

八、总结与踩坑提示

三个框架的定位可以这样概括：vLLM 是通用首选——生态好、性能强、坑少；TGI 是运维省心之选——Docker 部署、内置监控；TensorRT-LLM 是极致性能之选——编译期优化、性能最高但部署门槛高。推理优化的三个核心原则：首选 vLLM 生态好性能强；量化是必选项，同样的硬件差 4 倍吞吐；监控加调优是持续工作，上线后根据指标调。

踩坑方面，几个高频问题值得注意：启动时报显存不足，先降低显存利用率再考虑量化和张量并行；长请求被短请求"挤"掉时用优先级字段控制；AWQ 量化后输出乱码时换 GPTQ 或 FP8，用重要性矩阵重新校准；多 LoRA 内存爆炸时让框架自动卸载不用的 LoRA；流式响应中途断流时确认使用 SSE 协议、加心跳、前端做好重连。

推理优化没有银弹，但有一条被反复验证的路线：先启用推理引擎的内置加速能力，再选择合适的量化精度，最后结合监控指标持续调优。建议在真实负载下压测不同配置，关注推理框架的最新进展，构建成本最优的大模型服务层。