34ku.com OpenAI 中转站检测报告
71/100 · 存在风险 ·
模型 claude-opus-4-8 · 模式 standard ·
中转站 https://api.34ku.com/v1
· 品牌:34ku.com · 实际 endpoint:api.34ku.com
71%
存在风险
由 https://veridrop.org 生成
- 基础请求 通过
- 模型一致性 通过
- 函数调用 通过
- 结构化输出 未通过
- 协议规范性 未通过
- 流式一致性 通过
- Token 计费 通过
- 长上下文真实性 未启用
划重点:这份报告在说什么
结构化输出没有真正生效
返回的不是 JSON 也没有代码块包装。请求已发送 response_format=json_schema strict=true,但中转站很可能根本没把这个参数透传给后端。 实际返回片段: I don't have a schema to match here, and there's nothing in our conversation that defines one. If you have an actual task, like building an endpoint that returns JSON or validating...
中转站疑似伪装成 OpenAI
响应的 usage 字段里出现了 Anthropic / Google 后端才会用的字段(如 claude_cache_creation_*、gemini_* 或 usage_source 自报非 openai)。这强烈暗示中转站把你的请求转发给了别的厂商后端再包装成 OpenAI 响应,所谓的 GPT 输出可能并非真正的 OpenAI 模型在生成。
首 TOKEN
1,699ms
总耗时
17,386ms
吞吐 (T/S)
19.2
输入 TOKENS
865
输出 TOKENS
334
OpenAI 检测项各自检查什么?
- 基础请求 (Basic Request)
- 发送最小 Chat Completions 请求,确认接口可用且能提取 assistant 文本。
- 模型一致性 (Model Consistency)
- 验证
response.model与请求模型匹配,并检查低温多次调用的输出 token 稳定性。 - 函数调用 (Function Calling)
- 强制 tool_choice,验证
call_ID、type=function、函数名和 arguments JSON。 - 结构化输出 (Structured Output)
- 使用
response_format=json_schema,检查返回内容能否按 schema 解析。 - 协议规范性 (Protocol)
- 被动检查
chatcmpl-ID、chat.completion、choices、finish_reason、usage 等官方字段。 - 流式一致性 (Integrity)
- 比较同一 prompt 的 stream 与 non-stream 文本、finish_reason 和 usage 是否一致。
- Token 计费
- 检查中转站返回的输入/输出 Token 数是否自洽,并和同一次检测里的流式/非流式结果、本地可预期的变化进行对比。
- 长上下文真实性 (Long Context)
- 需在提交时勾选启用 — 用 needle-in-haystack 在 32k → 100k → 200k tokens 三档探针,验证中转站是否真兑现宣传的 context window(识别截断 / 路由到小窗口模型)。极限档可按模型完整上限自适应探到 950k+。
这份报告帮你避坑了吗?
GitHub 加星支持 →
如果 Veridrop 的字段级证据对你有用,欢迎顺手给 GitHub 点个 Star,支持公开、可复核的中转站测评继续维护。