新智元报道 OpenAI史上最快的模型，死了。 刚刚，Codex负责人Tibo发帖， GPT-5.3-Codex-Spark，下周退役。 每秒1200个Token、OpenAI第一个逃离英伟达的模型、750兆瓦Cerebras大单的头一份交付，从发布到下线，只活了7个月。 Tibo给的理由很简单，用量一直在往下掉，手上也已经有明显更好的模型了。「是时候给未来腾地方了。」 然后，他又在底下补了一刀，「真不敢相信，我们居然发布过名字这么长的模型！！」 告别式上，大家只关心「备用额度」 Spark走得很安静，甚至显得有些尴尬。 Hugging Face的Vaibhav Srivastav试图在评论区留下一点温情。 感谢服役，你很特别，希望你为自己是第一个「最快的小子」而骄傲。下周退役前，发条prompt吧，感受一下我们从那时到现在走了多远。 紧随其后的热评，画风立刻变得犀利起来。 所以它到底是干嘛用的？前两天我还在跟同事讨论这个问题。 OpenAI要退役Codex-Spark了，那仅存的67个重度用户该伤心了。 更致命的评价来自开发者argofowl， 「Spark是个好玩的模型，也是个极度糟糕、根本没法用的模型。很高兴它走了，我好几个月没碰过了。」 还有开发者表示，几个规模不小的项目里，他几乎没用过Spark，连理解项目上下文、分析日志这种基础任务，都会迅速把上下文窗口塞满，逼着他另开一个对话。 事实上，真正对Spark退役感到一丝惋惜的，惋惜的也并非模型本身，而是它附带的 独立配额 。 知名开发者Chubby坦言想要一个「GPT-6-Spark」，因为Spark拥有一份不占主额度的独立套餐。 在Astra额度极其紧张的当下，很多开发者是把Spark当作主额度耗尽后的「备用油箱」来顶一阵子。 7个月前的「未来」，败给了「降智提速」 把时间拨回今年2月12日，Spark上线那天的排场可谓盛大。 这是OpenAI第一个专为实时编程设计的模型，128k上下文，每秒生成超过1000个Token。 按官方给的数字，客户端和服务器之间的往返开销降了80%，每个Token的处理开销降了30%，首Token延迟砍掉一半。 代码不再一行一行往外蹦，整块整块地倾泻在屏幕上。 最早一批上手的开发者，反应也是真的兴奋。 开发者Ryan Vogel直接把它编进了正式工作流，GPT-5.4负责规划，GPT-5.3-Codex负责构建，Spark负责探索代码库、查文档、给第二意见。 他说这是自己第一次工作流里一个Claude模型都没有，「效率更高，花得更少」。 Instructor作者Jason Liu，直接开20个Spark子代理去搜文件系统，宣布「RAG已死」。 然后，他就在不久之后加入了OpenAI的Codex团队。 更关键的是，Spark承载着OpenAI摆脱单一硬件依赖的野心。 它是OpenAI第一个跑在英伟达技术栈之外的生产模型，底层算力来自初创公司Cerebras的晶圆级芯片WSE-3。 它标志着OpenAI与Cerebras签下的那份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%之间。 相比之下，完整版GPT-5.3-Codex从3分钟起步就是51%，拉到9分钟是56%，16分钟能到57%。 也就是说，Spark省下的那几分钟，换来的是往下掉五六个点。 宣传中的「15倍提速」也被拆穿了。 发布第二天，开发者Nicholas Van Landschoot就在X上发了篇长文，把OpenAI的对比条件扒了一遍，所谓15倍，是拿Spark去比开了最高推理强度的GPT-5.3-Codex。 在同等准确率下，Spark其实只快了1.37倍。 在实际编码场景中，它的缺陷被无限放大，凭空捏造API端点，JSON格式不稳定，多步任务极易跑偏。 培训机构Turing College对它的总结一针见血， 「没有智能的速度，只是更快地失败。」 对于程序员而言，花17分钟等一个能跑通的代码，永远比花2分钟拿一个全是Bug的废品要划算。 于是，这款主打速度的模型，注定走向边缘化。 旗舰本尊下场，Ultrafast终结了Spark 而真正给Spark宣判死刑的，是8月13日Cerebras发布的Ultrafast模式。 这一次，跑在晶圆上的不再是缩水版的Spark，而