最近帮好几家公司把大模型从“能跑”推到了“能扛生产流量”的阶段，踩了不少坑，也总结出一套可以复用的流程。正好赶上 2026 年这一轮框架和云服务的版本迭代，不少朋友私信问我到底该怎么选型、怎么部署，干脆把这几个月实战下来的经验整理成一篇完整的指南，覆盖框架选型、云服务对比，还有从零到生产环境的完整落地流程。
这篇内容适合三类人：一是刚把模型跑通、准备上线的算法工程师；二是负责给模型团队搭环境的运维和平台工程师；三是老板让“评估一下大模型部署方案”但还没什么头绪的技术负责人。我会尽量把选型的逻辑、对比的数据、部署的每一步都讲透，能直接照着操作。
1. 部署前必须想清楚的三件事
很多人一上来就问我“用哪个框架好”，其实这个问题根本不能独立回答。框架选型完全取决于你的场景约束，而场景约束主要由三件事决定：并发规模、延迟要求和成本预算。这三件事没想清楚之前，换再好的框架也是白搭。
1.1 先估算你的真实并发需求
这里的并发不是指“注册用户数”，而是指实际同时打到你推理服务上的请求数。用一个简单公式估算：
并发数 ≈ 每秒请求数(QPS) × 单请求平均耗时(秒)举个例子：你们给内部办公系统做智能助手，平均每秒进来 5 个请求，每个请求平均生成 800 个 token、速度大概 50 token/s，那单请求耗时差不多 16 秒。5 × 16 = 80，意味着你至少要有能同时处理 80 个请求的能力。这 80 个并发如果全挤在一块 GPU 上，显存和算力都会非常吃紧。
我一般建议先做 7 天的日志埋点，统计真实调用高峰和平均值。不要拍脑袋定指标，我就见过一个项目按“双十一峰值”去设计，结果日常负载只有峰值的 5%，GPU 空转一个月，成本直接翻了三倍。
1.2 分清你的延迟敏感度
不同场景对延迟的要求天差地别：
| 场景类型 | 可接受首 token 延迟 | 典型业务 |
|---|---|---|
| 实时交互 | < 1 秒 | 客服机器人、代码补全 |
| 准实时 | 1~3 秒 | 文档摘要、报表生成 |
| 离线批处理 | 不敏感 | 数据清洗、知识库向量化 |
这直接决定了你要不要上连续批处理（continuous batching）、要不要做KV Cache 量化、甚至要不要考虑投机解码。实时交互类业务对首 token 延迟极其敏感，如果模型是 70B 级别，单卡跑不动，就得考虑张量并行+流式输出，这些后面细讲。
1.3 预算决定了你的整个技术栈
GPU 成本是大模型部署的大头，没有之一。你选择的框架如果能把显存利用率从 60% 拉到 85%，那就等于省了一块卡的钱。这也是为什么 vLLM 这类做极致显存优化的框架能火起来——它不是“更好的推理实现”，而是“单位成本里能塞进更多并发”。
2. 2026 主流推理框架选型对比
目前生产环境里跑大模型推理，基本就是以下几个框架的天下。我把 2026 年初的现状梳理一下，每个都给出适用场景和劝退点。
2.1 vLLM：生产环境的首选
vLLM 至今仍是我在高并发生产场景下的默认选择。它的核心优势是 PagedAttention——把 KV Cache 按页管理，类似操作系统里的虚拟内存分页，把显存碎片问题从根上解决了。
实测下来，在同样一张 A100 上，vLLM 的吞吐量比传统 Hugging Face Transformers 的 naive 部署高出2~4 倍，这在业界已经不新鲜了。它的 Continuous Batching 调度机制能够在每个 step 动态插入新请求，不会因为某个慢请求阻塞整条流水线。
vLLM 的定位是 OpenAI 兼容 API 服务，部署完直接暴露/v1/chat/completions接口，现有的 OpenAI SDK 改个 base_url 就能切过来。这个兼容层太值钱了——不需要改业务代码，迁移成本几乎为零。
不过 vLLM 也有它的毛病：对新手不太友好。启动参数非常多，--gpu-memory-utilization、--max-model-len、--tensor-parallel-size这些都要理解清楚，不然很容易出现“显存明明够用却 OOM”的诡异问题。
2.2 TensorRT-LLM：需要榨干性能的时候才上
NVIDIA 的 TensorRT-LLM 是“性能天花板”的代名词。它把模型编译成 TensorRT Engine，算子融合、精度校准、内核自动调优全给你安排上，推理延迟通常比 vLLM 再低 20%~30%。
但要付出不小的代价：编译时间长、图结构固定。模型一变，Engine 就要重新编译，快则半小时慢则几小时。动态 shape 虽然支持，但配置起来非常繁琐。我一般只建议在两种情况下选 TensorRT-LLM：一是模型版本非常稳定、不需要频繁迭代；二是追求极致延迟的业务，比如实时语音交互，对首 token 延迟有硬性要求。
2.3 Ollama：本地开发和中小规模部署的便利选择
Ollama 在 2025 年之后基本成了本地开发环境的标准配置。一条命令拉模型、一条命令起服务，CPU 也能凑合跑，开发者手里的 MacBook 就能玩转。它最大的贡献是把大模型部署的门槛降到了几乎为零——这对推动生态普及的意义远大于框架本身的性能。
但把 Ollama 直接搬上生产，我持保留态度。它的并发控制、显存管理、动态 batch 能力都偏弱，接口也不是完整的 OpenAI 兼容格式，虽说新版本在改进，但和 vLLM 比起来，在高并发场景下的表现还是有明显差距。我的结论是：Ollama 适合个人电脑和开发测试，真要扛线上流量，换 vLLM。
2.4 TGI 与 SGLang：补充两个有力选项
Hugging Face 的 Text Generation Inference（TGI）也值得关注，它由 HF 官方维护，对 HF 生态模型的兼容性最好，很多模型的特性（比如 message 格式的 chat template）在 TGI 上支持得最及时。但性能和调度灵活性上，它和 vLLM 相比并不占优。
SGLang 则是这两年冒出来的新锐，主打 RadixAttention 技术——通过缓存公共前缀来加速推理。对多轮对话、Agent 类场景（每次请求都带很长的 system prompt 和上下文）效果极佳，在某些工作负载下吞吐量甚至能超过 vLLM。不过它的生态成熟度、周边工具链还在追赶，新版本偶尔会有行为变动，生产使用需要多盯 release note。
2.5 框架选型决策表
| 框架 | 最佳场景 | 吞吐量 | 延迟 | 上手难度 | 生态成熟度 |
|---|---|---|---|---|---|
| vLLM | 通用生产环境 | 高 | 低 | 中 | 极高 |
| TensorRT-LLM | 追求极致性能 | 最高 | 最低 | 高 | 高 |
| Ollama | 本地开发/测试 | 中低 | 中 | 极低 | 高 |
| TGI | HF 模型生态 | 中高 | 中 | 低 | 高 |
| SGLang | Agent/长上下文 | 高 | 低 | 中 | 中 |
3. 云服务选型与成本对比
框架定了之后，第二个大头就是“跑在哪”。2026 年主流选择基本是三大类：国内云厂商的 GPU 云主机、海外云厂商的国际节点、以及国内新出现的“弹性按需 GPU 算力平台”。我分别说说实际体验。
3.1 国内主流云厂商的 GPU 产品形态
国内云厂商目前主推的 GPU 实例大致分三种：
- 包年包月 GPU 云主机：适合长期稳定的生产负载。按月付费，单价最低，但绑定了固定的机型配置，想临时扩容要额外开机器。
- 按量付费 GPU 实例：按秒或按小时计费，随开随停。适合模型评测、临时压测、短期项目。缺点是单价贵，长时间跑不划算。
- GPU 容器服务 / Serverless：把推理服务打成容器镜像，由平台自动调度 GPU 资源，按调用量或按 GPU 时长计费。适合流量波动明显的业务。
我的经验是：稳定的核心链路用包年包月，突发流量用按量或 Serverless 兜底。混部策略能省不少钱，但前提是你的服务要支持弹性伸缩，后面会讲怎么做。
3.2 各厂商的差异化体验
说到具体厂商，我尽量客观，只讲实际操作中的主观感受：
阿里云的 GPU 生态最全，PAI 平台和容器服务 ACK 结合得很紧，如果你本来就在阿里云的 VPC 里，数据走内网不花流量费，延迟也低。ECS 的 GPU 实例型号覆盖从 T4 到 H 系列都有，但热门规格在高峰期偶尔会出现库存紧张。
腾讯云的 GPU 实例性价比时常有优势，尤其是一些促销活动能把成本压到很低的水平。TIONE 平台对开源模型的适配做得不错，很多模型直接一键部署。
华为云在昇腾芯片的推理上有独特优势，如果涉及国产化要求、或者想用昇腾卡跑量化模型，ModelArts 平台是绕不开的选择。但昇腾的软件栈和 CUDA 生态有差异，迁移时要注意算子兼容性。
海外厂商，AWS、Azure、GCP 的 GPU 集群规模大、型号新，国内访问延迟高，合规和数据出境问题也要考虑。一般除非业务本身就在海外，否则我不建议国内团队直接用。
3.3 一个可参考的计费对比表
以下是我整理的一个粗略参考（2026 年初的公开价格区间，实际以官网为准）：
| 云厂商 | 实例类型 | GPU 型号 | 参考价格(元/小时) | 适合场景 |
|---|---|---|---|---|
| 阿里云 | ecs.gn7i | A10 | 约 12~18 | 中小并发推理 |
| 阿里云 | ecs.gn6e | A100 40G | 约 30~45 | 70B 模型张量并行 |
| 腾讯云 | GN7 | T4 | 约 5~8 | 7B 模型轻量推理 |
| 腾讯云 | GN10Xp | A100 | 约 28~40 | 生产主力 |
| 华为云 | Pi2 | Ascend 310 | 约 4~6 | 边缘轻量推理 |
| 华为云 | P3 | Ascend 910B | 约 20~35 | 国产化推理 |
注意这些价格会随时变动，而且带宽、存储、快照都是单独计费的，别只盯着 GPU 单价看。我见过一个项目 GPU 费用占比 70%，看起来没毛病，结果仔细一算，公网带宽和数据盘快照的费用居然占到了总账单的 25%，这部分的优化空间往往被忽略。
3.4 从成本角度的选型建议
如果你的模型是 7B~13B 级别（INT8 量化后大概 8~16GB 显存），一张 24GB 显存的卡（比如 RTX 4090 云主机或 A10）就能跑得很舒服，没必要上 A100。
如果是 70B 级别，FP16 精度大约需要 140GB 显存，一张卡肯定放不下，至少需要2 张 A100 80G 做张量并行，或者用 INT4 量化后塞进单张 A100 80G。这里有个关键权衡：量化省显存但损失精度，张量并行保证精度但增加卡间通信开销。我的经验是：70B 模型做 INT8 张量并行（2卡）通常是性价比最均衡的方案。
4. 生产级部署全流程实录
框架和云主机都定了，下面就是我这两次项目落地时跑通的完整流程。我按实际执行顺序写，每条都标注容易踩的坑。
4.1 环境准备：驱动、容器运行时与必要依赖
拿到一台 GPU 云主机后，第一步不是装模型，而是把底层环境理顺。
先确认 GPU 驱动是否就绪：
nvidia-smi如果输出正常，可以看到 GPU 型号、驱动版本和显存总量。驱动版本和 CUDA 版本的匹配是关键，比如你要跑 vLLM 0.6 以上版本，要求 CUDA 11.8 或 12.x，驱动版本至少要 525 以上。
我强烈建议直接用官方 Docker 镜像，而不是在宿主机上裸装 CUDA 环境。原因很简单：裸装环境只要一次 apt 升级把驱动搞崩了，整个服务直接挂掉；容器化之后，GPU 驱动只需要在宿主机装好，CUDA 库、框架依赖统统在镜像里隔离，换版本也只是换个 tag 的事。跑起来之前记得把 NVIDIA Container Toolkit 装上：
sudo apt-get install -y nvidia-container-toolkit sudo systemctl restart docker然后拉起带 GPU 的容器测试一下：
docker run --rm --gpus all nvidia/cuda:12.1.0-runtime-ubuntu22.04 nvidia-smi能看到 GPU 信息就说明容器能访问 GPU 了。
4.2 模型获取与转化
模型来源通常有两个：Hugging Face 和 ModelScope（国内访问速度更友好）。语法上两者大同小异，用 Hugging Face 的snapshot_download最为顺手：
from huggingface_hub import snapshot_download snapshot_download( repo_id="Qwen/Qwen2.5-72B-Instruct", local_dir="/data/models/qwen2.5-72b-instruct", max_workers=8 )这里有个实操细节：务必先下到本地目录，再用本地路径启动服务。不要直接把repo_id传给 vLLM 让它联网拉——生产环境一旦断网，服务起不来，你就等着被线上事故群艾特吧。
下载完以后，用llm推理框架直接加载之前，我习惯先检查模型文件的完整性，尤其是分片文件（.safetensors的多个分片）是否齐全。当场踩过一次：某个分片下载中断，启动时日志显示“file not found”，重新下才恢复。建议用huggingface-cli download代替手写下载，它能做断点续传和完整性校验。
4.3 用 vLLM 启动生产服务
模型到位后，我用 vLLM 启动服务时会把参数写成一个start.sh脚本，方便重启和审计：
#!/bin/bash docker run -d --gpus all \ --shm-size=16g \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/qwen2.5-72b-instruct \ --served-model-name qwen72b \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 \ --max-num-seqs 64 \ --enable-prefix-caching逐个参数说明一下：
--tensor-parallel-size 2：用两张卡做张量并行，把 72B 模型的权重和 KV Cache 分摊到两张卡上。注意每张卡显存要一致，混用 40G 和 80G 卡会直接报错。--gpu-memory-utilization 0.9：让 vLLM 最多使用 90% 的显存。留出 10% 给 CUDA context 和其他开销，设 1.0 很大概率会 OOM。--max-model-len 32768：最大上下文长度。这个值直接影响 KV Cache 预留大小，设太大会浪费显存，设太小会截断用户输入。需要根据业务实际输入长度来调。--enable-prefix-caching：打开前缀缓存。对固定 system prompt 的业务，命中缓存后吞吐量提升肉眼可见。
启动后验证服务：
curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"qwen72b","messages":[{"role":"user","content":"你好，介绍一下自己"}]}'正常情况下会返回一个 OpenAI 格式的 JSON，包含choices、usage等字段。这一步通了，推理链路就跑通了。
4.4 压测与容量评估
服务起来，不代表能抗生产流量。我习惯用 Locust 或者简单的 Python 并发脚本做压测，先摸底：在 10、20、50 并发下分别测吞吐量（tokens/s）和首 token 延迟（TTFT）。
压测完你会拿到几个关键指标：
- 吞吐量：每秒生成的 token 总数。72B 模型两张 A100 张量并行，一般能到 1500~2500 token/s。
- 每请求生成速度：吞吐量除以并发。并发 50 时每请求速度就是 30~50 token/s，体感还行。
- TTFT：从发请求到收到第一个 token 的时间。vLLM 下通常控制在一秒以内，如果超过两秒，说明排队严重，需要扩容。
压测结果直接决定你对外的承诺——产品说“响应快”，你怎么量化？拿数据说话。
4.5 服务上线与自愈
最后一步是把容器跑成真正的生产服务。我现在的标准做法是：
- 用
docker compose定义服务，固定镜像版本，方便回滚。 - 加
--restart=always策略，容器崩了自动拉起。 - 宿主机上写一个 watchdog 脚本，每 30 秒 curl 一次
/health（vLLM 自带这个端点），连续失败 3 次就重启容器并告警。
告警我用的是钉钉或企业微信机器人 webhook，把服务状态、GPU 利用率、显存水位定期推送。别小看这个监控——大模型服务的隐性故障很多是“看起来活着但响应极慢”，没有监控根本发现不了。
5. 生产环境常见故障排查与避坑实录
这部分是真正的价值所在。我把部署这两个月里遇到的高频问题整理成一份速查表，每个都是我亲手踩过的。
5.1 高频故障速查表
| 症状 | 可能原因 | 排查命令 / 方法 | 解决方案 |
|---|---|---|---|
| 容器启动报 CUDA error | 驱动版本太低 | nvidia-smi看驱动版本 | 升级驱动到 525+ |
| 显存明明够却 OOM | gpu-memory-utilization 过高 | 看启动日志的显存分配图 | 降到 0.85~0.9 |
| 首 token 延迟高 | 请求排队严重 | 看吞吐和并发关系 | 加卡 / 开前缀缓存 |
| 文本乱码 / 带重复 | 温度参数过高 | curl 测不同 temperature | 降到 0.7 以下 |
| 模型加载特别慢 | 并发下载分片数据 | iostat看磁盘 IO | 换高性能云盘 / 本地盘 |
| 多卡利用率不均 | 张量并行但卡不一致 | nvidia-smi看每卡利用率 | 确保显存型号一致 |
| 输出内容截断 | max-model-len 太小 | 看 response 的 finish_reason | 调大 max-model-len |
| 服务频繁重启 | 健康检查误判 | 看 watchdog 日志 | 放宽超时阈值 |
5.2 一次真实的事故复盘：前缀缓存引起的吞吐暴跌
这里想分享一个特别容易忽略的坑。曾经有次我把一个 7B 模型升级到 vLLM 新版本，顺手开了--enable-prefix-caching，结果压测发现吞吐量不升反降，从 800 token/s 掉到 400 token/s。排查半天发现，这个模型的 prompt 里包含了大量时间戳和随机 ID，导致前缀几乎无法复用，缓存却一直在做哈希比对，白白消耗算力。
前缀缓存不是无脑开的。只有你的业务 prompt 有稳定的公共前缀（比如固定 system prompt、固定工具定义）时才有效。如果你的请求是“千人千面”的，开了反而拖慢速度。
5.3 模型热更新与版本管理
模型团队隔三差五就要调 prompt、换 checkpoint。生产环境最忌讳的就是“手动替换模型文件再重启容器”。我现在用一套版本管理方案：
- 每个模型版本对应一个独立目录，比如
/data/models/qwen2.5-72b-instruct-20260201。 - vLLM 通过
--model参数指定具体目录，切换版本就是修改启动参数后滚动重启。 - 对外接口的
served-model-name保持稳定，业务方无感知。
配合 Kubernetes 的滚动发布，能做到“老版本把存量请求处理完，新版本接管新流量”，基本实现无损切换。这块如果你还没上 K8s，至少也要用 compose 的rolling策略过渡。
5.4 微调模型的部署注意点
如果你跑的是微调后的模型，部署时有一个隐藏问题：base model 和微调模型的词汇表（tokenizer）必须一致。有次我部署一个 LoRA 微调过的模型，直接用原始 tokenizer 启动服务，结果生成的文本全是乱码。排查后才发现微调时采用了新扩展的 tokenizer，与 base model 不匹配。
处理方案有两种：要么在微调阶段就不要动 tokenizer，要么在部署前把 tokenizer 文件一并替换成微调后的版本。更稳妥的做法是部署后跑一个“自问自答”冒烟测试，对比几个典型 prompt 的输出是否符合预期再放流量。
6. 进阶：多服务编排、弹性伸缩与成本治理
生产环境跑稳之后，自然要想下一步：怎么支撑更大的流量，怎么把成本压得更低。
6.1 推理服务与业务服务的正确关系
不要把大模型推理服务和你的业务后端直接绑在同一个进程里。标准做法是：
- 业务服务调用推理 API（OpenAI 兼容接口）。
- 推理服务独立部署，独立扩缩容。
- 中间加一层 Redis 或消息队列做请求缓冲，削峰填谷。
特别是那个“Agent 应用”场景，一个 Agent 任务会发起十几轮模型调用，每一轮都有延迟，直接同步调用很容易把业务服务线程池打满。我现在的做法是：Agent 框架产生的模型请求全部投递到消息队列，推理服务按自身吞吐能力消费，结果通过回调通知 Agent。这对系统稳定性的提升是质的飞跃。
6.2 弹性伸缩策略
弹性伸缩不能只看 CPU，大模型服务的瓶颈在 GPU 利用率和显存水位。我给出一套实用的伸缩规则：
| 指标 | 扩容条件 | 缩容条件 |
|---|---|---|
| GPU 利用率 | 持续 5 分钟 > 85% | 持续 10 分钟 < 30% |
| 请求排队长度 | 队列积压 > 100 条 | 队列空转 > 5 分钟 |
| TTFT 分位数 | P95 > 2 秒 | P95 < 800ms |
注意缩容要加“冷却时间”——刚扩上来的实例至少稳定运行 15 分钟再判断是否缩，避免流量抖动导致频繁扩缩，既影响稳定性又产生额外的启动费用。
6.3 成本治理三板斧
最后分享一下我控制大模型部署成本的三个实操手段：
第一，模型量化要大胆。从 FP16 降到 INT8，显存减半，吞吐普遍能提升 30%~60%，而精度损失在大多数业务场景下几乎感知不到。如果你用的是 vLLM，直接在启动参数里加--quantization awq或--quantization fp8即可，不用改代码。
第二，低峰期规模收缩。夜间和周末流量掉到低谷时，把 GPU 实例缩到最小规模，甚至用 CPU 推理兜底（7B 量化后用 32 核 CPU 也能跑出每秒 10~15 token，足够应对凌晨的零星请求）。这笔账算下来一年能省六位数。
第三，共享推理服务。如果你有多个模型要服务，尽量统一到一个 vLLM 实例里，通过--served-model-name区分不同模型，共用一个 GPU 池，而不是每个模型单独开一台机器。单实例多模型的显存复用效率远高于多实例部署。
写在最后的一点个人体会
做了这么多部署项目，最大的感受是：大模型部署的难点从来不在“把模型跑起来”，而在“用最稳定的方式、最低的成本持续跑下去”。框架选型不是追新，而是找到与你业务负载匹配的工具；云服务对比不是比参数，而是算总账；生产级流程不是走形式，而是每一环节都要有监控、有备份、有回滚方案。
如果你正准备部署自己的第一个大模型服务，我的建议是：先拿一台 24GB 显存的卡跑通 7B 模型全流程，把 vLLM 的参数都调一遍，理解每个参数对显存和吞吐的影响，然后再去碰 70B 的多卡部署。地基打牢了，后面盖多高的楼都不怕。
这套流程我还在持续迭代，后续有新版本和踩坑经历会继续分享。有部署过程中遇到具体问题的朋友，欢迎留言交流，我尽量把每个坑的解法都聊透。
