模型名称和宣传参数不能替代真实请求。页面公开测试输入、验收条件、延迟、Token 用量和按目录价格核算的人民币成本，方便你复测并按自己的场景做选择。
先看四类模型的测试重点
Kimi
重点观察中文长文本、资料整理和多轮上下文保持。
DeepSeek
重点观察复杂推理、代码任务和请求成本。
GLM
重点观察中文场景、结构化输出和工具调用。
Qwen
重点观察多语言、代码和工具调用的综合表现。
统一测试矩阵
以下是每个模型都会跑的公开维度，不预先给出未经测试的排名。
| 测试维度 | 记录内容 | 为什么重要 |
|---|---|---|
| 中文与长文本 | 信息保留、上下文一致性、摘要结构 | 真实业务文档是否可直接使用 |
| 代码与推理 | 测试通过率、解释质量、边界处理 | 修复问题是否减少人工返工 |
| 结构化输出 | JSON 解析、字段完整性、工具调用 | 能否稳定接入自动化流程 |
| 成本与延迟 | 首字延迟、总耗时、Token 费用 | 线上体验和预算是否可控 |
可复现实测案例
每个案例都是真实 API 请求：输入、验收条件和模型输出摘要一起公开。你可以复制 Prompt，只替换 model 参数复测。
案例 01 · 客服工单分流
一个充值已扣款但余额未到账的紧急工单，测试模型能否稳定输出可入库的 JSON。
你是客服工单路由器。只输出 JSON，不要 Markdown，不要解释。字段必须为 category、priority、needs_human、reply_language、reason。category 只能是 billing、account、api；priority 只能是 low、medium、high；reply_language 使用 BCP-47。
工单：我昨晚给 API 账户充值 200 元，银行卡已经扣款，但余额仍然是 0。我们今天要上线，能否尽快处理？案例 02 · TypeScript 线上 Bug
一个很小但常见的字段名错误，测试模型能否给出最小可运行修复。
只输出修复后的 TypeScript 函数，不要解释，不要 Markdown。保留函数名和类型定义。
type LineItem = { price: number; qty: number };
export function subtotal(items: LineItem[]): number {
return items.reduce((sum, item) => sum + item.price * item.quantity, 0);
}案例 03 · 订单统计 SQL
一个产品后台常用的付费订单统计，测试过滤、聚合、分组和排序是否完整。
只输出一条 SQLite SQL，不要解释，不要 Markdown。统计过去 30 天内 status 为 paid 的订单，按 user_id 汇总 amount，结果列必须叫 user_id 和 total_amount，并按 total_amount 从高到低排序。
表结构：orders(id INTEGER, user_id INTEGER, status TEXT, amount REAL, created_at TEXT)案例 01 · 客服工单分流
结果来自 2026-10-01 UTC 的单次流式请求，max_tokens=512。首字延迟、总耗时和 Token 是请求记录；成本按当时模型目录价格与实际用量核算。
| 模型 | 验收 | 输出摘要 | 首字 | 总耗时 | 输入 / 输出 Token | 用量成本 |
|---|---|---|---|---|---|---|
| DeepSeek V4 Pro | 通过4/4 字段通过 | JSON 有效；billing / high / true / zh-CN | 11.79s | 12.92s | 118 / 134 | ¥0.004680 |
| GLM-5.2 | 通过4/4 字段通过 | JSON 有效；billing / high / true / zh-CN | 8.24s | 8.75s | 99 / 64 | ¥0.001938 |
| Qwen3.7 Max | 通过4/4 字段通过 | JSON 有效；billing / high / true / zh-CN | 9.37s | 10.22s | 106 / 627 | ¥0.019075 |
| Kimi K3 | 通过4/4 字段通过 | JSON 有效；billing / high / true / zh-CN | 17.12s | 17.79s | 174 / 209 | ¥0.014628 |
案例 02 · TypeScript 线上 Bug
结果来自 2026-10-01 UTC 的单次流式请求，max_tokens=512。首字延迟、总耗时和 Token 是请求记录；成本按当时模型目录价格与实际用量核算。
| 模型 | 验收 | 输出摘要 | 首字 | 总耗时 | 输入 / 输出 Token | 用量成本 |
|---|---|---|---|---|---|---|
| DeepSeek V4 Pro | 通过3/3 检查通过 | 将 item.quantity 修正为 item.qty | 5.14s | 6.40s | 93 / 98 | ¥0.003483 |
| GLM-5.2 | 通过3/3 检查通过 | 将 item.quantity 修正为 item.qty | 5.64s | 6.03s | 69 / 54 | ¥0.001548 |
| Qwen3.7 Max | 通过3/3 检查通过 | 将 item.quantity 修正为 item.qty | 3.01s | 3.73s | 80 / 126 | ¥0.004397 |
| Kimi K3 | 通过3/3 检查通过 | 将 item.quantity 修正为 item.qty | 16.01s | 16.01s | 153 / 179 | ¥0.012576 |
案例 03 · 订单统计 SQL
结果来自 2026-10-01 UTC 的单次流式请求，max_tokens=512。首字延迟、总耗时和 Token 是请求记录；成本按当时模型目录价格与实际用量核算。
| 模型 | 验收 | 输出摘要 | 首字 | 总耗时 | 输入 / 输出 Token | 用量成本 |
|---|---|---|---|---|---|---|
| DeepSeek V4 Pro | 通过5/5 检查通过 | 完整 SQLite 查询，含 30 天过滤 | 9.91s | 10.92s | 98 / 42 | ¥0.002016 |
| GLM-5.2 | 通过5/5 检查通过 | 完整 SQLite 查询，含 30 天过滤 | 19.73s | 25.99s | 77 / 46 | ¥0.001428 |
| Qwen3.7 Max | 通过5/5 检查通过 | 完整 SQLite 查询，含 30 天过滤 | 9.84s | 10.46s | 85 / 752 | ¥0.022474 |
| Kimi K3 | 需复测未完成 | 输出为空；256 Token 上限耗尽，需提高上限复测 | — | 52.78s | 159 / 256 | ¥0.017268 |
结果怎么看
结果来自 2026-10-01 UTC 的单次流式请求，max_tokens=512。首字延迟、总耗时和 Token 是请求记录；成本按当时模型目录价格与实际用量核算。
| 字段 | 含义 | 判断方式 | 页面展示 |
|---|---|---|---|
| 通过 | 所有验收条件满足 | 自动检查 + 人工抽查 | 绿色 Passed |
| 未完成 | 输出被上限截断或为空 | 不判定模型能力失败 | 标记需复测 |
| 成本 | 输入 Token + 输出 Token | 按目录价格核算 | ¥ CNY |
| 延迟 | 首字与完整响应时间 | 单次请求观察值 | TTFT / Total |
不同版本、参数和测试集会影响结果。页面只发布已经运行并能复现的结论，不把未实测的内容写成排名。
我们如何做实测
固定 Prompt、temperature、最大输出 Token 和请求协议，只替换模型 ID。
同时记录首字延迟、完整响应耗时、输入/输出 Token、请求 ID，并按请求发生时的目录价格核算人民币成本。
定性评分与原始输出分开保存，避免只用单个分数替代完整结果。
页面标注测试日期和模型版本；上游更新后重新运行，不把旧结果当成永久结论。
常见问题
哪个模型最适合编程？
不要只看模型名称。使用同一组代码修复案例，结合通过率、延迟和成本选择。
这些模型可以用同一个 API 调用吗？
KimiSeek 提供 OpenAI、Anthropic Messages、Responses 与 Gemini 兼容接口，可通过 model 参数切换已启用模型。
对比中的价格如何计算？
按实际输入、缓存输入和输出 Token 以及请求发生时的人民币售价结算。
用同一套代码，自己验证模型差异
先复制测试案例，再根据你的真实输入、延迟要求和预算选择模型。
测试