模型与参数 - Tapapi 文档

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

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

常用参数

参数	用途	建议
`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、工具调用和长上下文能力都和具体模型、渠道有关。模型详情页和控制台优先于静态文档。

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

参数起点

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

选型思路

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

验证清单

验证项	看什么
参数透传	`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 处理所有模型