GPT-6 Luna 评测：定价、应用场景、API 限制及最佳用途

快速回答： GPT-6 Luna 是 OpenAI 专为高吞吐量任务设计的模型。 官方 API 显示，标准费率下每 100 万输入令牌的费用为 OpenAI0.10，每 100 万输出令牌的费用为 $0.50，上下文窗口为 105 万令牌，最大输出为 12.8 万令牌。 最关键的考量在于：其生成的答案能否在可接受的总成本范围内满足您的任务需求。.

OpenAI 将 GPT-6 Luna 描述为其在专注、高吞吐量任务中效率最高的模型。这一表述属于供应商的定位宣传，并非经过测量的质量评分。本评测将已发布的规格转化为采购和架构决策，并附有出处地记录了公众的反应。 我们还针对该模型执行了三项小型任务，并保留了模型 ID、路径、提示词集、原始输出及使用情况。下文展示的任务结果仅为一次观察到的运行结果，并非官方基准测试。.

简评

最有用的区分并非仅仅在于“智能”与“快速”之间，而是工作负载的形态。GPT-6 Luna 与其同系列产品拥有相同的标称上下文处理能力与输出上限，但其定位和定价使得选择不同的运行点更为合理。对比更广泛的 AI模型选择指南 和 最适合编码的人工智能模型 当任务涉及多个提供商时，请参考本指南。.

GPT-6 Luna 概览

下表遵循当前的 GPT-6 Luna 官方模型页面. 上下文容量与推荐的提示词长度并不相同，且最大输入量与标题上下文窗口是分开的。.

这两款姊妹模型均在文档中列出的功能集内支持结构化输出、函数调用、流式处理、提示词缓存、图像输入、文件搜索和网页搜索。工具的具体行为仍取决于端点、账户和请求配置；请勿仅根据功能复选框的存在就推断工具运行成功。.

就家庭层面而言，该 GPT-6 Astra 评测 展示了相关的一篇 GPT-6 文章是如何将服务提供商文档、平台路径和归因反应区分开来的。.

GPT-6 Luna 的定价与“27.2K 规则”

按标准费率计算，该 OpenAI 定价页面 列出了每100万个令牌的$0.10输入、$0.01缓存输入、$0.125缓存写入以及$0.50输出。缓存写入量为未缓存输入量的1.25倍。 Batch 和 Flex 的定价为 50%（标准模式），Fast 模式的费率为适用费率的 2 倍，若区域处理可用，则额外增加 10%。.

“长上下文”列是根据 OpenAI 的规则计算得出的：当输入量超过 272K 时，输入速率和缓存速率翻倍，且整个请求的输出量乘以 1.5。这并非混合速率计费。 作为实际预算基准，100K 输入加上 10K 输出大约需要 $0.015 在工具或区域提升之前；一个30万输入加2万输出的示例大约需要 $0.075 按长上下文费率计算。.

GPT-6 Luna API 的适配、工具和限制

OpenAI 建议在内置工具和函数调用中使用 Responses API。Chat Completions 仅在以下情况下支持函数调用： 推理_努力 已设置为 无. 这是一个在迁移前值得注意的实现细节：一个请求在语法上可能有效，却可能与您当前集成所期望的工具行为不符。.

当前的速率限制表列出了以下标准层级。RPM 表示每分钟请求数，TPM 表示每分钟令牌数，而队列值即为批次令牌上限。.

在正式上线之前，请在您自己的账户中验证确切的层级、端点、流式传输模式和工具契约。该 《法典》使用限制指南 这有助于解释为何模型的公布上限与账户的实际可用额度并不一致。.

GPT-6 Luna 的规格意味着什么

这是一张拟合图，而非基准图。请使用 一体化 AI 模型工作流指南 当你真正需要决定的是如何在一个可重复的流程中切换模型，而不是哪个单一模型听起来最有力时。.

在我们的测试中：GPT-6 Luna 在三项实际任务中的表现

我们于2026年9月23日测试了一个小型JavaScript修复、一份三点决策备忘录以及JSON提取功能。下文保留的结果是针对模型ID的完整响应： gpt-6-luna. 早先的尝试曾遇到过临时过载错误，因此不应将这些结果视为首次尝试的可靠性测量结果。我们将探讨这些答案包含哪些内容、读者可以复用哪些部分，以及哪些部分尚未经过测试。.

代码修复：在不重写函数的情况下保留零值

该编程任务要求进行错误诊断、编写最小修复补丁以及编写两个回归测试。所示结果是重试后的完成结果；其提示的准确措辞已不可用。.

`filter(Boolean)` 会从结果中移除有效的 `0` 值（以及其他被视为假值的值）。将其移除：

```js
function uniqueSorted(values) {
  return [...new Set(values)].sort((a, b) => a - b);
}
```

回归测试：

```js
assert.deepEqual(uniqueSorted([0, 2, 1]), [0, 1, 2]);
assert.deepEqual(uniqueSorted([2, 0, 2]), [0, 2]);
```

该已完成回复的报告使用情况： 61个输入令牌，317个完成令牌，共计378个令牌. 完成词的使用可能包含推理标记；它不仅仅是指可见答案的长度。.

露娜的完整答案正确指出了这一点，即 filter(布尔值) 删除了有效的零值，并移除了该最后一步操作。该响应保留了现有的基于集合的去重功能和数值比较器。对于范围狭窄的维护工单而言，这种输出形式非常实用：先给出一段简短说明，随后直接呈现确切的函数实现。整个修复过程没有进行不必要的 API 重构、新增包依赖，也没有进行与修复无关的格式调整，从而确保修复内容清晰可见。.

积分中的差距出现在测试题中。露娜使用了 assert.deepEqual 执行了两次，但未包含 assert 导入语句。将这些语句粘贴到一个新的 Node.js 文件中，会在任何断言执行之前就失败。这些断言本身针对的是零、排序和重复项的相关组合，但该示例并非自包含的。 请添加一个严格的断言导入语句，或根据您现有的测试运行器调整这些语句。虽然这只是一个微小的修正，但它说明了为什么“合理的代码答案”和“可直接运行的测试结果”是两种不同的验收标准。.

保留的编码答案来自一次重试。之前的尝试达到了900个令牌的输出上限；而此次完成的重试使用了更短的提示词，并将输出上限设为1,200个令牌。 由于未保留重试时的确切措辞，因此我们不会将原始编码提示语呈现为产生此答案的来源。这使得无法与 Sol 进行纯粹的等效质量或延迟对比。这也提供了一个实用的部署经验：应记录提示语版本和完成原因，切勿将截断的响应视为成功的代码补丁。.

三音符合成：保持决策的条件性

将以下三条备注整合成一份简洁的决策备忘录，内容应包括：决策、依据、风险及后续步骤。备注 A：105 万令牌的上下文窗口虽能容纳大量源数据集，但并非每次请求的成本都很低。 备注 B：当输入令牌数超过 272K 时，已记录的输入/缓存速率会增加，且整个请求的输出量会成倍增加。备注 C：检索和缓存复用可降低重复提示的成本，但仍需对验收标准进行测试。.

## 决策
有选择地使用 105 万令牌的上下文窗口；对于重复或超大提示词，优先采用检索和缓存复用策略，但需经测试验证。

## 依据
该窗口可容纳大型源数据集，但容量并不能使每次请求的成本降低。当输入令牌数超过 272K 时，已记录的输入/缓存速率会增加，且整个请求的输出量会成倍增加。检索和缓存复用可能降低重复提示的成本。

## 风险
长上下文请求的成本可能高于预期。只有在满足验收标准后，检索和缓存带来的节省才能得到确认。

## 下一步
针对定义的质量和成本验收标准，测试具有代表性的工作负载，包括超过 272K 令牌的请求和重复提示场景。.

该已完成回复的报告使用情况： 99个输入令牌，223个完成令牌，共计322个令牌. 完成词的使用可能包含推理标记；它不仅仅是指可见答案的长度。.

Luna 保留了所要求的全部四个备忘录部分，并将其建议设定为以测试为前提。它保持了“持有大型数据源”与“经济高效地处理数据”之间的区别。它还指出，只有在满足验收标准后，检索和缓存带来的效益才算得到证实。 这种克制态度对于周期性的内部总结非常有用，否则，在经过几轮改写后，原本颇具吸引力的建议可能会变成毫无依据的承诺。.

该任务包含三条简短笔记，且仅报告了99个提示令牌。若将其称为长上下文基准测试，则有夸大其词之嫌。 该响应表明，Luna 在本次运行中能够对所提供的微量证据包进行整理；但这并未证明其在接近最大输入规模时，具备检索召回率、文档覆盖率、对冲突指令的抗干扰能力，或结果正确性。在将其用于周期性摘要之前，请加入包含矛盾日期和缺失所有者信息的案例，然后检查最终表述中是否仍存在不确定性。.

JSON 提取：明确标注未知项

从该简报中提取以下字段，并仅返回包含 customer、priority、deadline 和 unknowns 这四个键的有效 JSON 数据。简报内容：客户：Northwind Labs。优先级：高。截止日期：2026-10-04。负责人未命名，预算未确定。.

{"客户":"Northwind Labs","优先级":"高","截止日期":"2026-10-04","未知信息":["负责人","预算"]}

该已完成回复的报告使用情况： 64个输入令牌，63个补全令牌，共计127个令牌. 完成词的使用可能包含推理标记；它不仅仅是指可见答案的长度。.

在该小样本中，数据提取结果是考虑将Luna用于窄范围可重复工作的最有力具体依据。它返回了包含所需键值的有效JSON，正确复制了Northwind Labs和ISO格式的截止日期，并将所有者和预算保留为未知值。 该输出中没有需要去除的对话前缀。Sol 在相同的提取提示下生成了完全相同的 JSON，因此现有证据表明，就该记录而言，价格更高的模型并未展现出优势。.

语法正确性仅仅是第一道门槛。JSON 解析器会毫无问题地接受一个虚构的所有者、错误的客户，或者一个看似有效但实际上错误的日期。 模式可以对字段和类型进行约束，但无法证明内容与源数据一致。要实现这一目标，需要将三个已知值与需求文档进行比对，并确认两个缺失字段仍处于未知状态，以此作为语义验证的门槛。在规模化处理中，应将冲突的路线和不确定的日期转交审核，而非通过猜测来修复它们。.

一种超越可解析 JSON 的验证检查

以下是一个编辑验证示例，并非额外的模型响应。它在本地通过 Node.js 运行，且不向模型发起任何请求。它用于检查上文讨论的具体测试用例；并非对模型的通用评估。.

const assert = require('node:assert/strict');
const response = '{"customer":"Northwind Labs","priority":"high","deadline":"2026-10-04","unknowns":["owner","budget"]}';
const value = JSON.parse(response);
assert.deepStrictEqual(Object.keys(value).sort(), ['customer','deadline','priority','unknowns']);
assert.equal(value.customer, 'Northwind Labs');
assert.equal(value.priority, 'high');
assert.equal(value.deadline, '2026-10-04');
assert.deepStrictEqual(value.unknowns, ['owner', 'budget']);
console.log('此测试用例符合说明。新输入需指定相应的预期值。');

验证器会刻意检查预期事实以及键集。如果响应在保持有效 JSON 的同时添加了“confident owner”字段或更改了日期，验证器将拒绝该响应。这些确切的值属于此测试用例；生产环境中的验证器必须从输入合约中获取预期值，而不是为每个客户硬编码 Northwind Labs。 日历验证与更新记录的权限属于独立的检查项。通过此示例仅表示保留的答案符合本说明书的要求，并不意味着未来每次提取的结果都会正确。.

GPT-6 Luna 如何改变实际工作流程

只有当核心规格改变了团队的工作方式时，它才重要。GPT-6 Luna 定位于处理专注且高吞吐量的任务，因此首要问题是：您的工作负载是否能从中受益。 如果每个请求都具有简短的输入、明确的输出规范以及清晰的验收测试，该模型就可以集成到可重复执行的管道中。如果任务存在模糊性、依赖大量工具，或者可能需要多轮修正，那么周围的协调机制就与模型名称同样重要。.

对于 GPT-6 Luna，一种实用的生成模式是“两轮处理”流程：首先要求生成一个包含明确不确定性的简洁答案，然后仅将存在争议或不完整的部分发送至第二轮处理。 这既能减少输出令牌的浪费，又能使失败情况显而易见。此外，这还为您提供了与 GPT-6 Sol 进行比较的更好依据：关键不在于哪个名称听起来更响亮，而在于哪种流程能在更少的重试次数下达到验收标准。.

发货前的简易成本模型

官方价格表应转换为贵团队实际购买的计量单位：每日请求数、平均输入代币数、缓存前缀份额、输出代币数，以及输入量超过 27.2 万的调用所占比例。仅追踪标称输入价格的电子表格会掩盖长期上下文乘数和重试成本。.

在将 GPT-6 Luna 与 GPT-6 Sol 进行比较时，这一计算尤为重要。如果一个成本较低的请求需要反复进行修复处理，其成本可能会变得很高；而在进行确定性提取任务时，功能更强大的请求反而可能造成资源浪费。合适的基准应是您自身流量中的一小部分样本，且需采用相同的提示词、相同的模式以及相同的审核规则。.

采用前需检查的失效模式

模型页面可以告诉您哪些端点和模态已被记录在案，但无法保证您的现有应用在迁移后仍能保持相同的行为。请检查流式事件是否被正确解析、工具调用在重试过程中是否能保持状态、结构化输出是否会拒绝格式错误的字段，以及您的日志记录管道是否为每个请求记录了模型 ID 和推理设置。.

正是这些限制，使得本评测中的实践观察具有参考价值，同时又避免了将其演变为排行榜。我们设计的三个测试任务展示了该方案如何处理一个微小的代码缺陷、一份决策备忘录以及严格的JSON数据提取任务。这些测试并未衡量延迟、大规模场景下的可靠性，也未建立通用的质量排名。.

面向真实团队的决策框架

当模型评审能帮助某人在约束条件下做出决策时，它就很有用。对于 GPT-6 Luna 而言，最相关的约束条件包括请求格式、评审成本、上下文大小、输出格式以及错误答案可能带来的后果。 服务提供商的描述侧重于聚焦且高吞吐量的任务，但团队仍需将该描述转化为可监控的实施路径。首先，用一句话概括任务内容，明确模型将接收的输入、其他系统期望的输出，以及用于防止隐性错误的人工检查点。.

第一个错误是从演示提示中选择模型。演示通常侧重于流畅度，却隐藏了重试、令牌计数、工具权限和模式错误等操作细节。 更好的对比方法是使用三个具有代表性的任务：一个普通请求、一个困难请求，以及一个应被拒绝或上报的请求。结果并非一个单一的评分，而是一张简图，显示模型在哪些方面节省了时间、哪些方面需要监督，以及在哪些情况下其他模型（通常是 GPT-6 Sol）是更经济或更安全的选择。.

从验收测试开始

在编写提示语之前，先编写验收测试。对于代码，测试可能是通过的单元测试，或者是一个不改变公共 API 的补丁。对于数据提取，测试可能是包含所有必需键且显式保留未知值的有效 JSON。对于决策备忘录，测试可能是包含证据、风险、负责人和后续步骤的固定结构。 模型只能针对可见的目标进行评估。如果没有这个目标，一段措辞精炼的段落看似成功，却可能悄无声息地遗漏了下游流程所需的某个字段。.

一份好的验收测试既要足够具体，以便能够自动运行，又要足够有意义，以保障用户权益。它还应能清晰地指出分歧所在。如果两个输出结果不同，团队应能指出是由于事实缺失、假设缺乏依据、字段格式错误还是计算有误。这比单纯说某个答案“感觉更明智”更具可操作性。 这也是有助于采购的评审与仅仅重复发布说辞的评审之间的区别。.

设计与模型特征相匹配的提示词

不应将同一条提示词原封不动地复制到每个模型中。任务契约可以保持不变，但上下文的量、推理指令和输出约束应与具体场景相匹配。 对于 GPT-6 Luna，系统指令应保持足够简短，以免与源材料产生冲突。需明确说明角色、决策规则、所需的输出格式，以及需要显式未知项或上报处理的情况。.

对于长篇文档，应将检索与判断分离。首先确定能回答问题的段落；然后仅利用这些段落和给定的标准来推导结论。这可以减少因基于遥远且无关的细节而构建出自信句的可能性。同时，这也使得1.05M令牌的上下文窗口成为一种工具，而非默认设置。 当相距较远的证据之间的关联性重要时，大上下文具有价值；而当任务可以通过一小段精心挑选的文本片段解决时，大上下文则是一种浪费。.

对于使用工具的工作流，应描述模型与工具之间的边界。模型应决定是否需要使用工具，按照严格的模式提供参数，并说明将如何处理返回的值。 应用程序应执行权限控制、验证参数、记录调用，并决定失败的工具调用是否可重试。将模型视为整个应用程序会增加调试难度，并扩大错误假设的影响范围。.

一个可重复使用的四部分提示

背景： 仅提供该任务所需的事实和文件。. 目标 用一句话说明该决定或转变。简写中文（大陆）. 约束条件： 指定格式、排除项、不确定度处理以及工具限制。. 请核对： 在模型最终确定答案之前，请它列出缺失的输入或矛盾之处。这种结构足够简洁，便于重复调用，同时也足够明确，便于在不同模型之间进行比较。.

何时需要使用大型上下文窗口

“105万个令牌”这一标题既容易被引用，也容易被误用。上下文窗口仅告知你单次请求中可容纳多少内容；它并不会告诉你应该发送多少内容、模型会如何利用每一段文本，也不会说明该请求的成本是多少。 过长的请求还会导致审核速度变慢，因为团队需要审查的证据更多，且存在更多细微的指令冲突的可能性。.

当任务确实依赖于远距离引用时，请使用“全窗口”模式：例如，定义与异常分离的契约；接口与实现相距甚远的存储库；或是需要追溯序列才能找到答案的冗长研究档案。当问题属于局部范围、源数据集频繁变化，或者您希望获得紧凑的引用轨迹时，请使用“检索”模式。 当多个请求中共享一个稳定的前缀，且平台提供了足够的使用细节来验证缓存是否正常工作时，请使用缓存。.

27.2 万的阈值应作为架构图的一部分呈现，而非作为定价段落中的脚注。在阈值以下安全的请求，一旦超过阈值，成本可能会大幅增加。 团队应记录输入令牌、缓存令牌、输出令牌、模型 ID、推理设置，以及请求是否超过了该阈值。这些日志有助于建立真实的成本模型，并能及时发现因上下文膨胀导致的意外成本增加，避免其演变为每月账单中的意外支出。.

值得进行预发布测试的 API 迁移问题

在将现有集成迁移到 GPT-6 Luna 之前，请构建一个可重放小型匿名化样本的测试框架。对比最终文本、结构化字段、工具调用、终止原因以及令牌使用情况。 请勿仅比较响应的第一屏内容。模型可能会保留可见的结论，但同时更改字段名称、省略错误条件，或返回应用程序无法安全执行的工具参数。.

在集成计划中，“响应”和“聊天完成”并非可互换的标签。端点支持、推理设置、工具行为、流式事件和错误对象都会影响适配器。请在配置中固定模型 ID，但需确保其在日志和测试报告中保持可见。 当请求失败时，记录应显示端点、模型、推理耗时、提示词版本、请求大小以及重试决策。这些证据能让工程师重现故障，而非争论模型是否只是“状态不佳”。.

批处理会改变经济效益和运营节奏。它适用于夜间分类、文档准备或一系列紧急程度较低的转换任务。但对于需要向用户提供响应的交互式操作而言，批处理并不合适。 “快速”和“区域”模式也会改变价格计算方式。应将这些视为明确的配置选项，并在预算工作表中予以体现，而非将其隐藏在默认设置中。.

质量、安全与审查成本

代币价格较低并不一定意味着总成本更低，而更昂贵的模型也不一定能带来更好的业务成果。总成本包括重试、人工审核、事件处理以及修复下游数据所需的工作量。有用的指标是按任务类别划分的“每条被接受结果的成本”。 如果某条路径虽然每条请求的成本略高，但能减少高影响任务的修复工作，它仍然可能胜出；而对于具有强验证能力的确定性提取，一条成本极低的路径则可能占据压倒性优势。.

风险应按操作类型进行分类，而非按模型品牌分类。 阅读公开文件并起草摘要，与修改客户记录、批准付款、删除数据或发布法律声明是不同的。将不可逆的操作置于人工审核环节或第二个独立验证步骤之后。要求模型识别不确定性，但绝不能将听起来充满把握的句子作为授权机制。.

有关隐私和数据保留的问题应在部署审查中予以考虑。需确认发送了哪些数据、日志保留多长时间、谁可以查看提示信息，以及请求中是否包含机密信息或个人信息。 尽可能进行脱敏处理，尽量减少上下文信息，并清楚记录哪些字段已被移除。无论通过官方 API 还是其他兼容途径使用该模型，这些控制措施均适用。.

如何比较 GPT-6 Luna 和 GPT-6 Sol

公平的比较应保持任务和验收规则不变，同时允许每个模型发挥其已记录的优势。运行相同的输入数据包，但记录该模型是否需要不同的推理设置或不同的端点。 清晰地报告这些差异：一种模型可能生成更完整的补丁，另一种在重复提取时成本更低，还有一种可能更容易集成，因为其工具契约与您当前的适配器相匹配。.

不要将一项成功的任务视为普遍的排名依据。三项小型任务有助于发现工作流方面的问题，但不能用来证明存在一个放之四海皆准的赢家。 请使用多个现实的输入重复该任务，其中应至少包含一个对抗性或不完整的案例，并预先明确何种结果才算通过。如果样本量过小而无法支持结论，请如实说明。这种界定反而能增强信任，而非削弱评审的可信度。.

分阶段推出，确保决策可逆

从影子流量或非关键队列开始。让新路由生成响应，同时保持现有路由作为权威来源。 在固定时间段内，对比两者的接受率、令牌成本、审核时间及失败类别。随后逐个迁移任务类别，同时保留回滚开关和明确的版本标签。分阶段部署将模型选择转化为可观测的工程变更，而非一日之内完成替换。.

在部署过程中，请留意那些无法通过简单的通过率体现出的变化：输出结果更长、工具调用次数增加、升级处理次数增多，或者超过长上下文阈值的请求增多。模型看似准确，但可能消耗更多预算或增加操作员的工作量。针对这些维度设置警报，并与实际处理异常情况的人员一起审查这些情况。.

成功的样子

成功是一条成本明确、故障模式清晰、且人们可以遵循的审查流程的稳定路径。 它并不要求我们假装该模型是完美的。它要求我们清楚地知道：哪些任务它能处理得很好，哪些任务需要另寻他法，以及当输入不完整时如何停止或纠正它。这就是本次审查中收集的观察结果和文档背后所遵循的实用标准。.

公众反应能告诉你什么，又不能告诉你什么

以下来源作为注明出处的公众反响被纳入其中，而非作为官方文件或受控基准证据。其标题反映了各创作者选择测试或解释的内容；这些内容并不代表整个市场的结果。.

• Chase AI： GPT 6 Sol & Luna 现已上市（而且比 50% 更便宜！）. 将这种叙事框架和任何表现形式视为该创作者的个人体验，而非放之四海皆准的标准。.
• Rob “AI 专家”： ChatGPT 发布了 GPT-6 Sol 和 GPT-6 Luna（ChatGPT 的新模型与智能代理）. 将这种叙事框架和任何表现形式视为该创作者的个人体验，而非放之四海皆准的标准。.
• 与苏尔亚共话人工智能： GPT-6 Soul 与 Luna 与 Claude Opus 5.5：该选哪一款？. 将这种叙事框架和任何表现形式视为该创作者的个人体验，而非放之四海皆准的标准。.

这里还有另一个命名问题：一些公开视频在标题中将“GPT-6”和“GPT-5.6”混用。在复现某项说法时，请确保准确显示模型的ID。该 GPT-6 Astra 与 GPT-5.6 Sol 的对比 这是一个很好的例子，说明了为何应将提供商标识、平台标签和路由分别记录下来。.

如何访问 GPT-6 Luna

打开 GPT-6 Luna 工作区 不妨从一个可以评估的任务开始：一个简短的代码示例、一个简短的源数据包，或者一份结构化的数据提取简报。在比较不同版本时，请确保将要求的输出结果和验收规则置于可见位置。上文提到的官方令牌价格仅描述了直接使用 API 的情况，并不构成对工作区积分或订阅配额的承诺。.

关于当前平台的命名及独立署名规则，请参阅 GPT-5.6 定价指南 和 GPT-5.6 模型对比. 这些页面属于平台/编辑背景信息；它们不会覆盖 OpenAI 的 API 定价表。.

哪些人适合选择 GPT-6 Luna？

如果您的备选名单中包含一些价格较低的替代方案，请比较 更全面的型号目录 而不是理所当然地认为最新型号就一定最具性价比。如果您正在评估数据密集型工作，那么 数据分析模型指南 提供了一个独立的工作流视图。.

常见问题

什么是 GPT-6 Luna？

GPT-6 Luna 是 OpenAI 专为高吞吐量任务设计的模型。其官方 API 模型 ID 为 gpt-6-luna。.

GPT-6 Luna 的价格是多少？

OpenAI 显示，GPT-6 Luna 的定价为每 100 万个输入令牌 $0.10，每 100 万个缓存输入令牌 $0.01， 每 100 万次缓存写入为 $0.125，每 100 万个输出令牌为 $0.50（均按标准费率计算）。.

当输入令牌数量超过 272K 时会发生什么？

当请求的输入令牌数超过 272K 时，OpenAI 会对整个请求应用 2 倍的输入速率和缓存速率，以及 1.5 倍的输出速率。.

上下文和输出有什么限制？

GPT-6 Luna 指定的上下文窗口为 1,050,000 个令牌，最大输入为 922,000 个令牌，最大输出为 128,000 个令牌。.

知识截止点是什么？

当前的 OpenAI 模型页面显示，GPT-6 Luna 的知识截止日期为 2026 年 5 月 18 日。.

有哪些推理设置可供选择？

该 API 记录了“无”、“低”、“中”、“高”、“x高”和“最大”这几种推理难度级别，其中“中”为默认值。.

支持哪些 API 端点？

GPT-6 Luna 支持聊天补全、回复和批量处理。该模型页面未将实时处理、助手、音频、视频、图像生成、嵌入、微调、内容审核或旧版补全列为支持的功能。.

GPT-6 Luna 能处理图片吗？

是的。该模型页面列出了文本和图像输入以及文本输出。但这并不意味着它是一个图像生成模型。.

GlobalGPT 支持 GPT-6 Luna 吗？

请使用上文链接中的 GPT-6 Luna 专用模型页面。工作区积分和套餐配额与本评测中所述的直接 API 令牌费率是分开的。.

这篇文章中包含基准测试吗？

该测试包含三项小型任务的观察结果，并非受控基准测试。Luna在重试时需要修改编码提示。这些结果并不能确定一个通用的优胜者，也无法反映大规模场景下的性能表现。.

最终判决

在官方价格表中，Luna 是最务实的“成本优先”选项：它与 Sol 保持相同的标称上下文和输出上限，但收取的代币费率仅为后者的零头。这使其非常适合针对性强且重复性高的调用，但在未进行受控测试的情况下，低价格并不能证明其延迟更低或质量更高。 请根据可接受的输出结果和总运营成本进行选择，并在工作负载发生变化时重新评估该选择。.

核查日期：2026年9月23日。官方信息：OpenAI 开发团队。平台路线命名：GlobalGPT。公众反应：仅附有相关创作者和出版物的来源链接，未注明出处。.