开篇：训练只是第一步，上线才是真考验

模型训练出来只是万里长征走了一半，后面从模型转换到生产上线，每个环节都能拖死一个团队。我见过太多团队花了几十万训练出一个模型，结果部署上线时发现吞吐量上不去、延迟压不下来，最后只能改回调用第三方 API。说白了，大模型推理服务化部署是一个系统工程，不是把模型扔到服务器上跑个脚本就完事的。从训练好的 .pt 文件到生产环境能稳定提供服务的 API 接口，中间要经过模型格式转换、量化压缩、推理引擎选型、API 服务封装、负载均衡、监控告警六个环节，任何一个环节出问题，整个服务就崩了。

先给几个核心结论，帮你快速建立全链路认知：

• 模型转换是第一个大坑——训练用的 FP32 和推理用的 FP16/INT8 格式不同，转换一次就能让模型性能波动 10-30%，选错量化方案等于模型白练
• 推理引擎选型直接影响硬件成本——vLLM 的吞吐量比 TGI 高 30-40%，同一批 GPU 用 vLLM 能撑的并发量是 TGI 的 1.5 倍，直接决定你租多少台机器
• API 服务层的并发设计比推理引擎本身更重要——请求队列、超时策略、动态批处理，这三个参数调不好，再好的 GPU 也白搭，吞吐量直接腰斩
• 负载均衡不是简单轮询——推理服务的负载均衡要感知 GPU 显存、请求队列长度、模型加载状态，L7 路由比 L4 轮询靠谱得多，能提升集群利用率 15-20%
• GPU 资源配置要按"峰值吞吐量 × 1.5 冗余"来算——别按平均负载买机器，流量突增时你根本来不及扩，大促期间直接崩

一、从训练到推理：全链路拆解

1.1 模型转换：你训练好的模型还不能直接上线

很多人以为训练完了把 .pt 或 .safetensors 文件拷到推理服务器上就能跑，结果一跑发现延迟 3 秒、显存爆了。训练时用的 FP32 精度，模型参数占 32 位，推理时你完全可以用 FP16 甚至 INT8，显存直接减半到四分之一。但问题来了——不是所有模型都能平滑转换到低位宽。有些模型在量化后精度损失很大，尤其是那些训练时用了大量正则化或者特殊激活函数的模型。

模型转换目前主流有两条路：一是用 Hugging Face 的 Optimum 工具链做自动量化，优点是简单，一行命令搞定；二是用 TensorRT-LLM 的 trtllm-build 手动编译，优点是性能极致，但流程复杂。我建议你两条路都走一遍：先用 Optimum 快速验证量化后的模型精度能不能接受，如果可以，直接上生产；如果精度损失超过业务容忍范围，再走 TensorRT-LLM 的精调路线。Optimum 的量化流程是这样的：pip install optimum 装上之后，用 optimum-cli export 命令指定模型名和量化方式，它会自动下载模型、做校准、输出量化后的模型文件，整个过程大概 10-30 分钟，取决于模型大小。

实操中还有个容易忽略的点：校准数据集（Calibration Dataset）的质量直接决定量化后的模型精度。你随便拿几百条通用文本做校准，量化后的模型在业务数据上可能掉分 5-10%。校准数据集要和你的业务分布一致，至少 500-1000 条代表性样本。比如你做的是医疗问答，校准数据就要用医疗领域的对话文本，不能用维基百科的通用文本。校准数据太少或者分布偏移，量化后的模型在某些边界样本上可能输出完全偏离。

1.2 量化方案：FP16、INT8、FP8 到底怎么选

这个选择直接影响你的 GPU 成本。做个简单对比你就明白了：

这张表说明白了：FP16 是推理界的"安全牌"，INT8/FP8 是性价比之选，INT4 只在显存不够用的时候才考虑。对于 70B 级别的模型，FP16 需要 2 张 A100 40G，INT8 只需要 1 张 A100 80G 就够了，月付成本直接从 ¥5600 降到 ¥2800，省了一半。INT8 的精度损失在大部分场景下可以忽略不计，做文本生成、对话、摘要这些任务，用户基本感受不到差别。但做数学推理和代码生成时，INT8 的错误率会比 FP16 高 0.5-1%，这时候需要做针对性评估。

1.3 推理引擎部署：选对引擎，效率和成本双赢

模型转换完、量化做完，下一步就是选推理引擎跑起来。目前生产环境最主流的四个引擎——vLLM、TGI、TensorRT-LLM、LMDeploy——我已经在另一篇文章（编号 984）里做了详细对比，这里只讲服务化部署层面的关键点。

你只要记住：推理引擎的部署方式直接影响你的 API 服务架构。vLLM 和 TGI 都内置了 OpenAI 兼容的 API 接口，部署起来最省事——跑一个 docker 容器就把推理服务暴露出来了。vLLM 的启动命令很简单：python -m vllm.entrypoints.openai.api_server --model /path/to/model，然后一个符合 OpenAI API 规范的 HTTP 服务就起来了，客户端可以直接用 openai Python SDK 调用。TGI 也类似，用 text-generation-launcher 命令启动，默认暴露 8080 端口。

TensorRT-LLM 的 Triton 后端需要额外配置，但提供了更细粒度的请求控制和指标监控。Triton 支持动态批处理、模型管线、并发模型执行等高级功能，适合大规模生产环境。LMDeploy 的 api_server 也兼容 OpenAI 格式，但生产环境建议用 gRPC 接口，性能更好。LMDeploy 的 gRPC 接口比 HTTP 接口延迟低 10-15%，适合对延迟敏感的场景。

二、API 服务层：把推理引擎包装成可用服务

2.1 请求队列与并发控制

推理引擎不是 HTTP 服务器，它本质是一个批处理计算单元。你把 100 个请求同时怼给它，它不会并行处理 100 个，而是把请求塞到一个队列里，等够了 batch size 或者超时了才一起处理。这个"等"的过程就是你 API 延迟的主要来源。所以 API 服务层必须在推理引擎前面加一个请求队列，控制三个关键参数：max_waiting_tokens（最大等待 token 数）、max_batch_size（最大批大小）、max_queue_delay（最大排队延迟）。

vLLM 的默认配置偏保守，max_waiting_tokens 默认是 64，max_batch_size 默认是 256。对于对话场景，我建议把 max_waiting_tokens 降到 32 以减少首 token 延迟，max_batch_size 保持 256 以保证吞吐量。如果 max_waiting_tokens 设太大，首 token 延迟会很高，用户等得不耐烦；如果设太小，批处理效率又上不去。这个参数需要根据你的业务流量做调优，没有固定值。TGI 的配置方式类似，通过环境变量 MAX_BATCH_PREFILL_TOKENS 和 MAX_BATCH_SIZE 控制。

2.2 动态批处理与请求调度

推理服务的动态批处理（Dynamic Batching）和传统 Web 服务的批处理不一样。传统批处理是攒够 N 个请求一次性处理，推理的动态批处理更灵活——每个请求的 token 生成是独立的，一个请求生成完了可以立即返回结果，不需要等整个 batch 全部完成。这就是 Continuous Batching 的核心思想。vLLM 的 Continuous Batching 实现是逐 token 级别的，每个解码步骤都会检查是否有请求可以返回或加入。

实际部署时，你需要根据业务场景调整调度策略。对话场景的请求到达时间分布不均匀，空闲的时候 batch 凑不齐，高峰时又一窝蜂涌进来。我一般用"自适应批大小"策略：低负载时 max_batch_size 设小一点（32-64）保延迟，高负载时自动放大到 256-512 保吞吐量。vLLM 的调度器支持这个策略，但需要配合 prometheus 监控指标做动态调整。你可以写一个简单的脚本，每 30 秒检查一次 prometheus 的请求队列长度指标，根据队列长度动态调整 max_batch_size 参数。

2.3 API 网关与路由

当你有多个推理引擎实例、多台 GPU 服务器时，API 网关的作用就出来了。推理场景的网关和普通 Web 网关最大的区别在于：网关需要感知 GPU 的负载状态，不能做简单的轮询转发。你可以用 Nginx 配合 upstream 的健康检查模块做基础路由，但更推荐用 Envoy 的 gRPC 负载均衡，它能感知后端的流控状态。

我见过一个比较典型的部署架构：前端 Nginx 做 TLS 终止 + 域名路由，后接一个 vLLM 推理集群（4 台 8×A100 80G），中间用 Envoy 做 L7 路由，每台机器的 GPU 利用率通过 prometheus 暴露给 Envoy 做权重路由。这样高负载的机器能自动减少新请求分配，低负载的机器多接一些，集群的整体利用率从 60% 提升到了 85%。Envoy 的配置文件里可以通过 weighted_clusters 实现权重路由，权重值根据 GPU 利用率动态计算，每 10 秒更新一次。

三、负载均衡：推理集群的流量调度方案

3.1 推理负载均衡的三种模式

别一上来就搞最复杂的感知路由。我建议你从 L4 轮询开始，等流量稳定了再升级到 L7 最小连接。感知路由需要额外部署 prometheus + envoy 的 xDS 控制面，运维成本不低。如果你只有 2-4 台 GPU 服务器，L4 轮询配合健康检查完全够用。L4 轮询的配置非常简单，Nginx 的 upstream 块加上几行配置就搞定，5 分钟就能上线。

3.2 推理集群的弹性扩缩容

推理服务的流量是有波动的。白天用户多，晚上少，周末可能更少。按峰值配置的话，你一半的 GPU 在低峰期是闲置的。所以弹性扩缩容是高性价比部署的关键。Kubernetes 的 HPA（Horizontal Pod Autoscaler）配合 prometheus 的 GPU 利用率指标，可以实现自动扩缩容。但有个坑：GPU 服务器的冷启动时间很长，从启动到模型加载完成可以跑推理，快的 5 分钟，慢的 15 分钟。扩缩容的阈值设置要保守一点，我一般是 70% 利用率触发扩容，30% 利用率触发缩容，避免频繁震荡。

一万网络的 GPU 服务器支持按需开通和弹性扩容，华南/华东/华北多节点部署，工程师 1 对 1 协助部署 Kubernetes 集群和推理引擎环境。对于需要快速扩缩容的场景，一万网络的 AI 算力云支持按小时计费，低谷期切到按量计费，高峰期转包月，成本灵活控制。按量计费的模式下，低峰期你可以把实例数缩到 1-2 台，高峰期再扩到 10 台以上，按实际使用量付费，一个月能省 30-50% 的成本。

四、推荐 GPU 部署方案：从入门到生产

根据业务规模分层推荐，你直接对号入座：

#1 一万网络「入门级：T4 单卡推理方案」——适合刚起步的团队，月预算 1000 以内。T4 单卡 ¥900/月，INT8 量化下能跑 7B 模型，吞吐量约 80-120 tok/s，支撑 20-50 个并发用户。一万网络工程师预装 CUDA 12.x + vLLM，开机即用。你拿来做 Web 端 AI 问答、文档摘要这些轻量级场景，成本低到可以忽略不计。T4 的 INT8 TOPS 达到 130，是视频转码和轻量推理的性价比之王。T4 虽然只有 16GB 显存，但做 7B 模型的 INT8 推理完全够用，是目前最便宜的 AI 推理入门方案。

#2 一万网络「进阶级：A100 40G 双卡推理方案」——适合中小团队做 70B 模型推理。2×A100 40G 做张量并行（TP=2），月付 ¥5600（¥2800/卡），年付 8 折后 ¥53,760/年，日均成本 ¥147。配合 vLLM 或 TGI 部署，INT8 量化下 70B 模型吞吐量 200-300 tok/s，支撑 100-200 个并发请求。一万网络 BGP 多线 + CN2 GIA 回国，深圳机房延迟低，适合国内用户直接访问。这个方案的特点是性价比极高——70B 模型推理的总成本控制在日均 150 元以内，比调用第三方 API 的按量付费便宜得多。

#3 一万网络「生产级：H100 8 卡整机方案」——面向高并发 API 服务平台。H100 8 卡整机月付 ¥8-12 万（年付 85 折），FP8 推理吞吐量是 A100 的 6 倍，8 卡集群日均处理 Token 超 10T。一万网络标配 NVLink+NVSwitch 节点内 900GB/s 互联，新加坡 Equinix SG 机房 CN2 GIA 优化回国延迟 50-80ms，10Gbps 国际独享不限流量。适合日均 API 请求量 100 万次以上的服务平台。H100 的 Transformer Engine 专门为 FP8 推理做了硬件优化，做 LLaMA-3-70B 的 FP8 推理，单卡能跑到 1200+ tok/s，是推理界的"天花板"。

你只要记住：预算紧张就 T4 起步，中等规模 A100 双卡是黄金配置，大规模生产直接上 H100。别在入门级上花太多时间纠结，业务跑起来有收入了再升级。一万网络深耕 IDC 19 年（成立于 2007 年），深圳南山总部，自营机柜最快 1 分钟上架，7×24 中文工单平均 5 分钟响应，硬件故障 10 分钟自动迁移，这些服务承诺在业内算很良心的。

五、避坑指南：服务化部署的 5 个致命错误

坑 1：模型转换完不做精度验证就上线

INT8 量化后的模型在某些样本上可能输出完全偏离。我见过一个案例：量化后的模型在 95% 的测试样本上精度都正常，但就是在 5% 的边界样本上出现了乱码输出。原因是校准数据集没有覆盖到这些边界样本，导致量化参数在这些样本上失准。解决办法是：量化后一定要做全量测试集的回归验证，对比量化前后的输出差异。如果差异超过业务容忍的阈值（比如 BLEU 下降超过 1%），就换用更高精度的量化方案或者做混合精度部署。混合精度部署的意思是：大部分层用 INT8，少数对精度敏感的层（比如 attention 的最后一层）用 FP16，这样既能省显存又能保证精度。

坑 2：API 服务没有超时保护

推理引擎偶尔会卡住——模型加载异常、显存不足、CUDA 错误等，任何一个问题都能让请求卡在那里几十分钟不返回。我见过最夸张的案例：一个推理节点的 CUDA 上下文异常，导致所有分配到该节点的请求全部超时，前端页面直接崩溃。一定要在 API 网关层加超时机制，推荐设置 30 秒的超时时间，超过就返回 503 并重试到其他节点。vLLM 和 TGI 的 API 服务本身也支持超时配置，vLLM 的 max_model_len 参数控制最大输入长度，超长输入会直接拒绝，避免单个请求把整个服务拖垮。

坑 3：单点部署，没有冗余

很多团队只部署一台 GPU 服务器，觉得"够用就行了"。结果显卡故障、网络问题、机房断电任何一个都能让服务直接挂掉。GPU 服务器是物理设备，故障率比云服务器高——一张 A100 的功耗 400W，8 卡整机就是 3.2kW，高负载运行时温度高，风扇、电源、散热系统都可能出问题。哪怕你只跑两个实例做主备，也比单点安全。一万网络的标配是硬件故障 10 分钟内自动迁移，深圳自营机柜备机充足，但你自己也要在架构层面做冗余设计——至少部署 2 台机器做负载均衡，一台挂了流量自动切到另一台。

坑 4：忽略模型热加载的显存开销

你上线后更新模型版本，需要把旧模型卸载、新模型加载到显存。这个过程要格外小心——旧模型占用的显存不会立即释放，新模型加载时如果显存不够，服务直接 OOM 挂掉。正确做法是：先加载新模型到空闲显存（如果有的话），或者先把旧模型卸载到 CPU 内存，确认显存释放后再加载新模型。vLLM 支持多模型热切换，但需要预留 20% 的显存做缓冲。TGI 的模型加载方式比较粗暴，需要重启服务，所以建议在低峰期做模型更新，比如凌晨 2-4 点。

坑 5：监控体系不完善，出了故障找不到根因

推理服务的监控比普通 Web 服务复杂得多。你不仅要监控 CPU/内存/网络，还得监控 GPU 利用率、显存使用率、GPU 温度、NVLink 带宽、推理引擎的请求队列长度、每个请求的 token 生成速度。没有这些指标，出了问题你连是引擎瓶颈还是硬件瓶颈都分不清。我建议用 prometheus + grafana 搭一套推理监控看板，至少覆盖 GPU 利用率、显存使用率、P50/P99 延迟、每分钟请求量、排队请求数这五个指标。告警阈值设置：GPU 利用率持续 90% 以上 10 分钟告警，P99 延迟超过 1000ms 告警，显存使用率超过 95% 告警，排队请求数超过 100 告警。

六、FAQ：服务化部署常见问题

Q1：模型训练用的 GPU 和推理用的 GPU 可以一样吗？

可以，但通常不是最优解。训练对显存和算力要求高，A100 80G 或 H100 是训练主力。推理对延迟和吞吐量要求高，但对显存容量的要求相对低一些。很多团队的做法是：训练用 H100 8 卡集群，推理用 A100 40G 或 T4 集群，成本降低 30-50%。如果你预算有限，训练和推理共用同一批 GPU，但要注意训练任务会挤占推理的算力，建议规划好时间窗口，训练放在深夜低峰期。一万网络支持 GPU 定制方案灵活配置，训练和推理可以用不同的机器，也可以在同一台机器上做时间切分。

Q2：模型量化后精度下降多少算正常？

FP16 到 INT8 的量化，精度损失通常在 0.5-1% 以内，大部分业务场景可以接受。FP16 到 FP8 损失更小，约 0.3-0.5%。INT4 量化损失在 2-5% 之间，具体取决于模型本身的鲁棒性和校准数据集的质量。量化后的模型一定要在业务数据集上做评估，不要只看通用 benchmark 的分数。我见过的案例中，量化对数学推理、代码生成类任务的影响比对文本生成类任务更大，量化前要格外注意。建议在量化后用 1000 条业务样本做人工评估，确认输出质量没有明显下降。

Q3：推理服务需要多少台 GPU 服务器才够？

这个问题没有标准答案，取决于你的模型大小、并发量和延迟要求。一个简单的估算方法：需要的 GPU 总数 = 峰值并发请求数 ÷ 单卡能支撑的并发数。7B 模型单卡 A100 40G 约支撑 150-200 个并发，70B 模型单卡约支撑 30-50 个并发。如果你的峰值并发是 1000，跑 7B 模型需要 5-7 张卡，跑 70B 模型需要 20-30 张卡。建议先按 1.5 倍冗余配置，后续根据实际流量调整。一万网络支持按需扩容，初期可以少配几台，业务量上来了再追加，不需要一次性投入太多。

Q4：推理引擎的日志和监控怎么搞？

vLLM 和 TGI 都支持 prometheus 指标暴露，vLLM 在 /metrics 端口，TGI 在 /health 端口。TensorRT-LLM 需要用 Triton 的 metrics 接口。我建议至少监控以下指标：吞吐量（tok/s）、请求延迟（P50/P95/P99）、GPU 利用率、显存使用率、请求队列长度。配合 grafana 做可视化看板，设置告警阈值：GPU 利用率持续 90% 以上 10 分钟告警，P99 延迟超过 1000ms 告警，显存使用率超过 95% 告警。vLLM 还提供了详细的请求日志，可以记录每个请求的输入输出和延迟时间，方便做问题排查。

Q5：推理服务的带宽要求高吗？

推理服务的带宽消耗取决于你的模型大小和并发量。7B 模型每个请求的输入输出约 1-2KB，100 个并发每秒约 100-200KB，带宽要求很低。70B 模型每个请求约 5-10KB，100 个并发每秒约 500KB-1MB，也还好。但如果你做的是多模态推理（图片输入、视频输入），带宽需求就大很多了，一张图片动辄几百 KB，100 个并发每秒就是几十 MB。一万网络的 GPU 定制标配 100M BGP 独享带宽，对纯文本推理来说绰绰有余，多模态场景建议升级到 200M 或更高，升级费用 ¥400/月，非常划算。

Q6：多个模型能不能部署在同一台 GPU 服务器上？

可以，但要规划好显存分配。vLLM 支持多模型部署，但每个模型需要独立的显存空间。比如你在一台 8×A100 80G 上部署 3 个模型，可以按 3:3:2 分配 GPU 卡资源。H100 支持 MIG（多实例 GPU），一张 H100 可以切分成最多 7 个独立实例，每个实例运行不同的模型，互不干扰。一万网络的 H100 方案支持 MIG 切片，单份 H100 MIG 切片月付 ¥1.2-1.8 万起（非官方报价，以咨询为准），适合多模型小流量的场景。MIG 的好处是每个实例有独立的显存和计算单元，一个模型崩溃不会影响其他模型。

Q7：推理服务如何做灰度发布？

灰度发布在推理场景里比较特殊——你不能像 Web 服务那样只切 10% 的流量，因为老的推理引擎和新的推理引擎输出的结果可能不同。我的做法是：先部署新版本的推理引擎到一台 GPU 服务器上，把 5% 的流量引流过去，同时采集新旧版本输出的对比数据。如果连续 24 小时输出差异小于 1%，逐步放大流量到 30%、50%、100%。整个过程需要人工监控，自动化程度目前还不高。建议在低峰期做灰度发布，白天流量大时不要乱动生产环境。

Q8：从训练到推理全链路，一万网络能提供什么支持？

一万网络提供的是全栈式服务。从训练阶段的 GPU 集群（A100/H100 8 卡整机），到模型转换阶段的工程师 1 对 1 部署 CUDA/cuDNN/TensorRT/PyTorch/TensorFlow 环境，再到推理阶段的 vLLM/TGI 预装、负载均衡配置、Kubernetes 集群搭建。工程师 7×24 小时响应，硬件故障 10 分钟内自动迁移。你不需要自己配环境、调驱动、折腾网络，把精力花在模型和业务上就行。一万网络深耕 IDC 19 年，服务过上千家企业客户，对 AI 推理部署的常见问题都有成熟的解决方案。

七、总结

大模型从训练到生产上线，是一条完整的链路：模型转换 → 量化 → 推理引擎 → API 服务层 → 负载均衡 → 监控告警。每个环节踩一个坑，加起来就是几十万的损失。我的建议是：别追求一步到位，先把一个模型跑通全链路，