用 GPT-6 Luna 生成 API 测试：一次全量 OpenAPI 规范要花多少钱

从 OpenAPI 规范生成测试，早就不是技术难题了。能读懂一个 path item 并输出一份看起来像样的请求的模型，两年前就有了。真正的障碍是账单。测试生成的单次运行成本高到让团队把它当成一次性迁移来做：生成一整套用例、提交进仓库，然后永远手工维护，因为每次规范变更都重新生成，会在账单上多出一行，然后被人追问。

GPT-6 Luna 于 2026 年 9 月 22 日发布，输入 $0.10 / 百万 token、输出 $0.50 / 百万 token，把这件事推到了那条线的另一侧。对一份 42 个接口的规范完整跑一遍，不开缓存约 $0.29，开缓存后不到 $0.10。便宜到可以不再维护生成出来的用例集，直接在每次合并时重新生成。

下面给出算术、请求结构、需要预留的延迟，以及这个模型仍然会搞错的两件事。

AI Coding 交流群

如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。

变动的价格

GPT-6 Luna 是 GPT-6 家族中的新模型，不是改名的 GPT-5.6 档位。OpenAI 称 Sol 与 Luna 的训练方法与 GPT-6 Astra 类似，且两者都比 GPT-5.6 的促销价便宜 50%。这个限定词出自 OpenAI 自己，而且很关键：对比的是促销价，不是标价。完整的产品谱系见我们的 AI 模型价格战汇总。

对这个任务来说，上下文窗口比标价更重要。一百万 token 意味着整份规范、团队内部的测试约定和一组示例请求可以放进同一个 prompt 还有富余。你不需要分块，也不需要写检索逻辑去推断某个操作依赖哪些数据模型。关于这个模型本身，更多内容见「GPT-6 Luna 是什么」。

先定任务形态，再谈价格

两种形态，成本差别很大。

一次性版本把整份规范放进上下文，用一次补全产出整套用例。输入更便宜，输出更差：一次覆盖 42 个操作的补全，到第 20 个左右就明显变稀——靠前的接口每个能拿到五个用例，尾部的接口只得到一个 happy path 和一句敷衍。而且整轮运行只有一个重试单元。

按操作逐个处理的版本，每次发送共享的规范上下文加一个操作，共 42 次。输入量上升，因为共享上下文被重复发送，但输出质量稳定，每次调用都能独立重试，每个文件与上一轮运行的 diff 也很干净。缓存能把多出来的输入成本大部分收回来，所以要算账就按这个形态算。

以一份中等规模的规范为例，估算单次调用的预算：

前两行在每次调用中都逐字节相同。缓存作用的就是这 52,000 token 的前缀，把不变的部分放在最前面，是整个方案里杠杆最大的决定。

跑一遍要多少钱

按这个预算处理 42 个操作，整轮运行合计 2,247,000 输入 token 和 126,000 输出 token。

按 Luna 的价格，即输入 $0.2247、输出 $0.0630，所以是 $0.2877 for the pass，平均每个接口略低于 0.7 美分。同样的 token 用量放到这两周内发布或调价的其他模型上：

Astra 的输入和输出价格都正好是 Luna 的 100 倍，所以在这个任务上的成本也正好是 100 倍。Claude Opus 5.5 是 40 倍。

这个差距就是决策的全部依据。一次 $28.77，你会去写增量逻辑：追踪哪些操作变了、给每个 path item 算哈希、只重新生成差异部分，然后在它和规范不同步时调试这套机制。一次 $0.29，你直接把增量逻辑删掉。一个月合并 20 次就是 $5.75，比跑模型写的那些测试所消耗的 CI 时长还便宜。做个参照：OpenAI 称其中位数研究员每天在编码 agent 上花超过 $600，90th 百分位超过 $7,000。

提示缓存能把它带到哪一步

GPT-6 在调价的同时发布了真正的缓存能力：缓存读取享 90% 折扣、默认更高的命中率、一个看板和一个诊断工具、可显式设置断点以决定缓存前缀在哪里结束，以及在推理强度和工具可用性变化后缓存依然存活。GitHub 报告称，在数十亿次请求中，需要重新处理的 prompt token 减少了 50% 以上。细节见「GPT-6 提示缓存」。

套用到上面那轮运行，把 $0.10 的输入价格打掉 90%，即缓存读取每百万 $0.01：

约为未开缓存成本的三分之一，平均每个接口略低于四分之一美分。有两点不要想当然。OpenAI 声明了 90% 折扣，但在我们掌握的来源里并未公布 Luna 的缓存读取单价，所以上面的 $0.01 是算出来的，不是官方价格。另外，我们手上没有任何资料给出缓存有效期，所以这 42 次调用要背靠背发出，不要散在一个缓慢的 CI 队列里，并在看板中确认命中率。

请求

没什么特别之处。真正起作用的是顺序：

curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-luna",
    "reasoning_effort": "high",
    "messages": [
      { "role": "system",
        "content": "You write API tests. Emit one test file. Assert on status, response schema and error shape. Never assert on a field absent from the supplied schema." },
      { "role": "user",
        "content": "Shared spec context:\n<components, securitySchemes, servers>" },
      { "role": "user",
        "content": "Operation under test:\nPOST /orders\n<path item and examples>" }
    ]
  }'

系统提示词和共享规范块在 42 次调用中逐字节相同，并且放在最前面。变化的是操作，放在最后。把两者调换，你就什么都缓存不到，整轮成本变成 $0.29 而不是 $0.096。整个机制就这一点。

high 的 effort 设置是刻意的。Luna 相对前代公布的提升是在更高 effort 下测得的，而由于 GPT-6 的缓存在 effort 变化后依然存活，你可以按操作逐个调整而无需重建前缀。把最高档的设置留给涉及资金或鉴权的接口。

要预留的是时间，不是钱

便宜不等于快。第三方机构 Artificial Analysis 测得 Luna 的 max reasoning 变体输出速度为 153.9 token/秒，首 token 时间为 124.23 秒。这两个数字都来自他们而非 OpenAI，且都只适用于 max 变体，同时 AA 会持续重新评测，所以只能当作方向性参考。

按字面算，一次 max effort 调用大约是 124 秒等待，加上流式输出 3,000 token 的约 20 秒，算它 144 秒。42 次串行约 101 分钟。8 个并发约 13 分钟，就是一个普通的 CI 阶段。

这与大多数模型选型的论调正好相反，也正是这个组合成立的原因：首 token 时间对交互式助手是灾难，对一个写文件的批处理任务却几乎无关紧要。更大的兄弟型号也是同样的权衡，见「GPT-6 Sol 的首 token 时间」。

它做对了什么，以及两点没做对的

OpenAI 为 Luna 公布的成绩比它的价格所暗示的要强。在 DeepSWE 1.1 上，它在 max effort 下达到 66.6%，OpenAI 称这与 medium effort 下的 Claude Opus 5 和 Fable 5 相当，而单任务成本比 Opus 5 低 93%、比 Fable 5 低 96%。在 AutomationBench 上，它比前代高出 5.4 个百分点，单任务成本低 58%。这些全部是 OpenAI 在自己的 harness 上跑的，且没有一项衡量的是从规范生成测试。

在这里，两种失效模式比任何基准测试都更重要。

The model can only test what the spec says. 如果你的规范为 POST /orders 记录了 200 和 400，但服务在幂等键重复时还会返回 409，你不会得到冲突测试，而用例集看起来依然完整。生成质量受限于规范质量，所以值得投入的是规范，而不是 prompt。

Cheap generation fails by looking right. 这类错误的典型表现不是测试报错，而是一个通过的测试断言了响应里根本不存在的字段，或者接口从不返回的状态码。这些测试能通过评审，因为它们读起来像测试。在落地之前，用脚本把每一条生成的断言对照数据模型机械校验一遍，凡引用了 components 中不存在的字段就一律拒绝。这个检查不花钱，却能直接消灭这一类问题。

让产出真正可运行

生成的测试文件，其价值完全取决于它们运行所在的 harness。把规范作为唯一事实来源，基于它来生成，然后把用例落到每次 push 都会执行的地方。

Apifox 覆盖了这个闭环的后半段。它会导入你用来生成的那份规范，因此 prompt 里的共享上下文和 runner 里的请求定义来自同一份文档，不会漂移。生成的用例会成为测试场景，其断言会对照导入的数据模型校验，把上面那个检查从人工评审变成一道机械化的关卡。Smart mock 在后端还在开发时就按规范提供 mock 服务，所以生成出来的用例集在还没有真实服务可打之前就能诚实地失败。这些场景会在 CI 中运行，而这也是“每次合并就重新生成”这套流程唯一能体现价值的地方。

值得把这件事交给 Luna 吗？

值得，但有个前提。成本已经不再是跳过它的理由：一次 $0.29，开缓存后不到 $0.10，比你开会讨论要不要重新生成还便宜。延迟确实存在，但落在一个没人在等的窗口里。而 Luna 公布的成绩，让它在 agentic 编码工作上接近那些贵 40 到 100 倍的模型。

这些都不会让产出到手即可信。把省下来的钱花在一道数据模型校验关卡和首轮结果的人工通读上，并把结果当成初稿：它完整覆盖了文档化的部分，对未文档化的部分则毫无覆盖。即便如此，起点也比那套四个版本前就不再跟进规范的手写用例集要好。

开发必备：API 全流程管理神器 Apifox

介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具，Apifox 是目前提升研发效率的首选。

如果你正在开发项目，不妨试试其极其友好的界面设计，它完全兼容 Postman 和 Swagger 数据格式，导入数据非常方便，，即使是新手也能很快上手，点击这里即可注册使用。

值得一提的是，除了个人和常规团队使用，针对有高安全合规要求、或需要在内网环境协作的企业，Apifox 还提供了深度定制的私有化部署方案。

获取专属报价与部署方案

详细的私有化部署系统架构与安全白皮书

针对您公司规模的专属报价单

免费的 1v1 专属产品演示 (Demo) 机会

获取部署方案

* 提交后，我们的客户经理将在 1 个工作日内与您联系

林俊锋 企业微信

@Apifox 专属顾问

扫码备注: 私有化 + 公司名