讨论 model 命名与 KV Pool 命名空间边界

[DingYiBin]

背景

当前计算层加载模型时仍在多处使用 model_id。在对照 vLLM 后，需要拆清楚几个概念：

• model_path / backend model source：用于 AutoConfig.from_pretrained() 和权重 loader，可以是 HF repo 或本地目录。
• served_model_name：对外 API 请求中的模型名 / alias。
• KV Pool namespace：KV block / prefix cache 的命名空间是否需要包含模型身份。

vLLM 的 served_model_name 默认会退回到 args.model，但 lake 不应照搬这个默认行为，因为 args.model 可能是本地文件系统路径，直接作为对外模型名会暴露部署路径。

当前倾向

• lake 增加一个固定默认对外名称，例如 served_model_name = \"model\"。
• 不把本地 model_path 自动暴露为 served model name。
• 计算路径中逐步移除 model_id，请求侧最多校验请求的 model 是否匹配当前 worker 的 served_model_name。
• 模型加载继续使用 model_path / revision / load_format。

待讨论问题

核心问题：KV Pool 是否还需要以 model_id 区分 KV namespace？

一种观点是：不同模型的 KV 不可能在同一个推理实例中同时被正确管理或复用，因此 KV Pool 可以绑定单个 ModelDescriptor，不必在每个 KV block key 上携带 model_id。

需要和合作者确认：

1. KV Pool 是否仍坚持长期多模型共池设计？
2. 如果改成单模型 Pool / 单 ModelDescriptor 绑定，KVBlockID.model_id 是否可以删除？
3. revision 是否也从 block key 中移除，改为 pool/worker 启动上下文？
4. Router / Agent / Pool 的模型注册、配额、L3 object key、radix 分树逻辑如何调整？
5. API 层的 served_model_name 是否只作为对外 alias，不进入 hot path？

参考

• vLLM served_model_name 用作 OpenAI API 可见名称、请求校验、/v1/models 和 metrics label，不是多 base model 运行时选择机制。
• lake 当前 KVBlockID = (model_id, revision, block_hash, pool_kind, scope)，如果删除 model_id 需要同步修改 proto、存储池文档和 agent/control-plane 逻辑。