35B参数级大模型部署指南：从准备到上线

一、部署概述

本文的部署对象是一款总参数量35B级、激活参数为十亿级的混合专家（MoE）架构大语言模型。该模型在公开同规格基座之上，经“中训练＋后训练”二次优化，融合了大量研发团队自有数据集与研究轨迹数据，定位于自进化类应用场景。本文的目标是帮助读者将这样一款模型部署为稳定运行的在线推理服务：部署完成后，服务以标准API方式向内部业务或上游应用提供对话与文本生成能力，并发、时延与可用性等指标达到可控、可验证的状态。

本文适合的开发者、运维工程师、架构师与企业技术团队阅读。开始之前，需要建立三个基本认知：

1. 模型形态：MoE结构要求全部专家权重常驻显存，因此部署瓶颈主要在显存容量与显存带宽，而非单纯算力。这直接决定实例选型与量化决策。
2. 服务形态：推荐以容器化的HTTP API推理服务上线，这是行业主流路径，便于环境一致性管理、水平扩容与灰度发布。
3. 运行环境：GPU云服务器或自建GPU集群均可。以百度智能云为例，GPU云服务器、对象存储、容器服务、负载均衡、监控告警等通用产品即可覆盖部署所需组件，读者可按所用云平台等效替换。

二、部署场景

该类35B级MoE模型的部署通常适用于以下场景：

• 企业级知识问答与智能助手：面向内部员工或客户的对话服务，要求私有化承载、数据不出域；
• 办公自动化与数据加工：长文本摘要、信息抽取、报表生成等批量任务，吞吐优先；
• 自进化研发闭环：模型团队需要线上真实流量回流数据，支撑下一轮中训练与后训练迭代，部署环节是数据飞轮的起点；
• 安全合规敏感业务：行业客户不允许调用外部公有API，必须在自有或专属环境中完成推理。

不同场景对部署方案的侧重不同：对话型业务关注首字时延与流式体验，批量任务关注吞吐与成本，研发闭环场景则额外要求日志与数据的规范化留存。

三、架构与组件拆解

一次完整的上线涉及五层组件，建议在动手前先画出自己的部署拓扑：

层次	组件	作用与要点
接入层	负载均衡、API网关、认证限流	统一入口、HTTPS终止、令牌鉴权、配额与限流
服务层	容器化推理服务	权重加载、KV Cache管理、请求调度与批处理
计算层	GPU云服务器/自建GPU节点	多卡高速互联，规格按显存需求反推
存储层	对象存储、高速本地盘、日志存储	权重分发、版本化目录、日志留存与审计
运维层	监控告警、日志服务、健康检查	指标采集、异常通知、故障自愈触发

各层之间通过内网互联，权重下载与业务访问均应走内网链路，仅网关端口对业务网段开放。

四、前置准备

4.1 权重文件与版本管理

• 从模型团队或内部模型仓库获取权重包，单份权重约数十GB；
• 下载后必须做校验和比对（如SHA256），避免传输损坏导致推理输出异常这类极难排查的问题；
• 建立“模型名＋版本号”的目录规范，例如 /data/models/llm-35b-moe-v1，旧版本保留至少一个迭代周期，用于回滚；
• 磁盘容量按权重体积的1.5～2倍预留，为量化副本与临时解压留出空间。

4.2 资源规划与显存估算

显存需求可用通用公式估算：权重显存 ≈ 参数量 × 单参数字节数，再叠加KV Cache与框架开销。参考估算如下：

权重精度	权重占用（估算）	建议显存（含KV Cache与开销）	典型配置参考
BF16/FP16	约70GB	≥90GB	单机4卡×24GB，或2卡×48GB以上
INT8	约35GB	≥48GB	单机2卡×24GB，或1卡×48GB
INT4	约18GB	≥24GB	单机1卡×24GB以上

注意两点：其一，KV Cache占用与上下文长度、并发数正相关，若业务要求32K上下文且并发较高，需额外预留余量或增加卡数；其二，该模型激活参数小、单token计算量可控，对显存带宽更敏感，同等预算下优先选择高带宽显存的实例。

4.3 软件环境与依赖

• 操作系统、GPU驱动与容器运行时版本三者匹配，这是最常见的启动失败根因；
• 选用支持MoE结构的主流推理框架镜像，版本以官方文档为准，镜像统一存放于内部镜像仓库；
• 配置内网加速的镜像与权重下载通道，避免公网带宽成为瓶颈。

4.4 账号、权限与网络

• 使用子账号与最小权限原则：部署人员仅需实例操作、对象存储读取与日志写入权限；
• 网络规划：实例置于私有网络内，安全组仅放行网关端口与运维跳板地址；
• 对外提供HTTPS时，提前准备域名与证书，并配置解析。

4.5 验证数据与基线

准备50～200条覆盖典型业务的测试用例，并在离线环境先用同一权重跑出基线输出。上线后逐一比对，确认“同模型、同效果”，排除部署环节引入的精度或配置偏差。

五、部署流程

整体流程为：环境初始化 → 权重下载校验 → 容器化拉起 → 参数配置 → 健康检查 → 开放访问。

步骤一：初始化基础环境。 创建GPU实例，安装驱动与容器运行时，挂载高速数据盘，验证内网连通性。此步的意义在于消除底层环境不一致，后续所有问题排查都能因此收窄范围。

步骤二：下载并校验权重。 将权重从对象存储或内部模型仓库拉取至本地高速盘，支持断点续传；完成后执行校验和比对。切勿让推理服务在运行中直接依赖远端存储加载权重，冷启动时延与稳定性都会受影响。

步骤三：容器化拉起服务。 通用示意（伪代码，不可原样执行）：

启动容器：
  挂载  /data/models/llm-35b-moe-v1  →  /models/llm-35b-moe-v1
  挂载  配置目录与服务日志目录
  映射服务端口 8000
  启用全部GPU设备
  镜像：内部仓库/inference-framework:stable
  启动参数：--model-path /models/llm-35b-moe-v1  --config /app/config.yaml

步骤四：完成关键参数配置（详见第六节），先以保守值启动，压测后再逐步放开。

步骤五：健康检查与自测。 确认服务就绪探针通过，向本地端口发送样例请求，比对基线输出。

步骤六：开放访问。 注册到负载均衡，网关配置鉴权、限流与证书，从测试环境发起一次全链路调用后，方可接入业务流量。

六、关键配置说明

# 推理服务启动配置（通用示意）
model_path: /models/llm-35b-moe-v1
dtype: bfloat16            # 精度：bfloat16 / int8 / int4
quantization: none
tensor_parallel_size: 2    # 张量并行卡数，与实例卡数对齐
max_context_length: 32768
gpu_memory_utilization: 0.90
max_batch_tokens: 8192
port: 8000

• 精度与量化：BF16效果最优；INT8/INT4可显著降低显存与成本，但必须先跑评估回归，确认效果达标再切换；
• 张量并行度：与实际卡数对齐，错误的并行度会直接导致显存溢出或通信异常；
• 上下文长度：按业务真实需求设置，不要盲目拉满，否则KV Cache会挤占批处理空间；
• 显存利用率：建议0.85～0.92之间，预留余量防峰值溢出；
• 配置隔离：配置文件与密钥分离，密钥通过环境变量注入，严禁写入镜像或代码仓库。

七、上线验证

按以下清单逐项验收：

验证项	方法	通过标准
进程与端口	健康检查接口	返回正常状态码
基础能力	样例请求比对离线基线	语义一致、无乱码
流式输出	流式调用测试	输出连续、正常收尾
并发与时延	阶梯压测	P99时延达SLO、错误率低于1%
资源状态	监控面板	GPU利用率与显存平稳、无溢出
日志	启动与请求日志	无持续ERROR告警

压测方法：从低并发起步逐级加压，观察吞吐与时延曲线的拐点，把拐点对应的并发作为单实例容量上限，据此规划实例数与扩容阈值。

八、常见问题与排查

现象	可能原因	排查思路
启动即显存溢出	并行度与卡数不符、上下文过大	核对权重占用与利用率参数，降低上下文或改用量化
权重加载缓慢	存储带宽不足、远端加载	预下载至本地高速盘，校验后本地挂载
首字时延偏高	缺少预热、图编译未缓存	启动后执行预热请求，保留编译缓存
并发吞吐不达预期	批处理未生效、网络瓶颈	观察批次聚合指标，调整批量参数与接入链路
服务反复重启	健康检查过严、显存余量不足	放宽探针初始延迟，降低显存利用率
外部无法访问	安全组或网关路由未放通	检查私有网络策略、监听端口与转发规则

九、运维与优化

• 监控告警：覆盖资源指标（GPU利用率、显存、温度）、服务指标（QPS、首字时延、P99、错误率）与业务指标，分级设置告警阈值与通知升级策略；
• 稳定性保障：多实例＋负载均衡承载流量，健康检查自动摘除异常实例，发布时优雅下线、排空存量请求；
• 版本更新与回滚：权重版本化目录管理，新版本先以小流量灰度验证，再全量切换；旧版本权重与配置完整保留，确保可一键回滚；
• 自进化迭代闭环：这是该类模型区别于普通静态模型的关键运维项——在用户授权与数据脱敏前提下留存线上请求日志，定期离线评估、沉淀训练数据，模型团队完成新一轮中训练与后训练后，按本文流程发布新版权重，形成“部署—运营—数据—迭代—再部署”的飞轮；
• 安全控制：密钥定期轮换、访问白名单、传输加密与操作日志审计，权限随人员变动及时回收；
• 成本控制：常驻流量用包年包月资源覆盖基线，压测与评估任务用按量资源，定期巡检闲置实例；对象存储配置生命周期策略，自动清理过期的旧量化副本。

十、总结

部署一款35B级MoE大模型，核心在于三点：以显存估算驱动资源规划，用“下载校验—容器化拉起—参数保守启动—灰度开放”的顺序控制上线风险，用标准化清单完成验收。上线不是终点，配套的监控告警、版本灰度回滚与数据回流迭代机制，才决定了该服务能否长期稳定地创造价值。建议读者在实践前先完成第四节的前置清单，再按第五节流程推进，可显著降低返工与故障概率。