从单模型到推理平台：LLM部署框架选型与vLLM实战避坑指南

1. 从单模型到推理平台：部署这件事到底在解决什么问题

模型部署这个词，听起来像是运维的活儿，但真正做过的人都知道，它横跨了算法、工程、硬件、网络四个领域。你训练出一个模型，准确率再高，如果推理延迟 3 秒、吞吐量每秒 2 个请求、显存溢出崩一次，那它在生产环境里就是不可用的。我见过太多团队在实验室里跑通了 demo，一上线就发现 QPS 撑不住、GPU 利用率不到 30%、批处理逻辑写错了导致结果串号。所以部署框架的选择，本质上是在回答一个问题：你的模型以什么形态、什么成本、什么稳定性对外提供服务。

从最早的 Flask 包一个 PyTorch 模型，到后来的 TorchServe、Triton Inference Server，再到如今 vLLM、SGLang 这类专门为大语言模型设计的推理引擎，整个技术栈的演进路线非常清晰。单模型服务解决的是“能跑起来”的问题，推理平台解决的是“跑得稳、跑得省、跑得快”的问题。这两者之间的差距，不是简单加几台机器就能填平的，它涉及到连续批处理（continuous batching）、PagedAttention 显存管理、KV Cache 复用、多模型编排、动态扩缩容等一系列工程难题。

这篇文章适合谁看？如果你手头有一个训练好的模型，想把它变成 API 服务，那前面的单模型部署部分对你有用。如果你已经在维护多个模型、多个版本，正在被 GPU 利用率和成本问题困扰，那后面关于推理平台和 vLLM 的内容会更贴合你的需求。如果你只是好奇 LLM 推理平台到底在做什么，我也会用生活化的类比把核心原理讲清楚。整篇内容基于我在实际项目中的选型经验和踩坑记录，不堆砌官方文档的复述，重点讲清楚“为什么这么选”和“怎么落地”。

2. 单模型服务：从 Flask 到 Triton 的选型逻辑

2.1 什么时候用 Flask/FastAPI 直接包模型就够了

很多人一上来就问“部署框架选哪个”，但这个问题缺少一个前提：你的模型有多大、请求量有多少、延迟要求是什么。如果你的模型是一个 100MB 以内的传统深度学习模型（比如 YOLOv5、BERT-base、ResNet），QPS 在 10 以下，那说实话，Flask 或 FastAPI 直接包一层就足够了。我试过用 FastAPI 部署一个 YOLOv5s 模型，单卡 T4，输入 640x640，端到端延迟稳定在 25ms 左右，QPS 跑到 8 的时候 GPU 利用率才 40%。这种场景下引入 Triton 或 vLLM 反而是过度设计，增加了运维复杂度，收益却很小。

FastAPI 的优势在于开发速度快、调试方便、生态成熟。你可以用 Pydantic 做请求校验，用 Uvicorn 做 ASGI 服务器，用 Gunicorn 做进程管理。一个典型的单模型服务代码结构大概是这样的：

from fastapi import FastAPI from pydantic import BaseModel import torch app = FastAPI() model = torch.load("model.pt", map_location="cuda") model.eval() class Request(BaseModel): input_data: list @app.post("/predict") async def predict(req: Request): with torch.no_grad(): tensor = torch.tensor(req.input_data).cuda() output = model(tensor) return {"result": output.cpu().tolist()}

这段代码能跑，但有几个坑要注意。第一，模型加载要在服务启动时完成，不能放在请求处理函数里，否则每次请求都重新加载模型，延迟直接爆炸。第二，要显式调用 model.eval()，否则 Dropout 和 BatchNorm 的行为会和训练时不一致，导致推理结果不稳定。第三，torch.no_grad() 必须加，不然 PyTorch 会构建计算图，显存占用会翻好几倍。第四，如果用的是 GPU，要注意请求并发时的显存竞争问题，多个请求同时推理可能会导致 OOM。

提示：FastAPI 默认是单进程的，如果你用uvicorn main:app启动，它只用一个 CPU 核心。生产环境建议用gunicorn -k uvicorn.workers.UvicornWorker -w 4 main:app启动多个 worker，但要注意每个 worker 都会加载一份模型，显存占用会成倍增加。

2.2 Triton Inference Server 解决了哪些工程痛点

当你的模型数量超过 3 个，或者你需要同时服务 PyTorch、TensorFlow、ONNX 等多种格式的模型时，Flask 那套就力不从心了。Triton 的核心价值在于统一了多框架、多模型、多版本的管理。你不需要为每个模型写一套服务代码，只需要按照 Triton 的目录规范放置模型文件，它就能自动加载并提供统一的 gRPC/HTTP 接口。

Triton 的模型仓库目录结构是这样的：

model_repository/ ├── yolov5/ │ ├── 1/ │ │ └── model.pt │ └── config.pbtxt ├── bert/ │ ├── 1/ │ │ └── model.onnx │ └── config.pbtxt └── ensemble_model/ ├── 1/ └── config.pbtxt

每个模型目录下的数字文件夹代表版本号，Triton 支持热更新，你只需要新增一个版本目录，它就能自动加载新版本而不中断服务。config.pbtxt是模型配置文件，里面定义了输入输出的名称、维度、数据类型，以及使用的后端框架（PyTorch、TensorRT、ONNX Runtime 等）。

Triton 最实用的几个功能：动态批处理（dynamic batching）可以把多个小请求合并成一个大 batch 一起推理，显著提升 GPU 利用率；模型集成（ensemble）可以把预处理、推理、后处理串成一条流水线，减少网络往返；实例组（instance group）可以控制每个模型在 GPU 上启动几个推理实例，方便做资源隔离。

不过 Triton 的学习曲线比较陡，config.pbtxt的配置项非常多，稍有不慎就会加载失败。我踩过的一个坑是：输入输出的维度顺序要和模型实际期望的一致，特别是图像模型，NCHW 和 NHWC 搞反了不会报错，但推理结果会完全错误。另一个坑是动态批处理的最大 batch size 要合理设置，设太大容易 OOM，设太小起不到批处理的效果。

2.3 单模型服务的性能瓶颈在哪里

不管你用 Flask 还是 Triton，单模型服务最终都会遇到几个瓶颈。第一个是GPU 利用率上不去，因为请求是串行到达的，GPU 在等待请求的间隙处于空闲状态。第二个是显存碎片化，特别是 LLM 场景下，KV Cache 的动态分配会导致显存碎片，最终无法分配连续的大块显存。第三个是模型切换成本高，如果你有多个模型需要轮流使用，每次切换都要重新加载权重，耗时可能达到几十秒。

这些问题在传统深度学习模型上还不算致命，因为模型小、推理快、显存占用低。但到了 LLM 场景，7B 参数的模型 FP16 精度下光权重就要占 14GB 显存，推理时 KV Cache 还要额外占用大量显存，单模型服务的架构就彻底撑不住了。这就是为什么需要 vLLM 这类专门为 LLM 设计的推理引擎。

3. LLM 推理引擎：vLLM 为什么成为事实标准

3.1 PagedAttention 和连续批处理的核心原理

vLLM 最核心的两个技术是PagedAttention和连续批处理（Continuous Batching）。这两个词听起来很学术，但用生活类比就很好理解。

先说 PagedAttention。传统的注意力机制在推理时，每个请求的 KV Cache 需要一块连续的显存空间。这就像你去停车场停车，每辆车必须停在一个完整的连续车位上，不能跨车位停放。问题是，LLM 的输出长度是不确定的，你不知道用户会生成 10 个 token 还是 1000 个 token，所以你得按最大长度预留显存。这导致大量显存被浪费，而且不同请求的 KV Cache 大小不一，容易产生碎片。

PagedAttention 的思路来自操作系统的虚拟内存分页。它把 KV Cache 切成固定大小的块（block），每个块可以存放在显存的任意位置，通过一个页表来映射逻辑块和物理块的关系。这就像停车场不再要求连续车位，而是把车位切成小格子，每辆车可以停在不同位置的格子里，只要记录好哪些格子属于哪辆车就行。这样一来，显存利用率可以从原来的 20%-40% 提升到 90% 以上。

连续批处理解决的是另一个问题。传统批处理是静态的：凑齐一批请求，一起推理，等这批全部完成后才能处理下一批。如果这批里有一个请求要生成 1000 个 token，其他请求只生成 10 个 token，那其他请求早就完成了，但 GPU 还在等那个长请求，造成浪费。连续批处理的思路是：每个推理步骤结束后，完成的请求立刻退出，新的请求立刻加入。这样 GPU 始终处于满负荷状态，吞吐量可以提升 5-10 倍。

3.2 vLLM 部署实操：从 Docker 到生产环境

vLLM 的部署方式有很多种，最推荐的是 Docker 方式，因为依赖管理最干净。官方提供了vllm/vllm-openai镜像，直接集成了 OpenAI 兼容的 API 服务。一个典型的启动命令是这样的：

docker run --gpus all \ -v /path/to/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --dtype auto

几个关键参数需要解释一下。--tensor-parallel-size是张量并行数，如果你有多张 GPU，可以设为 GPU 数量，vLLM 会自动把模型切分到多卡上。--max-model-len是最大上下文长度，这个值直接影响 KV Cache 的显存占用，设太大容易 OOM，设太小会导致长文本请求被截断。--gpu-memory-utilization是 GPU 显存利用率上限，默认 0.9，意思是 vLLM 会尝试占用 90% 的显存，留 10% 给系统和其他进程。--dtype auto会让 vLLM 自动选择精度，通常是 FP16 或 BF16。

如果你用的是消费级显卡，比如 RTX 4090 24GB，部署 7B 模型是没问题的，但 14B 模型就比较勉强了。我实测下来，Qwen2.5-7B-Instruct 在 FP16 精度下，权重占约 14GB，KV Cache 按 8192 上下文算大约占 2-3GB，总共 17GB 左右，24GB 显存够用。但如果你要部署 14B 模型，建议用量化版本，比如 GPTQ 或 AWQ 4bit 量化，权重可以压缩到 8GB 左右。

注意：vLLM 的 Docker 镜像对 CUDA 版本有要求，vllm/vllm-openai:latest通常需要 CUDA 12.1 以上。如果你的驱动版本较老，需要选择对应 CUDA 版本的镜像标签。另外，vLLM 在 Windows 上的支持一直不太好，官方推荐用 Linux 环境，Windows 用户建议用 WSL2 或者 Docker Desktop。

3.3 vLLM 的常见坑与调优经验

vLLM 用起来简单，但调优有不少门道。第一个坑是显存碎片问题。虽然 PagedAttention 已经大幅减少了碎片，但如果你的请求长度差异极大（比如有的请求 100 token，有的 8000 token），仍然可能出现显存不足的情况。解决办法是设置--max-num-seqs限制并发请求数，或者用--swap-space开启 CPU 交换空间。

第二个坑是首 token 延迟。vLLM 的连续批处理优化的是吞吐量，但首 token 延迟（Time to First Token）可能不如预期。如果你对首 token 延迟敏感，可以调整--max-num-batched-tokens参数，减小批处理的最大 token 数，让新请求更快被调度。

第三个坑是模型加载时间。7B 模型从磁盘加载到 GPU 大约需要 30-60 秒，如果你频繁重启服务，这个时间成本很高。建议用--model指向本地 SSD 路径，不要用网络存储。另外，vLLM 支持--load-format参数，可以指定safetensors格式加载，比 PyTorch bin 格式快一些。

第四个坑是多卡并行的通信开销。如果你用--tensor-parallel-size 2部署，两张卡之间需要频繁通信，如果卡间没有 NVLink，走 PCIe 的话通信延迟会明显增加。实测下来，两张 4090 走 PCIe 4.0 x16 做张量并行，吞吐量提升只有 1.5 倍左右，而不是理想的 2 倍。

4. 推理平台全景：从 vLLM 到多模型编排

4.1 推理平台需要具备哪些核心能力

当你从单模型服务走向推理平台，需求就完全不一样了。一个生产级的 LLM 推理平台，至少需要具备以下能力：多模型管理（同时服务多个模型，支持动态加载和卸载）、自动扩缩容（根据请求量自动增减推理实例）、流量调度（负载均衡、灰度发布、A/B 测试）、监控告警（GPU 利用率、延迟、吞吐量、错误率）、权限与配额（API Key 管理、速率限制、用量统计）。

这些能力不是 vLLM 一个引擎能覆盖的，vLLM 只解决了“单个模型怎么推理得快”的问题。你需要一个编排层来管理多个 vLLM 实例，一个网关层来做流量调度，一个监控层来观测运行状态。这就是推理平台和推理引擎的区别。

目前市面上有几个开源的推理平台方案可以参考。KServe是 Kubernetes 原生的模型服务框架，支持 vLLM、Triton、HuggingFace 等多种后端，自带自动扩缩容和流量管理。Ray Serve是 Ray 生态的模型服务组件，适合 Python 原生的大规模部署。GPUStack是最近比较火的一个方案，主打轻量级和易用性，支持在 Windows 和 Linux 上部署，对个人开发者比较友好。

4.2 多模型编排的实操方案

假设你有一个场景：需要同时服务一个 7B 的对话模型、一个 0.6B 的 embedding 模型、一个 reranker 模型。这三个模型的资源需求不同，对话模型需要 GPU，embedding 模型和 reranker 模型可以用 CPU 或者共享 GPU。怎么编排？

我的做法是用vLLM 服务对话模型，用 Triton 服务 embedding 和 reranker 模型，前面加一个 FastAPI 网关做路由。网关根据请求路径分发到不同的后端，同时做 API Key 校验和速率限制。这样每个模型可以用最适合的引擎，资源利用率最高。

如果你用 Kubernetes，可以用 KServe 的 InferenceService 来定义每个模型的服务，KServe 会自动创建 Deployment 和 Service，并支持基于请求量的自动扩缩容。一个典型的 KServe 配置是这样的：

apiVersion: serving.kserve.io/v1beta1 kind: InferenceService metadata: name: qwen-7b spec: predictor: minReplicas: 1 maxReplicas: 4 model: modelFormat: name: vllm runtime: vllm-runtime storageUri: "pvc://model-pvc/qwen-7b" resources: limits: nvidia.com/gpu: 1

这个配置的意思是：最少 1 个副本，最多 4 个副本，根据请求量自动扩缩容。每个副本占用 1 张 GPU。KServe 会监控请求队列长度，当队列积压时自动增加副本。

4.3 监控与可观测性：别等崩了才看日志

推理平台的监控比传统 Web 服务复杂得多，因为 GPU 是一个黑盒，你很难直接看到它内部在干什么。我建议至少监控以下几个指标：GPU 利用率（用nvidia-smi或 DCGM Exporter 采集）、显存占用（区分权重占用和 KV Cache 占用）、请求延迟（P50、P95、P99 分位数）、吞吐量（tokens/s 或 requests/s）、队列长度（等待调度的请求数）、错误率（按错误类型分类）。

Prometheus + Grafana 是标配，vLLM 自带 Prometheus 指标导出，你只需要在启动时加--metrics-port参数。Triton 也自带指标导出。关键是告警阈值要合理，比如 GPU 利用率持续 5 分钟低于 20% 说明资源浪费，持续 5 分钟高于 95% 说明需要扩容，P99 延迟超过 2 秒说明用户体验受损。

提示：不要只看平均值。GPU 利用率的平均值 60% 可能意味着有的卡 100% 有的卡 20%，负载严重不均。要看每张卡的独立指标，以及 P95/P99 分位数。

5. 常见问题与排查技巧实录

5.1 模型加载失败与显存不足的排查路径

模型加载失败是最常见的问题，原因通常有几类：显存不足、模型格式不兼容、CUDA 版本不匹配、权重文件损坏。排查顺序建议从显存开始，因为这是最容易确认的。用nvidia-smi看当前显存占用，如果空闲显存小于模型权重大小，那肯定是加载不进去的。

如果显存够但还是加载失败，检查模型格式。vLLM 支持 HuggingFace 格式、GPTQ、AWQ、GGUF 等，但不同版本支持的格式不一样。比如 vLLM 0.27.1 对 GGUF 的支持就有限，建议用 safetensors 格式。CUDA 版本不匹配通常会在日志里报CUDA error: no kernel image is available for execution on the device，这时候需要确认 vLLM 编译时的 CUDA 版本和驱动版本是否匹配。

权重文件损坏的情况比较少见，但如果你从网络下载模型时中断过，可能会遇到。可以用sha256sum校验文件哈希，和官方提供的哈希值对比。

5.2 推理结果异常与性能骤降的常见原因

推理结果异常通常有几个原因：精度问题（FP16 溢出导致 NaN）、tokenizer 不匹配（用了错误的 tokenizer 导致输入编码错误）、模型版本混淆（加载了错误的权重）。我遇到过一次，部署 Qwen 模型时用了 LLaMA 的 tokenizer，结果生成的文本完全是乱码。排查方法是先用一个简单的输入测试，比如“你好”，看输出是否正常。

性能骤降的原因更多。KV Cache 碎片化会导致显存分配失败，vLLM 会报OutOfMemoryError或者自动降低并发数。批处理大小设置不当会导致 GPU 利用率低，比如--max-num-seqs设得太小，请求排队严重。网络带宽瓶颈在多机部署时很常见，模型权重通过网络加载会非常慢。CPU 瓶颈在预处理和后处理阶段可能出现，特别是图像模型，CPU 解码和 resize 可能比 GPU 推理还慢。

5.3 常见问题速查表

5.4 独家避坑经验分享

第一个经验：不要在生产环境用 latest 标签的镜像。vLLM 的 latest 镜像更新很频繁，有时候新版本会引入 regression。建议锁定具体版本，比如vllm/vllm-openai:v0.27.1，等新版本稳定后再升级。

第二个经验：模型文件放在本地 SSD 上。我试过从 NFS 加载模型，7B 模型加载了 5 分钟，换成本地 SSD 后只要 40 秒。如果模型文件很大，可以考虑用内存文件系统（tmpfs）做缓存。

第三个经验：压测要在真实流量模式下进行。用ab或wrk压测 HTTP 接口，和真实 LLM 请求模式差别很大。LLM 请求的输入输出长度分布很不均匀，建议用真实日志回放或者用 Locust 模拟真实用户行为。

第四个经验：日志要分级。vLLM 的 DEBUG 日志量非常大，生产环境建议用 INFO 级别。但排查问题时可以临时开 DEBUG，记得排查完改回去，否则磁盘很快会被写满。

第五个经验：GPU 温度要监控。消费级显卡长时间高负载运行，温度可能到 80 度以上，触发降频。如果发现推理速度突然变慢，先看 GPU 温度。机箱风道要做好，必要时可以限制功率上限，比如nvidia-smi -pl 300把 4090 的功率限制在 300W，性能损失不大但温度会低很多。

6. 从选型到落地：我的部署决策清单

6.1 不同场景下的框架选型建议

选型没有标准答案，但可以根据场景快速缩小范围。个人开发、单模型、低并发：FastAPI + PyTorch 直接部署，简单直接。多模型、需要版本管理：Triton Inference Server，统一管理多框架模型。LLM 推理、追求高吞吐：vLLM 或 SGLang，PagedAttention 和连续批处理是刚需。Kubernetes 环境、需要自动扩缩容：KServe + vLLM，云原生方案。Windows 环境、想快速体验：GPUStack 或 LM Studio，图形化界面友好。

如果你的模型是 GGUF 格式，llama.cpp 是首选，它对 CPU 推理优化很好，适合在树莓派或没有 GPU 的机器上部署。如果你需要部署 embedding 模型，vLLM 也支持，但要注意 embedding 模型的推理模式和生成模型不同，需要设置--task embedding参数。

6.2 硬件选型与成本估算

硬件选型直接决定部署成本。L20 显卡是最近比较热门的选择，48GB 显存，适合部署 14B-32B 模型，功耗 275W，性价比不错。RTX 409024GB 显存，适合 7B-14B 模型，但消费级卡没有 NVLink，多卡并行效率低。A100/H100是数据中心卡，显存大、带宽高、支持 NVLink，但价格昂贵。

成本估算要考虑三部分：硬件成本、电费、运维成本。一张 4090 大约 1.5 万元，功耗 450W，按 0.6 元/度电算，满载运行一年电费约 2400 元。如果租用云 GPU，A100 每小时大约 10-20 元，一个月就是 7200-14400 元。所以如果长期使用，自购硬件更划算；如果只是短期实验，租用云 GPU 更灵活。

6.3 上线前的检查清单

上线前建议逐项确认：模型文件是否完整（哈希校验）、推理精度是否达标（和训练时对比）、延迟是否满足 SLA（P99 延迟）、吞吐量是否满足峰值需求（压测验证）、显存是否有余量（留 20% buffer）、监控告警是否配置（GPU、延迟、错误率）、日志是否分级（避免磁盘写满）、API Key 是否启用（防止滥用）、限流是否配置（保护后端）、回滚方案是否准备（新版本出问题能快速切回）。

这份清单看起来繁琐，但每一条都是踩过坑之后总结出来的。我见过太多团队因为没做压测，上线当天就被流量打崩；因为没配监控，GPU 挂了半小时才发现；因为没做限流，被恶意请求刷爆账单。部署这件事，细节决定成败。

6.4 后续扩展方向

如果你已经跑通了单模型部署，下一步可以尝试多模型编排，用网关做路由和限流。如果多模型也跑通了，可以尝试自动扩缩容，根据请求量动态调整实例数。再往上就是多租户隔离，不同用户分配不同的 GPU 资源配额。最后是混合部署，把 LLM、embedding、reranker 等不同模型混合调度到同一组 GPU 上，最大化资源利用率。

我个人在实际操作中的体会是：部署框架的选择要匹配团队的技术栈和运维能力。vLLM 性能好，但调优需要一定的 GPU 知识；Triton 功能全，但配置复杂；FastAPI 简单，但撑不住高并发。没有最好的框架，只有最适合当前场景的框架。先跑通，再优化，不要一开始就追求完美架构。