radixark/miles · 标签视图

新增 Tinker 网关示例启动器、SDK 客户端与网关测试套件

值得精读，但建议带着「契约而非实现」的视角读三处：examples/multi_lora/serve_qwen3_30b_a3b_tinker.py（单节点 8 卡的资源切分与参数分组，是复刻其它模型的模板）、miles/tinker/arguments.py（Tinker 能力边界被写死在这里，扩模型族必看）、tests/fast/tinker/core/test_service.py 与 harness.py（checkpoint 版本化、租户隔离、失败隔离的对外承诺都在这些断言里）。值得关注的设计决策有：把上游 tinker-cookbook 当作 wire contract 的验收标准；用 test_layering.py 以导入图约束 core/runtime/server 分层；sampler 保存走不可变目录并支持 pinned version 解析。注意三点：本 PR 无逐行人工评审（批准来自共同作者），如需信任请自行核对最终 tree；run_id 每次调用生成导致重启后旧 checkpoint 路径不可达，长跑场景务必显式固定；IO 失败终止整个网关的策略是否可接受，建议结合业务 SLA 单独评估。

新增 Tinker 网关运行时与 serve 入口

值得精读，是本轮 multi-LoRA v2 栈中最靠近「真实执行链路」的一篇。阅读顺序建议：先看 `miles/tinker/runtime.py` 的 `_pad_to_dp_multiple` / `_build_train_data` / `_execute_batch` 三件套，理解 datum 契约与 `sample_index` 重组规则；再看 `serve_tinker.py` 的 `serve()`，重点体会任务监督（`asyncio.wait(FIRST_COMPLETED)`）、dispose 顺序与 `GatewayConfig` 的推导；最后扫 `miles/utils/arguments.py` 的 entry 维度，确认对既有 train 入口没有隐性行为回归。需要重点关注的设计决策有四条：训练命令经 object store 传递并让 worker 自行按 DP 切分、用零掩码副本做 DP 补齐、显式失败透传与未知失败终止网关的失败分类边界、以及 `NaN` / `MASK_LOGPROB` 的 wire 约定。建议精读时反向确认 `TrainerCell.execute(kill_on_failure=True)` 与 Tinker 服务错误分类是否已完全对齐，并确认 `_build_train_data` 依赖首条 datum 探测可选键的假设在真实 SDK 用法下是否成立。

新增 Tinker 网关协议层与每模型调度器，纯进程内无 runtime 依赖

值得精读，尤其是三处：core/service.py 的失败分级与 _close_model 的 slot quarantine 语义、core/scheduler.py 的“arrival 选 seed + pack_key 打包 + optim barrier 合并”三件套、以及 review 线程本身——它展示了一个很典型的踩坑模式：给外部 SDK 写服务端时，request_id 必须由 SDK 的 (session/seq) 幂等键派生，自己随机生成的 id 在客户端重试下必然重复占资源。阅读时建议对照 #2845 的 runtime 接线和 #2849 的测试，确认 review 中“Non-blocking”的几条（完整 outcome map 校验、loss_fn_config_v2 优先级）在最终实现里是否真的闭环。

新增 LoRA 适配器不可变磁盘快照发布路径

值得精读。三个最值得关注的设计点：一是 joyliu-q 发现的生成器惰性求值 bug 及其修复方式（把循环变量改为函数形参绑定，而非依赖 `itertools.chain` 的求值时机），这是 Python 里极易复现的陷阱；二是 `materialize_adapter` 的集合通信契约——所有 rank 必须走同一路径、只有 writer 产出数据；三是 staged-push 被整体删除后，失败与重试语义转移到了哪里（#2845 的 runtime 与 SGLang on-demand loading），以及删除 `slot_lora_name` 后全仓引用是否已清理。如果所在团队还在用旧的多 LoRA push 行为，需要先确认配置不再显式设置 `update_weights`/`model_path`。

单文件 CI 改从 PR 快照解析标签白名单，解除 /rerun-test 阻塞

值得精读，尤其是需要在 CI 中处理不可信输入的同学。重点看两处设计决策：一是 `_read_snapshot_labels()` 用 AST 字面量解析 + symlink 拒收 + 单次定义校验来“读快照而不 import”，这是 fork PR 场景下读取配置的通用范式；二是 `ci_register.py` 用默认参数注入白名单，把行为变更收敛在 file-run 一条路径上，最小化回归面。阅读时可一并追问三点：(a) 是否补 `tests/ci/test/test_file_run.py` 覆盖 symlink/重复定义/非字面量 dict 的错误分支；(b) cwd 契约是否改为显式传入 `labels_path` 更稳妥；(c) 是否需要在文档或注释里固化 `KNOWN_LABELS` 的写法约定。总体属于低风险、高收益的小修补，可放心合并。

纯 SFT train-only 复用 EvalDispatcher 支持 checkpoint 快照评估

值得精读。三个设计决策值得关注：一是“复用现有 EvalDispatcher 而非新增 train-only 专用路径”，避免平行实现漂移；二是把引擎启动决策派生为 args 上的单一字段，删除散落在 sglang_config/specs/controller 里的多处短路，降低不一致风险；三是用“显式校验 + 强制 3 个 eval 点的 e2e”代替静默跳过，任何短路都会让 CI 失败。后续 3 个修复 commit（resume id、final force、router sizing）展示了边界条件的排查思路，可作为同类接入的参考。

CPU-only PR 跳过 CUDA/ROCm 镜像准备

值得精读。该 PR 展示了 CI 门控设计中「需求推导」与「复用现有 gate」的平衡，尤其是 diff 缺失时保留 runnable 语义的修复，以及提交历史中「先扩展输出、后回退为复用条件」的演进过程，对理解 milos CI 策略的 stage 选择模型很有帮助。关注 `tests/ci/ci_policy.py` 的 `_write_github_outputs` 与 `tests/ci/stage_selection.py` 的 `select_skipped_gpu_stages` 两处核心逻辑即可。

补齐 AMD 平台 Qwen3-4B LoRA RL 启动器

值得精读。若团队需要维护或扩展 AMD / ROCm 上的 LoRA RL 训练，这是当前唯一入口；其「平台差异收敛在启动器层」的做法——环境变量桥接（HIP → CUDA 可见设备）、SGLang Triton 后端固定、以及「配方 + 快照 + 文档」三件套的组织方式——是值得复用的模式。验证数据（logprob 差、KL、截断率、AIME 趋势）可作为后续 AMD 训练健康度对比的参考基线，但不应据此断言训练收益。