企业官网建设流程全解析

一个初创团队要动大模型微调，最先被问住的问题通常不是“用哪个框架”，而是“把训练放到哪”。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 系列友好，微调中等规模模型是性价比很高的选择。

显存大小决定你能装下多大的模型和多长的序列。同样一张 A100，40GB 和 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 也好，只要装得下就行。但训练场景对存储的要求是分层的，不同类型的存储各有角色定位。

一条常见的错误路径是：把几百 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 算大概是 14GB（7B × 2 字节）；梯度也是约 14GB；Adam 优化器状态则比较夸张，每个参数可能占用 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 微调。

这种情况下，显存需求大概是：基础模型 14GB（FP16）+ 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 资源、好的分布式网络、好的存储架构，三者必须同时成立，才能让微调项目真正跑得起来、跑得稳。我从实践中得到的最大体会是：不要轻易相信任何宣传话术，把“网络是否通、存储是否贴身、故障后能否自愈”这三问测过一遍，再决定要不要把训练任务搬过去。