大模型部署基础：推理流程、部署方式与推理引擎

大模型从训练完成到真正对外提供服务，中间隔着一条名为“部署”的鸿沟。训练阶段关注的是如何降低 Loss，而部署阶段关注的是如何在有限的算力、内存、带宽和延迟约束下，将模型能力稳定、高效地释放出来。本章作为性能基准测试的前置基础，将系统梳理大模型推理的基本流程、三种主流部署形态（云端、边缘、本地）以及当前工业界最常用的推理引擎（vLLM、TensorRT-LLM、TGI），为后续章节的基准测试方法、指标解读和调优实践建立统一的认知框架。

大模型部署全景：推理流程 × 部署形态 × 推理引擎 ① 推理基本流程（离线/在线） 输入预处理 Token 化 Prefill 预填充 Decode 逐Token生成 采样与输出 后处理 计算密集 · 可并行 访存密集 · 串行 · 瓶颈 ② 云端部署 • 弹性GPU/TPU集群 • 高吞吐、多租户 • 典型：API服务、SaaS • 延迟：50-200ms • 成本：按需/包年 ③ 边缘部署 • 靠近数据源/用户 • 低延迟、数据本地化 • 典型：智能终端、网关 • 延迟：10-50ms • 算力：量化/蒸馏模型 ④ 本地部署 • 私有化、数据安全 • 单机/小集群 • 典型：工作站、私有服务器 • 延迟：可定制优化 • 成本：硬件一次性投入 ⑤ 主流推理引擎 vLLM PagedAttention 显存管理 Continuous Batching 高吞吐 · 易用 · 社区活跃 TensorRT-LLM NVIDIA 官方 · 图优化 FP8/INT4 量化 · 极致延迟 需编译 · 硬件绑定 HuggingFace TGI Text Generation Inference 与 HF 生态无缝集成 支持量化 · 生产级

上图从三个维度勾勒了大模型部署的核心骨架：推理流程决定了性能瓶颈的位置，部署形态决定了资源约束与优化目标，推理引擎则决定了底层算力释放的效率。下面逐一展开。

2.1 大模型推理的基本流程：从输入到输出的完整链路

核心原理：Prefill 与 Decode 的两阶段本质

大模型推理（Inference）与训练的本质区别在于：训练是前向+反向传播更新权重，而推理只做前向计算，且以自回归（Autoregressive）方式逐 Token 生成输出。整个推理过程可拆解为两个计算特征截然不同的阶段：

  • Prefill（预填充）阶段：将用户输入的 Prompt 一次性编码为 KV Cache（键值缓存），并行计算所有输入 Token 的注意力分数。此阶段属于计算密集型（Compute-bound），GPU 利用率高，耗时主要取决于输入长度和模型参数量。
  • Decode（解码）阶段：逐个生成输出 Token，每生成一个 Token 需要读取全部 KV Cache 并更新。此阶段属于访存密集型（Memory-bound），GPU 算力利用率通常不足 30%，耗时主要取决于模型大小、KV Cache 容量和显存带宽。

理解这两个阶段的差异是性能调优的起点。例如，在基准测试中，如果测试数据以短 Prompt 长输出为主，则 Decode 阶段主导延迟；如果以长 Prompt 短输出为主，则 Prefill 阶段主导首 Token 延迟（TTFT）。

判断方法：识别推理链路中的关键性能指标

在实际部署中，我们需要通过一组指标来量化推理流程的健康度。下表列出了与推理流程直接相关的核心指标及其含义：

指标名称缩写定义对应阶段典型优化手段
首 Token 延迟TTFT从请求发出到收到第一个输出 Token 的时间Prefill减少 Prompt 长度、使用投机采样
单 Token 生成延迟TPOT生成每个输出 Token 的平均耗时DecodeKV Cache 量化、减少模型层数
端到端延迟E2E Latency完整请求的总耗时全流程优化 Prefill/Decode 平衡
吞吐量Throughput单位时间处理的请求数或 Token 数全流程Continuous Batching、动态批处理
显存占用VRAM Usage模型权重 + KV Cache + 激活值全流程量化、PagedAttention、KV Cache 复用

案例拆解：一个在线聊天机器人的推理链路分析

假设我们部署一个 7B 参数的对话模型，用户输入 200 Token 的 Prompt，期望输出 500 Token 的回答。在 A100 80G 显卡上，我们观察到：

  • 初始现象：TTFT 为 800ms，TPOT 为 45ms，端到端延迟约 23.3s，吞吐量仅 21 Token/s，远低于业务要求的 50 Token/s。
  • 分析过程：通过 profiling 工具发现，Prefill 阶段 GPU 利用率达 85%，但耗时仅 0.8s；Decode 阶段 GPU 利用率仅 18%，耗时 22.5s，占端到端延迟的 96.5%。瓶颈明确指向 Decode 阶段的访存瓶颈。
  • 操作步骤：① 启用 vLLM 的 PagedAttention 减少显存碎片；② 开启 Continuous Batching 将并发请求从 1 提升至 8；③ 将 KV Cache 精度从 FP16 降为 FP8。
  • 结果对比：优化后 TPOT 降至 28ms，吞吐量提升至 68 Token/s，端到端延迟降至 14.8s，满足业务要求。
  • 复盘经验：Decode 阶段的优化空间远大于 Prefill 阶段；批处理大小是吞吐量的杠杆，但受限于显存容量。
经验提醒：在基准测试中，务必分别记录 TTFT 和 TPOT，而不是只记录端到端延迟。两者反映的是完全不同的硬件瓶颈，混合统计会掩盖真实问题。

2.2 部署方式：云端、边缘与本地

核心原理：三种形态的资源边界与优化目标

部署方式的选择本质上是延迟、成本、数据安全、算力规模四者的权衡。云端部署追求弹性与高吞吐；边缘部署追求低延迟与数据本地化；本地部署追求完全可控与私有化。三者的技术栈差异显著：

  • 云端部署：通常使用 A100/H100 等数据中心 GPU，配合 Kubernetes 进行弹性伸缩，通过 API Gateway 对外提供 REST/gRPC 服务。适合大规模并发、模型频繁迭代的场景。
  • 边缘部署：使用 Jetson Orin、边缘服务器等中低功耗设备，模型需经过量化（INT8/INT4）或蒸馏压缩。适合实时性要求高、网络不稳定、数据隐私敏感的场景。
  • 本地部署：使用单张或多张消费级/专业级 GPU（如 RTX 4090、A6000），模型可保持 FP16 精度。适合企业内部知识库、代码辅助等中等并发场景。

判断方法：部署形态选择决策清单

在项目启动前，建议按以下顺序进行决策：

  1. 数据合规性：数据是否允许离开本地？若否，直接选择本地或边缘部署。
  2. 延迟预算：业务要求的 P99 延迟是多少？若小于 50ms，边缘部署优先；若可接受 200ms 以上，云端部署即可。
  3. 并发规模：峰值 QPS 是多少？若超过 100，云端弹性扩容更经济；若低于 10，本地单卡即可。
  4. 成本模型：对比云端按量付费与本地硬件折旧+电费+运维成本，通常以 3 年为周期计算总拥有成本（TCO）。

案例拆解：某金融企业的智能客服部署选型

某证券公司需要部署一个 13B 参数的智能客服模型，处理客户咨询。约束条件：① 客户数据涉及个人隐私，不能出域；② 业务要求首响应时间小于 1.5s；③ 日请求量约 5 万次，峰值 QPS 约 20。

  • 方案对比：云端部署（公有云）因数据合规被否决；边缘部署（Jetson）算力不足，13B 模型 INT8 量化后仍需 16GB 显存，Jetson Orin 64G 勉强可跑但延迟超标；本地部署（2×RTX 4090）满足算力与合规要求。
  • 实施过程：采用 TensorRT-LLM 对模型进行 FP8 量化，使用张量并行（Tensor Parallelism）将模型拆分到两张 4090 上。实测 TTFT 为 0.9s，TPOT 为 35ms，满足业务要求。
  • 结果与代价：硬件投入约 5 万元，电费与运维成本约 2000 元/月；相比公有云按量付费（约 1.2 万元/月），一年半即可收回成本。
  • 复盘：本地部署并非“省钱”的代名词，当并发规模增长到 QPS>100 时，本地扩容成本将急剧上升，届时需重新评估云端方案。
风险提示：边缘部署的硬件更新周期短（通常 2-3 年），且大模型迭代速度快，可能出现“硬件刚买就过时”的情况。建议在边缘部署时预留 30% 的算力冗余。

2.3 常见推理引擎：vLLM、TensorRT-LLM 与 TGI

核心原理：推理引擎的三大核心能力

推理引擎的本质是调度器 + 显存管理器 + 计算优化器的组合。不同引擎的差异主要体现在：

  • 批处理策略：静态批处理（等待凑满一批再计算） vs 连续批处理（Continuous Batching，一个请求的 Decode 完成后立即插入新请求）。后者可显著提升 GPU 利用率。
  • 显存管理：传统方式为预分配固定大小的 KV Cache，容易产生碎片；vLLM 的 PagedAttention 将 KV Cache 分页管理，按需分配，显存利用率提升至 90% 以上。
  • 计算图优化：TensorRT-LLM 在编译阶段进行算子融合、层融合、精度校准，生成高度优化的 TensorRT 引擎，但需要针对具体 GPU 型号编译，且编译时间较长。

对比分析：三大引擎的选型参考

维度vLLMTensorRT-LLMTGI
开发语言Python + CUDAC++ + Python APIRust + Python
显存优化PagedAttention（分页）KV Cache 量化 + 内存池FlashAttention + 量化
量化支持AWQ、GPTQ、FP8FP8、INT4、INT8（SmoothQuant）GPTQ、AWQ、FP8
硬件适配NVIDIA GPU（通用）仅 NVIDIA GPU（需编译）NVIDIA/AMD/CPU
易用性⭐️⭐️⭐️⭐️⭐️（开箱即用）⭐️⭐️（需编译调优）⭐️⭐️⭐️⭐️（HF 生态）
典型场景高吞吐在线服务极致延迟/吞吐优化快速原型 + 生产

实战场景：如何选择与切换引擎

以一个实际项目为例：某团队需要将 Llama-3-8B 部署为内部代码补全服务，要求 P99 延迟小于 100ms，吞吐量大于 100 Token/s。

  • 初始尝试：直接使用 vLLM 默认配置，实测 P99 延迟 150ms，吞吐量 80 Token/s，不达标。
  • 调优过程：① 在 vLLM 中开启 --enable-prefix-caching 复用公共代码前缀的 KV Cache；② 将 --max-num-seqs 从 256 调至 512；③ 切换至 TensorRT-LLM，使用 FP8 量化并编译引擎。
  • 结果对比：vLLM 调优后 P99 降至 120ms，吞吐 95 Token/s；TensorRT-LLM 编译后 P99 为 85ms，吞吐 130 Token/s，达标。
  • 代价与决策：TensorRT-LLM 编译耗时约 40 分钟，且后续模型更新需重新编译。考虑到模型迭代频率较低（每月一次），最终选择 TensorRT-LLM 作为生产引擎，vLLM 保留为开发环境。
总结复盘：推理引擎没有绝对的“最好”，只有“最合适”。vLLM 适合快速迭代和动态批处理场景；TensorRT-LLM 适合追求极致性能且硬件固定的生产环境；TGI 适合深度绑定 HuggingFace 生态的团队。在基准测试中，建议至少对比 vLLM 与 TensorRT-LLM 两组数据，以量化引擎优化带来的收益。
← 上一章 📖 返回目录 下一章 →