Sora输给Codex不在算力绝对值，而在GPU时间能否被复用

8月23日，奥特曼在David Senra的播客里谈到OpenAI内部资源取舍时，主动提到了Sora。他的说法很直接：Sora本身是个好产品，继续做下去也能成为一门不错的生意，但它实在太吃compute，同一时期Codex的优先级更高，于是算力和团队投入开始往Codex倾斜。

但Codex其实也一点都不省GPU。Sora生成一段视频，要让巨大的时空latent经过多轮Transformer计算；Codex接到一句“把这个bug修掉”，后台则可能连续跑很多轮推理、读代码、调用工具、跑测试，再带着新的日志和上下文回来继续推理。一个把算力压在单次视频生成里，另一个则是把算力摊进一条可能持续几十分钟甚至更久的Agent工作流里。

工作负载架构决定扩张速度

同样是一批GPU，为什么视频生成的compute更难被摊开，而Coding Agent却能通过KV cache、continuous batching、prefill/decode调度和工具等待，把算力重新塞进更多并发任务里？Sora并非输在算力消耗的绝对值上，而是输在了工作负载架构上：Sora的算力是连续且独占的，而Codex的算力是碎片且可复用的。正是这种调度机制的差异，拉开了两者的扩张速度。

Sora的成本或许从视频进入模型时就已经开始膨胀了。它会先把原始视频压缩到latent space，再切成spacetime patches，让Transformer在这些patch上计算。文本token主要沿序列方向增长，视频patch同时铺在时间、高度和宽度上，因此视频在模型内部天然是一块有体积的状态。粗略来看，视觉token数可以理解成N_video ≈ T × H × W。这里的T、H和W已经过压缩和patch化，但三维乘法关系仍然存在。

视频时间拉长会增加时间方向上的patch，画面尺寸提高又会扩大空间patch。也就是说，视频长度和空间尺寸并不会彼此独立地增加成本，它们会一起把latent网格撑大。这块网格进入Transformer后，还要面对diffusion带来的第二层计算。Sora从带噪声的latent开始，每轮根据当前状态更新视频表示，再把新的latent送进下一轮。

视频diffusion难以复用历史状态

单条视频的计算量可以粗略理解成C_video ≈ D × C_transformer(N_video)，其中D是采样迭代次数。视频latent越大，每一轮越重；采样轮数增加，同一条视频又要多跑几轮网络。这里能看出视频diffusion和LLM的关键差异。语言模型生成后续token时，前面的Key和Value可以保存在KV cache里，模型不需要在每一步重新构造整段历史状态。视频diffusion每完成一轮更新，主体latent已经发生变化，下一轮面对的是一块新的时空状态，因此视频主体的大量计算仍然需要继续执行。

所以Sora的成本很难靠“复用历史”来大幅摊薄。它更像一段视效镜头在做多轮加工，每轮都要处理一整块已经变化的画面。视频越长、尺寸越高、采样越多，这条生成路径就越沉。也正因为单个任务足够重，Sora的GPU utilization反而可能很好看。大尺寸矩阵计算可以让Tensor Core长时间保持繁忙，监控图表里GPU几乎没闲着。

可利用率高只说明芯片一直在工作，并不代表单位时间交付了很多任务。一条视频如果连续占住一组GPU很久，那么utilization再漂亮，单条请求消耗的GPU-seconds依然很高。视频serving还会被shape差异继续卡住。时长、分辨率和纵横比不同，会形成不同tensor shape。服务端为了提高batch效率，需要把尺寸接近的请求放进相同bucket。多等一会儿可以凑出更厚的batch，却会增加排队延迟；立即执行可以缩短等待，batch又可能填不满。

因此，Sora的大部分算力成本已经锁在一条视频自己的生成路径里。采样轮数可以减少，latent可以继续压缩，模型可以蒸馏，kernel也可以继续优化，但scheduler能改动的主要是“这些重任务怎么排”，很难改变“一条视频本身就需要大量连续计算”这个事实。这也是理解Codex的入口。Codex同样昂贵，但它没有把全部成本压在一个连续计算块里，而是把任务拆成了许多可以暂停、恢复和重新组合的阶段。

Codex把任务拆成可暂停恢复的阶段

用户给Codex一句“修掉这个bug”，任务不会以一次模型调用结束。Agent可能先读取仓库，让模型判断下一步，再执行shell；拿到报错以后，把日志加入上下文，重新调用模型；随后修改代码、跑测试，再根据新的结果继续推理。所以一条Codex任务更接近很多轮Prefill + Decode + Tool的累加。关键在于，每完成一轮工具调用，下一轮模型看到的上下文往往比上一轮更厚。

任务刚开始时，模型可能只有用户要求和少量代码。运行一段时间以后，更多文件、diff、终端输出、测试日志和工具结果不断进入prompt。用户最后看到的也许只是几百字完成说明，GPU中间处理过的内容却可能已经非常庞大。Agent token consumption的压力，就藏在这条不断增长的工作轨迹里。

如果每一轮inference都重新处理全部历史，长任务会很快被重复prefill拖住，所以prompt caching对Codex很关键。假设一个Agent已经拥有100K token上下文，工具执行后只新增3K token日志，如果前面的稳定prefix能够命中缓存，本轮新增计算主要集中在后面这部分；一旦prompt前部变化导致cache miss，系统就可能重新面对一次很重的prefill。

这里出现了一个重要变化：逻辑token数已经不能直接代表实际GPU成本。两个请求都显示100K input tokens，其中一个大部分内容已经缓存，另一个需要重新计算，它们对GPU的压力完全不同。Agent的负载因此取决于上下文增长速度、cache hit，以及一个任务反复进入模型多少次。进入单次inference后，prefill和decode又有不同的硬件需求。Prefill一次处理很多输入token，矩阵尺寸较大，更容易形成compute-heavy workload；decode每条sequence每轮只处理少量token，但需要反复访问KV cache，更偏向memory-bound。

碎片化算力更容易被调度复用

Codex的算力之所以能被摊开，是因为Agent工作流天然存在大量等待点。模型调用工具后，要等shell返回结果；跑测试时，GPU可能暂时没有推理任务；用户思考下一步时，整个任务甚至完全暂停。这些间隙让调度器有机会把其他请求的prefill或decode塞进去。continuous batching可以在decode过程中动态插入新请求，而不是等整批任务全部结束。KV cache则让不同轮次之间共享已经计算过的前缀，避免重复prefill。

Sora的生成路径里没有这么多自然的等待点。一条视频从开始采样到输出结果，主体计算基本连续进行。即使调度器想插入其他任务，也很难在不打断当前视频生成的前提下找到合适的切分位置。视频diffusion每轮更新后的latent状态变化，又让跨轮复用历史计算变得困难。于是Sora的GPU时间更像被一条条长任务独占，而Codex的GPU时间则被拆成大量可调度的碎片。

这种差异最终反映在扩张速度上。Codex可以通过提高并发、复用缓存、填充等待间隙，把同一批GPU交付给更多任务。Sora则受限于单条视频的连续计算需求，即使优化kernel和压缩latent，也很难把算力从一条重任务里释放出来。奥特曼说Sora太吃compute，指的或许不只是单次生成成本高，更是这种成本难以通过调度机制摊薄。

GPU时间能否被复用，开始决定产品的扩张速度。Sora和Codex的差距，最终落在机房内部那些看似枯燥的调度细节里。