LiteLLM Terraform Provider 数据源 `litellm_models` 实战：从 `/v1/model/info` 读取代理上的全部模型部署

LiteLLM Terraform Provider 数据源litellm_models实战从/v1/model/info读取代理上的全部模型部署【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellmLiteLLM是一个以 Rust 核心 Python SDK 构建的 AI 网关能够以 OpenAI 兼容或各厂商原生格式调用 100 家大模型 API并统一提供成本追踪、护栏、负载均衡与日志能力其仓库内随源码一起维护了一个官方 Terraform Provider源码位于 terraform/provider让用户能用 IaC基础设施即代码方式管理 LiteLLM Proxy 上的模型、Team、Key、Budget 等资源。litellm_models正是该 Provider 中面向批量读取模型部署信息的只读数据源本文以 terraform/provider/docs/data-sources/models.md 为骨架结合同目录单条数据源文档 docs/data-sources/model.md 与 Go 实现源码完整讲解它的作用、参数、导出属性、安全设计与底层调用链并给出可直接运行的 HCL 示例。读完你将掌握如何用一条data litellm_models列出代理的全部模型、按 Team 过滤并把模型名与 ID 喂给 Output、资源引用或下游编排。一、数据源定位清单List形态的模型读取器在 LiteLLM Terraform Provider 中围绕模型部署存在两个互补的只读数据源Data Source读取代理上已存在的对象、不创建不修改数据源职责对应代理 APIlitellm_model按model_id读取单个模型部署的完整路由元数据GET /v1/model/info?litellm_model_ididlitellm_models列出全部模型部署可按team_id过滤GET /v1/model/info/GET /v1/model/info?teamIdidlitellm_models的核心文档描述非常明确见 docs/data-sources/models.mdLists all model deployments via/v1/model/info. Sensitivelitellm_paramsfields (API keys and other credentials) are never exposed.它通过 LiteLLM Proxy 的模型信息管理端点/v1/model/info拉取代理上注册的全部模型部署并且出于安全考虑绝不导出任何敏感凭据字段——例如api_key、aws_secret_access_key、vertex_credentials这类只存在于litellm_params中的密钥信息永远不会进入 Terraform State。这正是设计上把该数据源定位为安全路由元数据读取器的直接证据源码中定义请求体解析结构时注释明确写着modelInfoParams intentionally maps only the non-sensitive litellm_params fields见 litellm/data_source_model.go该结构体只声明了model、custom_llm_provider、api_base、api_version、tpm、rpm六个非敏感字段。二、Example Usage最小可用示例原文档给出的示例非常精简docs/data-sources/models.md一行data块即可拉取全部模型配合 Terraform 的for表达式把模型列表投影成模型名列表data litellm_models all {} output model_names { value [for m in data.litellm_models.all.models : m.model_name] }要真正跑通这段代码还需补齐 Provider 声明与鉴权配置。根据 Provider 主 README 中的用法README.mdlitellm_models依赖连接 LiteLLM Proxy 的api_base与虚拟 KeyVirtual Keyterraform { required_providers { litellm { source BerriAI/litellm version ~ 1.99.0 # Provider 版本与 LiteLLM Proxy 版本严格对齐 } } } provider litellm { api_base var.litellm_api_base # 例如 http://localhost:4000 api_key var.litellm_api_key # 具备 /v1/model/info 读取权限的 Key } data litellm_models all {} output model_names { value [for m in data.litellm_models.all.models : m.model_name] } output model_ids { value data.litellm_models.all.ids }版本注意事项README 明确指出Provider 版本就是 LiteLLM 版本README.md。每个 LiteLLM 发布dev、rc、stable都会以与 Proxy 相同的版本号发布 Provider并在 CI 中用代理自动生成的 OpenAPI 规格审计 Provider 调用的每一个端点。因此建议始终把 Provider 固定在与你所运行 Proxy 相同的大版本线上例如~ 1.99.0。2.1 按 Team 过滤的进阶用法把文档中的team_id参数见 docs/data-sources/models.md与模型名输出结合就可以实现只看某个团队能访问的模型data litellm_team infra { # 此处假设已有一个 litellm_team 数据源/资源提供 team_id } data litellm_models infra_models { team_id data.litellm_team.infra.team_id } output infra_model_providers { value { for m in data.litellm_models.infra_models.models : m.model_name m.custom_llm_provider } }三、Argument Reference入参说明litellm_models只接受一个可选入参参数类型必填说明team_idstring否按该 Team 可访问过滤模型。传参后Provider 会在请求/v1/model/info时追加?teamIdteam_id查询串不传则返回全部模型该语义在 Go Schema 中定义得十分清晰litellm/data_source_model.goteam_id的类型为TypeString、Optional: trueDescription 为 Filter models to those accessible by this team。从源码看team_id不仅影响请求还直接决定数据源 State 的 ID。读取逻辑dataSourceLiteLLMModelsRead在拿到team_id后首先改写端点随后在收尾阶段执行d.SetId(GetStringValue(d.Get(team_id).(string), all))即传了team_id时数据源 ID 等于该 Team ID否则为常量字符串alllitellm/data_source_model.go。这也是单元测试TestDataSourceModelsRead中断言d.Id()应为team-1的原因。四、Attributes Reference导出属性详解除了全部入参外litellm_models还会导出两个计算属性Computed由代理返回不可由用户设置4.1ids模型 ID 列表类型为 string 列表按model_info.id汇总本次返回的所有模型的 LiteLLM 模型 ID。在源码中对应 Schema 的ids字段litellm/data_source_model.go其值来源于响应的entry.ModelInfo.ID。这些 ID 有一个非常实用的下游用途它们是单条数据源litellm_model的model_id入参。按照单条数据源文档model_id即为 LiteLLM 模型 ID也就是代理在响应头x-litellm-model-id中返回的值docs/data-sources/model.md。也就是说litellm_models.ids天然可以循环喂给litellm_model实现先批量发现、再逐条获取完整细节的两段式读取。4.2models模型对象列表models是核心属性为对象列表List of Object每一项导出的字段与语义如下字段定义见 docs/data-sources/models.md字段类型说明idstringLiteLLM 模型 ID即model_info.idmodel_namestring对外公开、用于路由的模型名客户端实际请求时使用的名字modelstring底层litellm_params.model即真正指向厂商的具体模型串形如openai/gpt-4o、anthropic/claude-opus-4custom_llm_providerstring该模型使用的 Provider如openai、anthropic、bedrock、vertex_aimodel_api_basestring配置了才有的 API Base URL即litellm_params.api_basebase_modelstring用于定价cost与能力推断的基础模型名如gpt-4o、claude-3-5-sonnet-20241022tierstring模型层级取值为free或paidmodestring模型模式如chat对话、embedding向量、image_generation图像生成等team_idstring若该部署被限定到某个 Team则为对应 Team ID否则为空db_modelbool该部署是否存储在数据库中DB 路径而非来自 YAML 配置文件Config 路径Schema 中对上述每个字段的声明位于 litellm/data_source_model.go除db_model为TypeBool外其余全部为只读的Computed: true字符串。数据组装逻辑litellm/data_source_model.go展示了每个导出值与代理响应 JSON 的映射关系——例如model_name取自顶层entry.ModelName而model、custom_llm_provider、model_api_base取自litellm_paramsbase_model、tier、mode、team_id、db_model取自model_info。4.3 与单条数据源litellm_model的属性差异值得注意清单形态的litellm_models为了保持列表轻量并未导出api_version、tpm每分钟 Token 上限、rpm每分钟请求上限这三个在单条litellm_model中提供的字段对比 docs/data-sources/model.md。因此当你需要某个具体部署的限流配额或 API 版本时正确的姿势是用litellm_models先发现 ID再通过litellm_model按 ID 精确读取完整信息。五、安全设计敏感凭据永不进入 Terraform State这是该数据源最重要的设计约束值得单独强调。官方文档与源码从三个层面共同保障白名单式解析结构请求解析使用的modelInfoParams只声明了六个非敏感字段源码注释明示 credentials (api_key,aws_secret_access_key, ...) must never reach statelitellm/data_source_model.go。安全提示成文单条数据源文档末尾专门设有 Security Note 一节docs/data-sources/model.md说明litellm_params中的凭据材料如api_key、aws_secret_access_key、vertex_credentials绝不会被导出。State 落盘即隔离由于 Provider 结构体层面就没有定义敏感字段Terraform 根本不会把它们写入.tfstate更不会出现在terraform show/terraform output或计划差异中。这也意味着litellm_models与管理资源的litellm_model的分工不同创建/更新模型部署需要提交model_api_key等敏感参数属于 Resource 的职责示例见 README.md而读取侧的数据源负责在可发现性与不泄露密钥之间取得平衡。六、源码级原理从 HCL 到 HTTP 的完整调用链把数据源接入 Provider 的注册点位于 terraform/provider/litellm/provider.go注册名为字符串litellm_models值为工厂函数dataSourceLiteLLMModels()。随后 Terraform 在terraform plan/apply时触发其Read回调完整流程如下对应 litellm/data_source_model.go拼端点默认端点为常量endpointModelInfoV1 /v1/model/info同文件 L12。若配置了team_id则拼接?teamIdurl.QueryEscape(team_id)并对 Team ID 做 URL 转义。发请求调用MakeRequest(client, GET, endpoint, nil)发起 GET失败时错误信息包装为failed to list models: %w随后handleResponse(resp, listing models)统一处理非 2xx 状态码。解析响应响应按信封结构modelInfoEnvelope{ Data json.RawMessage }反序列化得到data字段的原始 JSON。兼容两种返回形态modelDecodeInfoEntries先尝试把data当作单个对象解失败再当作对象列表解litellm/data_source_model.go。源码注释解释了原因/v1/model/info在DB 存储路径下返回单个对象在Config 配置路径下返回单元素列表两种形状都必须兼容。组装 State遍历 entries并行填充ids与modelsdb_model等布尔值按model_info.db_model原样映射最后d.SetId(...)并写日志[INFO] Successfully listed %d models。代理侧对应的管理端点实现位于 litellm/proxy/management_endpoints/model_management_endpoints.py对 Proxy 上/v1/model/info返回内容与db_model区分 DB 与 Config 部署语义的进一步确认可深入该文件。七、测试佐证行为是被单测钉死的Provider 对数据源行为的验证并不依赖真实代理而是用 Go 标准库的httptest起假服务端因此能精确断言请求与解析行为。TestDataSourceModelsReadlitellm/data_source_model_test.go验证了四条关键约定请求必须是GET /v1/model/info配置team_id后URL 查询串必须携带teamIdteam-1解析后ids的长度与顺序符合响应中的两条记录id-1、id-2models首项字段正确包括model_name、custom_llm_provider与布尔类型的db_model。测试中构造的响应{model_name: b, litellm_params: {model: anthropic/b, custom_llm_provider: anthropic}, ...}也反向印证了第三节属性映射表——model与custom_llm_provider正是从litellm_params中白名单提取的。八、典型应用场景与最佳实践基于上述能力与约束litellm_models在真实 IaC 工作流中适合以下用途模型清单观测将代理上全部已注册模型的model_name、mode、tier投影为terraform output或写入外部系统的下游消费便于审计这台代理到底暴露了哪些模型。模型 ID 驱动的二次读取把data.litellm_models.all.ids与for_each结合逐个交给litellm_model获取tpm/rpm/api_version等清单中不包含的字段形成清单 明细的两层结构。Team 级模型可用性核对借助team_id过滤核对某个 Team 实际可路由的模型集合用于验证权限/模型绑定配置是否按预期生效。配置与 DB 双来源梳理利用导出的db_model布尔值区分来自 YAML 配置与来自数据库的部署帮助判断修改时该走 Config 热加载还是 DB 管理 API。实践要点可归纳为三点版本对齐把 Provider 版本固定在所运行 Proxy 的版本线如~ 1.99.0避免 OpenAPI 审计覆盖之外的 API 漂移。敏感信息走 Resource 而非 Data Source读取侧永远拿不到密钥——这是特性而非限制凡需提交model_api_key等凭据的变更一律走litellm_modelResource参考 README.md 中声明 API Key 的方式。善用ids与for表达式清单数据源返回的是models对象列表与平行的ids字符串列表HCL 中优先用for m in data.litellm_models.all.models : m.字段这类投影访问语义更清晰。如需继续深入建议阅读同目录的姊妹数据源文档 docs/data-sources/model.md单条读取、含tpm/rpm/api_version等字段以及 Provider 主说明 README.md版本策略、安装要求、全部资源/数据源能力总览并在 litellm/data_source_model_test.go 中观察更多可被断言的边界行为。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考