10T参数规模的大模型放在两年前还是实验室里不敢公开讨论的数字。现在它已经变成一个具体工程起点训练一个10T10万亿参数参数量级的语言模型无论目标是追赶还是超越当前最强前沿模型工程复杂度都与上一代百亿、千亿模型完全不同。围绕这个10T模型的话题行业真正关心的不只是“能不能做”而是“怎么做、成本多少、效果能到什么程度、训练遇到瓶颈时如何排查”。这篇博客从工程角度拆解10T模型涉及的架构设计、分布式训练、显存规划、数据与对齐问题并给出可复用的估算方法和配置示例。文章不会写成新闻评论而是聚焦到开发者能带走的技术清单如何估算显存和算力、如何组合并行策略、如何用小规模模型预演、如何排查分布式训练中的典型故障以及训练完成之后如何评估和对齐。1. 先理解10T参数模型到底意味着什么1.1 参数从1B到10T不只是数量变化大模型的参数量决定了两件最底层的事存储权重需要多少空间完成一次前向和后向传播需要多少计算量。先看存储。用FP16精度保存一个参数需要2字节10T参数的裸权重就是$$10 \times 10^{12} \times 2 20 , \text{TB}$$也就是说仅仅把10T模型权重放进显存就需要大约250张80GB显存的GPU。这还只是权重还没算梯度、优化器状态和激活值。如果使用Adam优化器参数、梯度和一阶/二阶动量通常需要额外的12字节每参数训练状态会膨胀到更夸张的量级。再看计算量。一个稠密Transformer模型的训练FLOPs大致可以估算为$$\text{FLOPs} \approx 6 \times N \times D$$其中N是参数量D是训练token总数。若10T模型训练5T token计算量约为$$6 \times 10^{13} \times 5 \times 10^{12} 3 \times 10^{26} , \text{FLOPs}$$一块目前主流的GPU每秒算力约 (10^{15}) FLOPsFP16/BF16算力单一GPU连续计算约需要 (3 \times 10^{11}) 秒也就是接近一万年。这个数字说明10T模型注定是超大规模集群才能完成的任务而且必须依赖并行策略。1.2 为什么单卡无法承载10T模型当前AI加速卡的显存主流在80GB左右部分专业卡可以达到192GB但相对于20TB权重仍然差着两个数量级。单卡无法承载10T模型直接原因是显存容量不够但深层原因是训练过程不是只放一份权重那么简单。训练时必须同时保存梯度、优化器状态和激活值。对于Adam优化器训练过程中每参数需要的显存远高于2字节。显存不够时系统会不断触发内存交换或直接OOM即使勉强运行也会因为频繁使用CPU内存或NVMe交换而慢到不可接受。这里常被误解的地方是参数多并不等于推理一定慢到不可用。MoE结构可以在推理时只激活一部分参数参数量大但激活参数可控但训练10T模型时不管激活多少专家优化器状态和全量参数存储仍然需要规划好。1.3 前沿实验室之间的竞争核心不是参数量而是效率当一个10T模型的标题把目标指向Anthropic这类前沿实验室时技术竞争的核心其实不是“谁的参数更大”而是同样的训练算力预算下谁的数据质量更高、损失收敛更快。同样的模型规模下谁的对齐和质量控制更可靠。同样的推理成本下谁能在延迟和吞吐之间取得更好平衡。所以想参与这个方向的人一开始就不应只盯着参数量。更应关注训练效率、数据配比、评估体系和对齐方法。这也是本文章节会同时覆盖训练前、训练中和训练后三个环节的原因。2. 训练10T模型需要重新设计的四层基础设施2.1 架构层MoE是10T模型的必然选择如果10T模型采用稠密Transformer每个token都要计算全部10T参数算力成本会高到几乎没有可操作性。因此大规模模型的共识是采用混合专家结构Mixture of ExpertsMoE。MoE的核心思路是把模型拆成多个专家子网络每个token只被分发到少数专家上计算。这样模型的总参数量可以很大但每个token实际经过的参数量可以控制在百亿或千亿级别这就是“稀疏激活”。在10T模型的架构设计中需要明确一组关键配置配置项作用典型值num_experts专家总数决定参数总量2048、4096或更高top_k每个token激活的专家数1或2expert_capacity每个专家处理的token上限动态或固定shared_expert是否设置共享专家常见做法是保留一个共享专家top_k的选择尤其重要。top_k1时通信量最小但路由压力大top_k2时模型更强但All-to-All通信量会翻倍。10T模型通常不会用单专家因为这会降低专家组合能力但具体选择需要根据训练吞吐实测确定。在训练框架中MoE层可以用类似下面的伪代码描述# 简化的MoE前向流程用于说明数据流 class MoELayer(nn.Module): def __init__(self, hidden_dim, num_experts, top_k): super().__init__() self.num_experts num_experts self.top_k top_k self.gate nn.Linear(hidden_dim, num_experts, biasFalse) self.experts nn.ModuleList([ nn.Sequential( nn.Linear(hidden_dim, hidden_dim * 4), nn.GELU(), nn.Linear(hidden_dim * 4, hidden_dim) ) for _ in range(num_experts) ]) def forward(self, x): # x形状: (batch_size, seq_len, hidden_dim) gate_logits self.gate(x) # 只保留top_k个专家的得分 top_k_weights, top_k_indices torch.topk(gate_logits, self.top_k, dim-1) top_k_weights torch.softmax(top_k_weights, dim-1) output torch.zeros_like(x) # 实际训练中这里会使用dispatch/combine实现而不是循环 for expert_id in range(self.num_experts): mask (top_k_indices expert_id).any(dim-1) if mask.any(): expert_input x[mask] output[mask] self.experts[expert_id](expert_input) return output这里要注意真实的分布式MoE不会用循环逐专家计算而是通过All-to-All将token分发到对应卡的专家上。上面的代码只用于理解数据流生产环境需要由DeepSpeed、Megatron或Tutel这类框架提供的MoE实现完成。2.2 并行策略DP、PP、TP、EP怎么组合10T模型训练不可能只用单一并行方式必须组合数据并行、流水线并行、张量并行和专家并行。四种并行方式的分工如下并行方式切分维度解决的瓶颈典型应用数据并行DP按数据batch切分提升吞吐量扩大并行规模几乎总是使用流水线并行PP按模型层切分降低单卡显存占用层数多的模型必需张量并行TP按矩阵维度切分降低单层显存和计算压力单机多卡适用专家并行EP按专家参数切分解决MoE专家数量过多问题MoE模型必需在10T场景中一个常见的策略组合是GPU节点内使用张量并行节点间使用流水线并行全局使用数据并行MoE专家则通过专家并行分布到多个节点。这种组合带来的复杂度不是简单相加的关系。张量并行会让通信量增加流水线并行会产生气泡专家并行会产生All-to-All通信风暴。因此10T模型的集群调度和网络拓扑设计往往比模型代码本身更关键。2.3 分布式框架配置示例DeepSpeed与Megatron当前训练10T级模型可以选择的工程框架主要包括DeepSpeed和Megatron-LM以及它们的融合版本Megatron-DeepSpeed。DeepSpeed在MoE和ZeRO优化上支持度高Megatron在张量并行和流水线并行上更成熟。下面是一个DeepSpeed配置的简化示例展示了10T模型会用到的基础优化能力。实际项目需要根据框架版本调整字段。{ train_batch_size: 2048, train_micro_batch_size_per_gpu: 1, gradient_accumulation_steps: 128, fp16: { enabled: true, loss_scale: 0, initial_scale_power: 32, loss_scale_window: 1000, hysteresis: 2, min_loss_scale: 1 }, zero_optimization: { stage: 3, offload_optimizer: { device: cpu, pin_memory: true }, offload_param: { device: cpu, pin_memory: true }, overlap_comm: true, contiguous_gradients: true, stage3_max_live_parameters: 1000000000, stage3_max_reuse_distance: 800000000 }, activation_checkpointing: { partition_activations: true, cpu_checkpointing: true, number_checkpoints: 100, synchronize_checkpoint_boundary: false }, moe: { enabled: true, num_experts: 2048, top_k: 2, expert_parallel_size: 64 }, aio: { block_size: 1048576, queue_depth: 32, thread_count: 16, single_submit: false, overlap_events: true } }这个配置里值得关注的点是gradient_accumulation_steps较高是因为10T模型单卡很难放大的micro batch必须通过累加凑足全局batch size。offload_optimizer和offload_param可以把优化器状态和参数放一部分到CPU或NVMe换取可训练规模。moe配置只有在使用支持MoE的DeepSpeed版本时才会生效不同版本的字段名差异很大。aio是异步I/O用于ZeRO-Infinity访问NVMe直接在CPU内存不够时使用。不过要特别提醒生产环境10T模型几乎不可能完全依赖CPU offload去训练因为offload会显著降低计算速度。这个配置更多用于中等规模模型预演而不是直接照搬到10T集群。2.4 硬件与网络跨卡跨节点的通信是真正的墙训练10T模型单卡显存和单机算力只是基础更关键的是集群网络拓扑。张量并行需要节点内高速通信NVLink是典型方案数据并行和流水线并行需要跨节点通信InfiniBand或RoCE是常见选择MoE的token分发则需要All-to-All通信能力这对网络拓扑高度敏感。如果网络带宽不足训练损失再多算力也发挥不出来。10T模型在MoE场景下每个batch的token都要在专家之间转移通信量可能达到GB级甚至TB级。一个经验法则是先用小规模压力测试测网络带宽再决定并行策略分配不要等大规模训练开始后才发现通信是瓶颈。3. 用算力与显存公式估算一个10T模型的最低门槛3.1 显存估算公式训练模型时显存占用可以粗略分成三块模型状态参数、梯度、优化器状态。激活值前向传播过程中保存的中间结果。临时缓冲区通信和计算中间数据。如果使用Adam优化器并采用FP16参数和梯度各占2字节每参数Adam一阶动量和二阶动量各占4字节每参数模型状态总计约12字节每参数。激活值则取决于序列长度、batch size、层数和隐藏维度。10T参数使用Adam时仅模型状态的显存需求约为$$10^{13} \times 12 , \text{字节} 120 , \text{TB}$$这已经超过几乎所有单机显存容量。因此必须通过张量并行、流水线并行和ZeRO状态切分把120TB拆分到成千上万张卡上。假设集群有4096张80GB GPU总显存约320TB模型状态占用约37.5%剩余空间还需要放激活值、临时变量和代码开销这样的利用率才算合理。3.2 数据量、token数与计算量的关系大模型训练数据规模有一个常被引用的经验法则训练token数大约是模型参数的20倍左右。这个结论来自Chinchilla论文强调计算最优的训练规模。按照这个比例10T参数模型需要$$10^{13} \times 20 200 , \text{T tokens}$$这个数据量非常庞大。当前公开数据集还很难支撑高质量200T token因此10T模型必须解决合成数据、数据去重、配比优化和高质量来源扩展问题。3.3 保守集群规模估算以下是一个粗略的工程估算表假设训练8B稠密模型与10T MoE模型的对比。这里不是官方数据只用于说明规模量级和选型参考。模型规模权重存储FP16Adam训练状态训练建议token数需要的集群量级1.8B3.6GB~21.6GB~40B单机多卡可完成70B140GB~840GB~1.4T几十到上百张卡1T MoE2TB左右~12TB~5T-20T数百到上千张卡10T MoE20TB左右~120TB~50T-200T数千张卡甚至更多需要注意MoE模型的总参数量虽然大但每个token激活的参数量有限。因此“需要多少算力”不完全由总参数决定更准确的计算要靠实际在训练中测量的TFLOPS和吞吐量决定。4. 从0到1的配置示例用8B小模型为10T做预演4.1 为什么先选8B模型10T模型无法在普通开发环境直接验证但训练过程中的很多机制可以用小模型预演显存优化、并行策略、日志监控、数据流水线、异常恢复。8B参数是一个合适的中间规模单机多卡可以训练又能暴露分布式训练的大部分问题。这里的目标不是复现10T而是把10T会用到的ZeRO-3、激活重计算、梯度累积、混合精度全部打开提前验证工具链和运维习惯。4.2 环境准备推荐使用如下环境实际项目要结合自己的CUDA版本和框架版本调整。Python 3.10PyTorch 2.xDeepSpeed 0.14Transformers 4.xCUDA 12.xGPU至少4张24GB以上显存卡安装基础依赖pip install torch deepspeed transformers datasets accelerate启动前检查GPU和通信库nvidia-smi python -c import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0)); import deepspeed; print(deepspeed.__version__)这一步的检查点torch.cuda.is_available()为Truedeepspeed能正常导入即可。如果卡在NCCL通信需要先检查网络和NCCL环境变量。4.3 DeepSpeed配置示例下面是一个用于小模型预演的DeepSpeed配置重点训练ZeRO-3和激活检查点。# ds_config.json { train_batch_size: 64, train_micro_batch_size_per_gpu: 1, gradient_accumulation_steps: 16, fp16: { enabled: true, loss_scale: 0, initial_scale_power: 32 }, zero_optimization: { stage: 3, offload_optimizer: { device: cpu, pin_memory: true }, overlap_comm: true, contiguous_gradients: true }, activation_checkpointing: { partition_activations: true, cpu_checkpointing: true }, wall_clock_breakdown: true }在这个配置中train_micro_batch_size_per_gpu设为1是为了在小显存下先跑通流程。gradient_accumulation_steps为16让全局batch达到64。wall_clock_breakdown开启后日志里会输出各阶段耗时方便判断瓶颈。4.4 训练脚本片段下面用一个基于Transformers和DeepSpeed的最小训练入口解释8B模型如何被加载和训练。import torch import deepspeed from transformers import AutoConfig, AutoModelForCausalLM, AutoTokenizer from datasets import load_dataset model_id meta-llama/Llama-2-7b-chat-hf config AutoConfig.from_pretrained(model_id) model AutoModelForCausalLM.from_pretrained(model_id) tokenizer AutoTokenizer.from_pretrained(model_id) # 准备一个很小的数据集 dataset load_dataset(json, data_filessample.jsonl)[train] def collate_fn(batch): texts [item[text] for item in batch] enc tokenizer(texts, truncationTrue, paddingTrue, max_length512, return_tensorspt) return enc model_engine, optimizer, dataloader, _ deepspeed.initialize( modelmodel, model_parametersmodel.parameters(), config_paramsds_config.json, training_datadataset, collate_fncollate_fn, ) for step, batch in enumerate(dataloader): batch {k: v.cuda() for k, v in batch.items()} outputs model_engine(**batch, labelsbatch[input_ids]) loss outputs.loss model_engine.backward(loss) model_engine.step() if step % 10 0: print(fstep {step}, loss {loss.item()})这段代码的关键点使用deepspeed.initialize接入DeepSpeed而不是自己写优化器循环。model_engine.step()负责梯度裁剪、参数更新和混合精度缩放。实际10T训练会引入更复杂的模型切分逻辑但执行入口仍然类似。生产环境的训练脚会比这个复杂得多但小规模预演的目是让团队熟悉这套入口和日志。4.5 启动命令与验证单机多卡启动命令deepspeed --num_gpus4 train_ds.py \ --deepspeed_config ds_config.json在日志中观察step数是否持续增长。loss是否逐下降。CPU offload是否产生大量swap导致吞吐骤降。wall_clock_breakdown里各阶段时间占比。如果loss正常下降说明训练管线基本打通如果loss不下降先检查数据加载是否正常、学习率是否过大、tokenizer是否匹配。这一步验证完成后再把并行策略、数据集和日志监控逐步替换成10T模型需要的版本。先让流程可控再扩大规模。4.6 如何扩展到千卡集群小规模预演的核心价值是暴露扩展问题。从4卡到千卡不能直接把--num_gpus改大就完事。需要检查数据加载是否成为瓶颈是否使用高性能数据流水线。通信库的NCCL环境变量如NCCL_IB_DISABLE、NCCL_SOCKET_IFNAME是否配置正确。检查点保存和恢复是否经过验证。训练失败时是否能从最近检查点快速恢复而不是从头开始。10T模型训练周期长中途失败是常态。没有可靠的检查点恢复机制一次断点可能造成数天算力浪费。5. 10T模型训练的三大瓶颈5.1 显存瓶颈ZeRO-Infinity、offload与激活重计算的权衡显存不足时优化手段通常有三种切分状态、下放状态、减少激活。它们各有代价。优化手段解决的问题代价适用场景ZeRO-3切分参数、梯度、优化器状态增加通信次数大规模集群Offload到CPU/NVMe扩展可用内存计算速度下降单机小规模或内存受限场景激活重计算不保存所有激活值增加前向重算时间任何显存不足场景在10T训练中ZeRO-3是基础激活重计算几乎必开但offload应该谨慎使用。全量offload到CPU会显著拉慢训练更好的做法是只offload优化器状态或参数并开启overlap_comm让通信和计算重叠。5.2 通信瓶颈All-to-All与梯度同步MoE模型训练时token需要被路由到不同节点上的专家这会触发大量All-to-All通信。通信量取决于专家数量、top_k、token数和专家排布方式。如果网络拓扑是每节点8卡专家并行度是64那么每个token可能在多个节点间传递。实践中常见问题是跨节点All-to-All导致带宽被打满。负载不均衡某些专家收到过多token。计算开始前一直在等待通信完成。缓解方法包括提高专家并行度但不超过节点边界减少跨节点通信。使用拓扑感知调度把常通信的专家放在同一节点内。开启overlap_comm让通信和计算并行执行。设置expert_capacity避免单个专家过载。5.3 稳定性和恢复loss尖峰、NaN/Inf与检查点10T模型训练过程中最常见的三类故障是训练若干步后出现loss尖峰然后无法恢复。梯度出现NaN或Inf导致参数更新失败。单卡故障导致整个任务中断。对应处理思路def safe_step(model_engine, loss): # 检测loss是否异常 if not torch.isfinite(loss): print(loss is non-finite, skip step) return model_engine.backward(loss) # 检查梯度 grad_norm model_engine.get_global_grad_norm() if grad_norm is not None and not torch.isfinite(grad_norm): print(grad norm is non-finite, skip step) model_engine.zero_grad() return model_engine.step()但更有效的做法是在超参数层面预防使用较小的初始学习率如1e-4量级。开启梯度裁剪max_grad_norm设为1.0左右。使用BF16或混合精度训练并设置合理的loss scale。定期保存检查点并验证检查点可以恢复。对于10T模型检查点保存本身也是一大挑战。20TB的模型权重即使分片保存也需要分钟级时间。建议使用异步保存、临时目录写完后原子替换防止检查点半写入导致恢复失败。6. 从训练完成到可用10T模型的评估、推理与对齐6.1 评估基准的选择和局限10T模型训练完成后不能只看训练集loss。评估需要覆盖多个维度评估维度常见基准目的局限语言能力MMLU、C-Eval知识广度和理解有数据污染风险推理能力GSM8K、MATH数学和逻辑难度分布不平衡代码能力HumanEval、MBPP生成可执行代码测试集可能出现在预训练数据中对齐安全红队测试、越狱测试判断输出是否安全合规需要持续更新10T模型的优势是记忆容量更大但记忆能力强并不等于推理能力强。数据混合比例和训练目标是评估差异的主要原因。评估环节要避免“单点依赖一个基准”。一个模型在MMLU上高1分但可能在真实任务上表现更差。参考做法是建立内部评测集并定期采样人工评估。6.2 推理部署量化、蒸馏、专家并行10T参数模型直接部署推理即使只有20TB权重也需要数十张GPU同时加载。这带来三个问题权重大、推理延迟高、成本高。常用手段包括量化将FP16权重量化为FP8、INT8甚至INT4。INT4可以把20TB权重压缩到约5TB但精度损失需要评估。蒸馏把10T模型知识迁移到更小的稠密模型或小MoE模型用于高并发场景。专家并行推理推理时也使用MoE路由只加载部分专家到显存或使用稀疏推理框架动态加载专家。在实际项目中10T模型通常不会直接面向所有用户。更常见的是用大模型离线生成高质量数据、跑批量审核再用小模型提供在线服务。6.3 安全对齐RLHF/DPO和红队测试为什么是必修课10T模型能力越强误输出被传播的风险也越高。安全对齐不能放到训练完成后才做而应该在数据过滤、训练过程和评估阶段都参与。安全对齐的工程方法包括数据层过滤有害内容、去隐私信息、做敏感词和语义标注。训练层通过指令微调和偏好优化让模型学会拒绝不当请求。评估层建立红队测试集反复测试边界场景。上线层加入输入过滤、输出审核和审计日志。对齐不是一次性工作。模型上线后还需要持续收集badcase、迭代训练和发布新版本。对于10T模型来说一次全量微调成本极高因此更常采用LoRA等参数高效微调技术在局部模块上做对齐更新。7. 常见问题排查与工程建议7.1 环境与配置检查清单在开始10T模型训练之前推荐按以下清单逐项确认[ ] 框架版本与CUDA版本是否匹配。[ ] 数据是否有去重和清洗。[ ] tokenizer词表是否与模型架构匹配。[ ] 并行策略组合是否经过小规模测试。[ ] NCCL环境变量是否明确配置。[ ] 网络带宽是否能在节点间支持All-to-All通信。[ ] 检查点保存路径和恢复脚本是否验证过。[ ] 监控面板能否看到GPU利用率、显存、温度、通信耗时。[ ] 训练中断时是否有自动告警和重启策略。[ ] 安全合规审查是否覆盖训练数据和模型输出。这份清单既适用于10T模型也适用于任何大规模分布式训练。清单的目的是把“看起来跑起来了”变成“每一步都经得起故障检验”。7.2 典型问题现象、原因和处理下面是分布式训练中常见的问题处理顺序通常是从输入检查开始再检查版本、路径、配置最后看日志和网络。问题现象常见原因检查方式处理建议任务启动后卡住不训练数据加载慢或NCCL等待看CPU和GPU利用率、网络流量先用单卡小batch确认训练脚本再逐步扩展loss不下降学习率过大或数据为空打印loss、检查数据长度降低学习率清洗数据增加warmup显存OOMmicro batch过大或激活未重算查看日志中的显存占用调小micro batch开启activation checkpointingloss出现NaN混合精度loss scale设置不当查看loss scale和梯度范数使用BF16增加梯度裁剪跳过非有限值多卡通信超时网络不稳定或NCCL变量错误查看dmesg和NCCL日志设置NCCL_IB_TIMEOUT检查网卡和防火墙MoE负载不均衡路由训练不够或capacity太小统计各专家token数调整expert_capacity或增加负载均衡损失检查点恢复后效果变差保存的权重不完整或恢复代码有误比较恢复前后loss保存优化器状态恢复时使用相同配置7.3 给个人和中小团队的建议10T模型不是个人开发者能够独立训练的。但个人和中小团队仍有很多事情可以参与研究MoE路由算法和专家负载均衡。优化数据去重、质量过滤和采样策略。在小模型上验证并行策略产出可复现的优化经验。参与推理引擎的稀疏推理优化。针对特定垂直领域做小模型微调和对齐。技术积累不必从10T开始。8B、70B、1T MoE这几个量级的工程经验会自然帮助你理解10T模型的瓶颈在哪里。8. 最佳实践与下一步方向8.1 建立可观测和自动恢复体系10T模型训练是长时间运行工程系统不是一次性的脚本任务。最值得投入的工程能力有三块指标监控记录GPU利用率、显存使用、通信时间、吞吐量、loss均值、梯度范数。日志采集按step、epoch、节点维度保存日志支持快速检索和告警。自动恢复训练任务失败后自动重启并加载最近检查点检查点保存采用原子写入避免半文件。好的监控体系能让你在故障发生前提前介入而不是等丢失大量算力后才追溯原因。8.2 学习路径推荐如果目标是参与10T模型训练建议按这个顺序进阶熟练掌握PyTorch和Transformers的模型定义与训练循环。在多卡环境跑通DeepSpeed ZeRO-2和ZeRO-3。理解Megatron的张量并行和流水线并行原理。在小规模MoE模型上实验观察路由和负载均衡。学习集群调度和网络调优理解通信对训练的影响。参与评估、微调、对齐和推理部署形成全链路经验。每一步都要留下可复现的配置和踩坑记录这些积累比只读论文更重要。8.3 关于10T模型的现实判断10T参数模型不是简单的“再加几千张卡就能训”。它要求团队同时具备数据工程、分布式系统、架构设计、稳定训练、评估对齐和部署优化能力。任何一个环节出问题都可能让前期投入变成沉没成本。如果你所在团队或项目准备朝这个方向推进建议先从一个明确的小目标开始训好一个8B模型把数据流水线、训练稳定性、检查点恢复、评估体系全部打通再逐步扩大参数规模和专家数量。工程问题会在小规模下暴露得足够明显处理成本也低得多。10T模型的最终价值不在于“参数世界第一”而在于相同成本下能不能获得更好的推理能力、更低的部署成本、更可控的模型行为。也就是说能够持续迭代和稳定运行的大规模训练体系才是真正值得长期建设的技术底座。