# 选择模型服务类型

产品内部区分 LLM、Embedding 和 Parser 三类 Provider。先根据调用方任务选择类型，再在对应根路径下配置 Backend、Endpoint 和 Router。

## 类型差异

| 类型 | 根路径 | 主要用途 | 类型专属能力 |
| --- | --- | --- | --- |
| LLM | `/llm` | 生成、推理、抽取和智能体对话 | 模型列表、地址探测、Backend 模型探测和一体化 Setup |
| Embedding | `/embedding` | 为语义模型和检索生成向量 | Embedding 模型列表、地址探测和 Backend 模型探测 |
| Parser | `/parser` | 把支持的文档转换为可处理内容 | Backend 声明 `supported_mime_types`；不提供模型探测 |

三种类型共享相似路径，但请求字段并不完全对称。LLM 和 Embedding Backend 创建时需要模型列表；Parser Backend 使用支持的 MIME 类型，不应发送模型探测请求。

## 查看产品可选模型

产品模型列表用于 Provider 配置和产品内选择器，不等于 Genesis `GET /models`：

```bash
curl "$PRODUCT_API_BASE_URL/models" \
  -H "X-API-Key: $PRODUCT_API_KEY" \
  -H "X-Workspace-ID: $WORKSPACE_ID"
```

Embedding 模型使用：

```text
GET /embedding/models
```

列表项包含模型 ID、Backend ID、Backend 名称、模型类型、来源和系统默认标记等当前可用字段。使用 `backend_id` 关联具体 Backend；不要只根据模型显示名推断服务来源。

## 探测远程服务

在创建 LLM 或 Embedding Backend 前，可以对服务地址运行模型探测：

```bash
curl -X POST "$PRODUCT_API_BASE_URL/llm/probe-models" \
  -H "X-API-Key: $PRODUCT_API_KEY" \
  -H "X-Workspace-ID: $WORKSPACE_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "address": "<PROVIDER_ENDPOINT>",
    "api_key": "<PROVIDER_API_KEY>"
  }'
```

成功响应的 `data.models[]` 是该地址在本次探测中返回的模型。探测成功只能说明当时的网络、凭据和模型发现请求可用，不保证长期可用性、配额或模型输入能力。

## 与 Genesis 的边界

- Provider 配置面向平台管理员或模型基础设施开发者，影响产品内部任务。
- Genesis 模型 API 面向业务应用，使用 Genesis 凭据和兼容接口发起推理。
- Product PAT、Provider API Key 和 Genesis API Key 是不同凭据，不得互换。

## 下一步

- [创建 Backend 和 Endpoint](provider-backend.md)
- [配置同一类型的 Router](router.md)
- [使用 Genesis 模型 API 调用模型](../../genesis-model-api/getting-started/quickstart.md)