radixark/miles · 标签视图

文档勾选 Modal 支持 Harbor 路径，附 B200 实测结论

值得花几分钟读，但重点不在 diff（只有一行），而在 PR 描述里的两个工程信号：一是该仓库把“能力矩阵填 ✓”的举证责任放在人工运行记录上，若继续沿用，建议后续给表格补证据链接或在 provider 参数化的 e2e 上加定期跑批，否则表格会逐渐失真；二是 B200 上 `--sglang-attention-backend triton` 这一 workaround 值得单独沉淀——要么进 sglang_args 默认值并加硬件判断，要么在文档中显式标注前置条件，避免每个 Blackwell 用户重复排查首次 prefill 崩溃。若你的关注点是 Harbor × Modal 的可用性结论，请直接联系作者确认运行前提（attention backend、模型 head_dim）。

为所有 CUDA 测试注册声明支持的 GPU 世代（hopper/blackwell），为后续硬件感知调度铺路。

本 PR 是 CI 基础设施的一次重要重构，虽然不改变运行时行为，但为硬件感知的 CI 调度奠定了坚实的基础。建议精读 `tests/ci/ci_register.py` 中的 `_check_cuda_hardware` 方法和 `tests/ci/hardware.py` 的设计，理解其如何通过架构词汇表、自动调度和严格校验来保证元数据的完整性。该设计值得在类似需要声明资源能力的 CI 系统中借鉴。

新增 stage-c-8-gpu-b200，接入 8×B200 CI runner

值得快速精读。虽然单看只是注册表加一行 + 一个 workflow job，但其中蕴含两个可复用的 CI 设计原则：一是「测试自声明 GPU 预算（ray start --num-gpus / torchrun --nproc-per-node）而不是读取可见设备」，这让不分区主机的资源分配语义清晰；二是「合入时零测试注册是安全的，因为空 stage 收集零测试并退出 0」，支撑了增量迁移的分步落地。对参与 CI 基础设施维护的工程师，建议重点关注 pr-test.yml 中 job 注释与 tests/ci/run_suite.py 的 suite 注释，这两处把「为什么这么设计」讲得最清楚。

--hardware 自动探测节点并推导 GPU 数

值得精读：它展示了如何把分散在 19 个脚本里的机器假设收敛为单一事实来源，并用「替换前字面量一致性核对 + 快照不变 + pin 机制」三重手段保证行为不漂移。最值得学习的两点：resolve_hardware() 用 typing.get_args 反射字段 Literal 做显式校验，避免 match 静默穿透；测试用 _fake_torch 在无 GPU runner 上完整覆盖硬件探测矩阵。合并前建议在 B300/GB300/H200 实机各跑一次探测。

Qwen3.8-2.4T 训练 recipe 文档化，替换 PR 占位 stub

对计划在 GB300 上跑 Qwen3.8-2.4T-A95B LoRA RL 的工程师：值得精读，§6.2 的 NCCL 版本坑与 §6.4 的交替备份内存预算属于实测得出的硬经验。对文档维护者：注意本文档与 #2488 的强耦合，建议在 #2488 合并时同步 review 本文档。值得关注的设计决策是「任意时刻恰好一边持有 host backup」的内存预算推演，以及用 `zero_copy=True` 避免 clone 备份膨胀 malloc arena 的做法。

镜像钉死 cutlass-dsl 4.6.2 与 flashinfer 0.6.15.post1，修复 B300 训练挂起

值得精读。虽然只是单文件 Dockerfile 改动，但它演示了一套高价值的镜像依赖治理模式：区分"元数据版本"与"实际加载 runtime"、用 force-reinstall + 构建时断言锁定镜像、基于上游回归链（sglang#31625 → #31927）谨慎选择修复版本。对负责镜像构建、发布流程以及 Blackwell/B300 训练基础设施的工程师尤其有参考价值。

补齐 H200/B200/B300 的每节点 GPU 数映射

值得快速合并（已合并）。这个修复解除了真实的启动阻断，但属于防御性薄弱的小改动。建议后续为 `NUM_GPUS_OF_HARDWARE` 补充单元测试，或与 `GENERATION_HARDWARE` 合并维护，避免同源字段不同步。