大模型训练与推理部署如何越过显存墙

一、部署概述

本文讨论的部署对象是大语言模型及类似大规模神经网络模型的训练与推理任务。与普通 Web 应用或微服务不同，这类任务的核心特征十分突出：模型参数规模巨大、单次前向与反向计算需要大量显存、多卡协作成为常态、训练与推理对资源形态的要求差异明显。

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

1. 模型能够稳定加载到计算资源中，不发生显存溢出或资源碎片化问题；
2. 训练任务可以按预期执行多卡并行计算，减少通信瓶颈；
3. 推理服务可以对外提供稳定的请求响应；
4. 资源使用、显存占用、请求延迟等指标可被监控与追踪；
5. 出现故障时能够快速定位并执行回滚或降级。

本文适合负责模型训练平台建设、模型服务上线的开发人员、算法工程师、运维人员和架构师阅读。部署开始前，读者应至少理解模型参数、优化器状态、激活值、梯度、数据加载等基础概念，以及 CPU 内存与 GPU 显存之间的基本关系。

---

二、部署场景

大模型相关部署通常分为三类场景：离线训练、在线推理、混合负载。

2.1 离线训练场景

离线训练部署的核心目标不是实时响应，而是在给定时间内完成一个训练任务。其部署重点在于：

• 多卡或多节点并行策略是否合理；
• 显存是否能完整容纳模型参数、梯度、优化器状态和激活值；
• 数据加载是否成为瓶颈；
• 断点续训与任务恢复能力是否可靠。

2.2 在线推理场景

在线推理部署要求模型在用户请求到来后快速返回结果。部署重点包括：

• 模型加载后的显存占用是否稳定；
• 并发请求下是否出现显存抖动；
• 响应延迟是否可接受；
• 服务是否可以水平扩展。

2.3 混合负载场景

部分团队会在同一组资源上同时运行训练、评估和调试任务。这种场景对资源隔离、任务优先级和显存配额管理提出了更高要求。

---

三、显存瓶颈与资源评估

3.1 内存墙问题的本质

大模型部署中最常被低估的问题，不是单卡算力不足，而是单卡显存容量长期停滞。以近几代数据中心加速卡为例，虽然计算吞吐成倍提升，但单卡显存容量长期维持在同一数量级。这导致模型参数规模的增长与单卡可容纳空间之间的差距持续扩大。

一个简化的估算方式是：模型参数量为 N，采用 FP32 存储时，仅参数量就需要约 4N 字节。若采用 BF16 或 FP16，可缩减至约 2N 字节。训练时还需要保存梯度、优化器状态、激活值等，实际显存占用通常是参数本身的数倍。

例如，一个接近两万亿参数的模型，仅参数以 BF16 保存就需要约 3.6TB 显存。而单台服务器即使插满 8 张高端加速卡，总显存也可能只有 640GB 左右。这个差距已经无法通过单机扩容弥补，只能依靠并行策略与存储优化手段解决。

3.2 显存估算公式

部署前应将以下显存占用项纳入评估：

显存占用项	说明	典型规模
模型参数	所有权重矩阵与偏置	与参数量正相关
梯度	反向传播时产生	与参数量相当
优化器状态	一阶和二阶动量等	可达参数量的 2～4 倍
激活值	前向计算结果临时保存	与批量大小、序列长度、层数相关
临时缓冲区	计算中间变量	视实现而定
通信缓冲区	多卡通信所需	与并行策略有关

训练部署必须为优化器状态和激活值预留额外空间；推理部署则主要关注参数、激活值和 KV Cache 等部分。很多推理任务之所以发生显存溢出，正是因为 KV Cache 随并发和序列长度增长后未被有效限制。

---

四、部署架构与并行策略

4.1 并行策略设计

单卡显存无法容纳模型时，必须引入并行策略。常见方法包括张量并行、流水线并行、数据并行和专家并行。

• 张量并行：将单个层的权重切分到多张卡上，每张卡负责部分计算并同步结果。优点是能显著降低单卡显存占用，缺点是引入额外通信。
• 流水线并行：按层切分模型，不同卡负责不同层，形成流水线。优点是通信压力相对较小，缺点是可能出现流水线气泡。
• 数据并行：每张卡保存完整模型副本，处理不同数据批次。适合显存足够但吞吐不足的场景。
• 专家并行：适用于混合专家模型，不同专家分布在不同卡上，路由机制决定数据流向。

实际部署通常会叠加多种策略。例如先按张量并行切分模型，再按流水线并行分配层，最后对剩余资源叠加数据并行。策略选择应遵循“先保证放得下，再优化跑得快”的原则。

4.2 节点内与节点间通信

多卡部署时，节点内通信通常依赖高带宽互联，节点间通信则受限于网络带宽。部署前应确认：

• 单机内多卡是否支持高速互联；
• 多机之间网络带宽与延迟是否满足通信需求；
• 通信拓扑是否与并行策略匹配；
• 是否启用梯度压缩或通信与计算重叠。

如果通信成为瓶颈，即使显存规划合理，训练吞吐也可能大幅下降。

---

五、前置准备清单

大模型部署前，需要完成以下准备：

1. 资源确认：确认加速卡数量、单卡显存、CPU 内存、磁盘容量、网络带宽是否满足最低要求。
2. 依赖环境准备：安装与硬件匹配的驱动、运行时、加速库和容器环境。
3. 账号与权限：为部署账号配置最小权限，包括计算资源、存储桶、日志服务和监控服务的访问权限。
4. 模型文件准备：确认权重文件格式、切分方式、校验值和版本号。
5. 数据集与索引：训练任务确认数据可被并行读取；推理任务确认外部知识库、向量索引或数据库连接可用。
6. 网络策略：确认推理服务对外暴露的端口、负载均衡、域名解析和 TLS 证书配置。
7. 配置中心准备：将模型路径、并行度、批量大小、超参数、环境开关等写入配置管理，避免硬编码。
8. 日志与监控通道：提前配置日志采集、指标上报和告警规则。

---

六、训练部署流程

下面按通用训练部署流程进行说明。

6.1 创建资源与网络

在云环境或私有环境中创建计算节点组，选择具备足够显存的实例规格。推荐使用容器化方式运行，以便固化依赖并保证环境一致性。

网络规划需要区分管理网络、数据网络和存储网络。数据面通信建议使用高带宽网络，存储面与训练数据源之间应避免跨公网访问。

6.2 准备镜像与依赖

构建统一的训练容器镜像，镜像内包含：

• 硬件驱动与运行时；
• 分布式通信库；
• 训练框架与依赖包；
• 训练脚本与配置模板；
• 健康检查与探活脚本。

镜像应通过只读方式运行，代码与配置通过挂载或启动参数注入。

6.3 配置并行参数

根据模型规模和显存容量，设置并行度。配置时需要同时修改资源限制和启动参数。一般配置包括：

• 每节点加速卡数量；
• 张量并行度；
• 流水线并行度；
• 数据并行度；
• 全局批量大小；
• micro batch 大小；
• 梯度累积步数；
• 序列长度上限；
• 优化器类型与状态切分方式；
• 重计算策略开关；
• 混合精度级别。

6.4 启动训练任务

推荐使用容器编排平台提交任务，而不是在裸机上直接运行。任务启动后，应立即检查：

• 每张卡是否被正确识别；
• 显存占用是否接近预估但未溢出；
• 分布式进程是否全部收敛；
• 第一步 loss 是否正常输出；
• 日志是否有通信超时或数据读取错误。

6.5 保存与断点恢复

大模型训练周期长，稳定的保存与恢复机制必不可少。建议：

• 每 N 步保存一次模型状态；
• 同时保存优化器状态和随机数状态；
• 定期将断点文件上传至对象存储；
• 使用异步保存避免阻塞训练；
• 启动时进行校验和检查，防止权重文件损坏。

---

七、推理服务部署流程

7.1 模型加载与显存规划

推理部署首要任务是控制显存占用。常见策略包括：

• 使用低精度存储，如 BF16、FP8 或 INT8；
• 对模型权重做量化；
• 限制最大序列长度；
• 限制 KV Cache 大小；
• 调整批量大小和并发数。

上线前应离线测算不同序列长度和并发下的显存变化，形成资源配置表。

7.2 服务框架设计

推理服务通常由以下模块组成：

模块	作用
接入层	处理请求参数、限流、鉴权
调度层	请求排队、批处理、动态合并
推理引擎	模型计算与结果生成
缓存层	缓存重复查询与中间结果
日志与指标层	记录延迟、显存、吞吐和错误

批处理是提升推理吞吐的关键。短请求可与同类请求动态合并，减少显存频繁分配。服务还应设置最大等待时间，避免高延迟请求拖垮整体调度。

7.3 服务启动与接入

推理服务启动后，通过健康检查确认模型已完整加载。健康检查不能仅返回 200，应同时检查：

• 模型是否已加载完成；
• 显存占用是否稳定；
• 一次空请求或最小输入是否返回预期结果。

接入负载均衡后，验证请求是否能被正确转发、响应头是否符合预期、超时策略是否生效。

---

八、上线验证

部署完成不等于上线成功。上线验证至少需要覆盖以下内容：

1. 模型正确性验证：输入一组基线样本，比对输出结果与离线结果是否一致。
2. 显存稳定性验证：模拟低、中、高并发请求，观察显存是否持续增长或频繁抖动。
3. 延迟与吞吐验证：统计首 token 延迟、端到端延迟和每秒 token 数。
4. 故障注入验证：主动杀掉一个推理进程、断开一次网络、上传一次异常请求，观察恢复能力。
5. 安全与权限验证：确认未授权请求被拒、密钥未暴露、管理接口未公开。
6. 回滚验证：保留上一版本镜像与配置，确需回退时可在短时间内完成切换。

---

九、常见问题与排查思路

9.1 启动即显存溢出

常见原因包括：

• 模型分片策略未生效；
• 序列长度超限；
• 批量大小过大；
• 推理缓存未限制；
• 混合精度未启用；
• 单卡重计算或参数切分配置错误。

排查方式：逐项降低批量大小、缩短序列长度、关闭额外缓存，观察显存变化曲线，定位是哪一项导致溢出。

9.2 训练过程中显存缓慢增长

通常是因为日志、缓存或数据加载存在内存泄漏。可通过周期性输出显存快照判断增长来源，并检查是否每次梯度更新后临时变量未释放。

9.3 多卡性能不达标

重点检查通信与计算是否重叠、单卡利用是否均衡、是否存在某一卡显存占用过高导致其它卡空转。还可以检查网络拓扑是否导致跨节点通信拥塞。

9.4 推理服务请求波动大

可观察批处理队列长度、请求合并策略、缓存命中率和首 token 响应时间。必要时对短请求与长请求分组处理，避免长文本请求阻塞短请求。

---

十、运维与优化建议

10.1 监控体系

建议围绕以下维度建立监控：

• 资源维度：每卡显存占用、显存带宽、CPU 内存、网络流量；
• 任务维度：训练步耗时、数据加载耗时、梯度同步耗时；
• 服务维度：请求量、成功量、失败量、延迟分位数、并发数；
• 存储维度：断点保存耗时、对象存储上传成功率、磁盘水位。

10.2 弹性与容量管理

训练任务可按队列调度，避免多任务同时争抢同组资源。推理服务则根据实际请求峰值设置自动扩容策略，缩短扩容收敛时间。对于显存消耗大的服务，扩容前应先评估单副本最低显存需求，避免资源碎片。

10.3 成本控制

大模型部署成本敏感。可通过以下方式控制：

• 训练期使用短租资源，推理期使用长期资源；
• 对推理服务按请求量与延迟要求选择不同规格；
• 对长尾模型使用降级精度或较小并行度；
• 定期清理旧断点、旧镜像和测试资源。

10.4 安全与权限

模型权重文件应作为敏感资产管理。部署过程中避免使用共享密钥，访问对象存储时使用临时凭证。推理服务对外仅开放必要端口，管理接口与监控接口应隔离在内部网络。

---

十一、总结

大模型部署的难点早已不是单纯的“买更多卡”。当单卡显存容量增长缓慢，而模型规模持续扩大时，部署能力取决于资源评估是否精确、并行策略是否合理、服务设计是否稳定、验证手段是否充分、运维体系是否完善。开发者和技术团队应从显存规划出发，系统看待计算、存储、网络、安全与成本之间的关系，才能让一个看似“放不下”的大模型真正跑起来并持续提供服务。