一只骑车的鹈鹕，测出了 GPT-6 Astra 的真实卖点

一只骑自行车的鹈鹕，成了 GPT-6 Astra 和 GPT-5.6 家族之间的临时裁判。

开发者 Simon Willison 用同一个 SVG 生成任务，分别测试了 GPT-6 Astra，以及 GPT-5.6 的 Sol、Terra、Luna，并把每个模型在 low、medium、high、xhigh、max 等推理档位下的结果放进一张对比网格。结果很直观：Astra 的图形质量明显更好，而且低档 Astra 的花费只有 9.55 美分，却超过了这次测试中所有 GPT-5.6 Sol 输出。

真正有意思的地方，不是鹈鹕画得可爱，而是价格表和实际成本之间出现了偏差。

一张对比图里的几个事实

这次测试使用的是“骑自行车的鹈鹕”SVG。它同时考验模型对形体、构图、对称关系和代码生成的控制力，算不上严谨基准，却很适合暴露模型在细节上的差异。

测试结果可以压缩成几句话：

  • Astra 从 low 到 xhigh 的结果，都比 GPT-5.6 Sol 最好的结果更完整。
  • Sol 在 xhigh 档的输出已经接近目标，但仍更像抽象几何形状。
  • Astra 的 max 结果最好；不过 low 档已经足够打败这组 Sol 样本。
  • Astra 在 max 以下的档位，仍不能稳定保证鹈鹕两侧都出现完整的腿。
  • Astra 不支持 reasoning=none，只能比较不同推理强度。
  • Astra 和 Luna 的输入 token 数是 16，Sol 和 Terra 是 26。

价格也有差异：

模型输入价格输出价格测试中的明显特征
GPT-6 Astra约 10 美元 / 百万 token约 50 美元 / 百万 token单价更高，但各档位使用的 token 更少
GPT-5.6 Sol约 5 美元 / 百万 token约 30 美元 / 百万 token单价更低，但这组图的结果明显较弱

这里的价格和 9.55 美分，来自这张测试对比网格；具体账单仍取决于输入、输出和推理 token 的实际计费方式。读者可以直接查看原始页面和完整图片：对比网格。

高单价，为什么可能反而更便宜

只看“每百万 token 多少钱”，Astra 像是更贵的模型。

输入价格约为 Sol 的两倍，输出价格也更高。但模型的总成本不是单价一个变量。它还取决于：

  • 生成了多少可见输出；
  • 隐藏推理消耗了多少 token；
  • 同一个任务需要重试几次；
  • 低档位是否已经能达到交付标准。

Astra 的优势，至少在这个任务里，正是最后一项：它不必开到最高推理档，就能得到比 Sol 更好的结果。模型单价更高，单次任务却可能更省。

这对开发者比“旗舰模型更聪明”有用得多。客服回复、代码修复、结构化提取这类任务，团队真正关心的是每个可交付结果要花多少钱，而不是模型宣传页上那一行漂亮的每百万 token 报价。

但这里也有一个容易被忽略的限制：9.55 美分不是一个可以直接复制到所有任务上的预算数字。SVG 鹈鹕的输入很短，输出形态也比较特殊。真实应用里，长上下文、工具调用、失败重试和并发控制都可能改变账单。

同一模型，换一类工作，成本排序就可能反过来。

这更像一次效率信号，不是全面登顶

我更愿意把这组结果理解成一个效率信号。

Astra 低档推理就能取得更好的结果，说明模型能力、推理预算和输出质量之间的关系正在变化。过去常见的做法是：任务越难，给模型越多 token，顺便接受更高费用。现在更强的模型可能在较低推理档位就完成同样的工作。

这会改变团队的模型选择方式。

使用者现实影响更稳妥的动作
独立开发者可以用 Astra low 处理一部分原本要交给高档模型的任务先记录每次调用的输入、输出和推理 token，再比较单任务成本
小型产品团队单价上涨会放大预算压力，但成功率提高可能减少重试用自己的真实任务做一轮 A/B 测试，不要只拿公开榜单做决定

模型评测史上一直有这个问题：一个漂亮的样例，能说明模型具备某种能力，却不能说明它在所有工作上都更好。

早期处理器评测会用固定程序跑分。分数很高，不代表所有软件都快。今天的生成模型也一样。一只鹈鹕能考察 SVG 结构和空间关系，却不能代替代码代理、长文档问答或批量分类测试。

所以，“Astra 全面碾压 Sol”目前说不成立。能成立的说法是：在这次 SVG 任务中，Astra 的质量—成本比很有吸引力。

16 个 token 暗示了什么

Astra 和 Luna 都用了 16 个输入 token，Sol 和 Terra 使用了 26 个。这个差异很小，却比单纯看图片更值得追踪。

它可能来自不同的提示模板、tokenizer、接口封装，也可能反映模型之间存在某些共享的处理方式。仅凭这一个数字，无法证明 Astra 和 Luna 的底层关系，更不能据此推断 OpenAI 没有公开的架构安排。

但它至少提醒开发者一件事：不同模型的 token 数不能想当然地横向比较。相同文字，经过不同 tokenizer 或系统提示处理，计费单位就可能不同。模型名称相近，也不代表输入路径、上下文包装和推理机制相同。

这也是 API 选型里最容易被忽略的一层。团队常常盯着输出质量，却忘了检查请求到底被模型处理成了多少 token。等月底账单出现，才发现真正贵的不是模型回答，而是上下文和重试。

接下来最该观察的，不是 Astra 还能不能画出更漂亮的鹈鹕，而是三件更硬的事：

  • 多次重复后，Astra low 的质量是否仍然稳定；
  • 在代码、工具调用和长上下文任务里，低档推理是否同样划算；
  • 官方计费说明是否明确列出隐藏推理 token，以及不同档位的实际收费口径。

这组测试已经足够说明：看模型价格，不能只看单价；看模型能力，也不能只看最好的一张图。

Astra 这次确实做对了一件事——用更少的推理预算交付了更好的样本。可要把一次漂亮的鹈鹕，变成团队敢于迁移的生产力工具，还得靠稳定性和账单数据来完成最后一跳。