这不是一篇只讲“支持多少模型”的介绍文。
这是一份基于真实 API 请求跑出来的性能数据报告：我们用短输出、低成本模型和可追踪task_id，对 非线智能API 的协议兼容、并发稳定性、流式响应、缓存计费和异常行为做了一轮当天可复现评测。
测试时间：2026年5月
如果你正在为团队选型大模型 API 平台，最关心的问题通常不是“能不能调通一次”，而是：
- 并发上来以后会不会大量 429、5xx 或超时？
- OpenAI-compatible、Anthropic-compatible、stream 是否真的可用？
- 费用字段是否能在 API 响应里看到？
- 长前缀缓存是否真的能降成本？
- 不同模型族的特殊响应行为，是否会影响业务解析？
本次测试围绕这些问题展开。
一句话结论
在本轮评测中，NoneLinear API 的 OpenAI-compatible、Anthropic-compatible 和 OpenAI stream 均可用；gpt-5.4-nano 与 gemini-3-flash-preview 两个低成本模型均完成 100 并发测试，全部请求返回 200；claude-sonnet-4.6 完成到 20 并发，除首次 1 并发出现一次连接重置外，重试和后续并发均成功。
缓存方面，gpt-5.4-nano 的 OpenAI-compatible 长前缀缓存命中非常明显：第二、三次请求均返回 cached_tokens=11008，单次费用从约 ¥0.016477 降至 ¥0.002607，降幅约 84%。
我们也记录了几个需要开发者注意的边界：Anthropic-compatible 响应目前缺少 cost 和 cache read/write token；Claude Haiku 通过 OpenAI-compatible 重复长前缀未观察到缓存命中；Gemini Pro thinking 响应可能出现 content 为空、内容进入 reasoning_content 的情况。
测试范围
本轮是当天可出报告版深度评测，不做跨时段稳定性对比，也不做 24 小时连续压测。测试目标是验证开发者选型时最关心的核心链路。
| 维度 | 本轮覆盖情况 |
|---|---|
| OpenAI-compatible chat | 已测 |
| Anthropic-compatible messages | 已测 |
| OpenAI-compatible stream | 已测 |
| 低成本模型 100 并发 | 已测 |
| Claude 主力模型轻量并发 | 已测到 20 |
| API 响应费用字段 | 已测 |
| OpenAI-compatible prompt cache | 已测 |
| Anthropic-compatible cache_control | 已测 |
| Gemini Pro thinking 行为 | 已复查 |
| 分时段稳定性 | 未覆盖，后续补测 |
| 多模态专项 | 样本集已整理，后续补测 |
测试时间：2026-05-18
测试地点：本地工作区 /Users/weichen/Downloads/AI_api_hub
测试方式：脚本请求 NoneLinear API，结果保存为 JSONL
输出控制：默认使用 max_tokens=8，控制费用和变量
追踪方式：OpenAI-compatible 非流式请求使用 task_id
核心测试模型
本轮优先使用低成本模型做并发，再用 Claude Sonnet 做轻量验证：
| 模型 | 测试目的 |
|---|---|
gpt-5.4-nano |
低成本并发、缓存、费用字段基线 |
gemini-3-flash-preview |
低成本高并发、速度表现 |
claude-sonnet-4.6 |
Claude 主力模型轻量并发 |
claude-haiku-4.5 |
OpenAI-compatible 与 Anthropic-compatible 缓存复查 |
gpt-5.4-mini |
GPT mini 可用性补充 |
gemini-3.1-pro-preview |
Gemini Pro thinking 响应复查 |
1. 协议兼容：OpenAI、Anthropic、stream 都能跑通
第一步是 smoke test，确认核心协议是否可用。
| 场景 | 模型 | 结果 | 延迟/TTFT | 费用字段 | 备注 |
|---|---|---|---|---|---|
| OpenAI-compatible chat | gpt-5.4-nano |
200 | 3.578s | ¥0.000050 | 返回 usage.cost |
| OpenAI-compatible chat | claude-sonnet-4.6 |
200 | 3.900s | ¥0.000672 | 返回上游模型名 |
| OpenAI-compatible chat | gemini-3-flash-preview |
200 | 4.301s | ¥0.000107 | 有 reasoning 字段 |
| Anthropic-compatible messages | claude-haiku-4.5 |
200 | 6.635s | 缺失 | usage 仅 input/output tokens |
| OpenAI-compatible stream | gpt-5.4-nano |
200 | TTFT 2.053s | 不适用 | 42 chunks，总耗时 2.347s |
结论很直接：三个关键链路都能跑通。
对开发者来说，OpenAI-compatible 是迁移成本最低的路径；Anthropic-compatible 可用于 Claude 原生消息格式；stream 的 TTFT 在本轮短输出测试中为 2.053s。
需要注意的是，Anthropic-compatible 响应目前没有直接返回 cost，因此如果要做自动化账单核验，OpenAI-compatible 的可观测性更完整。
2. 并发测试：低成本模型跑到 100 并发，全 200
本轮并发测试采用短输出，避免把模型生成能力和网关吞吐能力混在一起。测试并发档位为：
1 / 5 / 10 / 20 / 50 / 100
gpt-5.4-nano 并发结果
| 并发 | 成功 | 成功率 | P95 延迟 | 墙钟耗时 | API 返回费用合计 |
|---|---|---|---|---|---|
| 1 | 1/1 | 100% | 2.704s | 2.708s | ¥0.000091 |
| 5 | 5/5 | 100% | 3.198s | 3.459s | ¥0.000455 |
| 10 | 10/10 | 100% | 3.266s | 3.320s | ¥0.000910 |
| 20 | 20/20 | 100% | 4.407s | 8.937s | ¥0.001820 |
| 50 | 50/50 | 100% | 5.285s | 7.908s | ¥0.004550 |
| 100 | 100/100 | 100% | 7.554s | 11.123s | ¥0.009100 |
gpt-5.4-nano 是本轮最重要的低成本并发基线。结果显示，100 并发下全部请求成功，未观察到 429、5xx 或系统性超时。P95 延迟随并发升高，从 1 并发的 2.704s 上升到 100 并发的 7.554s。
gemini-3-flash-preview 并发结果
| 并发 | 成功 | 成功率 | P95 延迟 | 墙钟耗时 | API 返回费用合计 |
|---|---|---|---|---|---|
| 1 | 1/1 | 100% | 4.351s | 4.354s | ¥0.000142 |
| 5 | 5/5 | 100% | 5.385s | 5.592s | ¥0.000689 |
| 10 | 10/10 | 100% | 4.971s | 5.274s | ¥0.001273 |
| 20 | 20/20 | 100% | 5.990s | 5.996s | ¥0.002599 |
| 50 | 50/50 | 100% | 6.855s | 10.118s | ¥0.006540 |
| 100 | 100/100 | 100% | 8.163s | 8.194s | ¥0.012743 |
gemini-3-flash-preview 同样完成 100 并发且全部 200。整体延迟略高于 gpt-5.4-nano，但稳定性表现一致，没有出现明显限流点。
3. Claude Sonnet：主力模型轻量并发到 20
考虑成本，本轮没有把 Claude Sonnet 拉到 100 并发，只测试到 20。
| 并发 | 成功 | 成功率 | P95 延迟 | 墙钟耗时 | API 返回费用合计 | 备注 |
|---|---|---|---|---|---|---|
| 1 | 0/1 | 0% | 10.093s | 10.096s | 缺失 | 首次连接重置 |
| 1 | 1/1 | 100% | 2.894s | 2.898s | ¥0.001176 | 重试成功 |
| 5 | 5/5 | 100% | 4.092s | 4.146s | ¥0.005880 | - |
| 10 | 10/10 | 100% | 5.688s | 6.012s | ¥0.011760 | - |
| 20 | 20/20 | 100% | 6.339s | 6.806s | ¥0.023520 | - |
这里有一个异常必须如实记录：首次 1 并发请求出现 Connection reset by peer。这不是 429，也不是 5xx，但属于连接层异常。随后同档重试成功，后续 5、10、20 并发全部成功。
这说明本轮没有发现 Claude Sonnet 的持续限流点，但正式生产选型仍建议补做跨时段、长输出和更长时间窗口测试。
4. 缓存测试：GPT nano 命中后成本下降约 84%
Prompt cache 是大模型 API 成本优化里非常实际的一项能力。很多业务会反复发送相同的系统提示词、文档模板或长前缀，如果缓存命中可观测，开发者就可以明确知道钱省在哪里。
本轮 OpenAI-compatible 缓存测试使用重复长 system prompt，连续请求三次。
| 协议 | 模型 | Run | 输入 token | cached_tokens | 费用 | 结论 |
|---|---|---|---|---|---|---|
| OpenAI-compatible | gpt-5.4-nano |
1 | 11719 | 0 | ¥0.016477 | 首次未命中 |
| OpenAI-compatible | gpt-5.4-nano |
2 | 11719 | 11008 | ¥0.002607 | 命中 |
| OpenAI-compatible | gpt-5.4-nano |
3 | 11719 | 11008 | ¥0.002607 | 稳定命中 |
这个结果是本轮最清晰的成本优化证据。
同样 11719 prompt tokens，缓存命中后 API 返回费用从 ¥0.016477 降至 ¥0.002607，降幅约 84%。
Claude Haiku 的 OpenAI-compatible 缓存复查则没有观察到命中：
| 协议 | 模型 | Run | 输入 token | cached_tokens | 费用 | 结论 |
|---|---|---|---|---|---|---|
| OpenAI-compatible | claude-haiku-4.5 |
1 | 14416 | 0 | ¥0.104806 | 未命中 |
| OpenAI-compatible | claude-haiku-4.5 |
2 | 14416 | 0 | ¥0.104806 | 未命中 |
| OpenAI-compatible | claude-haiku-4.5 |
3 | 14416 | 0 | ¥0.104806 | 未命中 |
Anthropic-compatible 的 cache_control 请求可以成功，但响应中没有 cost，也没有 cache read/write token。因此它能证明请求格式可用，但还不能从 API 响应侧证明缓存是否实际命中。
5. 费用可观测：OpenAI-compatible 返回 usage.cost
本轮可从 API 响应直接汇总的 usage.cost 如下：
| 模型 | 请求数口径 | API 返回费用合计 |
|---|---|---|
gpt-5.4-nano |
191 | ¥0.038667 |
gemini-3-flash-preview |
187 | ¥0.024093 |
claude-sonnet-4.6 |
38 | ¥0.043008 |
claude-haiku-4.5 OpenAI-compatible |
10 | ¥0.314418 |
gemini-3.1-pro-preview |
1 | ¥0.000511 |
gpt-5.4-mini |
2 | ¥0.000215 |
| 已返回 cost 合计 | - | ¥0.420912 |
这组数据说明，OpenAI-compatible 路径适合做程序化成本核验：请求结束后，调用方可以直接读取 usage.cost 和 token 字段。
但 Anthropic-compatible 当前还存在可观测性缺口。本轮 7 条 Anthropic-compatible 成功响应没有返回 cost：1 条 smoke，6 条 cache_control。按价格表估算，这部分约 ¥1.916690，但估算值不能替代 API 返回值或后台账单。
6. task_id：非流式请求可追踪
为了避免评测变成“只看总账”，本轮 OpenAI-compatible 非流式请求全部使用 task_id，命名规则如下：
| 场景 | task_id 规则 |
|---|---|
| Smoke | nl-20260518-smoke-<model> |
| 并发 | nl-20260518-concurrency-c<并发>-<model>-req-<index> |
| Claude 并发重试 | nl-20260518-concurrency-retry-c1-claude-sonnet-4.6-req-0 |
| OpenAI-compatible 缓存 | nl-20260518-cache-<model>-run-<n> |
| Gemini Pro thinking | nl-20260518-gemini-thinking-pro |
stream 和 Anthropic-compatible 请求本轮没有传 task_id，这是按当前约束执行：OpenAI-compatible 非流式请求支持 task_id，stream 请求暂不传。
对企业团队来说，task_id 的意义很大：它可以把“某次压测”“某个业务任务”“某个客户项目”的用量从总账里拆出来，后续也可以用于成本归因和效果追踪。
7. Gemini Pro thinking：需要注意响应解析
本轮对 gemini-3.1-pro-preview 做了 thinking 行为复查：
| 字段 | 结果 |
|---|---|
| HTTP 状态 | 200 |
| 耗时 | 4.582s |
| finish_reason | length |
| content | 空字符串 |
| reasoning_content | 存在，728 字符 |
| extra_content.google.thought | true |
| usage.completion_tokens | 0 |
| usage.total_tokens | 11 |
| usage.cost | ¥0.000511 |
这对开发者有两个提醒：
- 如果只读取
message.content，可能把一次有效响应误判为空。 - 如果只看
completion_tokens=0，可能误解 thinking 模型的 token 和费用口径。
建议接入 Gemini Pro thinking 的开发者，在 SDK 适配层里显式处理 reasoning_content、extra_content 和 finish_reason。
8. 已知异常与改进方向
透明记录异常，比只展示漂亮数据更重要。本轮发现的问题如下：
| 问题 | 证据 | 影响 | 建议 |
|---|---|---|---|
| Anthropic-compatible 缺少费用字段 | smoke 与 cache_control usage 均无 cost |
无法 API 侧自动账单核验 | 在 usage 或 header 增加 cost/currency |
| Anthropic-compatible 缺少 cache read/write token | block/top cache_control 均只返回 input/output tokens | 无法证明缓存读写 | 增加 cache creation/read token |
| Claude OpenAI-compatible 长前缀未命中缓存 | Haiku 3 次 cached_tokens 均为 0 | Claude 缓存能力不可观测或未生效 | 明确缓存支持范围和命中字段 |
Gemini Pro thinking 内容不在 content |
content=""，reasoning_content_present=true |
调用方解析风险 | 文档说明解析方式 |
gpt-5.4-mini 最小输出限制 |
max_tokens=8 返回 400，16 成功 |
短输出压测可能误报 | 文档标注模型最小值 |
| Claude Sonnet 瞬时连接重置 | 首次 1 并发 Connection reset by peer |
单次稳定性异常 | 做跨时段长窗口复测 |
这些问题不影响本轮低成本并发和 OpenAI-compatible 主链路结论，但会影响更严肃的账单审计、缓存审计和多协议一致性评估。
9. 如何复现
本轮所有请求结果均保存为 JSONL。核心脚本包括：
scripts/smoke_test.pyscripts/concurrency_test.pyscripts/openai_cache_test.pyscripts/anthropic_cache_test.py
复现前准备 .env：
NONELINEAR_OPENAI_BASE_URL=https://api.nonelinear.com/v1
NONELINEAR_ANTHROPIC_BASE_URL=https://api.nonelinear.com/anthropic
NONELINEAR_API_KEY=你的 API Key
以 gpt-5.4-nano 并发测试为例：
python3 scripts/concurrency_test.py \
--model gpt-5.4-nano \
--concurrency 1,5,10,20,50,100 \
--max-tokens 8 \
--task-id-prefix nl-20260518-concurrency \
> results-concurrency-gpt-nano-20260518.jsonl
缓存测试示例：
python3 scripts/openai_cache_test.py \
--model gpt-5.4-nano \
--max-tokens 8 \
--task-id-prefix nl-20260518-cache \
> results-cache-gpt-nano-20260518.jsonl
为了便于外部复核，建议发布时同时附上：
- JSONL 原始结果摘要
- 脚本源码
- 测试日期和模型版本
- 费用统计口径
- 未覆盖范围和已知异常
10. 适合谁，不适合谁
如果你是生产环境开发者，本轮数据说明 NoneLinear API 至少在以下场景值得认真评估：
- 需要统一接入 GPT、Claude、Gemini 等多模型；
- 需要 OpenAI-compatible 快速迁移；
- 需要用
task_id做请求级追踪； - 需要 API 响应中直接看到
usage.cost； - 有短输出高并发、长前缀缓存降本需求；
- 团队希望用真实数据做模型选型，而不是只看宣传页。
如果你只是个人低频体验、对企业账单和多协议适配没有要求，或者只调用单一模型，完整平台能力的价值未必能体现出来。
结语
这轮评测给出的结论比较清晰：NoneLinear API 的 OpenAI-compatible 主链路表现稳定，低成本模型完成 100 并发测试且没有观察到 429、5xx 或系统性超时；usage.cost 和 GPT nano 缓存命中数据为成本核验提供了直接证据。
同时，我们也不会把还没补齐的能力包装成已经完美。Anthropic-compatible 的费用与缓存字段、Gemini thinking 的响应解析、Claude 缓存命中可观测性，都需要继续改进和复测。
后续我们会继续补充分时段稳定性、长输出流式、多模态专项、工具调用、Claude Code / Cursor 适配和企业后台账单核验，把 API 性能评测从“能调用”推进到“可审计、可复现、可用于生产选型”。
注：本文数据来自 2026-05-18 脚本评测。模型版本、价格和平台能力可能随时间变化，正式选型前建议以 非线智能 NoneLinear 官网和控制台最新信息为准。
