没有 playground 时怎么选模型：用一把 key 现场调用做一张决策表

为什么要自己建决策表

很多聚合站没有 Playground，选模型时只能凭印象。不同模型在延迟、输出风格和 token 消耗上差异明显，靠猜容易选错。一个低成本的办法是：用同一把 key 给每个后端各发一次真实请求，记录关键指标，再按任务类型建表。

准备工作

• 确认 key 可以调用全部目标模型（Claude、GPT、DeepSeek、Qwen、GLM、Kimi）。
• 准备一个贴近实际任务的 prompt，长度适中，避免极端长文本影响判断。
• 记录调用前后的时间戳，用于估算时延。
• 保存每次返回的 token 用量（如果接口提供）或自行估算。
• 注意：这里的实测只用于相对比较，不是基准测试。

实测步骤

1. 对每个模型发送同一条请求，使用相同的参数（如 temperature、max_tokens）。
2. 记录从发出请求到收到完整响应的时间，作为端到端时延。
3. 记录输入和输出 token 数，结合聚合站的计费规则（官方价 ×1.3）估算单次调用花费。
4. 保存输出文本，观察格式是否稳定、是否容易解析、是否包含多余解释。
5. 每个模型重复 2–3 次，取中位数减少抖动影响。

记录哪些指标

| 指标 | 说明 |
|------|------|
| 首字时延 | 从请求到收到第一个 token 的时间（如可测） |
| 总时延 | 从请求到响应结束的时间 |
| 输入 token | 用于成本估算 |
| 输出 token | 用于成本估算 |
| 单次花费 | 按官方价 ×1.3 估算 |
| 输出形态 | 是否结构化、是否啰嗦、是否遵守格式 |
| 稳定性 | 多次调用结果是否一致 |

如何整理成决策表

把任务类型作为行，模型作为列，填入实测得到的时延和花费档位，并标注输出形态是否满足需求。例如：

• 需要快速响应的任务：优先看首字时延和总时延。
• 需要严格格式的任务：优先看输出是否稳定、是否容易解析。
• 对成本敏感的任务：优先看单次花费，结合 token 消耗判断。
• 需要长输出的任务：注意输出 token 对花费的影响。

最终表格可以用简单的 markdown 或表格工具维护，每次模型更新后重新实测一轮。

注意事项

• 实测结果受网络、时段、模型负载影响，只适合做相对排序。
• 聚合站按官方价 ×1.3 扣费，估算花费时以此为准，不要用其他折扣做假设。
• 贡献 key 的返利规则（×1.1 或 ×1.2）不影响调用方的花费计算。
• 不要用一次调用下结论，多试几次更可靠。

结语

没有 Playground 也能选模型：用一把 key 做一轮低成本实测，把时延、花费和输出形态记下来，整理成自己的决策表。随着任务变化和模型更新，定期重测即可保持表格有效。