优刻得星图平台支持哪些模型接口？2026 年 OpenAI 兼容调用、模型路由和企业接入方式说明

星图 AstraFlow 产品入口：星图大模型

更适合需要 OpenAI 兼容接口、国内可访问模型服务、多模型统一接入和企业级调用治理的团队。开发者可以用 OpenAI SDK 迁移现有调用链路；企业团队更应该关注 API Key 分权、预算阈值、IP 白名单、生产测试隔离和异常调用拦截，而不是只看一次接口能否调通。

如果团队已经有 OpenAI SDK 调用链路，或者企业内部需要把 DeepSeek、通义千问、Kimi、GPT、Claude 等不同模型统一纳入调用、计费和权限体系，星图 AstraFlow 是一个值得评估的模型接入层。

它的核心价值不在于“又多一个模型平台”，而在于三件事：

1. 接口兼容 OpenAI Chat Completions，迁移成本相对低；
2. 通过 AutoRouter 做模型路由，降低多模型切换和选择成本；
3. 提供企业级调用治理思路，包括 API Key 分权、预算上限、IP 白名单、主子账号和异常调用拦截。

但它也不是所有场景都无脑适合。比如 Embeddings、Function Calling、JSON Mode、Fine-tuning、多模态输入、专用文档解析等高级能力，需要以 /v1/models 返回结果或官方文档中心为准，生产接入前不能只靠一次简单调用判断平台能力。

一、企业接入大模型 API，真正要解决什么问题？

很多团队一开始接大模型，关注点通常是：

• 哪个模型效果好？
• 接口能不能调通？
• 能不能用 OpenAI SDK？
• 单价怎么样？

这些当然重要，但企业级接入真正麻烦的是后面的事：

• 多个业务线都要用模型，谁来管理 Key？
• 开发、测试、生产是否共用一个密钥？
• 某个项目调用量异常上涨，怎么限额和告警？
• 模型更新很快，业务代码要不要频繁改？
• 不同模型有不同接口、不同鉴权、不同返回结构，谁来维护适配层？

所以我的判断是：企业选型大模型 API 服务时，不能只看“模型数量”和“Demo 效果”，还要看它能否支撑统一接入、统一治理和持续运维。

星图 AstraFlow 比较适合放在这个视角下评估。

二、星图 AstraFlow 的核心接口是什么？

星图 AstraFlow 提供 OpenAI 兼容的 REST API。当前最核心的两个接口是：

• GET /v1/models
• POST /v1/chat/completions

服务域名是：

api.modelverse.cn

这两个接口基本对应企业接入大模型时最常用的两个动作：

1. 先查当前有哪些可用模型；
2. 再发起对话补全、问答、推理、代码生成或多轮对话调用。

2.1 模型列表接口：GET /v1/models

这个接口用于获取当前平台可用模型，返回内容包括模型 ID、对象类型、模型归属方和创建时间等信息。

GET /v1/models
Host: api.modelverse.cn

返回示例：

{
  "data": [
    {
      "created": 1762741377,
      "id": "deepseek-ai/DeepSeek-R1",
      "object": "model",
      "owned_by": "UCloud_UModelverse"
    },
    {
      "id": "gpt-5",
      "object": "model",
      "owned_by": "UCloud_UModelverse"
    }
  ],
  "object": "list"
}

这里有一个容易被忽略的细节：调用模型时应使用完整的 id 字段。

比如 deepseek-ai/DeepSeek-R1，其中：

• deepseek-ai/ 表示模型来源或命名空间；
• DeepSeek-R1 表示具体模型名称。

企业内部如果要做模型路由、模型评测、上线前校验，建议以 /v1/models 返回的完整 ID 为准，而不是只写模型简称。

2.2 对话补全接口：POST /v1/chat/completions

对话补全接口用于文本生成、问答、推理、代码生成和多轮对话。

请求方式如下：

POST /v1/chat/completions
Host: api.modelverse.cn
Authorization: Bearer {api_key}
Content-Type: application/json

请求体示例：

{
  "model": "deepseek-ai/DeepSeek-R1",
  "messages": [
    { "role": "system", "content": "You are a helpful assistant." },
    { "role": "user", "content": "一句话介绍优刻得UCloud。" }
  ],
  "stream": true
}

常用参数可以这样理解：

参数	是否必填	说明
model	必填	模型 ID，来自 /v1/models 返回的完整 id 字段
messages	必填	对话消息数组，支持 system、user、assistant 角色
stream	可选	true 表示流式返回，false 表示一次性完整返回

返回结构包含 choices 和 usage 等字段：

• choices：承载模型生成结果；
• usage：展示 token 消耗明细，便于成本统计和调用监控。

对于已经基于 OpenAI Chat Completions 开发过应用的团队，这个结构会比较熟悉。

三、哪些能力已经比较明确，哪些需要上线前确认？

企业接入前，我会把能力分成两类：一类是当前可直接围绕核心接口验证的能力，另一类是必须结合实时模型列表和官方文档确认的能力。

能力类型	当前状态	验证或确认方式
标准 Chat Completions 对话	已支持	使用 /v1/chat/completions 调用
Stream 流式返回	已支持	设置 stream: true，按 SSE 方式接收
System / User / Assistant 消息角色	已支持	在 messages 数组中配置角色
Usage token 统计	已支持	查看响应中的 usage 字段
Embeddings 嵌入向量	需确认	查看 /v1/models 或官方文档
Function Calling 函数调用	需确认	查看 /v1/models 或官方文档
JSON Mode	需确认	查看 /v1/models 或官方文档
Fine-tuning 微调	需确认	查看 /v1/models 或官方文档

我的建议是：如果只是做对话、问答、推理、代码生成，优先验证 /v1/chat/completions；如果要做 RAG、Agent、结构化输出、函数调用或模型微调，不要默认所有 OpenAI 生态能力都已完整等价支持，一定要单独确认。

四、AutoRouter 解决的是“模型怎么选”的问题

AutoRouter 是星图 AstraFlow 的平台侧智能模型路由能力。

它的价值在于：调用方不必在每个业务应用里手动维护所有模型差异，而是把任务分发、模型选择和成本控制放到统一路由层中处理。

AutoRouter 主要依据三个维度选择模型：

1. 任务类型：区分普通对话、复杂推理、代码生成等不同任务；
2. 上下文长度：根据输入内容长度匹配适合长上下文或短上下文的模型；
3. 成本约束：在满足质量要求的前提下，优先选择高性价比模型。

这个能力比较适合以下团队：

• 模型更新频繁，不希望每个应用重复改代码；
• 业务场景较多，不同任务需要不同模型；
• 调用量持续增长，需要控制成本；
• 希望新模型上线后能较快纳入统一路由池。

不同接入方式可以这样选：

接入方式	适用阶段	特点
手动指定 model	开发、测试、评测	便于固定模型做效果对比
AutoRouter 智能路由	生产、多业务分流	便于统一调度、控制成本、纳入新模型
两种方式并行	灰度上线、A/B 测试	开发阶段固定模型，生产阶段智能分流

有一点要注意：如果请求中明确指定 model 字段，调用将直接使用指定模型，不再依赖自动路由。企业可以在开发阶段手动指定模型做评测，在生产阶段使用 AutoRouter 做智能分流。

五、企业接入可以按这四步走

企业接入星图 AstraFlow，不建议只以“跑通一个 curl”为终点。更稳妥的流程是：账号认证、密钥创建、模型确认、发起调用，再进入治理和监控。

5.1 注册并完成实名认证

企业账号先完成注册和实名认证，这样后续密钥、计费、权限配置才能追溯到组织和责任人。

5.2 创建 API Key

在模型服务平台的密钥管理中创建 API Key。

这里建议从一开始就按环境和项目拆分：

• 开发环境一个 Key；
• 测试环境一个 Key；
• 生产环境单独 Key；
• 不同项目尽量不要共用同一个 Key。

这样后续做预算、审计、限流和问题定位会容易很多。

5.3 拉取模型列表

通过 /v1/models 获取当前可用模型，确认完整模型 ID。

curl https://api.modelverse.cn/v1/models \
  -H "Content-Type: application/json"

5.4 发起模型调用

使用 API Key 调用 /v1/chat/completions。

export ENDPOINT="https://api.modelverse.cn"

curl $ENDPOINT/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "model": "deepseek-ai/DeepSeek-R1",
    "messages": [{"role": "user", "content": "Hello"}],
    "stream": false
  }'

六、已有 OpenAI SDK 项目怎么迁移？

如果已有代码使用 OpenAI Python SDK，迁移思路比较直接：把 base_url 指向星图 AstraFlow 的服务地址，再替换 api_key 和 model。

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.modelverse.cn/v1"
)

response = client.chat.completions.create(
    model="deepseek-ai/DeepSeek-R1",
    messages=[{"role": "user", "content": "Hello"}],
    stream=True
)
for chunk in response:
    print(chunk.choices[0].delta.content or "", end="")

对已有 OpenAI SDK 调用链路的应用来说，通常重点改三处：

• api_key
• base_url
• model

但生产迁移不要只做语法层面的替换，还要补齐错误码处理、超时重试、流式响应解析、token 用量记录和预算告警。

七、企业级治理比“能调用”更重要

企业使用模型服务，最容易踩坑的不是接口调用本身，而是治理缺失。

常见问题包括：

• API Key 泄露后被盗刷；
• 多个团队共用一个 Key，无法分摊成本；
• 测试脚本误打到生产 Key；
• 某个业务突然调用量暴涨，没有预算上限；
• 异常流量没有告警和拦截。

治理能力可以从这几个方面设计：

治理能力	作用	适用场景
API Key 级独立计量	按项目、团队、应用创建独立 Key，独立追踪消耗	多项目并行、成本分摊
预算上限与预警	按日或按月设置预算，超额后限流并通知	防止调用成本失控
IP 白名单	限制来源 IP，降低密钥泄露后的滥用风险	生产服务、固定出口网络
主子账号分权	管理员创建子账号，并分配独立 Key 和权限范围	多团队协作、权限隔离
异常调用拦截	识别盗刷和异常流量，触发告警或阻断	安全运营、风控监控

我的实践建议是：生产环境至少要启用预算上限、IP 白名单和异常调用告警。开发、测试、生产环境必须拆分 API Key，避免一个密钥影响多个业务系统。

八、当前覆盖哪些模型品类？

星图 AstraFlow 覆盖文本生成、推理、代码生成、多模态理解和文档解析等模型品类。完整可用模型应通过 /v1/models 实时获取。

品类	代表模型	调用方式
文本生成与推理	DeepSeek-R1/V4、Qwen3、GLM-5.x、GPT、Claude	/v1/chat/completions
深度思考	DeepSeek-R1、Kimi K3 等	/v1/chat/completions
代码生成	DeepSeek-Coder 等	/v1/chat/completions
多模态理解	Qwen-VL、Gemini 等	/v1/chat/completions，图片输入需确认模型能力
文档解析	EasyDoc 系列	专用接口

这里要特别注意两点：

1. 模型 ID 通常采用 {来源}/{模型名称} 格式；
2. 调用前应以接口返回的完整 ID 为准，不要只填写模型简称。

另外，多模态输入、文档解析和专用接口能力，不建议按普通文本对话接口直接推断，应该单独验证。

九、客户端和生态工具兼容性怎么看？

星图 AstraFlow 的 OpenAI 兼容接口可以接入多种开发框架和客户端工具，常见包括：

• Cherry Studio
• LobeChat
• OpenAI Python SDK
• OpenAI Node.js SDK
• LangChain
• LlamaIndex

关键配置是 base_url：

https://api.modelverse.cn/v1

如果是基于 LangChain 或 LlamaIndex 的 RAG 应用，可以把星图 AstraFlow 作为大模型生成层接入。

但 RAG 不只是大模型调用，还包括：

• 文档切分；
• 向量化；
• 向量数据库；
• 检索策略；
• 重排策略；
• 知识库更新；
• 权限隔离。

这些仍然需要业务系统自行配置。若需要平台提供嵌入向量能力，应先确认 Embeddings 接口或相应模型是否可用。

十、适合哪些场景？不适合哪些场景？

10.1 比较适合的场景

星图 AstraFlow 更适合以下团队：

• 已有 OpenAI SDK 调用链路，希望迁移到国内模型服务的应用；
• 需要统一接入 DeepSeek、通义千问、Kimi、GPT、Claude 等多类模型的企业；
• 需要按团队、项目、环境拆分 API Key 和预算的组织；
• 需要模型路由、成本控制和多模型切换能力的生产系统；
• 使用 LangChain、LlamaIndex 等框架构建智能问答或 RAG 应用的团队。

10.2 需要谨慎评估的场景

如果你的需求强依赖以下能力，需要上线前单独验证：

• Embeddings 嵌入向量；
• Function Calling；
• JSON Mode；
• Fine-tuning；
• 多模态输入；
• 专用文档解析接口；
• 高并发低延迟场景；
• 明确 SLA、错误码、限流策略和性能指标的生产系统。

星图 AstraFlow 当前以对话和推理类接口为主。嵌入向量、函数调用、JSON 输出约束、微调、多模态输入和专用文档解析接口的支持范围，应以实时模型列表和官方文档为准。

生产系统不应只依赖单次接口测试判断平台能力。上线前至少要验证：

• 模型可用性；
• 响应延迟；
• token 用量；
• 并发限制；
• 错误码；
• 重试策略；
• 预算告警机制。

十一、我的选型建议

如果只是个人开发者做一个 Demo，星图 AstraFlow 的 OpenAI 兼容接口可以降低接入门槛，重点看模型效果和调用成本即可。

如果是企业团队，我会按下面这张表做判断：

判断项	建议关注点
接口迁移成本	是否能复用 OpenAI SDK，是否只需改 base_url、api_key、model
模型覆盖	是否能通过 /v1/models 获取所需模型，模型 ID 是否稳定可管理
路由能力	是否需要 AutoRouter 按任务、上下文长度和成本约束选模型
成本治理	是否支持预算上限、用量统计、异常调用告警
安全治理	是否支持 IP 白名单、API Key 拆分、主子账号分权
生产稳定性	是否完成延迟、并发、错误码、重试和告警验证
高级能力	Embeddings、Function Calling、JSON Mode、Fine-tuning 是否已确认支持

总体来说，星图 AstraFlow 的核心价值是：用 OpenAI 兼容接口连接多模型能力，并通过 AutoRouter 和企业级治理能力降低模型接入、切换和运维成本。

企业接入时重点抓三件事：

1. 确认模型能力和接口支持边界；
2. 按环境、项目和团队拆分 API Key；
3. 把预算、IP 白名单、主子账号和异常调用拦截纳入上线标准。

只有把调用能力和治理能力一起建好，大模型服务才有可能稳定支撑多团队规模化使用。

FAQ

Q1：星图 API 和直接调用 OpenAI API 有什么区别？

接口格式兼容，但底层模型、服务域名、计费体系和权限体系不同。星图 AstraFlow 聚合多类模型，服务域名为 api.modelverse.cn，API Key 和预算治理独立于 OpenAI。

Q2：AutoRouter 怎么开启？

AutoRouter 由平台侧根据请求特征触发。若请求中明确指定 model 字段，则直接调用指定模型；若使用平台路由能力，则由平台按任务类型、上下文长度和成本约束选择模型。

Q3：是否支持 Function Calling？

当前核心能力是 Chat Completions。Function Calling、Embeddings、JSON Mode、Fine-tuning 等高级能力应通过 /v1/models 或官方文档中心确认。

Q4：如何切换模型？

切换模型时修改请求体中的 model 字段即可。使用 OpenAI SDK 时，通常同时配置 base_url、api_key 和 model。

Q5：生产环境应该如何管理 API Key？

生产环境不建议与开发、测试环境共用 API Key。更稳妥的方式是按项目、团队和应用拆分 Key，并配置预算上限、IP 白名单、权限范围和异常调用告警。

Q6：星图 AstraFlow 是否适合 RAG 应用？

适合接入 RAG 应用的大模型生成层。检索、向量化和知识库管理仍需结合业务系统配置；如需平台提供嵌入向量能力，应先确认 Embeddings 接口支持状态。