从一则校园新闻说起
2025年12月，华中科技大学对外公布了一项进展：学校鲲鹏昇腾科教创新孵化中心基于完全国产化的昇腾算力平台，借助 vllm-ascend 推理框架，完成了华为盘古Pro MoE 72B 大模型的本地化部署，并面向校内师生开放应用服务。这则经中国教育报报道的消息，在高校圈里引起的讨论比想象中持久。
值得琢磨的是模型规模。72B 参数的 MoE 模型，权重文件超过 140 GB，放在几年前只有云厂商和头部实验室碰得起，如今却稳稳跑在校园内网里，供一所学校的师生日常调用。把大模型从公有云 API 搬回自己的机房，正在从少数人的工程冒险变成高校和研究所的常规操作。
对人工智能方向的课题组来说，这件事还有另一层含义。深度学习的训练与推理长期共用一套话语体系——都是 Transformer、都是 PyTorch、都是 GPU。但真要把一个训练好的模型稳定地部署进内网，让全组几十个人同时用，故障的形态、资源的瓶颈、运维的重心，和训练阶段完全不同。这篇文章从一个典型的故障复盘切入，聊聊大规模训练之后，大模型内网部署这件事到底难在哪、该怎么做。
先搞清楚我们在训练什么
一切要从 Transformer 架构说起。自注意力机制让模型直接对序列中任意两个 token 的关系建模，配合前馈网络堆叠成深层结构，构成了当下几乎所有大语言模型的骨架。PyTorch 凭借动态计算图和清晰的模块抽象，成了学术界训练这类模型的事实标准：模型用 nn.Module 搭出注意力层，用 autograd 自动反传梯度，用 DDP 或 FSDP 把数据切到多张显卡上做并行，再用自动混合精度把显存砍半。
真正的大规模训练，难点集中在三处。第一是显存：以 Adam 优化器为例，参数、梯度、一阶和二阶动量再加上主权重，一个 32B 模型的训练状态轻松突破 500 GB，单卡根本装不下。第二是通信：数据并行每个 step 都要做 all-reduce，节点之间的网络带宽直接决定扩展效率。第三是容错：几百张卡连续跑几周，硬件故障是常态，checkpoint 断点续训是标配。
训练阶段大家操心的是这三件事。可当你捧着训好的权重走向部署环节，会发现另一套问题在等着。
一次典型的部署故障复盘
先看一个在很多实验室都发生过的故事。某课题组基于开源模型做了领域微调，效果满意，导师拍板：模型不许出内网，部署到组里的服务器上给全组用。负责这件事的是组里一位训练经验很丰富的博士生，结果他接连踩了五个坑。
第一个坑是显存溢出。他习惯训练思维——显存不够就调小 batch。但推理时模型权重必须完整加载，batch 可以为一，权重却一个参数都少不了。32B 模型按 BF16 加载就是六十多 GB，服务器上的卡根本吃不下，第一次启动直接 CUDA out of memory。
第二个坑更隐蔽。他换上 4-bit 量化的权重，模型总算塞进了一张卡，长上下文测试时又崩了。问题在于他漏算了 KV cache。Transformer 推理时为省算力会把每层每头的 Key、Value 张量缓存下来，这个缓存随上下文长度线性增长。以 32B 级模型为例，64 层、8 个 KV 头、每头维度 128，FP16 精度下每个 token 的缓存约 256 KB，上下文开到 32K 就是 8 GB 起步，并发一上来再翻倍。训练时注意力是实算的，没人教过他要为这块显存做预算。
第三个坑是性能静默劣化。他换了个推理框架的版本，没核对 CUDA 驱动的最低要求，框架悄悄把部分层卸载到了内存，生成速度从每秒三十多个 token 掉到个位数，界面上却没有任何报错。他排查了两天才发现根源是一套没人关注的版本组合。
第四个坑是监控缺失。服务跑起来之后他如释重负，周末没人值班，进程半夜挂了，周一全组的人对着打不开的页面面面相觑。没有告警、没有日志留存、没有自动拉起，服务运行状态全靠人肉盯。
第五个坑出在数据合规上。最初为了赶进度，有同学图省事把一批未公开的实验数据送去了公网 API 做对照测试，被导师发现后整个部署工作推倒重来，重新梳理了数据出域的边界和权限分级。
这次复盘暴露的核心问题是：训练思维和服务思维是两套逻辑。训练追求单次任务的吞吐和收敛，服务追求长时间运行的稳定、可控、可观测。把模型部署进内网，本质上是把一个一次性计算任务改造成一个持续运行的软件系统。
大模型内网部署：围绕模型池的六个要素
成熟的课题组现在普遍采用预分配模型池的做法：提前选定两三个开源模型，统一版本、统一量化策略、统一接口，部署在一台或多台图形工作站/算力工作站上，对内以标准 API 形式提供服务。下面以模型池中常见的两个真实开源模型为例，拆解内网部署的六个要素。
任务场景：先想清楚模型给谁用
内网部署的第一步是写清楚任务清单。课题组常见的场景包括：文献与资料的智能问答、代码补全与调试辅助、实验日志和数据的初步分析、组内知识库的检索增强问答。不同场景对模型的要求差别很大——代码任务看重推理链条的完整性，问答任务看重知识覆盖和响应速度，批量数据处理看重吞吐。任务清单直接决定模型池里放谁、放几个。
模型选择：DeepSeek-R1-Distill-Qwen-32B 与 GLM-4.5-Air
这两个模型在 2025 年先后开源，是目前高校内网部署里出镜率很高的一对组合。
| 模型 | 架构 | 参数规模 | 上下文 | 许可协议 | 特点 |
|---|---|---|---|---|---|
| DeepSeek-R1-Distill-Qwen-32B | 稠密 Transformer | 32B | 128K | MIT | 深度推理蒸馏，数学与代码能力强 |
| GLM-4.5-Air | MoE（稀疏混合专家） | 106B 总参 / 12B 激活 | 128K | MIT | 思考/即时双模式，智能体任务与长文本处理出色 |
DeepSeek-R1-Distill-Qwen-32B 是 DeepSeek 在 2025 年初发布的 R1 蒸馏系列成员，把 R1 的推理能力蒸馏进 Qwen2.5-32B 底座，在 AIME 等数学推理基准上表现接近当时的旗舰闭源模型，而参数量只有 32B，部署门槛大幅下探。GLM-4.5-Air 是智谱 2025 年 7 月开源的模型，总参数 106B、每 token 只激活 12B，稀疏 MoE 路由让它用接近 70B 稠密模型的显存占用换来更强的综合能力，还自带思考与非思考两种模式，适合既要做深度分析又要快速应答的混合负载。两者都是 MIT 协议，商用和二次开发都没有法律障碍，这对高校项目尤为重要。
量化与显存估算：把账算在开机之前
显存估算是内网部署的第一道算术题，要算两笔账。
第一笔是权重。经验公式很简单：FP16/BF16 精度下每 10 亿参数约占 2 GB，FP8 减半，4-bit 量化再减半。据此，32B 模型 BF16 权重约 62～64 GB，FP8 约 32 GB，INT4 约 18～22 GB；GLM-4.5-Air 因为 106B 参数全部要驻留显存，4-bit 量化后权重约 68 GB，FP16 则高达 206 GB 左右。注意 MoE 模型省的是算力，显存可一点没少省。
第二笔是 KV cache。前文算过，32B 级模型每 token 约 256 KB，32K 上下文、单并发就要 8 GB 起步；如果把上下文放到 128K 并开多并发，这块可以轻松吃掉三四十 GB。社区实测 GLM-4.5-Air 在 4-bit 量化、8K 上下文下总显存需求约 71 GB，已经是最保守的口径。
稳妥做法是权重加缓存再加 20% 到 30% 的余量，一次算清再决定用几张卡。很多人部署失败，根源就是只算了第一笔账。
推理框架：vLLM 生态是主流答案
推理框架决定了显存利用率和吞吐上限。目前高校内网部署的主流选择是 vLLM：它的 PagedAttention 把 KV cache 按块管理，显存碎片大幅减少；continuous batching 让不同长度的请求拼批执行，吞吐成倍提升；启动一个 OpenAI 兼容的服务端点只需要几行命令，组里任何会用 Python 的人都能接进去。前文提到华中科技大学的国产化部署同样选择了 vLLM 系的推理框架（vllm-ascend），从侧面说明这套技术路线已经成为共识。除此之外，SGLang 在复杂调度上见长，llama.cpp 和 Ollama 适合轻量验证，可以按场景搭配。关键原则是：框架版本、CUDA 驱动、显卡型号要在部署文档里钉死，别给“静默降级”留机会。
离线运行与数据安全：内网部署的立身之本
内网部署的核心动机是数据不出域。落地时要做到：模型权重从可信渠道下载后离线分发，服务器接入内网专用网段，与外界物理或逻辑隔离；API 层面启用访问令牌和按人分配的角色权限，敏感操作留审计日志；未公开的数据、代码、实验记录一律不离开内网环境，需要对照测试也只能在内网模型之间做。这些动作在技术上都不难，难的是写成制度并执行下去——前面复盘故事里的第五个坑，就是制度缺位付出的代价。
运维监控：让服务可观测、可恢复
最后一块是运维。最低限度的监控应覆盖：GPU 利用率和显存占用、每路请求的 token 生成速度、首 token 延迟、卡温和功耗、服务进程的存活状态。工具链上，dcgm 采集硬件指标，Prometheus 加 Grafana 做展示和告警，日志集中留存便于回溯。同时给服务加上健康检查和进程自动拉起，把模型版本、量化方式和启动参数写进配置管理，升级时保留回滚路径。做到这一步，那四个“周一才发现服务挂了”的坑才算真正填平。
工作站配置推荐
把前面的显存账和并发需求落到硬件上，支撑上述模型池落地的图形工作站/算力工作站，按并发规模可分四档考量：
- 轻量验证档：A350 15364-MBT（供 1～3 人调试量化模型与框架）
- CPU：Intel Core Ultra 7 265K，20核（8性能核全核5.3GHz / 12能效核全核3.8GHz）（5.3GHz / 3.8GHz为全核超频实测优化频率）
- GPU：RTX 5090D v2 24G 水冷（24GB GDDR7，384bit，显存带宽 1.34 TB/s，PCIe 5.0 x16）
- 内存：64GB DDR5
- 存储：2TB NVMe
- 适用说明：24GB 显存可覆盖 7B～13B 模型的全精度调试与 32B 级模型的 INT4 量化验证，适合框架选型、量化策略对比和接口联调阶段的小组使用；vLLM、SGLang、llama.cpp 等框架都能在这张卡上跑通完整流程。
- 小组共享档：AX430 127128-MCF（单量化模型、5～10 人低频并发）
- CPU：Xeon金牌6530，32核2.7G（2.7GHz为全核超频实测优化频率）
- GPU：RTX Pro 6000 96GB（96GB GDDR7，512bit，显存带宽 1.79 TB/s，PCIe 5.0 x16）
- 内存：128GB DDR5
- 存储：4TB NVMe
- 适用说明：96GB 单卡显存可把 GLM-4.5-Air 4-bit（权重约 68GB）连同 KV cache 一并装下，也可让 DeepSeek-R1-Distill-Qwen-32B 以 BF16 全精度常驻并留出长上下文空间，满足 5～10 人低频并发下的单模型服务。
- 课题组主力档：GX660M 227512-MD2A（模型池双模型常驻、10～30 人并发）
- CPU：2×Xeon金牌6530，64核2.7G（2.7GHz为全核超频实测优化频率）
- GPU：2×A100 80GB 水冷（单卡 80GB HBM2e，显存带宽 2 TB/s）
- 内存：256GB DDR5
- 存储：4TB NVMe
- 适用说明：160GB 显存总量让 32B 模型与 GLM-4.5-Air 4-bit 同时常驻成为可能——两张卡各驻一个模型，或经张量并行把负载摊开；配合 vLLM 的 PagedAttention 与 continuous batching，足以承接 10～30 人的日常并发，并保留微调与长文任务的余量。
- 实验室集群档：GX668 227512-MC4A 计算节点多台 + 存储管理节点（多机多卡、训练推理混部、50 人以上）
- 计算节点 CPU：2×Xeon金牌6530，64核2.7G（2.7GHz为全核超频实测优化频率）
- 计算节点 GPU：4×A100 80GB（单卡 80GB HBM2e，显存带宽 2 TB/s），整机半精度 FP16 833 Tflops / FP64 200 Tflops
- 计算节点内存：512GB DDR5
- 计算节点存储：4TB NVMe
- 存储管理节点：2颗Xeon银牌4314（32核），192GB DDR4，126TB 并行存储
- 网络互联：节点间按 10G/40G/100G 规格组网，推理入口前置负载均衡
- 适用说明：每个 4 卡节点可独立承载一个模型池实例，多节点并联把并发能力扩展到 50 人以上，训练任务则可跨节点调度；模型权重与语料集中存放在并行存储上，节点按需拉取，避免每台机器各存一份。
四档配置遵循同一套估算逻辑：先算权重，再算 KV cache，最后留 20%～30% 的余量。采购前建议把售后响应、质保条款与后续加卡扩展空间一并纳入考量，模型池扩容时优先在同类机型上堆叠，免得部署架构推倒重来。
写在最后
深度学习大规模训练的浪潮把模型越推越大，而 Transformer 与 PyTorch 奠定的技术栈让训练本身越来越工程化。真正的分水岭出现在训练结束之后：谁能把模型稳定、安全、可持续地部署进自己的内网，谁就能把训练成果变成全组日常可用的生产力。故障复盘的价值正在于此——它把部署从“把模型跑起来”的运气活，变成“把六要素做扎实”的工程活。对于课题组长久的科研积累来说，后者才值得信赖。
工作站配置选型欢迎咨询~
微信号：maxftxwx
fuyiqin@xasun.com
