radixark/miles

将 GPU 偏移量和卸载决策从运行时移入 SGLang 配置解析，简化启动逻辑。

**值得精读**。本 PR 是模块化重构的典范，清晰地展示了如何将横切关注点（如 GPU 偏移、offload 决策）从主业务流中剥离，并内聚到专门的配置解析模块。其引入的 `_MutableBox` 模式（用于跨函数累加状态）和详尽的测试策略（特别是针对配置逻辑的各种边缘场景）值得学习和借鉴。对于理解 Miles 系统中推理引擎的部署配置流程，以及近期重构系列（#1837）的设计思路，这是一个关键的参考点。

将 SGLang 解析配置模型从可变 dataclass 迁移为不可变 Pydantic 模型，提升类型安全与不变性。

此 PR 是一个高质量的架构性重构，值得精读。建议关注以下设计决策： 1. **不可变模型的选择**：从 dataclass 迁移到 `FrozenStrictBaseModel`，如何平衡验证、不可变性和代码简洁性。 2. **解析模式的转变**：将 `resolve` 从修改自身状态的实例方法改为返回新对象的类方法，这种“数据转换”模式如何简化了配置生成与消费的逻辑。 3. **错误处理的强化**：利用 Pydantic 的字段约束替代运行时断言，如何更早、更清晰地捕获配置错误（如零值 GPU）。 这是理解该项目配置系统重构方向的关键提交，其模式可能被后续重构沿用。

将 SGLang 配置解析重构为基于 Pydantic 模型的声明式验证，替代手写解析逻辑。

该 PR 是一个高质量的重构，值得精读。其核心价值在于展示了如何利用 Pydantic 模型优雅地替代手写的配置验证逻辑，从而提高代码的声明性、安全性和可测试性。作为 #1837 大型重构的一部分，它清晰地完成了“引入原始模型”这一步骤，为后续优化奠定了基础。关注其“两阶段配置”（原始 vs 解析）的设计模式，以及如何利用 Pydantic 的 `AliasChoices` 实现字段别名，这些决策对类似的配置管理任务有很好的借鉴意义。

将 SGLang 配置的解析从运行时循环提前到启动入口点，确保配置在路由器启动前完全解析。

本 PR 是一个高质量的架构重构，值得精读。它展示了一个常见的代码异味（配置解析散落在启动流程各处）及其优雅的解决方案（将其集中到专门的解析函数中）。虽然改动小，但其设计决策——**将配置的完整构建视为一个原子操作**——对于维护大型分布式系统的启动逻辑具有普遍借鉴意义。审核者 guapisolo 的评论精炼地总结了其价值，可以作为理解此类重构收益的范例。

为 SGLang 配置解析添加单元测试，通过 `resolve_sglang_config` 入口覆盖关键行为基线。

该 PR 是重构序列的重要前置，值得快速浏览以了解测试覆盖点。关注新增测试类（如 `TestYamlShapeValidation`）和迁移策略（从内部类到公共 API），这对理解后续重构的约束有价值。

将 SGLang 配置解析逻辑从 rollout_server.py 移入 sglang_config.py，完成职责分离。

此 PR 是一个清晰、小规模的模块化重构，值得精读以理解其设计思路。主要关注点是职责分离的合理性：将配置解析（构建数据结构）与服务器启动（使用数据结构）分开，是良好的软件设计实践。它展示了如何在复杂的系统中逐步整理代码结构，为后续更复杂的重构（如 issue #1837 中的其他项）奠定基础。

引入 `RayWorkerManager` 骨架与工作器规格入口，为统一工作器生命周期管理奠基。

本 PR 值得相关架构团队和负责 Rollout 模块的工程师精读。它不是一个功能性的变更，而是一个重要的架构基础搭建。建议关注： 1. **抽象设计**：`RayWorkerManager` 作为单一管理器的设计，以及通过 `specs` 模块聚合不同工作器规格的模式，是后续所有工作器管理重构的基石。 2. **重构路径**：理解 `wiring.py` 如何将启动流程从三个训练入口中抽取出来，这为未来支持非 Ray 部署模式（如注释中提到的 Kubernetes）预留了扩展点。 3. **TODO 规划**：仔细阅读代码中的 TODO 注释，它们清晰地指出了当前实现的差距和下一步的演进方向。 对于普通贡献者，了解此 PR 的作用即可，无需深入细节。

将路由器和会话服务器的启动从驱动子进程迁移至头节点 Ray Actor，统一生命周期管理。

此 PR 是 Rollout 模块一项重要的架构级重构，值得精读。核心设计决策是通过 Ray Actor 托管关键长运行进程，以解决子进程生命周期管理问题。`_launch_command_on_head` 和 `_actor_is_alive` 的实现模式，以及 `wait_tcp_ready` 对 Actor 存活状态的适配，都体现了在 Ray 环境下的工程权衡。理解这些变更有助于把握后续关联 PR（如 #2051, #2054）中“建立持久所有权”的上下文。