执行摘要

本 PR 为 Rust gRPC 前端新增服务发现控制接口，通过拆分服务和扩展握手协议，实现了 GetServerInfo 和 GetModelInfo RPC。这是 Rust 前端运营 API 的基础，影响模块包括新的控制服务和推理服务、ChatLlm 能力层以及 Python 引擎核心。

功能与动机

如 PR 所述：“Add GetServerInfo and GetModelInfo to the Rust frontend's gRPC control API”。目的在于使外部客户端能够通过 gRPC 控制通道获取 vLLM 实例的运行时状态和模型信息，从而支持负载均衡、自动扩缩容、监控等运维场景。

实现拆解

1. 服务模块拆分：原 grpc/mod.rs 中的 Generate 和 Control 实现被独立到 inference.rs 和 control.rs，同时 protobuf 服务更名为 vllm.Inference 并新增 vllm.Control 服务。
2. 握手协议扩展：在 Python 端 EngineCoreProc._make_ready_response 中构造更完整的 EngineCoreReadyResponse，新增 data_parallel_size、tensor_parallel_size、pipeline_parallel_size、decode_context_parallel_size、instance_id、max_num_seqs、max_num_batched_tokens 等字段。Rust 客户端通过 ready_response() 访问。
3. 控制服务实现：control.rs 中的 get_server_info 聚合引擎版本、并行度、KV 容量、调度限制；get_model_info 返回模型 ID、服务名、别名、多模态支持及解析器名称。
4. ChatLlm 能力扩充：在 chat/src/lib.rs 新增三个查询方法，供控制服务填充模型信息。
5. 测试配套：更新集成测试，使用 InferenceClient 替代 GenerateClient，并新增两个控制服务测试用例，覆盖单引擎和多引擎场景。

rust/src/chat/src/lib.rs

ChatLlm 新增三个查询方法：supports_multimodal、tool_call_parser_name、reasoning_parser_name，供控制服务填充 ModelInfo。

/// 检查加载的模型后端是否注册了多模态处理器。
pub fn supports_multimodal(&self) -> bool {
    self.processor.backend.multimodal_model_info().is_some()
}
​
/// 返回当前生效的工具调用解析器名称。
/// 当解析器未启用时返回 `None`，否则根据配置返回自动解析结果或显式名称。
pub fn tool_call_parser_name(&self) -> Option<&str> {
    match &self.tool_call_parser {
        ParserSelection::Auto => {
            ToolParserFactory::global().resolve_name_for_model(self.model_id())
        }
        ParserSelection::None => None,
        ParserSelection::Explicit(name) => Some(name),
    }
}
​
/// 返回当前生效的推理解析器名称。
/// 逻辑与 `tool_call_parser_name` 类似，返回自动或显式设置的解析器名称。
pub fn reasoning_parser_name(&self) -> Option<&str> {
    match &self.reasoning_parser {
        ParserSelection::Auto => {
            ReasoningParserFactory::global().resolve_name_for_model(self.model_id())
        }
        ParserSelection::None => None,
        ParserSelection::Explicit(name) => Some(name),
    }
}

评论区精华

• njhill 建议将 EngineCoreReadyResponse 构建抽取为独立方法，作者随即将 process_input_sockets 中的内联构造重构为 _make_ready_response。

• njhill 指出 protobuf 字段编号存在 gap，作者详细回应：ParallelismInfo 因字段删除后已重编号消除 gap；ModelInfo 因计划未来恢复 supports_lora 字段而保留 gap 作为占位。此设计决策体现了 protobuf 版本演进的典型实践。

风险与影响

• 兼容性风险：将 vllm.Generate 重命名为 vllm.Inference 是破坏性变更，但 Rust 前端服务仍处早期，影响面可控。
• 同步维护成本：Python 与 Rust 之间的握手协议字段需保持严格一致，后续添加字段时必须同时更新两侧。
• 信息泄露：控制 API 暴露了 instance_id、engine_version 等元信息，应通过 TLS 或网络隔离保护 gRPC 端口。
• 测试缺口：现有测试验证了正常路径，但未覆盖握手失败、空请求等异常场景。

关联脉络

本 PR 的前两个提交来自 #49466（服务分离），后者是本 PR 的基础依赖。这是 Rust 前端建立完整 gRPC 运维 API 的第一步，后续可沿 Control 服务继续添加 KV 卸载状态、请求统计等 RPC，最终形成生产级的运营接口体系。