OpenAI于周四发布了GPT-5.3-Codex-Spark,这是其首个运行在Cerebras Systems餐盘大小AI加速器上的模型。该加速器搭载了世界上最快的片上内存技术。
这款轻量级模型旨在通过Cerebras的SRAM封装CS3加速器为OpenAI的Codex代码助手用户提供更具交互性的体验,生成响应速度超过每秒1000个Token。
上个月,OpenAI与Cerebras签署了100亿美元的合同,部署多达750兆瓦的定制AI芯片来服务Altman团队的最新一代GPT模型。
Cerebras的晶圆级架构采用了一种名为SRAM的超快片上内存,其速度比英伟达今年CES上发布的即将推出的Rubin GPU中的HBM4内存快约1000倍。
结合推理和应用管道的优化,OpenAI的最新模型能够在眨眼间生成答案。
由于Spark是专有模型,我们无法获得参数数量等详细信息,不像OpenAI去年8月在HuggingFace上发布gpt-oss时那样。我们知道的是,与那个模型一样,它是一个纯文本模型,拥有128,000个Token的上下文窗口。
模型的上下文窗口是指它能同时跟踪的Token(词汇、标点符号、数字等)数量,通常被称为模型的短期记忆。
虽然128K个Token听起来很多,但由于模型必须跟踪现有代码和新生成的代码,像Codex这样的代码助手可能很快就会用完。即使从空白开始,以每秒1000个Token的速度,大约两分钟就会超出上下文限制。
这可能是OpenAI表示Spark默认采用"轻量级"风格的原因,只进行最小的针对性编辑,除非特别要求,否则不会运行调试测试。
快速的模型如果不能编写有效代码就没有太大价值。据OpenAI称,Spark模型在Terminal-Bench 2.0测试中比GPT-5.1-Codex-Mini提供更高的准确性,同时比更智能的GPT-5.3-Codex模型快得多。
OpenAI可能正在寻求GPU之外的选择,但短期内肯定不会放弃GPU。
OpenAI写道:"GPU在我们的训练和推理管道中仍然是基础,为广泛使用提供最具成本效益的Token。Cerebras通过在需要极低延迟的工作流程中表现出色来补充这一基础。"
这不仅仅是表面文章。尽管Cerebras的CS3加速器速度很快,但在内存容量方面无法与现代GPU匹敌。SRAM虽然快速,但空间效率不高。整个餐盘大小的芯片仅包含44GB内存。相比之下,英伟达的Rubin将配备288GB的HBM4,而AMD的MI455X将搭载432GB。
这使得GPU在运行大型模型时更经济,特别是在速度不是优先考虑因素的情况下。话虽如此,OpenAI建议随着Cerebras提供更多计算资源,它将把更大的模型引入该计算平台,这大概是为那些愿意为高速推理付费的用户准备的。
GPT-5.3-Codex-Spark目前向Codex Pro用户提供预览版,并通过API向特定的OpenAI合作伙伴开放。
Q&A
Q1:GPT-5.3-Codex-Spark有什么特别之处?
A:GPT-5.3-Codex-Spark是OpenAI首个运行在Cerebras Systems AI加速器上的模型,该加速器采用SRAM片上内存技术,速度比英伟达GPU中的HBM4内存快约1000倍。该模型专为代码助手设计,能以每秒超过1000个Token的速度生成响应,为用户提供更具交互性的编程体验。
Q2:为什么OpenAI选择与Cerebras合作而不是继续只用GPU?
A:OpenAI与Cerebras签署了100亿美元合同,主要是为了获得极低延迟的推理能力。虽然GPU在训练和推理管道中仍然是基础且更具成本效益,但Cerebras的SRAM技术在需要极速响应的工作流程中表现出色,两者形成互补关系而非替代关系。
Q3:GPT-5.3-Codex-Spark的上下文窗口有什么限制?
A:该模型拥有128,000个Token的上下文窗口,虽然看似很大,但由于需要跟踪现有代码和新生成的代码,在每秒1000个Token的生成速度下,大约两分钟就会达到上下文限制。因此模型默认采用"轻量级"风格,只进行最小的针对性编辑。
好文章,需要你的鼓励
今天讲的出海案例是开创电气,一家金华手持式电动工具制造商,在越南基地完成首款产品验收并形成80万台年产能力。
萨里大学与西蒙菲莎大学联合提出ABACUS模型,首次将物体计数、人群计数、指代计数与精准图像生成统一在单个30亿参数模型中,七项基准全面超越现有专业模型。
研究人员意外发现,标准MOSFET晶体管可同时模拟神经元和突触行为,形成"神经突触随机存取存储器"(NSRAM)。该技术仅需一至两个晶体管即可实现传统需数十乃至数百个元件才能完成的神经信号处理,且与现有硅基制造工艺完全兼容,良率达100%。未来有望应用于边缘AI及高能效神经形态芯片,长远或可挑战GPU地位。
Qwen团队揭示AI代码助手训练中"验证比生成更难"的核心困境,提出覆盖测试筛选、行为监控、用户反馈挖掘和代理评估四类验证方案,并以实验证明验证系统须持续与AI能力共同进化。