大模型综述:如何训练和部署大规模神经网络

你可能刚拿到一台机器或一笔预算，想知道跑一个大模型到底要经过哪几步、每一步卡在哪、什么时候该停下来重算。这篇不讲论文，只按工程顺序把训练、微调、量化、部署、监控串成一条线，每一步都给出判断依据和可执行动作；具体参数与价格请到站内对应页面核对当时的数字。

你可能刚拿到一台机器或一笔预算，想知道跑一个大模型到底要经过哪几步、每一步卡在哪、什么时候该停下来重算。这篇不讲论文，只按工程顺序把训练、微调、量化、部署、监控串成一条线，每一步都给出判断依据和可执行动作。

先声明一件事：全文不写具体参数、价格和跑分，凡是需要看数字的地方都会指到站内对应页面，你自己去核对当时的口径。另外本文默认你是一个 3 到 10 人的工程小队，手里有几张卡和一段不算宽裕的预算，不是大厂训练集群。如果你是个人开发者先跑通单机，那就把并行和集群那几节当背景知识看，重点放在后三段。

先把全流程拆成五段，别一上来就调参

大模型工程最典型的翻车方式是：团队拿到需求第一反应是找模型、配环境、开训，结果两周后才发现数据里混了评测集，或者任务根本不需要训练。所以先把链路切成五段，每段有独立的产出物和验收标准，段与段之间有明确的交接物。

数据准备

产出清洗去重后的语料与评测集，验收标准是抽样人工可读、评测集与训练集无重叠

预训练或继续预训练

产出基座权重，验收标准是通用能力不退化、loss 曲线收敛形态正常

微调对齐

产出面向任务的权重，验收标准是在固定评测集上稳定优于基座

量化与推理服务

产出可对外调用的接口，验收标准是延迟、吞吐、质量三项都落在可接受区间

上线监控

产出可观测面板与告警，验收标准是出问题能定位到是哪一段退化

关键是先定位你的起点。多数中小团队真正需要做的其实是第三段往后：拿开源基座做微调、量化、部署、监控。从零预训练只在一种情况下才合理，就是你的数据或任务在公开基座上系统性做不到，而且你能拿出证据说明不是微调方法的问题。

• 每段末尾设一个检查点，产出物不达标就停，不要带着问题往下走
• 预训练和微调之间的评测集要提前冻结，训到一半再改评测等于白训
• 数据或评测出问题，回退成本最高，所以这两样多花时间是划算的
• 拿不准某段该不该做，先去站内 /training 和 /models/deploy 看同类任务的常规做法再决定
• 预算和时间要按段分配，别把八成资源压在训练段，部署和监控同样吃人力

数据与算力预算：先算量级再谈方案

预算测算的目的是筛掉不可行的方案，而不是精确报价。第一步估总算力：按参数量和目标训练 token 量粗算一个量级，再折算成卡时和天数。如果算出来比你手上的资源差一个数量级，就别在并行策略上花时间了，直接换更小的模型或更少的训练量重新估。

第二步估数据。数据不是越多越好，重点看四件事：配比是否覆盖你的目标任务、重复率是否被压下去、清洗是否处理了乱码和模板污染、来源是否在合规边界内。语料版权与数据来源的判断口径可以对照站内 /safety 页面，那里整理了合规检查的常规维度。

第三步把预算切成三份：训练、评测、返工。返工那份最容易被低估，但现实中调数据、重跑评测、修训练脚本的时间往往超过第一次训练本身。具体单价、卡时成本区间和公开案例数据，请到站内 /compute/training-cost 与 /training 页面核对当时的数字，不要拿旧印象做决策。

并行与显存：三种切分方式各自解决什么

三种并行解决的是三个不同的问题，混淆它们会导致排查方向完全错误。数据并行是把同一份模型复制到多张卡上、各自吃不同数据，解决吞吐；张量并行是把单层内部的矩阵运算切开，解决单层放不下；流水线并行是把不同的层分到不同卡上，解决层数太多放不下。实际项目常常三者叠加。

显存不够时的排查顺序很重要，很多人一上来就改并行配置，结果通信开销把收益全吃掉。建议按下面顺序逐级尝试，每级都测一次是否还 OOM。

1. 第一步：减 batch 和序列长度先降 batch size，再考虑截断或分组处理超长序列。这一步几乎零成本，先排掉。
2. 第二步：开梯度检查点用计算换显存，训练速度会下降但显存占用明显降低，验证标准是能跑通且单步时间可接受。
3. 第三步：调整混合精度与优化器状态检查优化器状态是否用了显存优化实现，这一步常被忽略但收益稳定。
4. 第四步：上并行切分前几步都不够再考虑张量并行或流水线并行，上之前先估算通信量与小集群是否划算。

并行度不是越高越好。卡数少的时候，通信开销占比会迅速上升，堆并行反而更慢。按你的模型规模和卡数算一遍可行方案，可以参照站内 /compute/sizing 的测算思路，别凭感觉配。什么时候不适用：如果你的瓶颈是单卡显存而不是总吞吐，加卡不解决问题，该做的是量化和模型裁剪。

微调阶段：决定改哪些权重、留多少回退

微调是整个链路里最需要纪律的一段，因为它的效果依赖评测，而评测本身很容易做错。开训前必须先固定一份评测集，并且保证它与训练数据严格隔离；没有固定评测集就开训，后面你无法判断模型是变好了还是过拟合了。

无论选哪种方法，都要保留基座权重、训练配置、数据版本和随机种子的完整记录。回退时要能一键还原到微调前的状态，否则一次失败实验就可能污染整个环境。具体的方法选择标准和显存估算，站内已有专文展开，本篇只讲它在流程中的位置：它是第三段，输出是一份可评测的权重。

• 开训前冻结评测集，并记录它的版本和生成方式
• 先跑一次小规模试验，确认 loss 和评测指标方向正确再放大
• 每轮保存检查点，不要只保留最后一轮
• 过拟合的典型信号是训练指标涨、评测指标掉，看到就停
• 微调完立刻做一次基座对照，确认提升不是评测噪声

量化与推理服务：把模型变成能扛并发的接口

量化是在质量、显存、吞吐之间取舍，没有免费的那一档。选档位之前，先用真实业务样本跑一轮对比，而不是只看通用榜单：通用榜单衡量的是通用能力，你的业务分布可能对它不敏感，也可能格外敏感。对比时至少看三项：输出质量是否可接受、显存占用降了多少、单请求延迟和吞吐变成什么样。

推理框架的选择要看并发模型和部署形态。单机自用和对外服务不是同一套答案：前者更在意启动简单和资源占用，后者更在意批处理能力、并发调度和稳定性。上线前先量出自己的基线，站内 /tools/speed-test 可以测你所在网络到接口的延迟基线，有了这个数才能判断后续的慢是模型慢还是链路慢。

什么时候不适用量化：如果你的任务对细微输出差异极度敏感，比如某些结构化抽取或严格格式输出，量化后可能出现格式崩坏，这种情况宁愿多占显存也别强上激进档位。先做小样本对比，再决定。

部署上线：容量、灰度与监控三件事

部署阶段的核心不是把服务跑起来，而是让它在你预期的最坏情况下还能稳定。容量规划按峰值并发和最大上下文长度一起算，并且留出余量给缓存和显存碎片。只按平均并发配资源，等于把稳定性押在流量平稳这个假设上，而流量从来不平稳。

1. 灰度发布先放小流量，观察错误率、首 token 延迟、超长请求三类指标，稳定后再逐步放量。
2. 建监控面板至少覆盖请求量、错误率、延迟分位数、显存占用、队列长度，缺一个都会在故障时抓瞎。
3. 区分慢的来源监控要能分辨模型推理变慢还是网络与网关变慢，否则排查方向一开始就跑偏。
4. 设告警阈值按业务可接受的最差体验设阈值，别等用户投诉才发现。

用量和成本的变化要有历史对比，否则你会不知道是业务涨了还是某次改动漏了资源。可以去站内 /usage 与 /price-watch 对比历史区间，看趋势而不是看单点。如果你的服务还在依赖第三方中转，那还要额外关注可用性和稳定性，站内 /sites 和 /rankings 有这方面的整理。什么时候可以简化监控：内部工具、无对外承诺、可接受中断的场景可以砍掉部分告警，但错误率和延迟这两项建议一直留着。

什么时候该继续投入，什么时候该换路

投入决策的前提是先归因。同样是「效果不好」，瓶颈可能在数据质量、任务定义、模型能力、推理配置四个完全不同的地方，对应的动作也完全不同。加卡和换模型只对其中一种有效，对另外三种是纯浪费。

如果决定换模型或换框架，别直接切生产。按迁移清单逐项验证：接口是否兼容、权重能否正常加载、量化格式是否支持、许可证范围是否覆盖你的用法。每一项都要在测试环境跑通再上灰度。许可证这件事最容易被跳过，站内 /safety 有相关口径可以参考。

• 归因没做完之前不要做技术选型，那是在赌
• 换模型优先选接口兼容的，迁移成本比想象中高
• 换框架前先确认推理格式和量化格式都有支持
• 许可证范围要覆盖你的部署形态和商用场景
• 迁移后做一次完整的回归评测，不要只看 demo 对话

常见翻车点与排查顺序

这一节把前面各段的高频问题集中列一下，方便你当检查清单用。训练侧的典型问题是数据泄漏到评测集、学习率与 batch 不匹配、断点续训时优化器状态没存全导致重新收敛；部署侧的典型问题是显存碎片、上下文超限、并发限流配置与网关不一致导致实际压力和预期不符。

排查顺序建议固定下来，这样团队里不同人处理问题时不会各查各的。先看日志与指标，再复现最小请求，最后才动参数和硬件。顺序反了的话，你会花大量时间在改配置上，而问题可能只是某个请求超了上下文长度。

报错处理不要一上来就重装环境。多数报错能通过读日志定位到具体组件，重装会丢失现场信息。同类排查路径站内已有整理，对照着走比盲目试错快。