bug(proxy): public team aliases omit model metadata from /v1/models

快速结论：当 LiteLLM Proxy 通过团队级别名（team_public_model_name 或 model_aliases）对外暴露模型时，GET /v1/models/{id} 或 /v1/models 可能丢失 mode、max_input_tokens、max_output_tokens 等能力元数据。优先排查别名是否被当作真实 router deployment 解析（get_model_listing_info 是否返回有效索引）。

适用环境：LiteLLM Proxy，涉及团队级 model_info.team_public_model_name 与团队 model_aliases 配置；报告中出现 v1.100.0、v1.102.0-rc.1 两个版本。未确认操作系统、Python、CUDA、显卡等环境。

最快修复方案：暂无确认的一步修复方案。已合并的修复仅覆盖 team_public_model_name 场景；model_aliases（Community 级）的同类缺失在该 Issue 中被报告为仍然存在。

注意事项：把别名加入团队 models 数组只影响访问过滤与可见性，不会让别名获得 deployment 元数据。别名路由本身不受影响，缺失仅体现在动态发现（discovery）阶段。修复尚未覆盖 alias 路径，需要持续关注后续 PR。

问题场景

在 LiteLLM Proxy 中，使用团队级公开模型名或团队 model_aliases 作为对客户端暴露的模型标识。客户端通过 /v1/models 做动态发现，再用 GET /v1/models/{id} 获取单个模型的元数据。若使用别名（例如把 claude-opus 指向 claude-opus-5-bedrock），发现列表中的别名条目缺少 mode 与 token 上限，而底层 deployment 名称却带完整元数据。

报错原文

bug(proxy): public team aliases omit model metadata from /v1/models

原因分析

可能原因在于元数据解析路径无法处理别名。create_model_info_response 通过 llm_router.get_model_listing_info(model_id) 构建候选，其起点是：

indices = self.model_name_to_deployment_indices.get(model_name)
if not indices:
    return None

team_public_model_name 对应的是真实 router deployment 行，因此有索引、可以解析。而 model_aliases 是请求时的重写（request-time rewrite），没有对应的 deployment 行，于是 get_model_listing_info 返回 None，cost_map_keys 为空，别名本身也不是 cost-map key，两个候选来源都为空，最终没有附带 mode 或 token 限制。该行为在 v1.100.0 与 v1.102.0-rc.1 上一致，已确认不是回归。

环境排查

确认 LiteLLM Proxy 版本（报告中涉及 v1.100.0、v1.102.0-rc.1）。
确认使用的是 model_info.team_public_model_name 还是团队 model_aliases。
确认团队配置中 models 与 model_aliases 的实际内容。
确认虚拟密钥所属团队及其访问组。
检查底层 deployment 是否为 cost-map 条目。

解决步骤

先用同一把虚拟密钥分别请求 GET /v1/models?include_metadata=true 和 GET /v1/models/{public-alias}，记录两者返回的 mode、max_input_tokens、max_output_tokens 是否一致。
对比底层 deployment 名称的返回（例如 claude-opus-5-bedrock 带完整元数据），确认缺失只发生在别名条目上。
如果是 team_public_model_name 场景，升级到包含已合并修复（PR #40554）的版本，该修复对 team-scoped public model names 生效。
如果是团队 model_aliases 场景，目前没有已合并的修复。可优先尝试的方向是：在 deployment 查找之前先把 alias 解析到目标（例如借助 user_api_key_dict.aliases、user_api_key_dict.team_model_aliases，以及 llm_router.model_group_alias），保持 alias 作为响应 id、用目标 deployment 提供元数据。此方案在 Issue 中仅为建议方向，尚未验证。
作为临时缓解，可在客户端侧为已知别名补充能力元数据，但 Issue 明确指出硬编码模型在动态场景下不可接受，仅作过渡。

验证方法

用同一把团队虚拟密钥请求 GET /v1/models 与 GET /v1/models/{alias}，确认别名条目的 id 仍为公开别名，同时返回与底层 deployment 一致的 mode、max_input_tokens、max_output_tokens；对图片别名应看到 "mode": "image_generation"。同时确认调用 model: {alias} 仍能正确路由到后端（日志中出现对应的 Model Group）。