一个初创团队要动大模型微调最先被问住的问题通常不是“用哪个框架”而是“把训练放到哪”。GPU 要好用、要能多机扩展、要扛得住上 TB 的训练数据和频繁的 Checkpoint这三件事分开看都不难合在一起就会卡住不少人。下面这篇文章就是我踩过不少坑之后沉淀下来的一套选型判断方法重点解决一个问题创业企业做大模型训练微调时怎么判断一个云平台是不是真的具备 GPU 资源、分布式训练和海量存储能力而不只是“看起来有”。1. 创业团队的真实困境为什么先攒机、后上云的路越来越难走1.1 训练微调对基础设施的要求和纯推理完全是两码事很多团队第一次做微调时会犯一个认知错误觉得“推理能用几张卡跑起来训练应该也差不多”。实际上训练和推理对云资源的需求逻辑完全相反。纯推理阶段模型权重是只读的显存里只需要放权重、KV Cache 和临时激活值不需要保存梯度更不需要为优化器状态预留空间。你买一台 8 卡机器把模型用 vLLM 或者 TensorRT-LLM 拉起来只要并发控制得当利用率通常都能接受。一旦进入训练或微调阶段显存压力立刻变味。每个可学习参数除了要存权重本身还要存梯度像 Adam 这样的优化器还会额外保存一阶动量、二阶动量甚至一份 FP32 主权重。粗略估算下来全参数微调一个 7B 模型光是权重加优化器状态就要上百 GB 显存这还没算激活值。这不是单卡能搞定的事情需要多卡甚至多机协同。更麻烦的是分布式训练会引入通信开销。每轮迭代做完反向传播各张卡之间要做梯度同步同步次数以千次万次计。通信带宽不够、延迟太高训练速度会被无限拖慢卡越多反而越慢的情况我也见过。所以评估云平台能不能做微调本质上是在评估三个能力算力密度够不够、多卡之间通信效率高不高、海量训练数据能不能被高效率地喂给 GPU。这三件事是绑在一起的缺一个另外两个都会被拖下水。1.2 从硬件投入到运维成本的账算清楚再决定是买卡还是租卡创业团队做选型时总是会有人跳出来说“自己买卡是不是更划算”。这个账不是不能算但要算全不能只看硬件采购价。自己购买 GPU 服务器表面成本是一张卡几万块、一台 8 卡机器几十万一次性投入看着有数。但你要继续往里加机房托管或改造的电力成本、散热成本、运维人员成本还有硬件折旧。A100 这种卡的实际寿命和使用强度、转售价格挂钩二手残值远没有想象中稳定。更隐蔽的是利用率问题。创业团队的数据规模和训练频率往往波动极大这一周在调一个 7B 模型下一周可能只需要跑几天的 LoRA 实验。自建集群一旦空闲钱就是在烧地板。而且训练规模一旦上来扩卡不是买一张就能解决问题的还要考虑机柜空间、网络设备、存储扩容每次都像一次小型基建工程。云平台的逻辑完全不同它是把硬件投入拆成按需付费的运营成本训练密集的时候拉高实验间歇期释放。虽然单位时间的租金看起来比“理论折旧”贵但算上利用率、运维成本和灵活性创业初期租云往往是更理性的选择。当然等团队模型规模和频次稳定下来也有企业会走“包年预留弹性抢占”的混合路线。这个我们后面细说。2. 选云平台先懂三件事GPU 实例到底该怎么看、怎么比2.1 显卡型号、显存、精度分别决定了你能跑多大的模型和多快的速度选 GPU 实例不能只看“是不是 A100”要说清楚三个维度型号、显存、精度能力。型号决定的是算力天花板。拿 A100 和 H100 比H100 在各种精度下的算力优势非常明显V100 和 T4 则更老做推理够用做训练会比较吃力。中端场景里L40S 这类卡的 FP16 算力很强显存也大价格比 H 系列友好微调中等规模模型是性价比很高的选择。显存大小决定你能装下多大的模型和多长的序列。同样一张 A10040GB 和 80GB 版本能处理的 Batch Size 差了一倍。大模型微调时显存里同时要放权重、梯度、优化器状态、激活值还有通信缓冲区显存不够就只能拆序列、缩 Batch训练效率骤降。再往深一层还要看算力精度。老的 GPU 如果只支持 FP32不支持 BF16训练速度会非常吃亏。现在很多微调实践都依赖 BF16 混合精度能直接减半显存占用还能保持稳定。另外FP8 等新精度也越来越重要选实例时要确认平台镜像和框架版本是否支持这些精度格式。还有一个容易被忽略的指标是显存带宽。HBM 带宽高的卡数据搬运速度更快这在激活值特别大、通信密集的训练任务中非常关键。规格表里如果只写了 TFLOPS不看带宽很容易踩坑。2.2 实例类型与调度策略独享、抢占和弹性伸缩的适用场景云平台一般会给同一张 GPU 卡设计多种售卖方式最典型的是按需实例、抢占式实例有些平台叫 Spot有些叫竞价实例以及包月包年预留实例。按需实例最稳想用就开、不用就关但价格最贵。抢占式实例非常便宜通常只有按需价格的几折但有个致命条件平台随时可能回收资源。训练任务一旦长时间跑中途被回收如果没做好 Checkpoint 续训前面几小时甚至十几小时的钱就白花了。我的建议是不要一上来就全用抢占式实例。可以按这个节奏先用按需实例跑通整个训练流程把数据加载、Checkpoint 保存、续训脚本这些问题都验证掉再切到抢占式实例上做大规模训练。这样即便被中断也能自动从最近一次 Checkpoint 恢复。弹性伸缩和抢占不同它更偏资源池的调度层面。比如你申请了一个 8 卡任务平台在资源空闲时可以立刻调度给你在资源紧张时可能要排队。很多平台也支持任务排队和优先级策略这直接关系到训练任务能不能在黄金实验窗口内完成。创业团队要注意有些“看起来很便宜”的 GPU 实例背后可能是共享 GPU 或者虚拟化实例资源隔离和通信效率都要打折扣。下单前先确认是不是独享整卡、是不是独享整机尤其是多卡训练避免两个任务抢同一张卡的显存和带宽。2.3 多机通信才是分布式训练的分水岭RDMA 网络与 NCCL 连通性单机 8 卡训练卡间通信走 NVLink 和 NVSwitch带宽极高延迟极低平台差异不大。但一旦需要多机训练比如 2 台 8 卡机器组成 16 卡集群问题就来了。多机通信走以太网还是 RDMA完全是两个世界。NCCL 这类集合通信库对网络带宽极其敏感普通的 25G 以太网跑 all_reduce带宽可能连本地 NVLink 的十分之一都不到同为 100G 网络RoCEv2 的时延和带宽利用率和普通 TCP 也有明显差距最理想的是 InfiniBand但要确认物理网络是不是真的贯通到了节点级别。怎么验证不要听平台宣传直接在实例上跑一次nccl-tests的 all_reduce 测试。如果跨节点带宽能达到单卡内部带宽的较高比例说明网络架构正常如果数值低得离谱或者时延波动很大那说明这台机器和另一台机器之间可能存在网络瓶颈后续分布式训练大概率会卡。很多平台会单独划分“AI 专用集群”这种集群内部通常有完整的 RDMA 网络跨节点通信性能稳定。普通通用计算集群里的 GPU 节点虽然也能开多台但节点间往往只能走 VPC 网络训练性能会大打折扣。选型的时候一定要问清楚我申请的这批 GPU 节点是不是在同一个高速互连域内。3. 分布式训练支持能力拆解平台层到底帮你做了哪些事又有哪些它替代不了3.1 容器集群、作业调度和资源队列都说“支持分布式”实际粒度差异很大几乎所有云平台都会说自己支持分布式训练但这句话背后的含义可以差出十万八千里。最基本的是提供多台 GPU 云主机让你自己去搭环境、手动互信、手工拉起训练进程。这种方式最灵活但所有运维负担都在你身上一旦节点失败你不知道怎么自动恢复。好一点的是基于 Kubernetes 提供容器训练任务支持申请多节点资源并给你分配一个共享的 hosts 文件或者服务发现机制让各节点的训练进程能找到彼此。有些平台的 AI 平台产品比如阿里云的 PAI、华为云的 ModelArts、腾讯云的 TI 平台会在此基础上再做一层训练作业编排直接支持 PyTorchJob 这类 CRD自动拉起 worker、自动收集日志、自动清理资源。再往上是平台级调度器支持任务排队、优先级抢占、多租户配额、GPU 共享调度等功能。这种能力对团队多人共用一个账号池的场景很重要否则训练任务之间互相抢机器实验效率会变得很低。判断一个平台“分布式训练支持”是不是真的我的土办法是先不看文档直接创建一个小规模多节点训练任务打印每个进程的 RANK、LOCAL_RANK、WORLD_SIZE看它们能否互相通信然后用torch.distributed.all_reduce跑一轮简单的梯度同步。能通再聊后面的优化不能通再好的宣传都没用。3.2 从 PyTorch DDP 到 DeepSpeed、Megatron-LM平台兼容性要放在实测里验证微调大模型时启动方式五花八门单机多卡用torchrun启动 DDP模型大了以后可能用 DeepSpeed 的 ZeRO 策略更大规模可能要上 Megatron-LM 的张量并行和流水线并行。平台层面对这些框架的兼容性会影响你训练初期的推进速度。首先是镜像环境。平台默认提供的 PyTorch 镜像是不是支持 CUDA 版本、NCCL 版本、Python 版本能不能直接跑起来你手上的训练脚本。很多平台都有 NVIDIA NGC 的 PyTorch 容器镜像这类镜像本身就是训练框架的黄金标准兼容性一般很好我建议优先选这种镜像而不是自己从头装。其次是共享文件系统。DeepSpeed 的 ZeRO 分片和 Checkpoint 保存机制需要把所有节点的状态写到一个共享目录平台挂载的存储是否支持并发写入、逐字节一致直接影响能不能跑起来。我遇到过一个云平台对象存储可以随意挂载但延迟很高DeepSpeed 在 Checkpoint 时会因为写入超时而失败最后不得不切到并行文件系统才解决。然后是启动器。有些平台会在容器里注入自己的分布式启动命令比如把torchrun包装一下自动注入环境变量。这种设计对新手很友好但对自定义训练脚本可能会有侵入性。如果你的训练框架非常新或者做了很多定制要确认平台封装的启动器对这些脚本没有破坏性改动。最好的验证方式永远是先跑一个 10 分钟的小规模任务。3.3 训练中断与容错备份最容易被忽视的“稳定性”指标训练一个 7B 模型动辄几小时甚至几天中途如果因为 GPU 故障、驱动报错、容器 OOM、网络抖动导致进程退出没有自动恢复机制就得人工介入重来。创业团队人少不可能 24 小时盯着训练日志。所以选平台时一定要看三点第一节点故障发生后平台能不能自动替换坏节点并重新拉起任务第二你的训练脚本能不能在重启后从最近一次 Checkpoint 继续训练第三日志和指标是否集中收集方便失败后快速定位。GPU 的故障其实比想象中频繁。尤其是跑大模型时显存压力高、算力负载大偶尔会遇到类似XID之类的硬件报错平台如果没做故障隔离整个训练任务都会崩掉。有些平台提供 GPU 健康检查机制在任务启动前自动检测坏卡把故障卡隔离出调度池这是很大的加分项。对创业团队来说训练稳定性的价值往往比硬件报价更重要。一次 16 卡训练任务的租金哪怕每小时几千块只要因为故障多失败一次浪费的金额就够买好几个月的稳定服务了。4. 海量存储不是“硬盘大”那么简单训练数据、Checkpoint 和日志的存储架构4.1 对象存储、并行文件系统、云盘各自的角色定位别指望一种存储通吃很多人觉得存储就是硬盘容量训练数据几百 GB 也好、十几个 TB 也好只要装得下就行。但训练场景对存储的要求是分层的不同类型的存储各有角色定位。存储类型典型产品形态优势劣势主要用途对象存储S3、OSS、COS容量近乎无限、成本低、生态兼容好延迟高、小文件读写慢长期保存原始数据、基线模型、训练产物并行文件系统Lustre、CPFS或云厂商的 AI 文件存储高吞吐、低延迟、多节点同时并发读写成本相对高、一般按容量和吞吐计费训练数据预处理产物、Checkpoint、共享代码目录云盘云主机系统盘、数据盘延迟最低、单机场景稳定无法被多节点高效并发读写本地临时缓存、日志、少量环境文件一条常见的错误路径是把几百 GB 甚至几 TB 的小文件直接放在对象存储里然后训练脚本用 PyTorch 的DataLoader一个一个读。这样做不是不能跑但会非常慢因为对象存储对大量小文件的列表操作和随机读延迟很高GPU 计算等数据的情况会非常严重。训练数据的正确流转方式应该是原始数据进对象存储长期保存预处理完成后的数据集格式尽可能打包成大文件放到并行文件系统上直接供训练任务访问Checkpoint 文件则高频写入并行文件系统同时定期异步备份到对象存储。这样每一类存储都发挥自己最擅长的能力。4.2 数据准备阶段的上传与预处理如何在训练前把数据流转做顺数据准备是微调项目里最容易被低估的一环。很多团队花了两天调模型却花了两周和几 TB 数据作斗争。首先是从本地上传数据到云平台。如果你的数据源在机房或本地服务器走公网传输会非常慢建议先用云平台的离线迁移设备或者专线把数据一次性搬到对象存储如果数据本来就在云上那直接基于对象存储做拷贝和版本管理会更方便。其次是做数据清洗和 Tokenization。训练词表切分、指令数据格式化、去重、过滤长度超限样本这些操作计算密集但不需要 GPU可以用批量 CPU 任务完成。处理好以后最好把数据打包成 WebDataset、Tar 包这类大文件格式或者使用像datasets库的流式加载模式减少对象存储的请求次数。预处理产物的放置位置我认为放在并行文件系统上最合适。训练时所有节点通过共享挂载访问同一个数据目录既方便分发也方便训练过程中实时调试数据问题。不要把预处理产物继续放在对象存储里否则每次训练都要重新拉取IO 开销会吃掉一截训练时间。4.3 Checkpoint 频繁保存策略小文件多、大文件大的混合场景怎么破大模型训练中Checkpoint 是一把双刃剑。不勤保存故障后损失大勤保存存储压力和写入时延又会拖慢训练节奏。常见的做法是每 N 个 step 保存一次保留最近几个版本的 Checkpoint。问题在于标准 PyTorch 保存方式是一个model.safetensors或pytorch_model.bin大文件加多个小的配置文件保存过程如果你直接在共享文件系统上写可能会因为文件数量多、元数据操作频繁而导致保存时间暴涨甚至阻塞训练进程。我的经验是先写到本地云盘保存完成后立刻异步同步到并行文件系统或者上传到对象存储。这样不阻塞训练主线程Checkpoint 丢失的概率也小很多。另一个优化方向是使用框架自带的异步 Checkpoint 能力比如 DeepSpeed 的torch.distributed.checkpoint或者 Hugging Face Trainer 的异步保存选项能显著减少保存对训练吞吐的影响。另外要有 Checkpoint 的版本目录规划。不要把所有 Checkpoint 都堆在高速存储上太费钱。只保留最近几个在高性能存储里做热备历史版本定期移到对象存储归档。训练结束后最终产出模型同样及时转存到对象存储释放昂贵的高速存储空间。5. 主流云平台的差异点不是所有“GPU 云”都适合干训练这活5.1 公有云大厂生态完整适合绝大多数创业团队像阿里云、华为云、腾讯云、火山引擎这类公有云大厂以及海外的 AWS、Azure、GCP最大的优势是“东西齐全”。训练要用的 GPU 实例、对象存储、并行文件系统、容器服务、日志监控、权限体系都是现成的而且之间做了很好的集成。比如阿里云 PAI 平台提供 DLC 容器训练服务可以配合 CPFS 高性能并行文件系统训练任务和数据存储能放在同一个可用区内网络延迟非常低。华为云 ModelArts 也提供整套训练作业管理配合 SFS Turbo 使用数据处理和训练环境比较顺滑。腾讯云 TI 平台在模型微调、自动学习方向也有完整链路。这类平台的共同特点是学习成本低遇到问题有大量文档和案例可以参考。公有云大厂还有一个隐性好处是账号体系、账单、审计、权限管理跟企业合规需求能直接对齐。创业团队规模变大之后多人协作时可以通过子账号、资源组、配额来实现成本隔离避免“一个项目把整个账号的预算花光”的场面。当然大厂平台也有缺点最明显是价格。按需实例单价高长期使用必须学会预留实例、竞价实例叠加的计费策略。另外平台封装层越多可控性反而越低遇到问题需要联系工单支持响应速度不一定赶得上训练中断造成的损失。5.2 专用 AI 算力平台和 GPU 租赁平台价格可能有优势但要自己掂量运维除了公有云现在还有很多专门做 GPU 租赁和 AI 算力的平台它们一般不提供完整的企业云生态而是更纯粹地卖“算力资源 基础调度”。这类平台的价格通常比公有云按需便宜不少因为它们的商业模式更聚焦运维成本相对低。对于训练脚本已经很成熟、只需要临时跑一批任务的团队来说这类平台可以作为资源补充。但风险也要讲清楚。专用算力平台的网络架构、存储方案往往相对单一你很难自己组合出“高性能并行文件系统 RDMA 网络 GPU 集群”的完整方案。如果你要做多机分布式训练要先确认它们是否开放了节点间的高速网络如果只是做单机微调这类平台确实很香。另外任务排队和稳定性也要实测。有些平台机器不多抢卡高峰期调度时间不可控有些平台设备故障率偏高又没有自动迁移机制。我的建议是把这类平台当成“备用算力池”不要让它成为唯一的训练基础设施。核心实验用主云平台弹性爆发或算力低谷拼价格时再走到这类平台。5.3 混合方案把存储和数据放在一处算力弹性扩展对有一定数据积累的团队来说比较理想的方案是数据主存储放在一个主云平台上算力可以在多个平台之间弹性调度。实现方式通常是让算力平台通过专线或者高速公网挂载主云平台的并行文件系统。但要注意如果训练节点和存储跨地域甚至跨云数据读取的延迟和带宽会成为新的瓶颈。训练任务对数据读取的依赖极其密集跨云读数据的速度往往比本地 IO 慢一个数量级。所以混合方案要设计好两个原则一是训练节点和存储尽量同地域或者通过云厂商之间的骨干互联来减少物理距离二是把训练中高频访问的数据预热到训练平台本地的缓存或高速存储里而不是每次都要从远端拉。混合方案更适合已经有了一定数据规模、成本和平台绑定意识比较强的团队。刚起步的创业团队我反而建议你先选一个主云平台把存储和计算放在一起让事情尽量简单等跑顺了再考虑成本优化。6. 从模型规模和数据量倒推选型一份能直接套用的估算方法6.1 先估算显存占用再决定单卡 LoRA 还是全参多卡不要先想“我要几张卡”先想“我要跑什么规模的模型、用什么微调方式”。以 7B 模型为例全参数微调的显存占用大致由四部分组成模型权重、梯度、优化器状态、激活值。其中模型权重按 FP16 算大概是 14GB7B × 2 字节梯度也是约 14GBAdam 优化器状态则比较夸张每个参数可能占用 12~16 字节合计约 84~112GB。光这三项加起来就上百 GB再加激活值单张 80GB 卡根本放不下必须靠多卡分片。如果用 LoRA 这类参数高效微调方法情况就完全不同了。基础模型权重仍然是 14GB 的 FP16 存量但额外训练的参数可能只有 0.1%~1%优化器状态和梯度的体量被压缩到几 GB 的量级。再加上激活值24GB 显存就能跑起来48GB 卡可以直接加大 Batch Size。所以第一步判断是如果你的业务只需要在开源底座模型上做领域适配LoRA、QLoRA 这类方式通常是率先尝试的因为它们对 GPU 实例的需求低单卡就能跑成本可控的同时迭代效率高如果确定要全参数微调那必须接受多卡、多机、高成本的基础设施开销。6.2 训练时长与成本的估算公式把预算表做在开机之前显存估算决定你要几张卡训练时长的估算决定了你要租多久。这里分享一个粗糙但实用的前向估算方法。训练 Transformer 模型的计算量大约可以用公式粗估总计算量 ≈ 6 × 模型参数量 × 训练 Token 数。这里 6 倍是前向和反向的大致常数实际还会受模型结构、Batch Size、序列长度影响但做预算足够了。举个例子7B 模型训练 5 亿 Token总计算量大约就是 6 × 7e9 × 5e8 ≈ 2.1e19 FLOPs。如果单卡 A100 的 BF16 峰值算力约 312 TFLOPs但分布式训练的长期有效利用率很难超过峰值的三四成按 100 TFLOPs 估算会比较现实。这样单卡跑完这个数据量大约需要 2.1e19 / 1e14 210000 秒差不多 58 个小时如果用 8 卡做数据并行理想情况下能压到 7 小时左右再算上通信损失和 Checkpoint 开销实际按 9~10 小时估计比较稳妥。把这个公式放在决定之前算你会很快知道自己需要多少卡时GPU Hour然后乘以单价就是一个清晰的成本预算。云平台的计费如果按秒或按小时乘上卡数就知道这一轮微调大概要烧多少钱。6.3 一个典型场景的决策路径7B 模型 LoRA 微调的实际走位假设你们产品需要做一个客服领域的意图分类模型底座选择 7B 开源模型训练数据大概有几十万条指令样本总 Token 数约 2 亿先尝试 LoRA 微调。这种情况下显存需求大概是基础模型 14GBFP16 LoRA 参数和优化器状态几 GB 激活值若干。单张 48GB 的 L40S 或者 40GB 的 A100 就够用。如果数据量不大用单机 8 卡可以做并行 LoRA 实验一次跑多组超参效率反而更高。再往后如果业务效果达标要扩数据到 20 亿 Token并且想全参数微调提升上限这时候费用才会明显上升。此时再切换到 8 卡 A100/H100 实例做全参数微调并用 DeepSpeed ZeRO 做分片压榨单机资源的利用率。等单机不够了你还是先考虑“单机 8 卡 × 2”的规模再往上就要评估多机 RDMA 网络的情况。这个路径说明微调选型最好不要一步到位买最大的配置而是先跟着模型实验的节奏走把 GPU 资源规模和数据量匹配起来。7. 真实踩坑记录从选型到上线我替你先交过的几笔学费7.1 只比“单卡价格”不看网络多机训练直接卡死有一段时间我在某个便宜平台开了 16 卡资源打算跑一个大规模微调。单卡价格比主流云便宜不少我还以为自己捡了便宜。结果任务一启动每轮迭代的时间比单机 8 卡还慢一大截GPU 利用率起不来一看nvidia-smi大量时间都花在等待梯度同步上。用nccl-tests测了一下跨节点 all_reduce 的带宽只有几十 Gbps远低于预期。这属于典型的“机器跨网段通信走普通以太网”的情况。平台宣传不会写出来但你大规模训练时立刻就能感受到。后来我学乖了选型前先做两项测试第一同一个可用区内能不能保证节点间走 RDMA第二直接跑一轮nccl-tests验证集合通信真实带宽。只比单卡价格不看网络多机训练早晚要交学费。7.2 存储选错类型训练读取数据变成了最大瓶颈还有一个项目数据量大概 2TB都是几十 KB 的小文件直接放在对象存储桶里。训练脚本用datasets流式读取一开始还能跑但数据分布不均匀时GPU 经常空转数据加载成为热点。后来我把数据预处理成 WebDataset 的大包格式放到云厂商的并行文件系统上再把训练节点挂载到同一个文件系统训练吞吐立刻上了一个台阶。存储选型的核心不是看容量而是看你的数据访问模式是什么。训练集要高频读、并发读就别用小文件对象存储硬扛。7.3 计费模式没看清休眠后的费用比训练时还吓人云平台最容易被忽略的成本陷阱之一是“关机不收费”假象。很多 GPU 实例支持关机释放计算资源但云盘、弹性公网 IP、快照这些附属资源仍然在计费。如果把训练数据全都放在实例的系统盘上关机后这些容量费用照样扣。更隐蔽的是对象存储的请求费用。有些数据读取脚本每次训练都会全量列目录百万级文件的对象列表请求非常贵。训练前把数据打包成大文件不只是为了数据加载快也是为了避免这种“看不见的账单”。还有一点抢占式实例便宜但如果被回收后自动续租逻辑写得不严谨可能变成反复创建、反复中断、反复计费最后账单比按需实例还吓人。7.4 分布式训练稳定性宁可先慢也要做 10 分钟稳定性测试大模型训练跑 10 分钟往往看不出问题跑两小时才最容易暴露硬件故障。GPU 在长时间高负载下散热不良、显存颗粒老化、驱动异常等问题都会浮现。平台是否做任务前健康检查训练中是否检测到坏卡并及时隔离重启往往决定了你的训练是顺利跑完还是反复横跳。我现在的习惯是任何新的平台、新的实例类型第一次都先用一个小模型跑一轮 10 到 15 分钟的稳定性测试同时观察 GPU 温度、NCCL 通信吞吐、日志是否集中可查。稳定性验证通过之后再上正式任务。这个流程看起来耽误了一点时间但相比训练中段崩掉再重启性价比高太多了。选型这件事说到底就是在给训练任务找一个可靠的家。好的 GPU 资源、好的分布式网络、好的存储架构三者必须同时成立才能让微调项目真正跑得起来、跑得稳。我从实践中得到的最大体会是不要轻易相信任何宣传话术把“网络是否通、存储是否贴身、故障后能否自愈”这三问测过一遍再决定要不要把训练任务搬过去。