8 月 23 日，奥特曼在播客中亲口承认：Sora 是个好产品，但它实在太吃 compute，同一时期 Codex 优先级更高，于是算力和团队投入开始向 Codex 倾斜。诡异的是，Codex 同样烧 GPU。真正把两者分开的，是算力被锁死还是被拆开。
8 月 23 日，奥特曼在 David Senra 的播客中罕见地谈起了 OpenAI 的内部取舍。他没有回避：Sora 本身是个好产品，继续做下去也能成为一门不错的生意，但它实在太吃 compute——同一时期，Codex 的优先级更高，于是算力和团队投入开始向 Codex 倾斜。
但有趣的是，Codex 其实也一点都不省 GPU。
一段视频 = 巨大的时空 latent 经过多轮 Transformer 计算。任务期间，GPU 被连续独占，无法服务其他请求。
一句话 = 多轮推理 + 读代码 + 调工具 + 跑测试。算力碎片化，阶段之间可以让出 GPU 给别的任务。
对比的是两种任务的算力占用形态：左侧「独占一段连续时间」，右侧「在多个阶段间交错占用」。
一个把算力压在单次视频生成里，另一个把算力摊进一条可能持续几十分钟甚至更久的 Agent 工作流里。
所以，Sora 并非输在算力消耗的绝对值上，而是输在了工作负载架构上：Sora 的算力是连续且独占的，Codex 的算力是碎片且可复用的。正是这种调度机制的差异，拉开了两者的扩张速度。
视频从进入模型那一刻起，成本就开始膨胀。Sora 先把原始视频压缩到 latent space，再切成 spacetime patches，让 Transformer 在这些 patch 上计算。文本 token 主要沿序列方向增长，视频 patch 同时铺在时间、高度和宽度上——视频在模型内部天然是一块有体积的状态。
Nvideo ≈ T × H × W
Cvideo ≈ D × Ctransformer(Nvideo)
T=时间方向 patch 数，H/W=空间 patch 数，D=采样迭代轮数。视频长度与画面尺寸是乘法关系，会共同撑大 latent 网格，而非独立线性增长。
这块网格进入 Transformer 后，还要面对 diffusion 带来的第二层计算。Sora 从带噪声的 latent 开始，每轮根据当前状态更新视频表示，再把新的 latent 送进下一轮。视频 latent 越大，每一轮越重；采样轮数增加，同一条视频就要多跑几轮网络。
这里藏着视频 diffusion 和 LLM 的关键差异。语言模型生成后续 token 时，前面的 Key 和 Value 可以保存在 KV cache 里，不需要在每一步重新构造整段历史。而视频 diffusion 每完成一轮更新，主体 latent 已经发生变化，下一轮面对的是一块新的时空状态——大量计算必须继续执行。
所以 Sora 的成本很难靠「复用历史」来大幅摊薄。
也正因为单个任务足够重，Sora 的 GPU utilization 反而可能很好看：大尺寸矩阵计算可以让 Tensor Core 长时间保持繁忙。
可利用率高只说明芯片一直在工作，并不代表单位时间交付了很多任务。一条视频连续占住一组 GPU 很久，utilization 再漂亮，单条请求消耗的GPU-seconds 依然很高。时长、分辨率和纵横比差异还会形成不同 tensor shape，batch 要么凑不厚，要么排队等——调度器能改的主要是「这些重任务怎么排」，很难改变「一条视频本身就需要大量连续计算」这个事实。
用户给 Codex 一句「修掉这个 bug」，任务不会以一次模型调用结束。
一条 Codex 任务更接近很多轮 Prefill + Decode + Tool 的累加。关键在于，每完成一轮工具调用，下一轮模型看到的上下文往往比上一轮更厚。用户最后看到的也许只是几百字完成说明，GPU 中间处理过的内容却可能已经非常庞大。
如果每一轮都重新处理全部历史，长任务会很快被重复 prefill 拖住——所以 prompt caching 成了关键。假设一个 Agent 已经拥有 100K token 上下文，工具执行后只新增 3K token 日志：
灰色条=需要重新计算的量，蓝色条=命中缓存后的新增计算量。缓存命中可把本轮算力需求压缩一个数量级。
这里出现了一个重要变化：逻辑 token 数已经不能直接代表实际 GPU 成本。两个请求都显示 100K input tokens，一个大部分已缓存，另一个需要重新计算，对 GPU 的压力完全不同。Agent 的负载取决于上下文增长速度、cache hit，以及一个任务反复进入模型多少次。
进入单次 inference 后，prefill 和 decode 又有不同的硬件需求：prefill 一次处理大量输入 token，是典型的 compute-heavy；decode 每条 sequence 每轮只生成少量 token，却要反复访问模型权重和 KV cache，更依赖 HBM bandwidth 和并发规模。
现在进入调度层。假设系统里同时存在 200 条 Agent sequence：一部分正在 decode，一部分等待工具，还有几十条刚从工具环境回来。Scheduler 面对的约束不只包括 FLOPs，还包括 HBM 容量、memory bandwidth、KV cache residency 和延迟预算。
Continuous batching 先解决 decode 的利用率问题。传统静态 batch 让一组请求绑在一起，短 sequence 结束后，长请求还占着 batch；continuous batching 在 token iteration 层面动态换人——一条完成就移出，新请求马上补进来。Batch 越厚，模型权重访问和内存带宽的成本越容易被摊薄。
但很快会碰到显存墙。大量长 Agent 的 KV cache 持续占用 HBM，Tensor Core 还没跑满，显存已塞不进更多 sequence。PagedAttention 通过分页式管理降低显存碎片——本质上是在增加一张 GPU 能同时容纳的活跃 sequence 数量。
prefill 和 decode 之间还存在冲突：几十条 sequence 正在稳定 decode，一个 Agent 带着 100K token 新上下文回来要做大 prefill，旁边请求的 TPOT 就会明显变差。Chunked prefill 把长输入切块交错执行，更进一步是把两者拆到不同 GPU pool——它们本就偏向不同硬件瓶颈。
于是，GPU utilization 到这里已经不够用了。
容量团队还需同时盯 GPU-seconds per task、queueing latency、KV cache occupancy 等指标，它们共同回答一个终极问题：一小时 GPU 到底能卖多少次服务。
Codex 的可调度性就体现在这里。Stable prefix 减少重复 prefill，decode 可以 continuous batch，KV cache 可以分页和驱逐，Agent 等待工具时还能让出 GPU。它的 workload 很碎，但这些碎片可以被 scheduler 重新编排。
假设一个 Codex Agent 从接到任务到完成一共运行 60 分钟，其中只有一部分时间真的在做模型 prefill 和 decode，其余时间用于编译、测试、读写文件或者等待工具。Agent wall-clock 和 GPU compute 并非一比一。
一个诚实的注脚：下面的比例是示意，不是实测数据——但「Sora 的算力锁死在单条路径，Codex 的算力可以被阶段间让出」这个结构差异，是两家公司资源回报曲线分岔的根本原因。
读图方式：Sora 的墙钟时间几乎全程占用 GPU；Codex 的墙钟时间被拆成 GPU 计算与外部工具执行两段，比例随任务类型浮动。
系统里同时存在大量 Agent 时，它们不会在同一秒一起需要 GPU：有人正在 prefill，有人在 decode，有人在跑测试。只要 scheduler 能把阶段交错起来，有限 GPU 就可以维持远高于 GPU 数量的活跃工作流。
这直接改变新增 GPU 的含义。给 Codex 加一批 GPU，带来的不只是单任务更快，而是系统能同时维持更多 Agent——一位工程师可以并行启动多条改代码任务。Sora 的容量曲线更直接：新增 GPU 能增加视频吞吐，但一小时 GPU 和视频计算时间之间的关系很难拉开距离。
GPU 从单纯的生成设备，变成了整个 Agent 系统里的稀缺「思考资源」。
Sora 与 Codex 争的不是谁更烧钱，而是同一小时 GPU 能撑起多少有效工作。当 workload architecture 决定资源回报曲线，KV cache 怎么放、prefill 怎么切、batch 塞多厚，这些「底层细节」就从工程问题变成了 AI 产品扩张战略的胜负手。
完整对话出自 8 月 23 日 David Senra 播客，在任意播客平台搜索「Sam Altman」即可找到当期节目。关于 OpenAI 的资源取舍逻辑，这是最近距离的一手材料。