晨问 2026年10月13日

一、提问

1. AMD 多卡训练为什么反而比 NVIDIA 单卡还慢？

前两天我一直在折腾一个模型的分布式训练。

原来是在 NVIDIA 单卡上跑的，速度其实还挺快，一次迭代大概 3 秒。

后面换到了 AMD 多卡，想着多张卡一起训练，速度应该会更好一些吧。

结果跑起来之后，发现一次迭代竟然要 9 秒左右。

这就挺奇怪的。

而且显存占用也有点让我想不通。

我看官方的训练配置，Batch 12 的时候，显存好像还有不少余量，可能在 40G 左右。

但我自己现在 Batch 才 5，显存就已经到了 46G 左右。

我用的是 BF16，单张卡有 96G 显存，模型本身也放得下。

所以我就在想，这种情况下，到底有没有必要用 FSDP 做分片？

因为我原来单卡的训练速度其实挺好的，现在弄了分布式，反而感觉还不如之前。

中间也试过图编译，想着能不能把训练速度再提上去。

结果 AMD 这边先是遇到编译报错，后面调整了注意力计算的实现，虽然不报错了，但编译等了十几二十分钟都没什么进展，还生成了大量文件。

所以现在我也有点拿不准，到底是模型实现跟官方有差别，还是分布式训练、编译这些地方没弄对。

毕竟这几天已经花了挺多时间把训练跑通了，但这个效率确实有点低。

AMD 多卡训练为什么会比原来的 NVIDIA 单卡还慢，甚至 Batch 更小，显存占用却更高？

这种情况应该优先从模型实现、分布式通信，还是注意力计算和编译这几个地方去定位？

---

2. 50 个任务的训练，为什么光是扫描轨迹就这么费时间？

这两天我在弄一个 50 个任务的训练流程。

我想的是，先让这 50 个任务都走一遍，看看基础效果，然后再决定后面的训练策略。

但真正跑起来之后，发现光是前面的任务扫描、样本扫描，就有一大堆东西要处理。

比如每个任务要拿几条轨迹来评估，有些轨迹是上千帧的。

我后来去对比了一下原来的开环评测，发现它会按大概 50 帧采一帧的方式来处理。

这样一条一千多帧的轨迹，最后可能就剩十几二十帧。

但我现在又希望采出来的样本有一定的信息密度，所以不能直接照着原来的方式来。

结果数据量就上去了。

有一次光处理这些东西就花了差不多两个小时，而且当时已经考虑用多张卡分开计算了。

后面我又把任务扫描、样本难度扫描这些逻辑重新弄了一遍。

大概就是每张卡分到不同的轨迹，抽帧之后做模型推理，再算出对应的误差或者分数。

样本难度这一块，还会用到 GMSE 相关的指标，后面再调整不同任务的采样概率。

不过改着改着，又发现一些重复计算的问题。

比如前面已经扫描过任务，后面还有验证用的轨迹；有些地方看起来重复了，但想清楚后又发现，它们可能是为了比较训练前后的效果，确实有用途。

这就挺麻烦的。

因为我一方面想让样本扫描尽量准确，另一方面又不想每次训练都在这些扫描上花大量时间。

而且多卡分发也不简单，前面就出现过每张卡都拿到相同任务的情况。

所以我现在也还在一点点检查整个流程。

像这种 50 个任务、每个任务又有多条长轨迹的训练，任务扫描和样本评估到底应该怎么做，才能既保留有用的信息，又不让计算时间太长？

抽帧、重复验证和多卡分配这些地方，应该怎么取舍才比较合适？

---

3. 明明和 AI Agent 讨论好了方案，为什么它改代码还是会改错？

这两天我一直在用 Coding Agent 改一个分布式训练项目。

改着改着，发现一个挺麻烦的问题。

就是它其实很能写代码，很多功能跟它说一下，它就能帮我实现。

但有时候它理解的逻辑跟我要的根本不是一回事。

比如我让它把不同任务的轨迹分配到不同显卡上，让每张卡处理自己那部分数据。

结果这个事情就反复搞错。

有时候它会把同样的任务分到每一张卡上，看起来是多卡计算了，但实际上每张卡都在重复做一样的事情。

所以我后面就发现，不能直接告诉它需求，然后让它开始改。

我得先跟它讨论清楚。

先让它理解我要什么，确定整个逻辑，然后它再去找代码、检查相关的地方，看看方案是不是对的。

这个过程其实会花挺多时间。

但就算前面讨论好了，真正开始改的时候，我还是会有点担心。

因为它可能修好了 ABC，又把 EFG 给改坏了。

所以我又想到，改代码之前，最好先让它把要动的地方都列出来。

告诉我原来是什么逻辑、准备改成什么逻辑，必要的时候直接把前后的代码拿出来对比。

不过说实话，搞得很累的时候，我也不会每次都仔细看它改了什么。

太麻烦了，没那么多精力。

而且 Agent 有时候自己想出的办法还挺好的。

比如我原来没特别说轨迹怎么抽样，它自己用了窗口移动的方式，而不是随机抽样，这个思路我就觉得不错。

所以我也不想把它所有的决定都限制死。

现在比较困惑的就是，这个度到底怎么把握。

明明已经和 AI Agent 讨论清楚了方案，为什么它真正改代码时还是可能理解错、改错，甚至把其他功能弄坏？

到底应该把多少工作放在改代码之前的讨论里，又应该怎么检查它的修改，才不至于每次都要人工从头看一遍？

---

4. 模型已经存成 DCP 和 HF 了，继续训练时怎么恢复之前的任务进度？

这两天在弄训练任务调度的时候，我突然想到一个比较重要的问题。

我现在训练的是 50 个任务，不是所有任务一直平均地训练。

有些任务可能已经 pass 了，有些任务已经耗尽了，还有一些任务是没有尝试过的。

训练的时候，会根据这些状态去挑选后面的任务，再决定要采哪些数据。

但我就在想，如果这一轮训练结束了，下一次再接着训练，这些状态怎么办？

因为模型本身是可以存档的，现在涉及 DCP 和 HF 这两种模型存档产物。

至于优化器、梯度这些参数，我倒不是特别在意。

就算重新来，重新学，我觉得也还好。

但任务状态不一样。

比如已经通过了 15 个任务，那下一轮训练的时候，剩下的任务应该怎么扫描、怎么挑选，肯定跟最开始不一样。

如果这些信息没有记录，后面是不是又得从头判断？

所以我当时就在想，是不是还需要一个文档，专门记录每个任务当前的状态。

下次训练的时候，如果传了这个文档，就按原来的任务状态继续。

如果没传，那就按默认的流程开始。

但这个具体逻辑我还没有完全检查清楚。

包括现在候选任务是怎么选出来的，已经处理过的任务后面会不会减少扫描，这些我都还要去看代码。

像这种会动态挑选任务的训练流程，模型已经保存成 DCP 和 HF 之后，应该怎么把之前的任务状态也恢复过来？

这些通过、耗尽、未尝试的记录，放在模型存档里比较合适，还是单独用一个状态文件来管理？

---

二、想法与点子

1. 训练项目不光要存 Git 代码，还要把数据和运行环境一起存档，避免服务器出问题后重新折腾。

10 月 11 日早上本来要看训练效果，没想到服务器上的东西直接没了。

还好前一天有 Git 记录，代码算是保住了。

但光是重新传数据、解压，就花了差不多两个小时。

所以后面还是得把环境和数据也存好，最好能留一份镜像。这样下次真的出问题，至少不用什么东西都重新搞。

建议去向： 知乎想法

---

2. 任务扫描和样本扫描应该分别做缓存，模型和采样逻辑没变，就没必要因为无关的代码改动全部重算。

现在每次调试，光是模型加载就要两分钟，任务扫描、样本扫描又得花几分钟。

这几个加起来，每次测试的成本就很高。

原来还用了指纹机制，源码一改，可能缓存就要重新算。

但我想的是，只要模型没变、扫描和采样的逻辑没变，那这些东西其实就没必要重算。直接保留对应的缓存地址，后面再读取就好了。

建议去向： 知乎想法

---

3. 50 个任务先跑一轮基础训练，定期评估各任务的成功率，再根据表现调整样本采样概率。

现在最关键的还是先把 50 个任务的基础效果跑出来。

训练过程中可以每 50 步评估一次，每 100 步重新调整一下数据采样的概率。

这样就能看到不同任务到底学得怎么样，再决定后面哪些任务需要更多样本。

至于最终有没有效果，还是得等第一阶段训练出来，先看实际的成功率。

建议去向： 知乎想法

---

4. 可以尝试让模型在训练时看到更多未来信息，甚至完整的动作轨迹，再比较不同方式对学习效果的影响。

昨天想到一个训练策略。

我感觉模型能学会一些事情，可能跟它能看到后面要做什么有关系。

所以就想到，能不能参考之前世界模型那类思路，让它看到更多未来的信息。

最好是能看到更完整的动作轨迹，相当于一部分是接下来要做的动作，一部分是整体的动作过程。

这样就有点像不同的教学方式。

我觉得可能对学习有帮助，不过这个已经涉及模型算法层面的改动了，还是得先把当前训练阶段跑出来再说。

建议去向： 待验证的点子

---

5. 把和 Coding Agent 反复确认的需求、修改原则和开发流程做成 Skill，让它换了会话也能按同一套规则做事。

前面用 OpenCode 的时候，我没有特别考虑把自己的开发经验整理成 Skill。

现在发现有些事情是反复出现的。

比如先把需求和方案讨论清楚，再让 Agent 去找代码验证；确认了之后才开始修改，最后测试、提交代码、更新文档。

这些流程其实可以固定下来。

尤其是那些经常容易理解错的地方，或者跨会话之后需要重新解释的经验，都可以放进去，不用每次从头讲。

建议去向： 文章选题

---

6. Agent 写出来的代码可以先保证流程跑通，再逐步封装和分包，同时补好 README，方便后面继续维护。

AI 写代码的时候，有时候会偏向于把很多东西直接平铺出来。

一开始这样确实快。

但功能越来越多之后，再去找某个东西，就得看一大堆代码，对人来说也不方便。

所以我的想法是，前面先把逻辑跑通，后面再一点点整理架构。

该封装就封装，该分包就分包。README 也可以先写好当前的目录说明，让人和 Agent 都更容易找到对应的代码。

建议去向： 知乎想法

---

7. 训练程序启动一次成本很高，应该尽量在同一轮测试里发现多个 Bug，集中修改，而不是每修一个就重新跑。

现在调试训练程序，启动一次就得加载模型、扫描任务、处理样本。

如果每发现一个 bug，就只改这一个，然后重新跑一遍，那真的挺费时间。

就像一个学生每次找老师只问一个问题，问完回去，过一会儿又跑过来问。

我更想要的是，一次把能检查的地方多检查一下，发现的问题尽量集中处理。

这样也能少花一点时间在反复启动和等待上。

建议去向： 知乎想法

---

8. TensorBoard 用来看训练指标的历史变化，再做一个实时仪表盘，专门看当前训练步数、任务通过情况和 GMSE 等数据。

前面在弄训练监控的时候，才发现仪表盘这个东西还挺方便的。

TensorBoard 能看训练指标的历史变化。

但我在训练的时候，更想直接看到当前是什么情况。

比如现在训练到多少步、通过了多少个任务、某个任务之前的 GMSE 怎么变化。

这些数据如果能直接从训练过程里取出来，放在一个仪表盘上，看起来就很清楚。

建议去向： 知乎想法

---

9. 先把 50 个任务的基础训练和评估跑通，拿到实际成功率，做出能展示的作品，再继续优化模型。

现在时间其实挺紧的。

10 月 11 日的时候就在想，距离要交付作品已经没有多少天了，这一周必须得发。

但目前连基础要求都还没有完全达到，很多时候只是单任务测试。

所以我觉得还是得先把第一轮训练跑完，看看 50 个任务整体能达到什么成功率。

先把基本的效果做出来，再用单卡做评估，能拿到一份可以展示的结果。

至于样本优化、推理策略、模型算法这些东西，后面再慢慢改。

现在最重要的是先让它真正训出来。