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 优先级）在最终实现里是否真的闭环。