> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tapapi.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 模型与参数

> 文本模型的选择方式和常用参数

文本模型选择先看任务类型，再看成本、上下文长度、速度和输出质量。不要一开始就把所有任务都放到最贵模型上，建议先用真实样本做小规模评估。

<Note>模型可用性、上下文长度和价格以控制台为准。文档里的参数建议是通用起点，生产环境仍需实测。</Note>

## 常用参数

| 参数                  | 用途     | 建议                            |
| ------------------- | ------ | ----------------------------- |
| `model`             | 选择文本模型 | 必填，以控制台可用模型为准                 |
| `messages`          | 对话上下文  | 必填，至少包含一条 `user` 消息           |
| `temperature`       | 控制随机性  | 稳定任务低一些，创意任务高一些               |
| `top_p`             | 控制采样范围 | 通常保持默认，不要和 `temperature` 同时大改 |
| `max_tokens`        | 限制输出长度 | 防止长输出失控                       |
| `presence_penalty`  | 话题重复惩罚 | 仅在目标模型支持时使用                   |
| `frequency_penalty` | 词频重复惩罚 | 仅在目标模型支持时使用                   |
| `stream`            | 是否流式返回 | 聊天 UI 建议开启                    |
| `stream_options`    | 流式附加选项 | 需要统计 usage 时可验证是否支持           |
| `response_format`   | 结构化输出  | 视模型支持情况而定                     |
| `tools`             | 工具调用   | 视模型支持情况而定                     |
| `tool_choice`       | 工具选择策略 | 视模型支持情况而定                     |

严格 JSON、JSON Schema、工具调用和长上下文能力都和具体模型、渠道有关。模型详情页和控制台优先于静态文档。

<Warning>`max_tokens` 不只是“输出上限”。在计费预估和额度预占场景里，它也会影响系统对本次请求最大输出成本的判断。生产环境不要把它随手设得过大。</Warning>

## 参数起点

| 任务         | temperature   | 说明        |
| ---------- | ------------- | --------- |
| 分类、标签、字段提取 | `0` - `0.3`   | 追求稳定和一致   |
| 摘要、改写、翻译   | `0.3` - `0.7` | 兼顾稳定和表达   |
| 创意文案、头脑风暴  | `0.7` - `1`   | 允许更多变化    |
| JSON 输出    | `0` - `0.3`   | 配合明确格式和校验 |

## 选型思路

1. 简单分类、摘要、改写：优先看成本和速度
2. 长上下文、复杂推理：优先看上下文长度和稳定性
3. 代码生成、工具调用：优先看指令遵循和结构化输出
4. 生产默认模型：用真实请求测成功率、耗时和成本
5. 兜底模型：选择一个更稳或更便宜的模型，用于失败重试或降级

## 验证清单

| 验证项   | 看什么                                                                 |
| ----- | ------------------------------------------------------------------- |
| 参数透传  | `temperature`、`top_p`、`max_tokens` 是否被目标模型接受                        |
| 输出长度  | 长输入和短输入下是否会提前截断                                                     |
| 结构化输出 | JSON 是否能稳定 parse，字段是否完整                                             |
| 工具调用  | `tools`、`tool_choice` 是否返回预期 tool call                              |
| 流式输出  | 是否有首 token 延迟、ping 事件、usage chunk                                   |
| 成本    | 同一批样本的平均耗时、平均用量和失败率                                                 |
| 错误结构  | 是否能拿到 HTTP 状态码、`error.code`、`error.message` 和 `X-Oneapi-Request-Id` |

## 生产建议

* 先用默认参数跑通，不要一开始调太多参数
* 每个业务场景保留 20-50 条真实样本做回归测试
* 记录模型名、参数、耗时、错误码、成本和 `X-Oneapi-Request-Id`
* 不同模型对 `tools`、`response_format`、长上下文的支持不同，接入前单独验证
* 文本、图片、视频接口的响应结构不同，不要用同一个 parser 处理所有模型