GPT 6.1 Terra 成本与上下文指南：实现可靠的 JSON 提取

GPT 6.1 Terra：估算 API 成本并限制 JSON 提取智能体

对于结构化提取而言，关键问题不只是 GPT 6.1 Terra 能否读取发票或表单，还在于每次尝试是否具有可预测的上下文大小、输出上限、重试策略和验证步骤。这样可以更容易地进行成本预算，也能让工作流更安全。

发布报道将 Terra 描述为一款用于常规计算机操作的模型，包括读取屏幕、操作应用、填写表单和处理收到的发票。报道还称其图像理解能力有所提升，且公布的价格低于上一代产品。这些是 OpenAI 自行报告的说法，并非独立评估。有关发布详情，请参阅所提供的 The New Stack 来源报道。

本文聚焦于一种更具体的实现方式：从文档或屏幕中提取字段，返回符合 schema 的 JSON，在应用中进行验证，并仅在重试可能有帮助时重试。

决策：在需要受限提取时使用 Terra

当工作负载同时包含常规视觉或文本理解，以及后续的结构化操作时，GPT 6.1 Terra 是一个合理的候选方案。例如，可以提取发票号码和总额、读取表单字段，或将文档转换为会计或客服系统中的记录。

来源称 Terra 能够读取屏幕并与应用交互。来源还报道称，OpenAI 的测试发现，在最低设置下，其事实错误率低于上一代产品，并且命令行编码表现更强。这些报告结果并不能保证发票提取效果，来源也没有给出 JSON Schema 验证得分。你的应用仍然需要确定性验证、可观测性和失败处理路径。

对于更困难的任务，所提供的来源称 OpenAI 建议使用 Sol 或 Astra 处理最具挑战性的编码工作。该比较针对的是编码能力，而非结构化提取，因此不应将其用作文档工作流的排名依据。

通过 OneMux 使用 GPT 6.1 Terra 的价格

以下是已公布的 OneMux 价格快照，采集时间为 2026-10-30 09:00:04.984Z。价格保留目录中的计费单位：每 1 million tokens 对应的美元价格。这是已公布的快照，并非实时基准测试。

Terra 的列示上下文窗口为 1M token，并对超过 272K token 的请求采用单独的计费层级。对于跨越已公布层级边界的请求，不要套用 ≤272K 价格。缓存价格也会因层级和缓存操作而变化。在 ≤272K 层级中，目录列出的 OneMux 缓存读取价格为每 1M token $0.0078，缓存写入价格为每 1M token $0.195，12 小时缓存写入价格为每 1M token $0.39。缓存价格不等于免费输入，未知数值也不应按零处理。

一个工作负载估算示例

假设每次提取尝试使用 100,000 个输入 token，并生成 2,000 个输出 token。两者都处于 ≤272K 层级内。计算如下：

• 输入：0.1 million × $0.156 = $0.0156
• 输出：0.002 million × $0.78 = $0.00156
• 每次尝试合计：$0.01716

对于 10,000 份文档、每份仅尝试一次的情况，估算成本为 $171.60，前提是每个请求的 token 配置相同，且没有缓存或层级变化。如果 5% 的文档各产生一次额外的付费尝试，则工作负载变为 10,500 次尝试，估算成本变为 $180.18。这只是算术估算，并不保证实际用量。

更大的请求可能改变结果。当输入 token 为 300,000、输出 token 为 3,000 时，应采用 >272K 费率：

• 输入：0.3 million × $0.312 = $0.0936
• 输出：0.003 million × $1.17 = $0.00351
• 合计：$0.09711 per attempt

实际的成本控制要点是：删减无关的文档历史，并在提取不需要时避免发送过大的智能体对话记录。

限制上下文、重试和输出 token

可靠的提取工作器应执行四项相互独立的限制：

1. 上下文限制： 尽可能将文档与指令的最大长度设置在计费层级边界以下。如果文件更大，应将其分块、进行摘要，或通过单独的工作流处理，而不是无提示地跨入更高层级。
2. 输出限制： 根据 schema 设置合适的响应 token 上限。发票记录所需的 token 可能远少于长篇叙述。上限应为有效 JSON 留出足够空间，但不应允许意外生成长篇文章。
3. 重试限制： 对格式错误的 JSON 或临时传输错误，先设置零次或一次重试。不要对每个业务规则失败都进行重试；缺少发票号码可能需要人工审核或改进提取提示，而不是重复请求。
4. 尝试次数预算： 按文档和批次跟踪总尝试次数。预算耗尽后停止，并将项目放入审核队列。

一种实用策略是：在本地验证返回对象，对错误进行分类，并仅对可恢复类别进行重试。保留原始响应以便诊断，但不要自动将每个失败响应都附加到下一次提示中；这可能扩大上下文并增加成本。

JSON Schema 提取模式

具体的结构化输出参数名称和端点行为取决于有文档说明的 OpenAI 兼容接口。部署前，请在 OneMux 快速入门 和 API 文档 中确认支持的参数。下面的 Python 模式展示了工作流；端点占位符必须替换为文档中规定的值。

import json
from jsonschema import validate, ValidationError
from openai import OpenAI

client = OpenAI(
    api_key="YOUR_ONEMUX_API_KEY",
    base_url="YOUR_DOCUMENTED_ONEMUX_ENDPOINT",
)

schema = {
    "type": "object",
    "required": ["invoice_number", "invoice_date", "total", "currency"],
    "additionalProperties": False,
    "properties": {
        "invoice_number": {"type": "string"},
        "invoice_date": {"type": "string"},
        "total": {"type": "number"},
        "currency": {"type": "string", "minLength": 3, "maxLength": 3}
    }
}

response = client.chat.completions.create(
    model="GPT 6.1 Terra",
    messages=[
        {"role": "system", "content": "Extract only the requested invoice fields."},
        {"role": "user", "content": document_text}
    ],
    response_format={"type": "json_schema", "json_schema": {
        "name": "invoice",
        "strict": True,
        "schema": schema
    }},
    max_tokens=300
)

record = json.loads(response.choices[0].message.content)
validate(instance=record, schema=schema)

此示例假定端点支持所示的结构化输出格式和 max_tokens 参数。如果文档中的接口使用其他参数名称，或不支持 JSON Schema 响应强制约束，请保留本地解析和 jsonschema 验证，并将不受支持的结构化输出参数视为配置问题，而不是模型失败。

常见失败的排查方法

请求跨越 272K 层级。 测量完整请求，包括指令、文档文本、图像或图像表示，以及保留的对话上下文。在重试前删除未使用的历史记录或拆分文档。

响应是有效 JSON，但未通过 schema。 将语法错误与语义错误分开处理。一个有效的 JSON 对象仍可能缺少字段、类型错误或包含意外属性。可以使用简短的纠正消息重试一次，然后将持续失败的项目转交审核。

模型将数字返回为文本。 根据你的会计规则决定是否允许强制转换。对于财务记录，应明确验证币种和数值范围，而不是静默地转换所有值。

重试意外增加了成本。 记录每份文档的尝试次数，并使用实际输入和输出 token 数计算成本。带上完整先前对话记录的重试，成本可能高于一次干净且更短的重试。

结论

当实现将上下文、输出、验证和重试视为独立控制项时，GPT 6.1 Terra 可以支持成本受控的提取流水线。先从小型 schema 开始，限制响应，测量实际 token 用量，并保持严格的重试策略。OneMux 提供通往 Terra 的实用 OpenAI 兼容路径，并公布相关的输入、输出、缓存和上下文层级价格，帮助团队在投入更大批次前对工作负载成本进行建模。

如需了解当前模型可用性，请查看 GPT 6.1 Terra 模型页面，并将工作负载假设与 OneMux 模型目录进行比较。

来源

• The Next Web：OpenAI 发布 GPT-6.1 Terra —— 所提供的发布报道和模型说法。
• OneMux 上的 GPT 6.1 Terra —— 已公布的模型和层级价格。
• OneMux 定价 —— 上文引用的已公布价格快照。

已公布的价格快照

采集时间为 2026-10-30T09:00:04.989Z，来源为 OneMux 已公布目录。价格保留网站计费单位；这不是实时基准测试。分层、缓存或基于时间的计费可能有所不同。未知数值不等于零。

OneMux 当前价格。只有在输入/输出及计费单位一致时，才能比较工作负载成本；层级条件请参阅各模型页面。