首页 / 资讯详情
Sora 为什么输给 Codex？
摘要
GPU 时间能否被复用，开始决定产品的扩张速度。 作者丨郑佳美 编辑丨岑 峰 8 月 23 日，奥特曼在 David Senra 的播客中谈到 OpenAI 内部的资源取舍时主动提到了 Sora。他说得很直接：Sora 本身是个好产品，继续做下去也能成为一门不错的生意，但它实在太吃 compute，同一时期，Codex 的优先级更高，于是算力和团队投入开始往 Codex 倾斜。但有趣的是，Codex 其实也一点都不省 GPU。Sora 生成一段视频，要让巨大的时空 latent 经过多轮 Transformer 计算；Codex 接到一句“把这个 bug 修掉”，后台则可能连续跑很多轮推理、读代码、调用工具、跑测试，再带着新的日志和上下文回来继续推理。一个把算力压在单次视频生成里，另一个则是把算力摊进一条可能持续几十分钟甚至更久的 Agent 工作流里。于是，Sora 和 Codex 真正拉开差距的地方开始落到机房内部。同样是一批 GPU，为什么视频生成的 compute 更难被摊开，而 Coding Agent 却能通过 KV cache、continuous batching、prefill / decode 调度和工具等待，把算力重新塞进更多并发任务里？事实上，Sora 并非输在算力消耗的绝对值上，而是输在了工作负载架构上：Sora 的算力是连续且独占的，而 Codex 的算力是碎片且可复用的。正是这种调度机制的差异，拉开了两者的扩张速度。沿着这条线往下看，会发现 Sora 输掉的那部分资源，背后或许是一场关于 GPU 时间应该怎么用的选择。01Sora 为什么难拆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 送进下一轮。雷峰网单条视频的计算量可以粗略理解成 C_video ≈ D × C_transformer(N_video)，其中 D 是采样迭代次数。视频 latent 越大，每一轮越重；采样轮数增加，同一条视频又要多跑几轮网络。这里能看出视频 diffusion 和 LLM 的关键差异。语言模型生成后续 token 时，前面的 Key 和 Value 可以保存在 KV cache 里，模型不需要在每一步重新构造整段历史状态。视频 diffusion 每完成一轮更新，主体 latent 已经发生变化，下一轮面对的是一块新的时空状态