每秒1200个Token、OpenAI第一个跑在英伟达体系之外的模型、750兆瓦Cerebras大单的首批交付物——GPT-5.3-Codex-Spark，从发布到下架只撑了7个月。Codex负责人Tibo在社交平台发帖确认：下周退役。理由给得干脆，用量持续下滑，手头已有明显更强的替代品，「是时候给未来腾地方了」。
告别评论区里，没人在怀念模型本身
Hugging Face的Vaibhav Srivastav试图挽尊：感谢服役，你是第一个「最快的小子」，退役前发条prompt感受一下走了多远。
下面的热评立刻转向。有人问它到底干嘛用的，有人调侃仅存的67个重度用户该伤心了。工程师argofowl的评价最狠：好玩的模型，也是极度糟糕、根本没法用的模型，很高兴它走了，好几个月没碰过。
在几个体量不小的工程里，他几乎没用过Spark。连理解项目上下文、拆解任务这种基础操作，都会迅速把上下文窗口塞满。
真正让人惋惜的不是模型，是那份独立配额。工程师Chubby直言想要一个GPT-6-Spark，因为Spark有一份不占主额度的独立套餐。在Astra额度紧张的当下，不少人把它当主额度耗尽后的备用油箱。
2月12日的排场：整块倾泻的代码
回到发布当天。这是OpenAI第一个专为实时编程构建的模型，128k上下文，每秒产出超过1000个Token。官方数字显示，客户端与服务器之间的往返开销降低80%，单Token处理成本降低30%。代码不再逐行蹦出，而是整块倾泻在屏幕上。
早期用户的兴奋是真的。Ryan Vogel把它编进正式工作流，说这是第一次流程里一个Claude模型都没有，效率更高、花得更少。Instructor作者Jason Liu直接开20个Spark子代理搜文件系统，宣布RAG已死——不久后他加入了OpenAI的Codex团队。
更关键的是硬件意义。Spark是OpenAI第一个跑在英伟达栈之外的产物模型，底层算力来自Cerebras的晶圆级芯片WSE-3，对应那份750兆瓦、总额超200亿美元的算力大单，这是第一份答卷。
一块晶圆装不下旗舰，这是物理约束
Spark的致命伤从一开始就写死在架构里：它实质上是为极致速度妥协出来的蒸馏版小模型。
Terminal-Bench 2.0上，Spark准确率58.4%，完整版GPT-5.3-Codex是77.3%。OpenAI自己放出的SWE-Bench Pro曲线也说明问题：Spark能把任务时长压在1到2分钟，准确率停在47%到51%；完整版从3分钟起步就是51%，拉到9分钟到56%。省下的几分钟，换来五六个点的下滑。
宣传里的15倍提速也被拆穿。工程师Nicholas Van Landschoot发长文扒了对照条件，发布第二天就指出：同等准确率下，Spark只快1.37倍。
现实编码场景里它的缺陷被放大——凭空捏造API端点，JSON格式不稳定。Turing College的总结一针见血：没有智慧的速度，只是更快地失败。对程序员来说，花17分钟等一段能跑通的代码，永远比花2分钟拿一堆全是Bug的废品划算。
Ultrafast登场，把Spark的存在价值抽干了
给Spark判死刑的是8月13日Cerebras发布的Ultrafast模式。这次跑在晶圆上的不再是缩水版，而是旗舰模型GPT-5.6 Sol本尊。
Ultrafast在保证与基准版同等智慧的前提下，跑出每秒750个Token，铺设在多台CS-3机器上组成流水线。Cerebras给的对照是：比基准档快14倍，中间还有一档Priority。CEO Andrew Feldman的评价是「速度与智慧，不再互斥」。
他们用GDP-Val里6个质量对齐的任务做耗时对照：基准档Sol平均跑7.7分钟，其中7.5分钟花在模型输出上；换到Ultrafast，同样任务总共83秒，模型输出68秒。端到端快5.6倍，回答质量几乎没有差别。
Spark的构建初衷是拿智慧换速度。半年后同一家公司的晶圆上能跑完整旗舰，速度只慢四分之一。Cerebras产能有限，无人问津的压缩版和排队疯抢的旗舰版挤在同一批晶圆上，谁该腾地方不言而喻。
速度从专用模型变成付费档位
Spark不是唯一被清理的包袱。过去三个月OpenAI模型库经历了一轮激进换血：6月2日GPT-5.2与GPT-5.3-Codex退役；8月31日GPT-5.4与5.4 Mini退役，用户全局迁移至5.6世代；9月11日轮到GPT-5.3-Codex-Spark。
伴随旧世代离场，Codex进入Sol（太阳）、Terra（大地）、Luna（月亮）、Astra（星辰）的新命名纪元。「GPT-5.3-Codex-Spark」这种带冗长迭代号和产品线后缀的名字，确实像上一个纪元的遗迹。
更深的逻辑变化是：快，正从一个独立的专用模型，变成旗舰模型的一项标配档位。就像推理强度分Light到Max，速度也从Standard、Priority排到Ultrafast。速度与算力挂钩，按档付费的商业模型已经跑通。
工程视角：什么时候该用快模型，什么时候别碰
这里有个常被忽略的判断标准。低延迟小模型适合三类场景：交互式补全、单文件级别的局部改写、格式固定的结构化抽取。一旦任务需要跨文件推理、长链路工具调用、或者对输出格式有严格校验要求，压缩版模型的失败率会陡增。
验证方法很直接。拿同一批真实任务分别跑快模型和旗舰模型，比对三项指标：任务一次通过率、需要人工返工的比例、端到端完成时间（含返工）。很多团队只测了第三项，得出快模型更划算的结论，实际返工成本被完全漏算。
部署这类模型时常见的报错是上下文溢出。128k听起来够用，但工具调用返回的原始日志、diff、文件内容会迅速吃掉窗口。稳妥做法是在客户端做截断和摘要，而不是把整个仓库塞进去。
Spark做完了它的过渡使命：证明Cerebras晶圆能扛住生成式AI的产出级吞吐，也证明推理任务可以脱离英伟达体系运转。探路结束，大部队入驻，探路者退场。拿智慧换速度这条路，今天正式封死。下一轮竞赛比的不是谁能做出最快的阉割版，而是谁能把最强的旗舰模型跑出最极限的速度。
