选择模型服务类型¶
产品内部区分 LLM、Embedding 和 Parser 三类 Provider。先根据调用方任务选择类型，再在对应根路径下配置 Backend、Endpoint 和 Router。
类型差异¶
类型 |
根路径 |
主要用途 |
类型专属能力 |
|---|---|---|---|
LLM |
|
生成、推理、抽取和智能体对话 |
模型列表、地址探测、Backend 模型探测和一体化 Setup |
Embedding |
|
为语义模型和检索生成向量 |
Embedding 模型列表、地址探测和 Backend 模型探测 |
Parser |
|
把支持的文档转换为可处理内容 |
Backend 声明 |
三种类型共享相似路径，但请求字段并不完全对称。LLM 和 Embedding Backend 创建时需要模型列表；Parser Backend 使用支持的 MIME 类型，不应发送模型探测请求。
查看产品可选模型¶
产品模型列表用于 Provider 配置和产品内选择器，不等于 Genesis GET /models：
curl "$PRODUCT_API_BASE_URL/models" \
-H "X-API-Key: $PRODUCT_API_KEY" \
-H "X-Workspace-ID: $WORKSPACE_ID"
Embedding 模型使用：
GET /embedding/models
列表项包含模型 ID、Backend ID、Backend 名称、模型类型、来源和系统默认标记等当前可用字段。使用 backend_id 关联具体 Backend；不要只根据模型显示名推断服务来源。
探测远程服务¶
在创建 LLM 或 Embedding Backend 前，可以对服务地址运行模型探测：
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 是不同凭据，不得互换。