# 4.5 模型检查

## 功能说明

模型检查功能（也称为 **Stream Check**）用于验证供应商配置的模型是否可用，通过发送实际的 API 请求来测试：

- 模型是否存在
- API Key 是否有效
- 端点是否正常响应
- 响应延迟是否正常
- 流式响应首字节时间（TTFB）

v3.13.0 起，Stream Check 覆盖范围扩展到 **Claude / Codex / Gemini / OpenCode / OpenClaw**，包括 OpenClaw 的全部协议变体（`openai-completions` 等）。OpenCode 通过 npm 包映射自动识别；OpenClaw 支持自定义 `auth-header` 检测，并处理了 Bedrock 错误消息、`baseURL` 回退等边界情况。

对于使用 Chat Completions 协议的 Codex 第三方供应商（如 DeepSeek、Kimi、MiniMax），Stream Check 会探测 `/chat/completions` 端点（而非 `/responses`），并与代理实际转发的 URL 顺序保持一致（origin-only 地址优先尝试 `/v1/...`），避免把可用供应商误判为不可用。

## 打开配置

设置 → 高级 → 模型测试

## 测试模型配置

为每个应用配置用于测试的模型：

| 应用     | 配置项        | 默认值   | 说明                                         |
| -------- | ------------- | -------- | -------------------------------------------- |
| Claude   | Claude 模型   | 系统默认 | 建议使用 Haiku 系列（成本低、速度快）        |
| Codex    | Codex 模型    | 系统默认 | 建议使用 mini 系列                           |
| Gemini   | Gemini 模型   | 系统默认 | 建议使用 Flash 系列                          |
| OpenCode | OpenCode 模型 | 系统默认 | v3.13.0 新增，通过 npm 包映射自动检测        |
| OpenClaw | OpenClaw 模型 | 系统默认 | v3.13.0 新增，覆盖全部协议变体及自定义 auth-header |

### 模型选择建议

选择测试模型时考虑：

1. **成本**：选择价格较低的模型（如 Haiku、Mini、Flash）
2. **速度**：选择响应快的模型
3. **可用性**：选择供应商支持的模型

## 检查参数配置

### 超时时间

| 参数 | 说明 | 默认值 | 范围 |
|------|------|--------|------|
| 超时时间 | 单次请求超时 | 45 秒 | 10-120 秒 |

设置过短可能导致误判，设置过长会延迟故障检测。

### 重试次数

| 参数 | 说明 | 默认值 | 范围 |
|------|------|--------|------|
| 最大重试 | 失败后重试次数 | 2 次 | 0-5 次 |

网络不稳定时建议增加重试次数。

### 降级阈值

| 参数 | 说明 | 默认值 | 范围 |
|------|------|--------|------|
| 降级阈值 | 响应超过此时间标记为降级 | 6000ms | 1000-30000ms |

超过阈值的供应商会被标记为「降级」状态，但仍可使用。

## 执行模型检查

### 手动测试

在供应商卡片上点击「测试」按钮：

1. 发送测试请求到配置的端点
2. 使用配置的测试模型
3. 等待响应或超时
4. 显示测试结果

### 测试内容

测试请求会：
- 发送简短的 prompt（如 "Hi"）
- 限制最大输出 token（通常 10-50）
- 使用流式响应检测首字节时间

## 测试结果

### 健康状态

| 状态 | 图标 | 说明 |
|------|------|------|
| 健康 | 🟢 | 响应正常，延迟在阈值内 |
| 降级 | 🟡 | 响应正常，但延迟超过阈值 |
| 不可用 | 🔴 | 请求失败或超时 |

### 结果信息

测试完成后显示：
- 响应延迟（毫秒）
- 首字节时间（TTFB）
- 错误信息（如果失败）

## 与故障转移集成

模型检查与故障转移功能配合使用：

### 健康检查

开启代理服务后，系统会定期对故障转移队列中的供应商执行健康检查：

1. 使用配置的测试模型发送请求
2. 根据响应更新健康状态
3. 不健康的供应商会被暂时跳过

### 熔断恢复

当供应商从熔断状态恢复时：

1. 执行模型检查验证可用性
2. 检查通过后恢复正常状态
3. 检查失败则继续熔断

## 常见问题

### 测试失败但实际可用

**可能原因**：
- 测试模型与实际使用的模型不同
- 供应商不支持配置的测试模型

**解决方法**：
- 修改测试模型为供应商支持的模型
- 检查供应商的模型列表

### 延迟过高

**可能原因**：
- 网络延迟
- 供应商服务器负载高
- 模型响应慢

**解决方法**：
- 使用更快的测试模型
- 调整降级阈值
- 考虑使用镜像端点

### 频繁超时

**可能原因**：
- 超时时间设置过短
- 网络不稳定
- 供应商服务不稳定

**解决方法**：
- 增加超时时间
- 增加重试次数
- 检查网络连接

## 注意事项

- 模型检查会消耗少量 API 配额
- 建议使用低成本模型进行测试
- 测试频率不宜过高，避免浪费配额
- 不同供应商支持的模型可能不同