我用 Rust 把语言模型从头训练了一遍，结果发现这路子目前还真走不通

最近在 arXiv 上看到一篇挺有意思的论文（arXiv:2609.25008v1），作者用 Rust 语言尝试了一次完全脱离 Python 和 PyTorch 的端到端语言模型预训练。他只花了 164 美元的 GPU 租赁费，独自一人搞定了整个流程，最后训练出了一个大约 0.4B 参数、侧重孟加拉语的模型。

虽然这听起来像是个硬核的技术秀，但作者给出的结论非常冷静：这仅仅是一次“成就展示”，而不是“实操建议”。如果你现在想把训练流程从 PyTorch 迁移到 Rust，看完他踩过的坑，你可能会冷静很多。

为什么说 Rust 目前不适合做模型训练

作者在实验中对比了目前 Rust 生态里最主流的两个机器学习框架：Candle 和 Burn。他发现这两个框架在处理“训练”任务时，都有一些极其隐蔽的致命缺陷。最恐怖的是，这些问题在普通的 Loss 曲线观察中完全看不出来，模型看起来训练得很正常，但实际上梯度早就坏了。

他总结出的问题清单如下：

• Candle 的缺陷（共 5 处）： 其中最严重的是融合算子（fused kernels）会导致梯度静默消失。也就是说，前向传播看起来没问题，但反向传播时这些算子根本不产生梯度，而 Loss 曲线依然会下降，误导你以为模型在学习。
• Burn 的缺陷（共 3 处）：

- 反向传播的吞吐量极低，只有理论 GPU 吞吐量的 3% 左右。 - 在处理百亿级参数规模时，其算子融合路径会导致训练中途直接发生段错误（segfault）。

为了抓出这些“隐形杀手”，作者不得不自己写了一套验证机制，叫作“梯度流仲裁器（gradient-flow arbiter）”。这个测试的核心逻辑很简单：跑一个完整的正向和反向传播，然后断言每一个可训练参数都必须接收到一个有限且非零的梯度。靠着这个方法，他才抓到了 6 个这种“静默失败”的 Bug。

孟加拉语 Tokenizer 里的“生育力陷阱”

除了框架底层的坑，作者在处理非英语语料时还遇到了一个非常隐蔽的 Tokenizer 问题，他称之为“Tokenizer-fertility trap”。

在处理孟加拉文字符时，如果使用朴素的字节级（byte-level）分词，会导致分词效率极低。作者实测发现，这种做法下孟加拉语的 Token 效率只有大约 1.4 个字符/Token，而英语可以达到 3.9 个字符/Token。这意味着，虽然语料库里语言比例看起来是平衡的，但由于分词效率的巨大差异，模型在计算量上其实被英语占据了主导，导致孟加拉语的学习信号被严重稀释。

他通过调整优化后，孟加拉语的效率提升到了 4.1 个字符/Token，这才算真正回归了语料的原始比例。

最终的实验数据和我的看法

这次实验的配置和结果其实非常清晰，大家可以对照一下：

• 硬件与耗时： 使用了一块租赁的 H100，总计训练时长约 54.6 小时。
• 数据量： 约 20 亿 Token。
• 模型表现： 0.4B 参数量。在孟加拉语建模上，其每 Token 的负对数似然（NLL）为 0.93，而随机初始化的对比组是 12.60。但在英语常识选择题上，它的表现仅仅是随机水平，这符合他故意把预算倾斜给孟加拉语的设计预期。

看完这篇报告，我的感觉是：Rust 在 AI 领域的生态正在分化。如果你是做推理（Inference）或者端侧部署（On-device serving），Rust 的内存安全和高性能绝对是利器；但如果你现在的目标是模型预训练或者大规模微调，现阶段还是老老实实待在 PyTorch 的怀抱里比较稳妥。

毕竟，谁也不想辛辛苦苦烧了几千美金的 GPU 算力，最后发现模型是在靠“错误的梯度”假装学习。