AI分析阅读约 9 分钟

GPT-6.1 Terra每百万输入token只需1美元。完成一项工作要多少钱?

GPT-6.1 Terra降低了视觉推理与计算机操作的标准token价格。本文说明如何评估已完成工作、重试、审核投入,以及模型之外的集成成本。

K
Ken Jo

说明图: GPT-6.1 Terra每百万输入token只需1美元。完成一项工作要多少钱?

Ken Jo根据下方列出的来源制作的原创说明图。

屏幕一侧是一张发票,另一侧是会计表单。读出金额是一项任务;选对供应商、输入正确币种,并确认保存的记录确实存在,是更大的一项工作。当点击由AI模型执行时,这个区别尤其重要。

OpenAI于 2026年10月26日推出GPT-6.1 Terra,标准API价格为 每百万输入token 1美元、每百万缓存输入token 0.05美元、每百万输出token 5美元。公司将其定位于视觉推理、计算机操作和写作,并表示这些标准费率比GPT-5.6 Terra与GPT-6.1 Sol低50%。官方公告、注明日期的系统卡。

更低的价格让更多实验变得负担得起。但要判断哪些实验值得发展成工作流,需要另一种尺度:获得一个可以接受的结果要花多少钱。本文介绍三个实用场景、一组公开假设的成本计算,以及如何避免把成功的工具调用误认为完成的工作。

模型在系统内选择动作,由系统执行

Terra由OpenAI提供,这家公司也提供ChatGPT与Codex。选择它,意味着应用获得一组特定的语言和视觉能力。至于模型能观察哪个屏幕、调用哪些工具、工具能访问哪些账户,仍由外围应用决定。

以发票处理作为示例:模型观察表单、提出动作,工具执行后返回更新的画面。新画面很重要,因为看似正确的一次点击,可能打开了另一个面板、显示了校验错误,或仍未完成保存。工作流必须先识别结果状态,再继续。

因此,计算机操作是循环,不是一次回答。有用的集成连接观察、动作与结果状态检查,也规定什么时候停止、询问人类,或报告缺少必要输入。即便模型擅长理解屏幕,这些决定仍属于应用设计。

10月27日核对的OpenAI计算机操作文档区分浏览器活动事件与整轮的最终状态,还提供在流式输出中包含截图的控制。开发者可以用事件展示进度,同时单独验证所请求的结果确实存在。

解释观察、拟议动作、工具执行以及结果状态检查的示意图。

计算机操作循环示例。应用提供工具与权限,验收检查判断工作是否完成。这是原创解释图,不是OpenAI界面截图。

价格表是工作负载预算的起点

只要采用相同计费条件,10月26日公告中的标准费率很容易比较。输入与输出价格不同,缓存输入又是单独类别。因此,即便用户请求数量不变,较长回答或反复观察的循环也可能改变账单。

token类别每百万token标准价格试用中应测量什么
输入$1.00所有尝试的计费输入
缓存输入$0.05实际缓存命中,而非假设会复用
输出$5.00整次运行的全部计费输出

10月27日核对的模型卡列出其他计费条件:缓存写入另有费率,超过272,000输入token的提示触发长上下文调整,服务模式也可能改变价格。应使用实际请求适用的费率,而不是把价格表最低一栏当作通用价格。

下面的算例假设采用标准处理、不使用缓存,且请求低于长上下文阈值。每次尝试消耗10,000个计费输入token与1,000个计费输出token,因此成本为 每次0.01美元+0.005美元=0.015美元。这些token数量是为计算选择的输入,并非Terra或发票流程的实测值。

有用的预算从这种区分开始:先在明确假设下算一次尝试的账单,再问工作流需要多少次尝试、还使用哪些服务,以及有人接受结果前需要多少审核。

重试与审核改变了验收工作成本

假设一批有100项请求。在一种情景中,系统尝试100次,90项通过验收;在另一种情景中,恢复工作让尝试次数增至150次,95项通过验收。更多成功有价值,但成本比较也变了。

表格再加入第三种情况:30个项目分别接受20秒人工审核,人工费率假定为每小时30美元。总计600秒,也就是10分钟,成本5美元。表中所有工作量、验收数量与人工假设均为示例,不是实测产品结果。

示例批次token支出审核支出验收任务每项验收任务支出
100次尝试$1.50$0.0090$0.0167
150次尝试$2.25$0.0095$0.0237
150次尝试加上述审核$2.25$5.0095$0.0763

分母是通过验收的任务,不是生成的回答。如果记录保存错误,再漂亮的完成消息也不能增加这个分母。反过来,一个提出简短澄清问题的流程,可能比缺少信息却自信继续的流程更有用。

可以把额外工作称为 完成账单:把尝试过的动作变成可接受结果所需的资源。token价格只是其中一项,工具收费、执行环境、恢复和人工审核也可能加入。上表为了让算术清晰而省略其他服务;生产估算应包含实际集成使用的项目。

我们的看法是,模型价格降低最有价值的影响,是为改善完成情况留出更多空间。团队可以比较指令、检查失败案例、测试恢复路径。仅把未经检查的答案变便宜,不如利用节省的费用产生需要更少返工的结果。

从完成标准明确的发票草稿记录开始

第一个实际场景是应付账款助手:根据提供的发票准备草稿记录。使用测试账户和范围有限的示例文档。要求模型操作表单前,先定义供应商、币种、金额和参考字段的要求。

该场景的验收结果是:保存的草稿字段与来源一致,且记录标识符可以重新取得。点击“保存”只是中间事件。流程应检查实际记录或确认状态,并报告未解决的字段,而不是用看似合理的猜测填充。

试用应包含普通文档,也包含刻意设置的困难案例:币种不清、缺少供应商标识符、发票号码已存在。这些案例揭示不同故障。正确读文本、选对账户、避免重复记录,是工作的不同部分。

首次试验应小到能够审核每个结果。发生失败时,应定位最早错误的观察或动作,而不是一次重写整套指令。缩小诊断范围,才能知道问题来自文档理解、导航、账户数据还是验收检查。

这个场景说明的是应用设计,并不意味着Terra自带会计连接器,也不意味着本文测试了某个会计产品。模型只是流程的一个组件,工具与业务规则需要另行提供。

目录匹配在执行动作前检验视觉判断

第二个场景是将产品照片匹配到现有目录条目。10月27日查阅的OpenAI模型卡明确把产品照片匹配列为Terra的预期用途。对零售商而言,有用结果可以是一项匹配建议,并带有足够信息,让审核者区分“看起来相似”与“就是正确商品”。

建立小型评估集,包括简单匹配、相似包装以及缺少细节的照片。把预期目录标识符与给模型的指令分开保存。要求返回建议标识符及支持选择的可见特征,并明确允许在图像不足时回答“未解决”。

未解决可能恰恰是正确结果。如果两个包装只在图中看不到的信息上不同,流程就需要另一张照片或非视觉标识符。流畅的包装描述无法创造输入里不存在的证据。

允许修改目录之前,先只提出匹配建议。这让验收规则容易检查,也让团队得到可以理解的错误集合。如果之后加入写作步骤,要评估描述草稿是否保留已验证的目录事实,而不是从视觉相似性引入未经确认的细节。

旧式门户让恢复成为任务的一部分

第三个场景是在具有浏览器界面的内部门户中准备更新草稿。任务可能是找到记录、改成指定描述,并留待人类批准。价值在于把可理解的业务请求连接到一连串界面动作。

困难情况常常与状态有关。会话可能过期,前一个选择可能让新的必填字段出现,页面更新也可能比预期更慢。有用的评估应记录流程如何应对这些条件,而不是只统计最容易的导航路径。

试用前定义恢复预算。例如,保存状态不确定时,应用可允许再观察一次;仍不清楚就停下来等待审核。这是政策选择示例,不是Terra产品限制。它为团队提供了可测试的有限行为,也避免无效循环持续消耗资源。

还要区分集成故障与模型故障。工具无法到达页面、账户没有编辑权限、模型选错控件,需要不同修复。让这些类别保持可见,才能使成本估算与质量改进更有意义。

可用性说明从哪里开始,不代表每个账户都能操作一切

10月26日发布宣布Terra可用于 Plus、Pro、Enterprise和Edu的ChatGPT Work与Codex,以及API标识符 gpt-6.1-terra。这些是访问模型的途径,具体流程可用的工具与权限仍取决于产品、账户和集成。

面向开发者的模型卡(于10月27日查阅)指定使用Responses API进行工具调用,默认推理强度为medium。评估时记录所选模型与推理配置,才能有意义地比较两次运行。如果同时修改模型、指令和工具环境,结果差异就更难解释。

使用Work或Codex的团队应从已支持的流程开始,检查实际控制。自定义应用则应依据当前计算机操作集成文档配置执行环境和许可动作。仅有模型标识符,不会自动建立公司应用的认证连接。

用同一组验收任务比较配置

有用的初次试验应小到能逐项检查,又足够多样,覆盖真实工作将遇到的条件。先定验收规则,再看生成结果。下列步骤是建议的评估方法,不是基准结果。

  1. 选择一项边界明确的工作。 指定输出与负责验收的人。第一次优先使用草稿或测试环境中的动作。
  2. 准备固定案例集。 包括普通输入、缺失信息和相关界面中断。预期结果放在模型指令之外。
  3. 记录配置。 保存模型ID、推理设置、指令、工具版本与相关账户权限。
  4. 定义停止与恢复规则。 规定什么时候允许再观察、什么时候重试有用、什么时候必须由人解决不确定性。
  5. 收集可观察结果。 记录通过验收、错误、未解决、尝试次数、耗时和计费用量。工具操作状态只是记录的一部分。
  6. 加上实际运营成本。 包含适用的工具、环境费用与实测审核时间,并用一致定义除以验收任务数。
  7. 改变一个有意义的变量。 用相同案例比较修改后的指令或推理设置,先检查哪些失败改变了,再扩大试验。

区分token支出、重试、工具与人工审核,再计算通过验收工作的成本。

建议成本模型:加总流程实际消耗的资源,再除以通过验收的任务数。这些组件是评估框架,不是已发布的Terra运营测量。

即便第一次试验令人失望,这份记录仍有用。它能指出改进应针对视觉理解、流程设计、工具可靠性,还是人工返工量。与单独看每次请求平均成本相比,这更适合决定下一步自动化什么。

更便宜的计算机操作,只有让完成更可负担才有意义

Terra较低的标准token价格,为更仔细的测试和在预算内支持更多工作创造了机会。业务问题在于:具体集成能否以可管理的审核和恢复投入,将机会变成可接受结果。

能读屏幕、选择点击的模型是有用的;能够展示改变、识别完成,并核算为此付出的流程,才是团队可以评估和持续改善的对象。

来源

三个工作流场景、成本输入与评估程序均为示例。美元计算采用所述标准费率和明确选择的假设,并非延迟、准确率或运营成本实测结果。


Telli.sh推荐: 让试验笔记、参考资料和流程修改背后的决定随时可查。创建Telli.sh账户,整理你的评估笔记。


← 返回博客