2、大模型部署基础：常见部署架构与推理服务框架

大模型从训练完成到真正对外提供服务，中间隔着一条名为“部署”的鸿沟。模型权重文件只是静态资产，而部署则是将模型权重、推理引擎、硬件资源、调度策略与业务接口有机整合的系统工程。本章聚焦于大模型部署的两大基石：一是部署架构的选型逻辑（单机、分布式、微服务），二是主流推理服务框架（vLLM、TGI、TensorRT-LLM）的定位与适用边界。理解这些基础，后续的日志采集、链路追踪与故障调试才有明确的落点。

大模型部署架构与推理框架选型全景 部署架构 单机部署 单卡/多卡 · 低延迟 · 开发验证 适合：原型、内部工具、小并发 分布式部署 多节点 · 张量并行/流水线并行 适合：超大模型、高吞吐 微服务部署 弹性伸缩 · 多副本 · 网关路由 适合：生产环境、高可用、多租户 推理服务框架 vLLM PagedAttention · 高吞吐 适合：在线高并发、长文本 Hugging Face TGI Text Generation Inference 适合：HF生态、快速集成 TensorRT-LLM NVIDIA 官方 · 极致性能 适合：NVIDIA GPU、生产优化 选型决策要点 • 模型规模 vs 显存容量 • 并发量级 vs 延迟要求 • 硬件平台（NVIDIA/国产） • 生态兼容（HF/TRT） • 运维复杂度与团队能力 • 日志/监控/追踪集成难度 架构决定资源边界，框架决定性能上限，两者共同决定日志与追踪的观测维度

2.1 部署架构的核心原理与选型逻辑

部署架构的本质是在资源成本、服务性能、运维复杂度三者之间寻找平衡点。单机部署将所有组件压缩在一台物理机内，依赖单机GPU显存与计算能力；分布式部署将模型切分到多节点，通过高速互联（如NVLink、InfiniBand）协同计算；微服务部署则进一步将推理服务、预处理、后处理、API网关等拆分为独立进程，通过容器化与编排系统（如Kubernetes）管理生命周期。

选型时需回答三个关键问题：模型能否装入单卡显存？（决定是否需要张量并行）；单机吞吐能否满足业务峰值？（决定是否需要水平扩展）；团队是否有能力运维分布式系统？（决定微服务化深度）。下表对比了三种架构的核心差异：

维度单机部署分布式部署微服务部署
硬件规模1~8卡单机多节点多卡多节点+CPU/GPU混合
典型延迟低（<100ms）中（100~300ms）中高（含网络开销）
吞吐扩展受限于单机总线通过并行策略扩展通过副本数水平扩展
故障域单点故障节点故障影响面大故障隔离性好
运维复杂度低高（需并行策略配置）中高（需容器编排）
适用场景开发调试、内部工具超大模型（>100B）生产环境、多租户

实际生产环境常采用混合架构：前端通过微服务网关路由请求，后端将推理服务以分布式方式部署，再通过水平扩展多个推理副本支撑高并发。这种分层设计既保证了弹性，又兼顾了性能。

2.2 推理服务框架：vLLM、TGI、TensorRT-LLM

推理框架负责将模型权重加载到显存、执行前向计算、管理KV Cache、调度请求并返回结果。不同框架在显存管理、批处理策略、算子优化上各有侧重，直接影响吞吐与延迟。

2.2.1 vLLM：PagedAttention驱动的吞吐利器

vLLM的核心创新是PagedAttention，它将KV Cache划分为固定大小的块（Page），按需分配，类似操作系统虚拟内存管理。传统框架需为每个请求预分配最大长度显存，导致大量浪费；vLLM通过块级管理将显存利用率提升至90%以上，并支持连续批处理（Continuous Batching）——当一个请求的生成结束时，立即插入新请求，无需等待整个批次完成。

关键优势：高吞吐、长文本友好、与HuggingFace模型无缝集成。适合在线服务、多用户并发场景。

vLLM的日志输出包含详细的调度信息，例如：

INFO 06-10 14:23:45 scheduler.py:312] Added request req-001, prompt_len=128, max_tokens=512
INFO 06-10 14:23:45 scheduler.py:356] Running batch #1 with 8 requests, total_tokens=2048
INFO 06-10 14:23:46 model_runner.py:210] Generated 64 tokens in 0.82s, throughput=78.0 tok/s

这些日志是排查吞吐瓶颈的第一手资料——若total_tokens远低于显存容量，说明批大小未打满；若throughput波动剧烈，需检查是否出现显存碎片或CPU Offload。

2.2.2 Hugging Face TGI：生态集成与快速部署

TGI（Text Generation Inference）由Hugging Face维护，原生支持HF生态的模型格式与分词器，内置模型并行（Model Parallelism）、动态批处理、量化（GPTQ/AWQ）等功能。TGI的定位是“开箱即用”，通过Docker镜像即可拉起服务，并提供RESTful API与gRPC接口。

TGI的日志结构清晰，包含请求级追踪信息：

2025-06-10T14:23:45.123Z INFO generate: request_id=abc123, model=gpt2, prompt_tokens=64, generated_tokens=128
2025-06-10T14:23:45.456Z INFO batch: batch_size=16, max_tokens=2048, queued_requests=3

TGI适合快速原型验证和中小规模生产，但极致性能优化不如TensorRT-LLM。若团队已深度使用HF生态，TGI是降低集成成本的首选。

2.2.3 TensorRT-LLM：NVIDIA生态的极致性能

TensorRT-LLM是NVIDIA官方推出的推理框架，它将模型编译为TensorRT引擎，针对Ampere、Hopper、Blackwell架构GPU做深度算子融合与内核调优。支持FP8/INT4量化、KV Cache量化、Inflight Batching（请求级调度），在相同硬件上吞吐可比vLLM提升30%~50%。

但代价是编译时间长（大模型需数小时）、灵活性低（模型结构需符合TRT支持范围）、调试困难（引擎内部黑盒）。TensorRT-LLM的日志以引擎加载和推理统计为主：

[TensorRT-LLM][INFO] Loaded engine from /models/llama2-7b-trt.engine, max_batch_size=64
[TensorRT-LLM][INFO] Inference batch: 16 requests, total_input_tokens=1024, total_output_tokens=2048
[TensorRT-LLM][INFO] GPU memory usage: 12.4GB / 24.0GB, KV cache: 4.2GB

选择TensorRT-LLM的前提是：硬件为NVIDIA GPU、模型结构稳定、追求极致性能且有专门的性能优化工程师。

2.3 框架选型对比与决策矩阵

三个框架并非互斥，实际项目中常组合使用。下表从多个维度给出选型建议：

评估维度vLLMTGITensorRT-LLM
吞吐性能高中高极高
显存效率极高（PagedAttention）高（动态批处理）高（量化+KV Cache优化）
模型兼容性HF模型直接加载HF模型直接加载需转换为TRT引擎
部署复杂度低（pip install）低（Docker）高（编译+调优）
日志/追踪结构化日志，易集成JSON日志，含请求ID引擎级日志，需二次解析
社区活跃度极高高中高（NVIDIA主导）
最佳场景在线高并发、长文本快速集成、HF生态固定模型、极致性能
经验建议：若业务处于快速迭代期，优先选择vLLM或TGI；当模型稳定且GPU利用率成为瓶颈时，再迁移至TensorRT-LLM。迁移前务必用压测工具（如Locust、wrk）对比三个框架在相同硬件上的吞吐与延迟，避免凭经验决策。

2.4 实战场景：从单机到微服务的演进路径

某智能客服团队部署一个7B对话模型，初始阶段使用单机单卡（A100 80G）运行vLLM，日请求量约5万次。随着业务增长，日请求量攀升至50万次，单机吞吐达到瓶颈（峰值时请求排队超过3秒）。团队决定演进为微服务架构：

  1. 拆分服务：将请求预处理（意图识别、敏感词过滤）与推理服务分离，前者部署在CPU节点，后者保留GPU节点。
  2. 水平扩展：将vLLM推理服务容器化，通过Kubernetes部署3个副本，前端使用Nginx做负载均衡。
  3. 引入TGI作为备用：保留一个TGI服务作为降级方案，当vLLM节点故障时自动切换。
  4. 监控与日志：在网关层记录请求耗时、排队长度、GPU利用率，在推理层记录每次请求的prompt_tokens与generated_tokens。

演进后，系统峰值吞吐从80 QPS提升至350 QPS，P95延迟从2.1秒降至0.8秒。复盘发现，日志中“排队请求数”是扩容的关键指标——当该值持续超过10时，应触发自动扩容。

风险提示：微服务化并非银弹。若请求体较大（如多轮对话历史），网络传输开销可能抵消扩展收益。建议在网关层开启gzip压缩，并评估是否将KV Cache预热（Prefix Caching）前置到网关层。

2.5 常见误区与总结复盘

在部署架构与框架选型中，团队常陷入以下误区：

  • 盲目追求分布式：7B模型单卡即可部署，强行使用张量并行反而增加通信开销，吞吐下降20%以上。
  • 忽略框架日志差异：vLLM的scheduler.py日志与TensorRT-LLM的引擎日志格式完全不同，统一日志采集需在框架层做适配。
  • 只关注吞吐不关注延迟分布：平均延迟低不代表P99延迟可接受，需在日志中记录分位数指标。
  • 将框架与架构混为一谈：vLLM可以部署在单机，也可以部署在分布式集群；微服务架构同样可以使用TensorRT-LLM作为推理引擎。架构解决资源组织问题，框架解决计算效率问题。
← 上一章 📖 返回目录 下一章 →