不少 AI API 中转站会在商品页写“GPT-5.6-Sol 官方原版”“纯血模型”“不降智”。问题是：调用方看到的只是一个兼容接口，很难直接知道请求最终落到了 GPT-5.6-Sol、成本更低的 GPT-5.6-Terra/Luna，还是另一个被包装成 Sol 的模型，也无法排除按用户、时段或请求难度动态切换模型的可能。

所以，测评的目标不应是寻找一道能“一锤定音”的暗号题，而应该是回答三个更严谨的问题：

1. 这个接口是否具备宣称模型应有的协议与能力？
2. 它与官方基线在一组受控实验中的行为分布是否足够接近？
3. 这种一致性是否能跨时段、跨账号持续出现？

先说结论：除非上游提供可独立验证的签名、账单或远程证明，否则外部黑盒测试通常只能给出“高置信一致”，不能数学意义上证明它就是官方原版。 返回字段、回答口吻、延迟甚至请求 ID 都可能被中转站改写或伪造。真正可靠的结论来自多类证据相互印证。

---

一、先定义什么叫“纯血版”

“纯血版”不是标准技术术语。为了避免各说各话，测试前应把它拆成可验证的承诺：

• 模型身份一致：实际执行的是商家宣称的模型家族与版本，而不是更小模型、蒸馏模型或其他厂商模型。
• 能力没有被阉割：上下文长度、工具调用、结构化输出、视觉输入等能力与宣称版本相符。
• 请求没有被偷偷改写：中转站没有加入会明显改变结果的隐藏系统提示，也没有擅自压缩上下文、降低输出上限。
• 路由规则透明：不会因高峰期、低余额、请求难度或用户等级而悄悄降级。
• 计费口径可信：输入、输出、缓存和推理 token 的统计逻辑能解释，并与同条件官方基线大致相容。

这五条中，第一条是“模型真假”，后三条更接近“服务是否完整”。实际使用时，两者同样重要：即使上游模型是真的，若中转站压缩上下文或篡改参数，体验仍然不是所谓的“原汁原味”。

二、以 GPT-5.6-Sol 为例，先确认你测的到底是什么

按本文写作时随附的 OpenAI GPT-5.6 参考资料，明确的旗舰模型标识是 gpt-5.6-sol；gpt-5.6 是会路由到 Sol 的家族别名。同一家族还包括偏成本与吞吐的 gpt-5.6-terra、gpt-5.6-luna。这意味着测试必须先固定模型名、接口和推理档位，否则你可能把配置差异误判成模型替换。

建议第一轮固定为：

{
  "model": "gpt-5.6-sol",
  "reasoning": { "effort": "medium" }
}

上面是 Responses API 的字段形状；若使用 Chat Completions，对应字段是 reasoning_effort: "medium"。参考资料指出 GPT-5.6 支持 none、low、medium、high、xhigh、max，省略时默认为 medium。因此，一边用默认 medium，另一边用 none，测出来的质量、时延和 token 消耗本来就可能不同。

还可以检查以下“能力指纹”，但每一项都只能作为组合证据：

GPT-5.6-Sol 观察项	怎么测	能否单独证明
请求模型为 gpt-5.6-sol	检查请求体、返回 response.model、服务端日志	不能，代理可改写
Responses 推理档位	同题依次跑 none 到 max，看参数接受情况与分布变化	不能，代理可模拟或转译
约 1.05M 上下文、128K 最大输出	从 32K 起逐级增加合成上下文	不能，Terra 也可能相同；极限测试成本很高
推理与工具调用	在 Responses 中组合推理、函数工具和状态续接	不能，但持续缺失是强反证
Chat Completions 工具兼容性	函数工具应使用有效推理 none；推理加工具优先测 Responses	不能，主要验证接口契约

这些规格应在测试当天以OpenAI GPT-5.6 模型指南为准。规格会变化，文章里的数字不能替代实时文档。

三、不要把这些现象当成铁证

网上常见的鉴真方法通常只问一句固定问题，再按关键词判断真假。这种做法很容易误判：

• 模型更新、系统提示和随机采样都会改变答案；
• 中转站可以专门识别公开流传的“验身题”，返回预置结果；
• 不同模型可能对简单题给出几乎相同的回答；
• model 字段、响应头、请求 ID 和错误文案都可以被代理层重写；
• 速度快不等于假，速度慢也不等于真。缓存、并发、网络距离和服务负载都会改变时延；
• “它自己说自己是谁”几乎没有鉴别力，模型只是在响应当前提示词。

因此，单题、单次、单字段只适合初筛，不能作为公开指控或采购决策的唯一依据。

四、正确对照：官方 Sol、Terra、Luna 和中转站四路盲测

只拿“官方 Sol”和“中转站 Sol”做 A/B 测试还不够。你需要知道中转站若不是 Sol，它更像哪个廉价档位。最有鉴别力的实验是四路对照：

先用官方接口分别采样 Sol、Terra、Luna，找出三者能稳定拉开差距的题目，再让中转站跑同一批题。若一道题三个官方模型都能答对，它对鉴别身份几乎没有帮助；应优先保留那些 Sol 通过率明显更高、错误类型也稳定不同的题。

测试时应尽量固定：

• 明确到具体模型快照；若只能用滚动别名，记录测试日期和返回的模型标识；
• 使用完全相同的 temperature、top_p、max_tokens、工具定义和系统提示；
• 同一条输入分别发给官方接口与中转接口，请求顺序随机化；
• 每条用例重复 3 至 5 次，不要只比较一次输出；
• 每轮新建会话，避免历史上下文污染；
• 官方与中转都保留原始 JSON、响应头、时间戳和错误信息；
• 测试集不要全部公开，保留一部分私有题，减少针对性适配。

正式题集建议 100 至 300 条，至少一半是能自动判分的代码、逻辑、结构化输出和长上下文任务。每题每路重复 3 至 5 次，隐藏模型来源后统一判分。最后比较中转站在各子集上的通过率、错误类型、工具成功率和 token 分布，究竟更接近 Sol、Terra 还是 Luna。

如果拿不到官方账号，仍可做能力与协议测试，但最终结论应写成“未发现明显降级”或“与宣称能力相符”，不要写成“已证明是官方模型”。

案例：把 aikopen 作为待测中转站

下面以 aikopen 作为报告中的具体中转站案例。需要先说明：本文没有获得 aikopen 的可核验接口文档、base_url、模型列表响应或测试凭证，也没有向其接口发出实际请求。 因此，这一节不对 aikopen 使用的模型作真假判断，更不构成推荐或负面评价。

本次能够如实列出的测试状态如下：

项目	当前结果	可以得出的结论
待测服务	aikopen	已确定案例名称
目标模型	gpt-5.6-sol	这是测试设定，不代表已确认其在售模型
权威接口页面	未取得	无法核对公开模型 slug 与接口限制
GET /v1/models	未执行	不知道接口实际返回哪些模型
Chat/Responses 请求	0 次	没有原始 JSON、响应头、usage 或请求 ID
Sol/Terra/Luna 四路基线	未执行	无法判断行为分布更接近哪个档位
当前评分	N/A	缺少数据不能算成 0 分，也不能判定高风险
当前结论	证据不足，尚不能判断	需要真实接口采样后再下结论

拿到 aikopen 的测试接口后，可以按下面的格式列出结果。下表中的数字全部是排版演示值，不是 aikopen 实测数据，不能截取后当作测评结论传播。

测试项目	官方 Sol 演示值	官方 Terra 演示值	官方 Luna 演示值	aikopen 演示值	演示性解读
有效响应率	99.4%	99.6%	99.7%	98.9%	可用性接近，不鉴别模型身份
严格 JSON 通过率	98%	96%	93%	97%	接近 Sol，但单项证据较弱
高难推理/代码通过率	81%	69%	52%	77%	更靠近 Sol，仍需置信区间
工具调用成功率	97%	94%	90%	95%	位于 Sol 与 Terra 之间
256K 埋点召回率	96%	94%	88%	92%	未发现明显截断，不能区分 Sol/Terra
三时段最大分差	2.1 分	2.8 分	3.0 分	3.4 分	暂未显示明显动态降级
可核验上游证据	有	有	有	无	这是最终置信度的主要缺口

按照这组纯演示数据，报告最多可写成：“待测接口的行为整体介于官方 Sol 与 Terra 之间，部分高难任务更接近 Sol，但缺少上游可核验证据，不能确认物理上游就是 GPT-5.6-Sol。”不能写成“已实锤纯血 Sol”。

要把这一节替换成真正的 aikopen 实测结果，至少需要：

• aikopen 的准确 base_url 和目标模型 slug；
• 一枚仅有少量测试额度、可随时撤销的临时 API key，或由使用者在本机运行本文脚本；
• 同一时间窗的官方 Sol、Terra、Luna 基线；
• 脱敏后的原始 JSONL、响应头、请求 ID 和自动判分文件。

API key 不应出现在文章、截图或聊天记录中。最稳妥的方式是在密钥持有者的本机运行采样脚本，只提交脱敏结果。

五、测试矩阵：至少覆盖四个层面

1. 协议指纹与原生能力

先测试“它会不会做宣称模型应该会做的事”，而不是先看文风像不像。建议覆盖：

测试项	观察指标	常见风险信号
流式输出	事件格式、结束事件、usage 返回位置	事件缺失、格式与文档长期不符
工具调用	参数 schema 遵循率、并行调用、工具结果续写	把工具调用写成普通文本
结构化输出	JSON Schema 约束通过率	频繁输出无法解析的 JSON
长上下文	不同深度埋点的召回率	未到宣称长度就报错或遗忘
多模态	图片数量、尺寸、格式边界	名义支持但实际拒绝或只做 OCR
错误行为	超限、无效参数、限流时的错误结构	与兼容协议冲突且无说明
输出控制	stop、seed、max tokens 等参数是否生效	参数被静默忽略

协议完全相同也不能证明模型相同，因为中转层可以模拟协议；但关键能力持续缺失，是很强的反证。

2. 行为能力对比

准备 50 至 100 道测试题，按任务分层。不要只测知识问答，建议至少包括：

• 严格指令遵循：多条件格式、禁止项、边界条件；
• 代码能力：定位缺陷、补测试、跨文件理解；
• 数学与逻辑：可自动判分的题，避免只看表达风格；
• 长文档检索：在不同位置埋入唯一事实，测精确召回；
• 工具选择：需要调用、不应调用、并行调用三类场景；
• 多语言：中文、英文及混合输入；
• 安全边界：只检查一致性，不诱导生成真实危害内容；
• 视觉理解：若宣称支持视觉，加入图表、界面截图和细节定位。

评分优先使用客观规则，例如单元测试通过率、JSON Schema 通过率、精确匹配或人工双盲偏好。比较的不是逐字一致，而是通过率、错误类型和输出分布是否接近。

3. 用量与性能分布

每次请求至少记录以下字段：

timestamp, endpoint, advertised_model, returned_model,
prompt_id, run_id, status_code, request_id,
input_tokens, output_tokens, cached_tokens, reasoning_tokens,
time_to_first_token_ms, total_latency_ms, finish_reason, raw_response_sha256

重点看分布，不看某一个数字：

• 同一输入下，token 统计是否存在长期、系统性的异常偏差；
• 首 token 时延和生成速度是否呈现不合理的双峰或分层；
• 高难题与低难题是否突然出现两种截然不同的能力档位；
• 低价是否能由批量折扣、缓存或促销解释，还是明显低于可持续成本；
• 高峰期是否能力下降、上下文缩短或错误类型变化。

价格异常是风险提示，不是模型身份证据。中转站可能有合法折扣，也可能在亏损获客；反过来，高价同样不保证真实。

4. 跨时段稳定性

一次测评通过，只能说明那个时间窗口没有发现问题。建议在工作日、周末、峰值和非峰值时段重复测试，并使用至少两个独立账号。若只有某些账号或某些时段能力显著下降，很可能存在分层路由或动态降级。

六、最关键的长上下文测试怎么做

长上下文是最容易被中转服务“缩水”的能力之一，也最适合自动化检测。

准备一份不会被模型凭常识猜中的合成文档，在 10%、35%、60%、85% 的位置分别插入不同随机口令，例如“记录 K-7 的校验值为 MANGO-4821”。然后提出精确问题，统计不同深度的召回率。文档长度从 8K、16K、32K 逐级增加，直到接近宣称上限。

注意三个细节：

1. 每轮更换随机口令，防止缓存或题库命中。
2. 口令附近加入相似干扰项，避免只做关键词检索。
3. 同时测官方基线；接近极限时，官方模型本身也可能出现召回下降。

若中转接口在远低于宣称上限时稳定报错、截断，或深部信息召回率断崖式下降，而官方基线没有同类现象，这是高权重风险证据。

七、一个可直接改造的四路采样脚本

下面的 Python 示例面向 OpenAI 兼容接口。它会对同一组题分别请求官方 Sol、Terra、Luna 和中转站宣称的 Sol，将原始响应、用量和时延写入 JSONL。运行前安装 openai，并在环境变量中设置密钥；不要把密钥写进脚本或测试报告。

import hashlib
import json
import os
import random
import time
from openai import OpenAI

official = OpenAI(
    api_key=os.environ["OFFICIAL_API_KEY"],
    base_url=os.environ["OFFICIAL_BASE_URL"],
)
relay = OpenAI(
    api_key=os.environ["RELAY_API_KEY"],
    base_url=os.environ["RELAY_BASE_URL"],
)

TARGETS = {
    "official_sol": (official, "gpt-5.6-sol"),
    "official_terra": (official, "gpt-5.6-terra"),
    "official_luna": (official, "gpt-5.6-luna"),
    "relay_claimed_sol": (relay, "gpt-5.6-sol"),
}
PROMPTS = [
    {"id": "format-01", "text": "只输出一个 JSON 对象，字段为 answer 和 confidence。计算 17*23。"},
    {"id": "logic-01", "text": "若所有甲都是乙，且没有乙是丙，能否推出没有甲是丙？只回答能或不能。"},
]

def sample(name, client, model, item, run_id):
    started = time.perf_counter()
    response = client.chat.completions.create(
        model=model,
        reasoning_effort="medium",
        temperature=0,
        max_tokens=300,
        messages=[{"role": "user", "content": item["text"]}],
    )
    elapsed_ms = round((time.perf_counter() - started) * 1000, 1)
    raw = response.model_dump(mode="json")
    usage = raw.get("usage") or {}
    return {
        "timestamp": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime()),
        "target": name,
        "prompt_id": item["id"],
        "run_id": run_id,
        "requested_model": model,
        "returned_model": raw.get("model"),
        "latency_ms": elapsed_ms,
        "input_tokens": usage.get("prompt_tokens"),
        "output_tokens": usage.get("completion_tokens"),
        "finish_reason": raw["choices"][0].get("finish_reason"),
        "content": raw["choices"][0]["message"].get("content"),
        "raw_response_sha256": hashlib.sha256(
            json.dumps(raw, sort_keys=True, ensure_ascii=False).encode()
        ).hexdigest(),
        "raw": raw,
    }

jobs = [(name, item, run_id) for item in PROMPTS
        for run_id in range(3) for name in TARGETS]
random.shuffle(jobs)

with open("samples.jsonl", "a", encoding="utf-8") as f:
    for name, item, run_id in jobs:
        try:
            client, model = TARGETS[name]
            row = sample(name, client, model, item, run_id)
        except Exception as exc:
            row = {
                "timestamp": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime()),
                "target": name,
                "prompt_id": item["id"],
                "run_id": run_id,
                "error": type(exc).__name__,
                "detail": str(exc),
            }
        f.write(json.dumps(row, ensure_ascii=False) + "\n")
        f.flush()

正式测评时，还应在 HTTP 客户端层记录响应头与首 token 时延；示例为了兼容性没有绑定某一家厂商的专有字段。若接口包含敏感业务数据，测试前应确认中转站的数据保留、训练使用和跨境传输政策。

脚本只是采样器，不会自动宣布真假。你还需要给每道题设置客观判分器，并先筛出官方 Sol 与 Terra/Luna 真正存在显著差异的题。若中转站在这些题上长期贴近 Terra 或 Luna，而在简单题上又与所有模型都相同，才构成“疑似廉价模型替换”的强行为证据。

八、用 100 分制合并证据

建议将证据按可伪造难度和鉴别力加权：

证据类别	分值	满分条件示例
可核验上游证据	30	官方合作关系、可向上游核验的账单或请求记录
协议与能力一致性	25	关键原生能力完整，边界行为与文档和基线相符
行为统计相似度	25	私有测试集多次采样后，能力与错误分布接近官方
用量与性能分布	10	token 口径可解释，时延和吞吐没有异常分层
跨时段稳定性	10	多时段、多账号复测结果稳定，没有动态降级迹象

分数可以这样解释：

• 85–100：高置信一致。 多类强证据相互支持，未发现实质冲突。
• 70–84：大概率一致。 主要能力吻合，但缺少可核验上游证据或样本量不足。
• 50–69：证据不足。 不能据此认定为假，但不适合承载高价值或敏感业务。
• 0–49：高风险。 存在多项能力缺失、行为偏移或稳定性问题。

评分之外还应设置硬冲突项。例如：返回模型标识与宣称版本直接冲突；在明显低于宣称上限时稳定截断；关键原生能力被替换成文本模拟；同条件官方基线稳定通过而中转站大量失败；经上游支持渠道确认请求记录不存在。出现硬冲突后，不应再用若干低权重“像官方”的现象把分数补回来。

九、只有十分钟时，先做这组初筛

时间有限时，可以先跑六项：

1. 保存完整响应和响应头，检查模型标识、usage、finish reason 与错误结构。
2. 用一个严格 JSON Schema 任务测试结构化输出。
3. 用一个必须调用工具、一个绝不该调用工具的任务检查工具选择。
4. 构造一份 16K 以上的随机口令文档，检查中部和尾部召回。
5. 同一题连续跑五次，观察结果、token 和时延是否出现明显分层。
6. 换一个时段和账号复测，并把结果与官方 Sol、Terra、Luna 并排保存。

这组测试能快速发现明显的能力缩水，但通过初筛仍不等于“鉴真完成”。采购、批量充值或生产切换前，至少跑完一轮正式测试矩阵。

十、怎样写出负责任的测评结论

一份合格报告应同时给出模型、参数、日期、地区、样本量、题集类别、原始数据哈希、评分规则和已知限制。推荐使用这样的表述：

在 2026 年 7 月的 120 条私有用例、每题 3 次采样中，该中转接口在协议能力、客观任务通过率和长上下文召回上与官方基线接近，跨三个时段未发现明显降级。由于缺少可独立验证的上游签名，本报告结论为“高置信一致”，而非证明其物理上游身份。

如果发现异常，也应描述可复现事实，例如“32K 输入在 18K 左右被稳定截断”，而不是仅凭主观文风写“模型变笨了”。公开报告发布前，给服务商复核时间，并排除参数不一致、地区路由、滚动版本更新和自身测试脚本错误。

结语

测中转站是否为所谓“纯血版”，本质上是一次黑盒供应链审计。可靠方法不是寻找神秘问题，而是建立官方基线，控制变量，覆盖协议、能力、行为和性能，保留原始证据，再做跨时段复测。

真正值得信任的服务商，也不应该只说“保真”，而应主动提供可核验的模型版本、路由规则、数据政策、故障说明和账单口径。对调用方来说，最务实的目标不是追求无法达到的绝对证明，而是把不确定性量化，并让每一个结论都能被别人重复验证。

---

使用说明： 本文的评分权重是通用模板，不同厂商、模型和业务应按官方文档调整。本文写作时未能在当前环境连接在线 OpenAI 文档，GPT-5.6-Sol 的模型名和能力边界依据随附参考资料整理；正式发布或执行极限测试前，应重新核对上文链接的在线模型指南。测试应遵守模型供应商与中转服务的使用条款，不要上传真实密钥、个人信息、商业机密或受监管数据。