Sora为何在算力效率上输给Codex：连续独占与碎片复用的架构差异
OpenAI内部资源倾斜显示，尽管Sora和Codex均消耗大量算力，但Codex因工作负载可被调度复用而具备更高的扩张速度。Sora的视频生成涉及连续的时空潜在状态计算，难以通过KV Cache等机制复用历史状态，导致算力呈连续独占特性。相比之下，Codex作为Agent工作流，其推理过程被工具调用打断，形成碎片化任务，允许Scheduler通过Continuous Batching、Prompt Caching等技术实现GPU时间的交错复用，从而显著提升单位算力的有效吞吐量。
事件概述
据OpenAI CEO Sam Altman在播客中透露，尽管Sora是一款优秀的产品，但由于其极高的算力消耗（Compute），OpenAI将团队资源和算力优先倾斜给了优先级更高的Codex项目。这一决策背后的核心逻辑并非单纯的绝对算力消耗对比，而是两种模型在工作负载架构上的根本差异：Sora的算力是连续且独占的，而Codex的算力是碎片且可复用的。这种调度机制的差异直接决定了两者的业务扩张速度。
Sora：连续独占的计算瓶颈
Sora的成本结构源于视频生成的本质。视频数据在进入模型前会被压缩并切分为时空补丁（Spacetime Patches），形成一个三维的潜在状态网格（Latent Space）。
- 计算不可复用：与语言模型不同，视频扩散模型（Video Diffusion）在每一轮迭代中，主体的潜在状态都会发生变化。这意味着下一轮计算无法像LLM那样利用KV Cache保留历史状态，必须重新处理整块变化的画面。因此，Sora很难通过“复用历史”来摊薄成本。
- 高利用率不等于高效率：虽然大尺寸矩阵计算能让Tensor Core保持高利用率（GPU Utilization），但这仅表明芯片忙碌，并不代表交付效率高。一条视频生成需要长时间独占一组GPU，单条请求消耗的GPU-seconds极高。
- 形状差异限制并发：视频时长、分辨率和纵横比的多样性导致Tensor Shape各异，服务端难以高效地进行Batching。为了凑齐足够的Batch以优化效率，往往需要增加排队延迟；若立即执行，则Batch填充不足，造成资源浪费。
简言之，Sora的大部分算力成本被锁定在单一视频的连续生成路径中，调度器只能调整重任务的排列顺序，无法改变其本身需要大量连续计算的事实。
Codex：碎片化任务与算力复用
Codex作为代码智能体（Coding Agent），其工作流程由多轮推理、工具调用（如读取代码、运行测试、查看日志）组成。这种结构使得算力消耗呈现碎片化特征，为调度优化提供了空间。
- 工具调用释放GPU：当Agent执行编译、测试或I/O操作时，GPU无需继续工作，CPU和文件系统接管任务。这使得一个长达60分钟的Agent任务，并不意味着连续占用60分钟GPU。Scheduler可以利用这段空闲时间服务其他序列。
- 显存管理的权衡：等待工具的Agent是否保留KV Cache是一个关键决策。保留Cache可加速恢复但占用HBM（高带宽内存）；驱逐Cache可腾出空间但带来恢复成本。这类似于操作系统管理休眠进程。
- Prompt Caching的重要性：随着Agent运行，上下文不断累积。如果稳定的前缀部分能命中缓存，新增计算主要集中在尾部；若发生Cache Miss，则需重新进行昂贵的Prefill操作。因此，实际GPU成本取决于上下文增长速度和缓存命中率，而非单纯的Token数量。
调度优化：从Kernel到系统级编排
Codex的高效性不仅来自算法，更来自对计算资源的重新组织。在Fleet层面，系统需同时平衡FLOPs、HBM容量、内存带宽和延迟预算。
- Continuous Batching：解决Decode阶段的利用率问题。传统静态Batch在短序列结束后仍占用资源，而Continuous Batching在Token迭代层面动态替换完成的序列，使新请求立即补位，摊薄权重访问和内存带宽成本。
- Chunked Prefill与资源隔离：长输入的Prefill阶段计算密集，可能阻塞正在Decode的请求。通过将Prefill和Decode拆分到不同的GPU Pool，或采用分块Prefill（Chunked Prefill）交错执行，可以分别针对计算吞吐（Prefill）和HBM带宽/低延迟（Decode）优化硬件配置。
- 多维指标评估：对于Agent Serving，单一的GPU利用率已失效。容量团队需综合监控GPU-seconds per task、TTFT（首字延迟）、TPOT（单字生成时间）、Queueing Latency、Prefix Cache Hit Rate、KV Cache Occupancy以及SLO Goodput（有效吞吐量）。
结论：算力吸收能力的差异
Codex的工作负载具有天然的并行潜力。由于Agent的Wall-clock Time（总耗时）远大于GPU Compute Time（实际计算耗时），且各Agent处于不同阶段（Prefill、Decode、Tool Execution），Scheduler可以将这些碎片化的需求交错安排。这使得有限数量的GPU能够维持远高于物理数量的活跃工作流。
因此，新增GPU对Codex的意义不仅是加速单个任务，更是提升系统的并发承载能力，支持工程师并行启动多个独立任务。相比之下，Sora的容量曲线更为线性，新增算力主要转化为单条视频生成的速度提升，而非并发量的指数级增长。这正是Codex在资源复用和扩张速度上优于Sora的根本原因。