对话模型

使用对话模型进行文本生成、编程协助、推理、信息提取和多轮助手工作流。本页帮助你选择对话模型。发送请求时，请使用规范的 Chat Completions API 指南。

选择模型

从 Models 表开始，并比较这些字段：

初始测试时，选择 qwen3.5-flash 这样的低成本 live 模型。对于 coding-heavy workloads，先从 kimi-k2.7-code 这样的编程导向模型开始。对于长文档或 agent workflows，请选择 context 足够容纳完整 prompt 和预期工具输出的模型。

常见选择模式

上下文规划

Chat requests 包含你在 messages 中发送的一切：system instructions、用户输入、前序轮次、检索文档和工具结果。更大的 context 很有用，但也会增加 input-token spend。

上线 workload 前：

• 估算现实中最大的 prompt。
• 在估算中包含对话历史和检索上下文。
• 如果模型会调用 functions，请为工具输出留出空间。
• 将 max_tokens 设置得足够低，以控制失控的输出成本。
• 使用 summarization 或 retrieval，而不是发送无边界历史。

定价说明

Chat model pricing 通常拆分为输入和输出 token。选择模型前请同时比较两列。

• 对于短 prompts、长回答，输出价格更重要。
• 对于 agents、RAG 和多轮 chat，输入价格通常占主导。
• 对于 coding tasks，context size 可能比原始 token price 更重要。
• 对于生产环境，路由新流量前请重新检查 Models 页面，因为模型可用性和 pricing 可能变化。

路由

默认情况下，请省略 route，让 OpenModels 使用所选模型的默认可用路由。只有在测试、合规、延迟或确定性成本比较需要特定供应商时，才固定供应商路由。

请求结构和 route.provider 语法见 Chat Completions。

生产检查清单

将 chat workload 投入生产前：

• 确认模型在 Models 表中处于 live 状态。
• 确认所选模型有足够 context。
• 根据预期 usage 检查输入和输出价格。
• 为 API 密钥添加积分并配置月度支出限额。
• 决定工作负载是否需要流式传输或函数调用。
• 记录 model ID、token usage、request ID 和 gateway errors。

后续步骤

• Chat Completions：发送 chat requests。
• Streaming：以 server-sent events 流式传输生成文本。
• Function Calling：向兼容模型暴露工具。
• 定价指南：理解 token pricing 和 route costs。