大模型推理服务部署：两个主流框架如何选择与上线

一、部署概述

本文讨论的部署对象是大语言模型推理服务。具体来说，就是把已经训练或微调好的大模型权重，加载到推理运行环境中，对外提供统一的HTTP或RPC接口，使业务系统可以调用模型完成文本生成、代码补全、对话、摘要等任务。

部署完成后应达到以下效果：

1. 推理服务可以稳定接收请求并返回结果；
2. 服务具备基本的并发处理能力；
3. 显存和计算资源使用合理，不出现频繁超限；
4. 可以通过统一的接口协议访问；
5. 监控、日志和故障恢复机制可用；
6. 上线后具备可回滚、可扩容、可观测的运维能力。

适合阅读本文的读者包括：

• 需要将大模型推理服务从实验环境推到生产或预生产环境的开发者；
• 负责模型上线、服务编排和容量规划的运维人员；
• 需要评估推理框架选型的技术负责人和架构师；
• 企业内负责AI应用平台建设的工程团队。

部署前需要理解的基本背景：

• 大模型推理通常依赖GPU资源，部署形态多为常驻服务，而非一次性批处理任务；
• 推理服务对显存、显存带宽和并行计算能力敏感；
• 请求通常具有长文本、变长输出、并发波动明显等特点；
• 推理框架需要处理KV缓存、连续批处理、调度策略、量化加载等问题；
• 生产环境通常需要接入身份认证、限流、日志、监控和网关等通用能力。

本文会尽量避免陷入某一具体框架的营销话术，而是围绕部署过程本身，给出通用的决策依据和落地方法。对于“用A框架还是B框架”这类问题，正确思路不是追求标准答案，而是明确部署目标后，再根据目标选择更匹配的实现路径。

---

二、部署场景

不同业务场景对推理服务的部署要求差异很大。先明确场景，后续的资源规划和配置才会清晰。

1. 在线对话与交互式应用

典型场景包括智能客服、办公助手、问答机器人等。这类场景要求延迟低、首字响应快，用户对排队和超时敏感。部署时需要重点考虑：

• 小批次请求下的响应速度；
• 流式输出能力；
• 并发连接数；
• 会话状态管理；
• 超时与重试策略。

2. 批量内容生成与离线任务

典型场景包括批量生成摘要、标签、翻译、评测数据、合成语料等。这类场景对单请求延迟不敏感，但整体吞吐量很关键。部署时更关注：

• 大批量请求的吞吐效率；
• GPU利用率；
• 队列和任务调度；
• 结果存储与失败重跑。

3. 代码补全与低延迟辅助

典型场景是IDE插件或编辑器实时补全。用户输入暂停后，系统需要在极短时间内给出候选建议。部署要求接近实时推理，通常需要：

• 更小的模型尺寸；
• 更短的解码步数；
• 严格的超时控制；
• 边缘部署或多区域部署。

4. 企业内部统一模型网关

当企业内多个业务共用一套大模型服务时，部署任务是搭建统一的模型推理网关。此时框架选择不只是技术性能问题，还涉及：

• 多模型管理；
• 多租户资源隔离；
• 配额与限流；
• 统一观测和审计；
• 灰度发布和版本切换。

---

三、架构与组件

一个可用的生产级大模型推理服务，不只是一个推理进程，而是一组相互配合的组件。

1. 推理引擎

核心职责是加载模型权重、执行前向计算、管理KV缓存并生成输出。不同的推理引擎在调度算法、显存管理、批处理策略和并行策略上存在差异。

2. 服务网关

网关负责接收业务请求、完成鉴权、路由、超时控制、请求大小限制和响应格式转换。很多团队会在推理服务前面放置一层通用API网关，统一处理非推理逻辑。

3. 消息队列

当请求洪峰超过推理服务承载能力时，可以引入队列削峰。队列常用于离线批处理场景，在线低延迟场景则需要谨慎使用，因为排队本身会增加延迟。

4. 配置中心

模型路径、运行参数、批处理上限、日志级别等配置不应硬编码在进程里。通过配置中心下发，可以避免改配置就要重启服务。

5. 日志与监控

推理服务应当输出结构化日志，包含请求ID、模型名称、首字延迟、总延迟、生成token数、显存使用情况等。监控系统采集这些指标，并配置告警。

6. 对象存储与模型仓库

模型权重文件体积很大，通常放在对象存储中，部署时再拉取到本地磁盘或共享存储。模型仓库需要管理版本、摘要信息和校验值。

7. GPU计算资源

GPU是推理服务最重要的计算资源。部署时需要根据模型参数量、精度、批处理大小和并发目标，评估所需显存和算力。

---

四、前置准备

1. 明确模型规格

部署前先确认以下信息：

• 参数规模；
• 权重精度，例如FP16、BF16、8比特量化等；
• 上下文长度上限；
• 是否使用多卡并行；
• 模型来源和许可证限制。

2. 准备计算资源

资源规格要结合请求量和延迟目标估算。建议预留一定冗余，避免单点过载。

资源类型	关键考虑点
GPU显存	模型权重、KV缓存、激活值、框架运行开销
GPU算力	吞吐目标、批处理能力、长序列场景
CPU与内存	请求预处理、数据搬运、辅助线程
网络带宽	请求体大小、流式输出、跨节点通信
本地磁盘	模型文件缓存、临时日志、交换空间

3. 准备模型文件

将模型权重放到可被推理节点访问的位置。生产环境建议使用对象存储或共享文件系统，并在节点启动时拉取或挂载。不要依赖开发机上随意拷贝的权重文件。

4. 准备运行环境

包括操作系统、GPU驱动、容器运行时和基础库。建议将推理服务容器化，减少环境差异。镜像中应固定依赖版本，避免升级导致行为变化。

5. 准备网络与安全策略

• 确定推理服务的监听端口；
• 确定是否只允许内网访问；
• 如果需要公网访问，是否通过API网关暴露；
• 是否配置HTTPS证书；
• 是否需要请求来源白名单；
• 敏感信息如API密钥如何安全注入。

---

五、部署流程

以下流程为通用部署思路，适用于两种主流推理框架中的任意一种。具体框架的命令和参数应以官方文档为准，但部署整体顺序可以复用。

第1步：创建推理节点或容器工作负载

在云服务器或容器平台中创建运行实例。如果使用容器平台，建议声明以下资源：

• 至少一张GPU卡；
• 足够的内存；
• 持久化磁盘用于保存模型缓存；
• 网络策略允许访问内部模型仓库和外部配置服务。

第2步：准备模型目录

将模型权重下载到节点本地或挂载到容器内。建议验证文件完整性，例如通过哈希校验。不要在每次启动时重新下载所有权重，除非确认本地缓存失效。

第3步：编写配置文件

将模型路径、张量并行度、批处理上限、上下文长度、端口号、日志级别等参数写入配置文件。配置文件应与代码分离，放在配置中心或环境变量中。

通用示意配置如下：

server:
  host: 0.0.0.0
  port: 8000
model:
  path: /data/models/llm-main
  tensor_parallel_size: 1
  max_context_length: 8192
runtime:
  max_batch_size: 32
  log_level: info

注意：以上为通用配置示意，不代表任何具体框架的真实参数。

第4步：启动推理服务

启动方式通常有两种：

• 直接运行推理进程；
• 以容器方式启动，并设置健康检查。

建议使用进程管理器或容器编排平台托管推理服务，以便崩溃后自动拉起。首次启动时，推理引擎会加载模型权重，可能需要数分钟，需预留足够的启动时间。

第5步：配置服务发现与路由

如果推理节点较多，需要引入服务发现机制。网关或负载均衡器根据健康状态将流量分发到可用实例。不要将业务方直接绑定到某个节点的IP地址。

第6步：开放受控访问

生产环境不建议将推理端口直接暴露公网。应在网关层完成鉴权、限流和访问控制。如果仅在内部使用，可限制为内网可达。

---

六、关键配置说明

不同推理框架的配置项差异较大，但可以从几个通用维度理解配置含义。

1. 并行策略

单卡放不下的模型需要拆到多卡。常见做法包括张量并行和流水线并行。并行策略会影响显存分布、通信开销和吞吐。增加并行度不一定总是带来收益，需结合模型规模和GPU拓扑测试。

2. 批处理策略

批处理大小直接影响延迟和吞吐。设置过大可能提高吞吐，但会拉高尾部延迟和显存占用；设置过小则资源利用率不足。需根据请求形态做压力测试。

3. 上下文长度

上下文越长，KV缓存占用越大。部署时应设置一个合理上限，既满足业务需求，又避免极端请求耗尽显存。对超长请求可以拒绝或截断。

4. 量化加载

为了降低显存占用，很多部署场景会使用量化后的模型。量化方式很多，部署时要确认推理框架是否支持当前权重的量化格式。量化可能带来精度下降，需要在业务侧评估。

5. 超时与队列长度

在线场景要设置合理的排队长度和超时时间。队列过长会增加用户等待；超时过短则容易误杀慢请求。建议从业务可接受的最大等待时间反推。

---

七、部署示例说明

下面以“企业内网部署一个中等规模对话模型”为示例，说明从准备到上线的整体逻辑。示例中的命令为通用伪命令，不能直接复制使用。

部署拓扑

业务应用
   |
   v
内网API网关（鉴权、限流、路由）
   |
   v
推理服务实例A（GPU节点1）
   |
   v
共享模型存储

示例流程

1. 创建两台带有GPU的云服务器，配置内网互通；
2. 将模型权重上传至对象存储或共享文件系统；
3. 使用容器镜像启动推理服务，挂载模型存储；
4. 配置模型路径和上下文长度等参数；
5. 设置健康检查接口，确认服务就绪；
6. 在API网关上配置到推理实例的路由；
7. 使用压测工具模拟真实请求；
8. 观察GPU利用率和延迟指标是否在预期范围内；
9. 将生产流量按比例切流；
10. 持续观察一段时间后再全量切换。

---

八、上线验证

部署完成后，不能以“进程启动了”作为成功标准。需要做更充分的验证。

1. 基础可用性验证

• 服务健康检查接口是否返回正常；
• 发送一条简单请求，确认能返回合理结果；
• 确认输出长度和格式符合预期；
• 确认流式输出是否稳定。

2. 性能验证

• 在低并发下测量平均首字延迟和整体延迟；
• 逐渐加大并发，观察延迟拐点和GPU利用率；
• 测试长文本请求，观察显存是否接近上限；
• 验证连续运行一段时间后是否出现显存缓慢增长。

3. 稳定性验证

• 持续运行小时级压测，观察是否有内存泄漏或连接泄漏；
• 模拟单个节点重启，确认能被自动拉起；
• 模拟依赖存储短暂不可用，确认异常处理合理；
• 模拟客户端断连，确认推理服务不会因此僵死。

4. 安全验证

• 确认未授权请求被拒绝；
• 确认密钥不会出现在日志中；
• 确认管理端口未暴露到公网；
• 确认访问日志可审计。

---

九、常见问题与排查

问题1：显存不足，服务启动失败

原因分析：模型权重、KV缓存预留和运行开销之和超过单卡显存；或并行策略未生效。

排查思路：

• 降低上下文长度上限；
• 调整并行度，使用多卡部署；
• 检查模型是否以更低精度加载；
• 关闭不必要的调试日志或额外功能；
• 检查是否有其他进程占用显存。

问题2：服务启动成功，但请求一直排队

原因分析：批处理设置过大，或请求队列未设置合理上限；部分慢请求阻塞了后续请求。

排查思路：

• 检查当前批处理规模和队列长度；
• 降低单批最大处理数量；
• 为慢请求设置单独超时；
• 观察是否存在异常请求长时间未结束。

问题3：延迟偶发飙升

原因分析：GC波动、显存碎片、调度抢断、网络抖动或节点负载异常。

排查思路：

• 查看尾延迟与CPU、GPU利用率的相关性；
• 检查是否在推理过程中反复触发内存回收；
• 确认是否混部了其他高负载服务；
• 观察不同时间段是否存在资源争抢；
• 结合链路追踪定位具体请求阶段。

问题4：长时间运行后吞吐下降

原因分析：连接未释放、日志文件膨胀、进程状态异常或显存碎片化。

排查思路：

• 检查连接数和句柄数是否持续增长；
• 配置日志轮转；
• 观察服务运行时间与性能衰减的关系；
• 设置定期重启或滚动替换策略。

问题5：升级新版本后性能不一致

原因分析：默认参数变化、权重格式不兼容、调度策略调整或依赖库升级。

排查思路：

• 保留旧版本配置和镜像，便于快速回滚；
• 对比新旧版本默认参数差异；
• 使用同一批固定请求做基准测试；
• 小流量灰度后再扩大范围。

---

十、运维与优化

1. 稳定性保障

• 使用进程管理器或容器编排平台托管推理服务；
• 配置健康检查和自动重启；
• 对服务设置资源上限，防止拖垮宿主机；
• 重要配置变更走灰度或滚动发布；
• 保留上一版本镜像和配置，便于回滚；
• 多实例部署时避免所有实例同时重启。

2. 性能优化

• 根据请求分布动态调整批处理参数；
• 对高频固定前缀使用缓存，但需评估一致性风险；
• 长文本场景考虑分段处理或提前截断；
• 针对低延迟场景关闭不必要的日志和指标采集；
• 评估量化模型的精度和速度收益；
• 将预处理和后处理逻辑与推理计算解耦。

3. 成本控制

• 根据流量曲线评估是否需要常驻GPU实例；
• 对离线批处理场景使用弹性扩缩容；
• 定期清理无用模型版本和过期镜像；
• 对低频测试环境使用降配或共享资源；
• 统计单token推理成本，持续跟踪。

4. 可观测性

• 采集请求量、错误率、首字延迟、总延迟、生成token数、GPU利用率和显存使用率；
• 日志中携带请求ID，方便串接上下游；
• 告警维度兼顾资源异常和服务体验异常，不要只看“进程是否存活”。

5. 安全与合规

• 定期轮换访问密钥；
• 对请求内容做最小化记录，避免记录敏感信息；
• 限制管理端口和调试接口的访问范围；
• 对模型下载和推理节点之间的传输做加密；
• 记录操作和访问日志，便于审计。

---

十一、两个框架的部署差异如何影响选择

回到开头的问题：两个主流推理框架到底该怎么选。如果从部署角度看，不应只比较“谁快”，而应比较它们的部署形态、配置复杂度、生态适配度和运维成本。

1. 部署形态

两个框架都可以以HTTP服务方式提供推理接口，但参数组织、默认值和扩展方式不同。选型时应关注：

• 哪一种框架的默认配置更接近你的业务形态；
• 哪一种框架的配置项更易理解、更易通过配置文件管理；
• 哪一种框架更容易嵌入现有发布流程。

2. 资源行为

不同框架对显存的管理策略不同。同样的模型和请求，可能出现：

• 某一个框架显存占用更低；
• 某一个框架在长文本下更稳定；
• 某一个框架在多GPU并行下配置更简单；
• 某一个框架在高并发下排队行为更可控。

这些都需要通过实际负载测试得出结论，不宜只看通用评测数据。

3. 运维成本

运维成本包括升级频率、参数兼容性、文档完整度、日志可读性和故障排查难度。如果团队人力有限，应优先选择能更快接入现有监控体系的框架。

4. 灰度与回滚能力

两个框架本质上都是常驻服务，因此都可以通过流量切分实现灰度。但注意：

• 请求协议是否兼容；
• 流式响应格式是否有差异；
• 会话状态由谁维护；
• 框架升级是否需要业务侧配合修改。

如果两个框架的接口协议不完全一致，灰度时需要保证业务方能够适配。

---

总结

大模型推理框架的选择不是一个抽象的性能排名问题，而是一个部署工程问题。真正决定上线效果的是：部署目标是否明确、资源规划是否合理、配置是否可管理、验证是否充分、异常是否可恢复、长期运维是否可持续。

对于准备部署大模型推理服务的团队，建议按以下顺序推进：

1. 先明确业务场景是低延迟在线、高吞吐离线、实时交互还是统一网关；
2. 再评估模型规模、请求负载和可用GPU资源；
3. 选择一个框架搭建最小部署单元；
4. 完成配置、健康检查、日志接入和指标采集；
5. 通过真实压测判断延迟、吞吐和稳定性是否达标；
6. 如果另一个框架在关键指标上明显占优，再做对照测试；
7. 最终以部署和运维完整性作为选型的重要依据，而不是只看单一性能数字。

框架可以替换，但部署逻辑和方法是可复用的。把环境、配置、验证和运维都做到位，剩下的选型不过是基于事实做一次更稳妥的决定。