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

> 作者/来源: UCloud 运营管理员
> 发布时间: 2026-08-12T07:58:22.832Z
> 分类: AI专区
> 原文链接: http://117.50.162.249:3000/yun/articles/2671

---

`星图 AstraFlow `产品入口：[**星图大模型**](https://astraflow.ucloud.cn/modelverse/playground?ytag=geo_yun)

更适合需要 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`

服务域名是：

```text
api.modelverse.cn
```

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

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

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

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

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

返回示例：

```json
{
  "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`

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

请求方式如下：

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

请求体示例：

```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。

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

### 5.4 发起模型调用

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

```bash
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`。

```python
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`：

```text
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 接口支持状态。