GPT-6 Astra定价2.5倍性能却无显著提升：成本效益分析

系列推荐：TypeScript 中的 AI——5 本书，从你的第一次 LLM 调用到生产环境中的 AI 智能体——五本全集在此

我的项目：Hermes IDE | GitHub——为使用 Claude Code 和其他 AI 编程工具的开发者打造的 IDE

关于我：xgabriel.com | GitHub

新模型发布了。团队里有人在 PR 中改了一个字符串——某个配置文件里的模型 ID。五分钟后 diff 就绿了。评测看起来没问题，也许在你恰好拥有的评测套件上高了一分。它上线了。

三周后账单来了，形状和以前不一样了。没有人写出坏循环。没有人引入提示词注入。系统做的和上个月完全一样。只是做同样的事成本更高了，因为一行 diff 把每次请求的费用从每百万 token 2 美元和 10 美元变成了 10 美元和 50 美元。

OpenAI 于 2026 年 9 月 3 日发布了 GPT-6 Astra。OpenAI 称其为迄今为止发布的最强模型。这是该公司的声明，我不打算反驳。但"最强模型"和"你的服务应该默认调用的模型"是两个不同的问题，它们之间的距离会体现在你的基础设施账单上。

发布数据说了什么

OpenAI 公布的 API 列表价格，按每次调用计：

标准层：输入 token 每 100 万 10 美元，输出 token 每 100 万 50 美元

快速层：输入 token 每 100 万 20 美元，输出 token 每 100 万 100 美元

Astra 接收文本和图像输入，仅返回文本，上下文窗口为 100 万 token。发布后首先提供给 OpenAI Daybreak Access 计划中的有限组织，随后向付费 ChatGPT 层级开放，API 按计划在发布后数日内可用。同时也已在 AWS Bedrock 和 Microsoft Azure 上线。

现在来看第三方数据。Artificial Analysis 独立于厂商运行自己的评测。在其 Intelligence Index 上，Astra 得分为 60，在该网站追踪的 202 个模型中排名第 14。其每个 Intelligence Index 任务的成本约为 0.96 美元。该集合中的中位模型得分为 36，定价约为输入每 100 万 token 2 美元、输出每 100 万 token 10 美元。

这一页上的两句话是本文存在的理由。Artificial Analysis 指出，Astra 在 Intelligence Index 上的得分接近 GPT-5.6 Sol，而定价约为 Sol 的 2.5 倍。该机构还指出，在其 Coding Agent Index 上，Astra 得分与 Claude Fable 5 持平，且成本更低。

这两件事可以同时为真，它们合在一起就是全部论点。同一模型在通用工作中是糟糕的默认选择，在 AI 智能体编程中却是划算的买卖。得到哪个结果，取决于你把它路由给谁。

OpenAI 在发布时公布了自己的基准测试结果，但这些是厂商数据而非独立数据。有两个值得引述，因为下面的路由论证就靠它们：DeepSWE v1.1 达 74.1%，以及 OSWorld 2.0 离线子集在每个任务约 40 分钟下达到 72.6%。两者都衡量的是长时间 AI 智能体运行，这是唯一一种昂贵模型可能更省钱的工作形态。其余发布数据是推理、数学和科学分数，与此处的路由决策无关；系统卡里有详细数据。

OpenAI 联合创始人兼总裁 Greg Brockman 表示："我认为我们现在处于 AGI 时代，这并非不合理"（VentureBeat）。这是他对整个领域的看法，你可以持有任何你喜欢的观点。但你的财务团队还是会问账单的事，而账单是算术题。

在任何具体数字之前先说一句警示。这里的都是发布价格表。模型定价会变动，层级会新增，批量和缓存输入会有折扣。在做预算前请查看当前的定价页面。

输出 token 才是账单所在

以一个每天处理 1000 次请求的服务为例。每次请求发送约 4000 个输入 token，返回约 800 个输出 token。这是从公布的按 token 价格进行的示例计算，不是任何人的实际账单。

在 Astra 标准层上：

输入：400 万 token，按每 100 万 10 美元 = 每天 40 美元

输出：80 万 token，按每 100 万 50 美元 = 每天 40 美元

每天约 80 美元，三十天约 2400 美元。再读这两行。你发送的输入 token 是接收到的输出 token 的五倍，而账单的两部分相等，因为一个输出 token 的定价是输入 token 的五倍。

这个比率才是需要内化的东西。你所有的提示词工程直觉都集中在输入侧，而输入侧是便宜的那一半。让响应更冗长的改动，在账单上的价值远比让提示词更长的改动值钱得多。

看看如果每次请求的输出从 800 token 增加到 3000 会发生什么——这是要求响应中加入更多推理时的常见结果：

输入：保持不变，每天 40 美元

输出：300 万 token，按每 100 万 50 美元 = 每天 150 美元

账单翻了一倍多，而你的请求量纹丝不动。没有人写出循环。只是有人改了一个提示词。

快速层让两边再次翻倍，在原始工作负载下达到每天 160 美元。它买的是延迟。想想看，是所有请求都需要这个，还是只有 5% 有人在旁边等着。

作为对比，用 Artificial Analysis 报告中价格中位数（输入 2 美元、输出 10 美元）的模型运行相同工作负载，每天只需 16 美元，三十天约 480 美元。这才是你在决定的那个差距。它不是边缘性的。

简洁是一种折扣

细微之处会走向反面。

按 token 价格不等于按任务价格，Artificial Analysis 两样都公布。在其索引测试中，Astra 输出了 1600 万 token，而追踪模型的中位数是 6200 万 token：约为四分之一的 token 量，得分 60 对中位数的 36。这种简洁是为什么其每个 Intelligence Index 任务的成本落在 0.96 美元，而不是按每 100 万输出 50 美元的价格本该达到的位置。

对此要谨慎解读。0.96 美元是一套基准测试，针对整个追踪领域的测量。2.5 倍是另一个不同的测量，按 token 对比 GPT-5.6 Sol 的单价。两者不能相乘得到任何东西。站得住脚的是形态：一个是低价表上的冗长模型，一个是高价表上的简洁模型，在按任务账单上可能比价目表显示的接近得多，排序可能颠倒任一方向。

这正是为什么按每百万 token 价格比较是选模型的坏方式。两个相同定价的模型在你的实际账单上可能相差 3 倍，因为其中一个会自言自语地思考，另一个不会。而一个便宜的模型如果验证失败、重新尝试两次、最后升级调用，那就是三笔费用加一笔贵的。

回答这个问题的数字是每个成功任务的成本。

type Outcome = {
  usd: number;
  accepted: boolean;
};

export function costPerSuccess(rows: Outcome[]): number {
  const spend = rows.reduce((s, r) => s + r.usd, 0);
  const wins = rows.filter((r) => r.accepted).length;
  return wins === 0 ? Infinity : spend / wins;
}

在每次请求上记录 usd 和 accepted，你就能按模型、按路由、按客户层级计算这个值。accepted 是"这个实际上成功了"在你所在领域的含义：JSON 解析通过 schema 验证，生成的补丁编译通过，客服回复发出前没有人工修改，提取的发票总额与账本匹配。

在 10% 的流量上运行昂贵模型一周，将这个数字与便宜模型比较。如果昂贵模型的成功率足以弥补便宜模型的 retry 税，它就是更便宜的选择——按 token 单价是一个干扰项。通常它在部分流量上胜出，在其余上落败，这就是需要路由的原因。

先走便宜路线，有信号时升级

模式是一把梯子。先调用便宜模型。用你信任的东西检查结果。如果检查失败，就升级到贵的。拒绝任何会使请求超过你预先设定的成本上限的调用。

从价格和一个成本函数开始。

// 发布列表价格，单位 USD 每 100 万 token。
// 在依赖这些数据前核实当前定价。
export type Price = { inPerM: number; outPerM: number };

export const PRICES = {
  cheap: { inPerM: 2, outPerM: 10 },
  strong: { inPerM: 10, outPerM: 50 },
} as const satisfies Record<string, Price>;

export function costUSD(
  p: Price,
  inTok: number,
  outTok: number,
): number {
  return (inTok / 1e6) * p.inPerM
    + (outTok / 1e6) * p.outPerM;
}

然后是路由需要的两种形态：模型调用返回什么，验证检查返回什么。

export type Completion = {
  text: string;
  inputTokens: number;
  outputTokens: number;
};

export type ModelCall = (p: string) => Promise<Completion>;

export type Check<T> =
  | { ok: true; value: T }
  | { ok: false; reason: string };

export type Validate<T> = (text: string) => Check<T>;

Check 在失败时携带 reason。这个字符串是整个系统最重要的产出。它告诉你便宜模型为何不够好，这是后续判断升级是否值得的唯一输入。

路由器的 result 类型是设计决策所在。一个被路由的请求和一个被拒绝的请求携带不同的字段，因此将它们做成一个联合类型，以 stop 作为辨识键。

export type Tier = "cheap" | "strong";

export type Routed<T> = {
  stop: "validated";
  value: T;
  model: Tier;
  usd: number;
  attempts: string[];
};

export type Refused = {
  stop: "ceiling" | "exhausted";
  value: null;
  model: "none";
  usd: number;
  attempts: string[];
};

export type RouteResult<T> = Routed<T> | Refused;

选项包是调用方的配置入口。refuse 函数在一处构建拒绝那一半的联合类型，这样两条放弃的退出路径不会渐行渐远。

export type RouteOptions<T> = {
  prompt: string;
  cheap: ModelCall;
  strong: ModelCall;
  validate: Validate<T>;
  maxUSD: number;
  maxOutputTokens: number;
};

const estTokens = (s: string) => Math.ceil(s.length / 4);

function refuse(
  stop: "ceiling" | "exhausted",
  usd: number,
  attempts: string[],
): Refused {
  return { stop, value: null, model: "none", usd, attempts };
}

路由器本身按顺序逐级攀升，在调用前预测每一层的成本，并在第一个通过验证的结果处停止。

export async function route<T>(
  o: RouteOptions<T>,
): Promise<RouteResult<T>> {
  const attempts: string[] = [];
  let usd = 0;

  const tiers = [
    { name: "cheap", call: o.cheap, price: PRICES.cheap },
    { name: "strong", call: o.strong, price: PRICES.strong },
  ] as const;

  for (const tier of tiers) {
    const worstCase = costUSD(
      tier.price,
      estTokens(o.prompt),
      o.maxOutputTokens,
    );
    if (usd + worstCase > o.maxUSD) {
      return refuse("ceiling", usd, attempts);
    }

    const res = await tier.call(o.prompt);
    usd += costUSD(
      tier.price,
      res.inputTokens,
      res.outputTokens,
    );

    const check = o.validate(res.text);
    if (check.ok) {
      return {
        stop: "validated",
        value: check.value,
        model: tier.name,
        usd,
        attempts,
      };
    }
    attempts.push(`${tier.name}: ${check.reason}`);
  }

  return refuse("exhausted", usd, attempts);
}

其中三个细节承担了整个设计的重量。

天花板检查在调用前运行，并带有预测功能。它计算即将使用的层级的最坏情况成本，使用你配置的最大输出 token 数而非你期望的输出数。如果该预测超过天花板，本次调用就不会发生。在调用后检查的话，你已经为那个让你超支的请求付过钱了。注意 estTokens 是一个粗略的启发式估算，所以如果一个 prompt 的 token 压缩率比每 token 四字符更差，最终总额仍可能略微超过天花板。如果你需要天花板精确而非接近，替换成一个真正的分词器即可。

stop 是一个编译器能够理解的返回值。以 ceiling 结束的请求和以 exhausted 结束的请求是截然不同的产品决策。第一种意味着你拒绝消费；将它放入队列、批量处理，或请用户确认。第二种意味着两个模型都尝试了，但都没有产出有效结果；这是需要人工介入的问题。抛出一个错误会让两者在调用方处混为一谈。以 stop 作为联合类型的键，紧缩（narrowing）就身兼二任：它既区分了两种拒绝，又让 validated 分支中的 value 是一个真实的 T 而不是每个调用方都需要重新检查的 T | null。

第三个细节是 usd。它随答案一起返回，这样你就能在仍有它的时候将它写入行记录和追踪 span。如果你没有记录每次尝试的成本，就无法后续计算每个成功任务的成本。

选择你能信任的升级信号

路由器的好坏完全取决于 validate。有三类信号，它们并不等价。

确定性检查免费且应优先考虑。Schema 验证、JSON 解析、枚举成员测试、编译步骤、单元测试运行、查询确认模型命名的实体是否真实存在于你的数据库中。这些对每个请求零成本且从不撒谎。

type Ticket = {
  category: "billing" | "bug" | "account" | "other";
  urgency: 1 | 2 | 3;
};

const CATEGORIES = ["billing", "bug", "account", "other"];

const validateTicket: Validate<Ticket> = (text) => {
  let raw: unknown;
  try {
    raw = JSON.parse(text);
  } catch {
    return { ok: false, reason: "not_json" };
  }
  if (typeof raw !== "object" || raw === null) {
    return { ok: false, reason: "not_object" };
  }
  const t = raw as Record<string, unknown>;
  if (
    typeof t.category !== "string"
    || !CATEGORIES.includes(t.category)
  ) {
    return { ok: false, reason: "bad_category" };
  }
  const u = t.urgency;
  if (u !== 1 && u !== 2 && u !== 3) {
    return { ok: false, reason: "bad_urgency" };
  }
  return { ok: true, value: t as Ticket };
};

在工单处理器中，这个联合类型在调用方的价值得以兑现：在 validated 分支内部，result.value 是一个 Ticket 而非 Ticket | null，因此 save 可以直接接受它，无需空值检查。

const result = await route({
  prompt: buildPrompt(ticketText),
  cheap: callCheapModel,
  strong: callStrongModel,
  validate: validateTicket,
  maxUSD: 0.05,
  maxOutputTokens: 300,
});

if (result.stop === "validated") {
  await save(result.value);
} else {
  await queueForHuman(ticketText, result);
}

设置 maxUSD 时要让整条梯子都能容纳其中，否则天花板会在升级从未发生之前就触发，所有困难请求都会以 ceiling 回来。按这些价格计算，一个 1,500 token 的 prompt 加上 300 token 的输出上限，在便宜层级最多花 $0.006，在强层级花 $0.03，整条梯子需要约 $0.036。$0.05 的天花板留有空间且仍会拒绝有人粘贴了日志文件的 10,000 token prompt。根据你自己的 p95 prompt 大小推算你自己的数字，而非照搬这一个。

模型自报的置信度是最弱的信号，也是最诱人的。让模型以 0 到 1 给自己打分的不确定性得到一个数字，这个数字与某些东西相关，但与正确性的关联并不牢靠。如果你使用它，把它当作多个输入之一，并用你实际标注过的结果来校准阈值。不要把它作为唯一的关卡上线。

第二种意见需要花费第二次调用。运行便宜模型两次并在出现分歧时升级是可行的，但这会将你的便宜层级花费翻倍，以避免部分强层级花费。这笔账是否划算，用上面的数字算一下就知道了：当强模型成本高于额外一次便宜调用，且分歧是失败的一个合理预测因子时，这种策略就值得。

按这个优先级排序。确定性优先，没有确定性检查时用第二种意见，模型自报置信度最后且永远不要单独使用。

贵模型贵在哪里

以上都不是支持总是路由到便宜模型的论据。有一类工作场景，强模型才是正确的默认选择，发布数据指向了它。

长时间智能体运行。Artificial Analyses 的数据显示 Astra 在编程智能体指数上与 Claude Fable 5 持平，且成本更低，OpenAI 报告在 OSWorld 2.0 离线子集上达到 72.6%，每个任务耗时约 40 分钟。在这类工作上，弱模型的失败并不干净。它在第 4 步走错方向，然后又在之上花费另外二十步构建，而每一步都是一次付费调用。便宜模型的失败模式代价昂贵，这是按 token 单价无法体现的。

由此得出的启发式规则：自主运行时间越长，升级就应该越早。单次分类是便宜层级加验证器的好候选，因为重试只需一次调用。四十分钟的智能体任务是差候选，因为重试代价是四十分钟的调用，而且你在最后才知道结果。

同样的逻辑反向适用。高批量、规格明确、有 schema 检查的工作——分类、提取、路由、打标签、短摘要——属于便宜层级，2.5 倍溢价在这些可测量的维度上最难自圆其说。

本周要做的两个改变

两件事，都很小。

给你的服务产生的每个 LLM 响应附加成本。不是附加到仪表板。是附加到响应对象、日志行和追踪 span 上。在调用点将 token 数乘以每百万 token 的价格。没有这四行代码，本文中的每一个问题都无法回答。

然后选择你最高流量的 LLM 端点，在模型选择前加一个验证器。先跑廉价层，检查输出，失败后升级。给整个流程设置一个单请求费用上限，这样一个病态输入就不会花费无上限的费用。一周后比较每个成功任务的成本。

前沿模型是一个真正的成就，基准分数就摆在那里。它仍然是一个有价格的组件，而你仍然是决定哪些请求值得使用它的人。

成本上限、升级信号和评估套件——这些才能告诉你一次模型切换是否真的有帮助——这些都是只有在真实流量击中系统时才会生效的 LLM 系统组件。这正是 AI That Ships 这本书涵盖的领域，用 TypeScript 编写，附带了完整的仪表化。

这是 AI in TypeScript 系列的第 5 本书，这个五本书的系列从你的第一个 LLM 调用讲起，一直到可以在生产环境中运行的 AI 智能体。