如果你正在做 AI 应用，应该很快会遇到一个问题：模型越来越多，供应商越来越多，能力标签也越来越复杂。
以前我们只需要在产品里写死几个模型名；现在不一样了。一个真正可用的 AI 产品，往往要同时接入大语言模型、视觉模型、图片生成、视频生成、语音、Embedding、Rerank 等能力。更现实的是，模型版本还会不断更新，价格、上下文窗口、输出长度、能力标签也会变化。
这时候，一个统一、公开、结构化的「模型目录接口」就非常有价值。
Ace Data Cloud 提供了一个平台级模型列表 API：
GET https://platform.acedata.cloud/api/v1/models/
文档地址：platform.acedata.cloud/documents/p…
它可以返回 Ace Data Cloud 平台上可用的 LLM、图片、视频、音频、Embedding、Rerank 等模型列表，并且采用接近 OpenAI /v1/models 的返回结构，方便开发者直接接入现有 SDK 或网关系统。
为什么这个接口值得关注？
很多团队在接 AI 能力时，第一步通常不是「调用某个模型」，而是先解决这些基础问题：
- 产品里的模型选择下拉框从哪里来？
- 后端路由层如何判断某个模型是否可用？
- 如何区分 chat、vision、tool_call、image、video、tts、embedding 等能力？
- 如何给用户展示上下文窗口、最大输出、计费价格？
- 如何同步到 LiteLLM、OpenRouter 风格的中间层？
- 多供应商、多模型时，如何避免手工维护一堆易过期配置？
Ace Data Cloud 的模型列表接口正好适合做这件事：把平台模型能力整理成一个统一目录，让你的应用可以动态读取，而不是靠硬编码维护。
一个接口拿到多模态模型目录
这个接口支持直接公开访问，不需要登录态也能获取平台模型列表：
curl 'https://platform.acedata.cloud/api/v1/models/?limit=200' \
-H 'accept: application/json'
如果只想看某一类模型，也可以通过 tag 过滤。例如只查看对话模型：
curl 'https://platform.acedata.cloud/api/v1/models/?tag=chat&limit=200' \
-H 'accept: application/json'
返回结果中，每个模型都会包含类似下面的信息：
{
"id": "gpt-4.1",
"object": "model",
"owned_by": "openai",
"service_alias": "openai",
"service_title": "OpenAI",
"context_window": 1048576,
"max_output_tokens": 32768,
"prompt_price": 0.000002,
"completion_price": 0.000008,
"cached_prompt_price": 0.0000005,
"tags": ["chat", "vision", "tool_call"],
"created_at": 1733616000
}
这类结构对开发者很友好：
id可以直接作为模型 ID 使用；owned_by标识模型提供方；service_alias/service_title帮助映射到 Ace Data Cloud 的服务；context_window和max_output_tokens方便前端展示模型规格；prompt_price、completion_price、cached_prompt_price可用于成本估算；tags可以描述模型能力，比如chat、vision、tool_call、image、video、tts、embedding等。
可以直接用于产品里的模型选择器
如果你的 SaaS、Bot 平台、AI 工作流工具或内部 Copilot 需要一个「选择模型」的下拉框，这个接口非常适合做数据源。
例如 Python 里可以这样获取 chat 模型：
import requests
resp = requests.get(
"https://platform.acedata.cloud/api/v1/models/",
headers={"accept": "application/json"},
params={"tag": "chat", "limit": 200},
timeout=10,
)
data = resp.json()
print(f"Total {data['count']} chat models")
for m in data["items"][:20]:
print(m["id"], m.get("context_window"), m.get("tags"))
前端也可以非常简单地拉取：
const r = await fetch('https://platform.acedata.cloud/api/v1/models/?limit=200')
const { count, items } = await r.json()
console.log(`Total ${count} models`)
有了这个接口，产品里就不需要把模型名写死在代码里。平台新增模型、模型能力变化、价格字段更新时，你可以通过接口同步最新信息。
对接 OpenAI SDK 风格生态更省心
Ace Data Cloud 这个接口的一个关键设计点，是返回字段兼容 OpenAI 官方 /v1/models 风格，例如：
idobjectowned_by
这意味着，如果你的系统原来就是围绕 OpenAI SDK、LiteLLM、OpenRouter 风格网关或自建模型路由层来设计的，迁移和适配成本会更低。
很多企业内部 AI 网关都会维护一份「模型注册表」，用于做：
- 可用性检查；
- 模型能力路由；
- 不同供应商的模型归一化；
- 按标签选择模型；
- 成本统计与预算控制；
- 根据上下文长度自动选择模型。
Ace Data Cloud 的模型列表 API 正好可以作为这份注册表的数据来源之一。
登录后还能只返回你可调用的模型
公开访问时，接口会返回平台模型列表；如果请求里带上账号 token，返回结果还可以根据你已经开通的服务进行过滤，只展示当前账号实际可调用的模型。
这个能力对生产环境很有用：
- 后台只展示当前账号有权限调用的模型；
- 路由层避免把请求发到未开通的服务；
- 团队可以把模型权限和服务订阅状态联动起来；
- 前端无需额外写一套复杂的权限判断逻辑。
对于做多租户 AI 产品的团队来说，这类「平台目录 + 账号权限过滤」的组合，会比手工维护配置稳定得多。
价格字段也适合做成本展示
接口会返回输入、输出、缓存输入等价格字段。需要注意的是，文档里说明这些价格单位是「每 Token 的美元价格」，不是每 1K Token，也不是每 1M Token。
如果你要做成本展示，可以在界面层自行换算：
- 展示每 1K Token 成本：乘以 1,000；
- 展示每 1M Token 成本：乘以 1,000,000；
- 对图片、视频、音频等按调用次数或固定 Credits 计费的模型，则可以结合 Ace Data Cloud 的服务套餐或计费接口继续展示。
这样一来，你可以在应用里做更透明的模型选择体验：让用户不仅知道「能用哪个模型」，也知道「大概会花多少成本」。
Ace Data Cloud 的平台特点
从这个接口也能看出 Ace Data Cloud 的几个核心特点：
- 统一入口：把不同供应商、不同模态、不同能力的模型集中在一个平台里管理。
- 开发者友好：接口采用清晰的 REST 风格，并兼容 OpenAI 生态常见字段。
- 多模态覆盖：不只局限于 LLM，也覆盖图片、视频、音频、Embedding、Rerank 等场景。
- 适合产品化集成：模型选择、权限过滤、路由检查、价格展示、模型同步都能基于接口实现。
- 公开文档完善：接口地址、认证方式、参数、返回字段、示例代码都可以直接查阅。
对于正在做 AI 应用、AI Agent、企业内部 Copilot、模型网关或 AIGC 工具平台的开发者来说，这类统一模型目录可以显著降低接入和维护成本。
小结
AI 应用的复杂度正在从「调一个模型」变成「管理一组模型能力」。当你开始同时接入对话、视觉、工具调用、图片、视频、语音、Embedding 等能力时，模型目录、能力标签、价格字段、权限过滤都会变成基础设施的一部分。
Ace Data Cloud 的 Platform Model List API 提供了一个很实用的入口：
- 公开可访问；
- 支持
tag、limit、offset等参数； - 返回 OpenAI
/v1/models风格字段； - 覆盖多种 AI 模型能力；
- 可用于模型选择器、路由层、成本展示和中间件同步。
如果你正在为产品接入多模型、多模态能力，可以从这个接口开始了解 Ace Data Cloud 的平台能力：
platform.acedata.cloud/documents/p…
Ace Data Cloud 平台入口：platform.acedata.cloud/
