结论先说： 公平对比两个大模型 API 入口，必须固定除 Base URL 和 API Key 以外的条件，在多个时段重复采样，并把兼容性、质量、稳定性、Token 和账单分开记录。只比较一张测速截图或一道固定题，结论不可复现。
比较前先定义决策问题
不同业务需要不同权重。先写清楚这次测试要决定什么：
- 普通对话：关注成功率、首字节延迟、上下文和价格。
- 代码 Agent：关注工具调用、结构化参数、长任务稳定性和 Responses API 等真实协议需求。
- 内容生产：关注约束遵循、事实错误、长文一致性和人工返工时间。
- 批处理：关注吞吐、429、重试成本、账单可核对性和失败恢复。
没有明确业务目标时，综合总分很容易掩盖真正的阻断项。
控制变量
除服务地址和密钥外，以下条件必须一致：
| 变量 | 要求 |
|---|---|
| 模型 | 使用双方明确支持的同一模型或已公开的等价映射 |
| 请求参数 | 固定 temperature、max_tokens、top_p、stream |
| 提示词 | 使用同一份版本化题集，不临时改写 |
| 客户端 | 使用同一脚本、SDK 版本、网络和超时 |
| 时段 | 在接近的时间窗口交替请求，降低网络与高峰偏差 |
| 重试 | 记录原始失败，重试次数和退避规则保持一致 |
如果两个入口返回的模型 ID 或协议并不等价，应标记为不同产品，不要强行合并成“同模型横评”。
AI快站 HK 的对照记录怎么填写？
下面是空白记录模板，不是已完成的测速或账单结果。先按 HK 快速开始 取得该站 Key 和模型 ID，再用同一脚本交替测试两个入口。
| 记录项 | AI快站 HK | 对照入口 |
|---|---|---|
| OpenAI Compatible Base URL | https://www.aifast.hk/v1 |
填写该服务的真实 Base URL |
| 认证与模型 | HK 账号的独立限额 Key、目录中的完整模型 ID | 对照账号的独立 Key、可核验的等价模型 |
| 路由与价格 | 记录 HK 分组、模型映射、价格查询时间 | 记录对照分组、映射与同一时点的价格 |
| 抽样与原始证据 | HK 模型检测工具 分项结果、脱敏请求 ID | 同模式分项结果、脱敏请求 ID |
| 业务协议 | 分别验证 Chat Completions、Responses 或 Messages 的实际需求 | 使用同一协议和验收条件 |
| 结果与账单 | 填写实际日志和 HK 控制台用量，不预填通过 | 填写对照日志和控制台用量 |
HK 模型检测工具的 Chat Completions 抽样不能证明 Responses 或 Anthropic Messages 完整兼容。Agent 场景还需按 Codex 检查清单 或 Claude Code 检查清单 执行原生客户端任务。无法确认模型映射或价格单位一致时，保留两组结果，不输出“同模型更便宜”的结论。
从 HK 检测报告到可比较记录
HK 工具的一轮检测和一次模型调用不是同一个统计单位。先用下表核对实际报告字段，再填入自己的原始请求记录；工具没有测量的数据必须留空，不能从总分推算。
| 报告信息 | 可以用于 | 不能替代 |
|---|---|---|
| 报告编号、检测时间、请求地址、请求与响应模型 | 定位同一配置的检测轮次 | 上游请求 ID、模型身份认证 |
| 整轮用时、请求数量 | 比较同模式探针的执行情况 | 单次聊天的首字延迟、P50/P95、并发容量 |
| 分项状态与证据 | 核对 SSE、工具调用和协议失败 | 真实业务任务的成功率 |
| Token 汇总与完整性标记 | 核对已返回的用量及缺失项 | HK 控制台实际扣费、另一提供商的账单 |
| 快速或标准模式 | 确保比较范围一致 | 将快速模式未执行的项目记为通过 |
检测由 HK Docs 边缘服务向目标端点发起，不是从用户本机直连测速。快速模式通常尝试 3 次请求，标准模式通常尝试 7 次，其中包括模型目录请求；请求计数也不能当作成功聊天次数。模型生成请求可能计费，应使用临时限额 Key；达到整轮时限时，实际发出的请求可能少于尝试次数。
可下载 空白对照 CSV。文件只有列名，没有预填成绩，也不会自动读取账号或上传检测结果。每轮填写一行，先记录检测模式与 Token 是否完整，再关联自己保存的脱敏证据。计分与导出范围见 HK 检测报告说明。
测试单次聊天延迟时，应使用相同客户端另行记录首个有效内容事件与完成时间；浏览器页面加载时间、HTTP 首字节和模型首个内容 Token 是不同指标。测试成本时，按同一时区、分组、完整模型 ID 与请求 ID 核对 HK 用量记录，无法匹配的费用单列，不用 Token 总量强行凑齐。
建议的四层题集
第一层：协议冒烟
验证 /models、最小聊天、错误响应、model、usage、SSE 和工具调用。协议不满足业务要求时，不必继续扩大样本。
第二层：动态能力题
每轮由本地脚本生成随机数、随机字段名或随机 nonce，检查计算、约束遵循和工具参数回传。动态题能降低固定答案污染，但不能证明底层模型身份。
第三层：公开任务
准备代码修复、信息抽取、长文约束、JSON Schema 和多轮对话等可自动判分任务。题目、期望结果和判分器要版本化。
第四层：真实业务样本
从历史失败案例中抽取并脱敏。记录任务完成率、人工修改时间和业务阻断原因。真实样本最有决策价值，但不能泄露用户数据或内部密钥。
原始记录模板
每次请求保留一行原始数据：
run_id,provider,started_at,model_requested,model_returned,http_status,first_byte_ms,total_ms,input_tokens,output_tokens,total_tokens,retry_count,probe_id,passed,error_type,request_id另建测试配置文件：
suite_version: "2026-07-14.1"
temperature: 0
max_tokens: 512
timeout_seconds: 60
retries: 0
stream: false
sample_windows:
- low_peak
- high_peak
- next_day不要记录完整 API Key、未脱敏提示词、用户文件或响应中的个人信息。请求 ID 也应确认不包含敏感数据后再公开。
需要计算的指标
可用性
- 原始成功率：首次请求返回有效结果的比例。
- 最终成功率：包含有限重试后的成功比例。
- 错误分布：401、429、5xx、超时、协议解析错误分别统计。
不要把无限重试后的成功算成入口稳定。首次失败率决定真实延迟和额外成本。
延迟
- 首字节延迟与首个内容 Token 延迟分别记录：收到 HTTP 字节或 SSE 心跳，不代表用户已经看到模型正文。
- 总耗时：任务完整结束需要多久。
- P50/P95：分别观察典型体验和尾部慢请求。
能力质量
- 约束遵循率。
- JSON 或工具参数解析成功率。
- 代码测试通过率。
- 真实业务一次完成率。
- 平均人工返工分钟数。
Token 与成本
分别汇总输入、输出、失败请求和重试 Token。再根据测试时的价格快照计算：
完整任务成本 = 成功请求费用 + 失败请求费用 + 重试费用 + 人工返工成本价格和模型开放状态会变化，报告中必须记录查询时间和来源，不能把一次快照写成永久价格。
样本量与判读边界
协议检查可以少量运行，但稳定性和延迟至少需要数十次请求才能看到初步分布。样本越少，越不应使用“必然更快”“绝对稳定”之类结论。
模型输出有随机性。即使 temperature=0，不同服务实现、版本和并行策略也可能产生差异。能力结论应结合多题、多轮和真实业务基线。
以下现象只能标记为“需要核实”：
- 返回
model与请求不一致。 usage缺失或 Token 算术异常。- 某轮动态题失败。
- 输出风格或知识 cutoff 自述变化。
只有多项证据持续出现并可复现，才适合升级风险等级。黑盒结果不能代替模型厂商证明。
发布报告时的最小结构
一份可审计的公开报告至少包含：
- 测试日期、地区、网络和客户端版本。
- 模型 ID、协议、参数和题集版本。
- 样本量、原始数据字段和失败是否计入。
- 成功率、P50/P95、能力指标、Token 与成本。
- 已知限制、异常解释和复测计划。
- 密钥与业务数据已经脱敏的说明。
可以先使用中转站检测工具生成协议与行为抽样，再按照检测报告判读指南查看分项证据。选型阶段继续使用12 项中转站实测清单，避免单一总分替代业务判断。