Ultrafast 编程：即时设计循环与高昂成本

Ultrafast 让 Astra 的响应显得非常即时：我可以要求修改一个小应用，然后实时看着改动出现。这对现场原型、交互式开发和计算机操作可能有用。问题是，同样的速度也会极快地消耗账户额度和按 API 价格计算的用量。

在展示的价格表中，Astra 标准输出每百万 token 为 50 美元；Ultrafast 短上下文为 300 美元，长上下文为 450 美元。我让它审查了两个各不到 100 行的拉取请求，报告的合计用量约为 600 美元。这只是我的例子，并非每次审查的通用成本。

价格上涨的不只是输出。展示的短上下文 Ultrafast 价格表列出每百万输入 token 60 美元、缓存输入 6 美元、缓存写入 75 美元。即使代码改动很小，长时间且大量使用缓存的智能体工作流也可能因此变得昂贵。

按这些价格，我认为大多数人不应该使用这种模式，包括通过 500 美元订阅使用。我估计每周额度约相当于 1,000 美元的 Ultrafast API 用量价值，以及约 2.1 小时生成时间；这是根据我的用量和假设做出的推算，不是保证额度，也不是完整一周的实测。

现场演示前，我的账户显示剩余 38%。两个提示词——一个构建初始应用，另一个修改外观——分别用了 38 秒和 16 秒，显示的剩余额度降到了 37%。显示百分比比较粗略，因此这个小样本不能确定每分钟工作的准确价格。

接着，我让智能体把应用改成带实时聊天的看板，并逐项进行修改。看着开发服务器更新，我可以注意到别扭的文案，并在它仍在工作时作出反馈。这与发送一个长请求、很久以后再回来查看的体验不同。

当推理快得多时，工具调用和构建会占据更大的总耗时比例。与十分钟生成时间相比，30 秒的工具步骤不算什么；在短得多的运行中，它却可能成为主要耗时。为了实时设计循环，我有时会让智能体少做额外的预览操作，以便更快看到代码变化。

我让它删除不必要的副标题和导航空间，修改约在 11 秒内出现。随后，它还在处理时，我又提出深色模式、聊天权限和工单权限的修改。能够在不中断状态的情况下引导多个小改动，是这个体验吸引我的地方。

完成几项修改后，我的 500 美元订阅显示剩余额度从 37% 降至 34%。我让另一个模型计算 token 价值：画面估算同一组记录的 token 数量按 Astra Ultrafast API 费率为 46.32 美元，按标准 Astra 费率为 7.72 美元。这些是等价费率估算，不是额外的 API 账单。

我估算，同一组 token 数量按普通 GPT-6.1 Sol 费率重新计价约为 1.10 美元，比 46.32 美元低 40 多倍。这是假设性重新计价，而不是另一次受控运行：换一个模型可能产生不同的 token 数量或结果。

这就是我担心把非常昂贵的模式设计成一个轻松开关的原因。人们很自然会把设置调到最高，有些人可能还没理解后果就消耗了订阅额度的一大部分。我认为这个价格不适合大多数日常工作。

不过，在一个例子里，速度确实改变了我做出的东西。我用 Astra Ultrafast 做了 Slopalytics，一个探索模型基准分数和成本的网站。在我的比较中，Opus 初稿大约用了 15～20 分钟，而快速 Astra 初稿约在一分半钟内出现。

在我看来，Opus 的初始设计更好看，但快速初稿让我能立刻指出问题并看到修改。等我回到 Opus 时，已经在 Astra 版本上反复迭代过。这只是我在一个项目中的体验，并不是受控的模型质量基准。

因为我一直关注线程，我发现它试图使用远程开发配置，尽管我就在那台机器上。我纠正它使用 localhost。大约两分钟内，我得到了包含数据和粗略界面的本地版本，然后开始修改图表方向和布局。

我要求使用实验室标志和统一颜色，接着又改变了排序想法并移除平均线。短反馈循环让我容易发现问题、发出小指令，并在忘记上下文之前检查结果。我在一个线程中发送的消息比平时多得多。

一个可视化问题是如何比较同一模型家族中的推理设置。在 Slopalytics 中，我按家族分组，并增加了隐藏 max 等级别的控件。这让我更容易看到比较高推理和最大推理时 token 用量如何变化。

我甚至在需要把食物从烤箱取出时，暂时切换到普通速度的 Sol：较慢的节奏让我更容易离开。切回 Ultrafast 后，我又回到了快速循环。这说明的是个人偏好，并非做好界面的客观必要条件。

我的提示词变得简短而频繁：修改排序、删除标题、调整分享 URL、增加比较线。有些回复在几十秒内完成。我可以针对眼前看到的结果作出反应，而不是试图在一个大提示词里预测每个细节。

比较面板正是在这种反复交流中出现的。我移动了它好几次，还尝试用延迟减少闪烁，结果不喜欢又撤销了。我也要求加入悬停时突出一条模型曲线的交互。这些都是我看到运行中的产品后作出的设计决定。

智能体提出的名字并不好，即使速度很快也是如此，所以我自己选了 Slopalytics。我在这个线程中发送了 50 多条消息。速度不会自动赋予模型良好品味；它让我的反馈和修正更容易融入结果。

在我的实测运行中，普通速度约为每秒 30 个输出 token，fast 模式约为 60，Ultrafast 为 320～340。这些是我自己的用量观察值；工具耗时、工作负载和供应商条件都可能改变端到端结果。

后来的核算发现，Slopalytics 工作中 Astra Ultrafast 的 token 按 API 费率估值为 544.75 美元。同一组 token 数量按标准 Astra 费率重新计价为 90.79 美元，按标准 Sol 费率为 12.03 美元。其他模型可能不会使用相同数量的 token，也可能作出不同选择，因此这些反事实价格是估算，而不是重复运行的实测。

对大多数人来说，多花几百美元节省时间可能不值得。我自己的反面理由是，没有即时反馈，我可能根本不会做这个网站：等待时我会丢失上下文，而快速循环帮助我完善界面。这是个人价值判断，并不能证明额外费用一定物有所值。

未来的 Sol Ultrafast 如果能提供类似的速度提升且价格可接受，可能改变这笔账。我讨论了假设的六倍价格系数和公开预告，但录制视频时，实际未来价格、速度和基础设施并没有通过本次实验确定。

我已经在一些系统管理工作中使用 Sol fast，因为它对我的需求而言兼顾速度和能力。至于 Astra Ultrafast，我能想到的可能用途只有异常紧急的情况，或额度即将重置前使用剩余额度。即便是事故响应，也需要实际评估速度是否值得这笔成本。

我有特殊的重置机会，因此会在重置临近时使用这个模式，同时接受账户可能一直为空直到重置到来。这种时机只适用于我的账户，并不能保证每个人都会得到重置或能预测重置时间。

我当时的建议是，不要仅仅为了 Ultrafast 升级到 500 美元档位。体验令人兴奋，但成本和额度消耗太高，我无法广泛推荐。未来更便宜的加速模式可能改变答案，但这里还没有展示出这样的模式。