Ultraman tiết lộ trong podcast lý do OpenAI ưu tiên tài nguyên cho Codex thay vì Sora. Việc tạo video của Sora yêu cầu lượng lớn năng lực tính toán liên tục, thời gian GPU dành cho mỗi nhiệm vụ khó có thể tái sử dụng; trong khi Codex thông qua các cơ chế như KV cache, continuous batching và gọi công cụ, phân tán năng lực tính toán thành nhiều giai đoạn có thể xen kẽ, giúp cùng một GPU hỗ trợ nhiều luồng công việc song song hơn. Khả năng tái sử dụng thời gian GPU bắt đầu quyết định tốc độ mở rộng của các sản phẩm AI.

Tác giả bài viết, nguồn: LeFeng.com

Tại sao Sora lại thua Codex?

Ngày 23 tháng 8, Otomo đã chủ động đề cập đến Sora khi nói về việc phân bổ nguồn lực bên trong OpenAI trên podcast của David Senra.

Anh ấy nói rất trực tiếp: Sora là một sản phẩm tốt, nếu tiếp tục phát triển cũng có thể trở thành một ngành kinh doanh khá tốt, nhưng nó tiêu tốn quá nhiều compute; trong cùng thời gian đó, Codex có mức độ ưu tiên cao hơn, nên nguồn lực tính toán và đội ngũ bắt đầu dồn sang Codex.

Nhưng điều thú vị là Codex thực ra cũng không tiết kiệm GPU chút nào. Sora tạo một đoạn video, cần cho latent không gian-thời gian khổng lồ trải qua nhiều vòng tính toán Transformer; còn Codex nhận một câu lệnh “sửa cái bug này”, phía sau cảnh có thể liên tục chạy nhiều vòng suy luận, đọc mã, gọi công cụ, chạy kiểm thử, rồi quay lại với nhật ký và ngữ cảnh mới để tiếp tục suy luận.

Một cái dồn toàn bộ sức mạnh tính toán vào một lần tạo video, còn cái kia phân tán sức mạnh tính toán vào một luồng công việc Agent có thể kéo dài vài chục phút hoặc lâu hơn. Vì vậy, điểm khác biệt thực sự giữa Sora và Codex bắt đầu xuất hiện bên trong trung tâm dữ liệu.

Cùng một bộ GPU, tại sao tính toán cho tạo video lại khó phân bổ hơn, trong khi Coding Agent lại có thể tái sử dụng hiệu suất tính toán vào nhiều tác vụ đồng thời hơn thông qua KV cache, continuous batching, lập lịch prefill/decode và chờ công cụ?

Thực tế, Sora không thua ở giá trị tiêu thụ sức mạnh tính toán tuyệt đối, mà thua ở kiến trúc tải công việc: sức mạnh tính toán của Sora là liên tục và độc quyền, trong khi sức mạnh tính toán của Codex là mảnh vỡ và có thể tái sử dụng. Chính sự khác biệt trong cơ chế lập lịch này đã tạo ra sự chênh lệch về tốc độ mở rộng giữa hai bên.

Dọc theo đường này, bạn sẽ thấy phần tài nguyên mà Sora đã thua có thể là kết quả của một lựa chọn về cách sử dụng thời gian GPU.

Chi phí của Sora có thể đã bắt đầu tăng từ khi video được đưa vào mô hình. Nó sẽ nén video gốc xuống không gian latent trước, sau đó chia thành các spacetime patches để Transformer tính toán trên các patch này.

Các token văn bản chủ yếu tăng dọc theo hướng chuỗi, trong khi các patch video được trải đều theo thời gian, chiều cao và chiều rộng, do đó video trong mô hình tự nhiên trở thành một trạng thái có thể tích.

Looking roughly, the number of visual tokens can be understood as N_video ≈ T × H × W, where T, H and W have already been compressed and patched, but the three-dimensional multiplication relationship still exists.

Kéo dài thời gian video sẽ tăng các patch theo hướng thời gian, trong khi tăng kích thước hình ảnh sẽ mở rộng các patch không gian. Nói cách khác, độ dài video và kích thước không gian không tăng chi phí một cách độc lập; chúng cùng nhau làm giãn rộng lưới latent.

Sau khi khối lưới đi vào Transformer, nó còn phải đối mặt với lớp tính toán thứ hai do diffusion mang lại. Sora bắt đầu từ latent mang nhiễu, mỗi vòng lặp đều cập nhật biểu diễn video dựa trên trạng thái hiện tại, sau đó gửi latent mới vào vòng lặp tiếp theo.

Khối lượng tính toán cho một video có thể được hiểu sơ bộ là C_video ≈ D × C_transformer(N_video), trong đó D là số lần lặp lấy mẫu. Latent của video càng lớn, mỗi vòng càng nặng; tăng số vòng lấy mẫu, cùng một video sẽ phải chạy thêm vài vòng mạng.

Ở đây có thể thấy sự khác biệt then chốt giữa video diffusion và LLM. Khi mô hình ngôn ngữ tạo ra token tiếp theo, các Key và Value trước đó có thể được lưu trong KV cache, giúp mô hình không cần tái tạo toàn bộ trạng thái lịch sử ở mỗi bước.

Mỗi khi video diffusion hoàn thành một vòng cập nhật, latent chính đã thay đổi, vòng tiếp theo sẽ đối mặt với một trạng thái không-thời gian mới, do đó vẫn cần tiếp tục thực hiện nhiều phép tính cho đối tượng video.

Do đó, chi phí của Sora rất khó để giảm đáng kể thông qua việc “tái sử dụng lịch sử”. Nó giống như một cảnh quay hiệu ứng hình ảnh đang trải qua nhiều vòng xử lý, mỗi vòng đều phải xử lý toàn bộ khung hình đã thay đổi. Video càng dài, độ phân giải càng cao và số mẫu càng nhiều, thì con đường sinh xuất này càng trở nên nặng nề.

Chính vì mỗi nhiệm vụ đủ nặng, việc sử dụng GPU của Sora ngược lại có thể rất tốt. Các phép tính ma trận kích thước lớn giúp Tensor Core duy trì trạng thái bận rộn trong thời gian dài, biểu đồ giám sát cho thấy GPU gần như không bao giờ nhàn rỗi.

Tỷ lệ sử dụng cao chỉ cho thấy chip đang liên tục hoạt động, không có nghĩa là trong mỗi đơn vị thời gian đã xử lý nhiều nhiệm vụ. Nếu một video chiếm giữ một nhóm GPU trong thời gian dài, thì dù tỷ lệ sử dụng có đẹp đến đâu, số GPU-seconds tiêu tốn cho mỗi yêu cầu vẫn rất cao.

Video serving vẫn sẽ bị kẹt do sự khác biệt về shape. Thời lượng, độ phân giải và tỷ lệ khung hình khác nhau sẽ tạo ra các tensor shape khác nhau. Để tăng hiệu quả batch, máy chủ cần gom các yêu cầu có kích thước tương tự vào cùng một bucket. Chờ thêm một chút có thể tạo ra batch dày hơn, nhưng sẽ làm tăng độ trễ xếp hàng; thực thi ngay lập tức có thể giảm thời gian chờ, nhưng batch có thể không đầy.

Do đó, phần lớn chi phí tính toán của Sora đã bị khóa trong chính đường dẫn tạo ra một đoạn video. Số vòng lấy mẫu có thể giảm, latent có thể tiếp tục nén, mô hình có thể được tinh luyện, kernel cũng có thể được tối ưu hóa thêm, nhưng điều mà scheduler có thể thay đổi chủ yếu là “cách sắp xếp các tác vụ nặng này”, rất khó thay đổi thực tế rằng “một đoạn video bản thân đã cần rất nhiều phép tính liên tục”.

Đây cũng là điểm khởi đầu để hiểu về Codex. Codex cũng đắt đỏ, nhưng nó không dồn toàn bộ chi phí vào một khối tính toán liên tục, mà chia nhiệm vụ thành nhiều giai đoạn có thể tạm dừng, khôi phục và kết hợp lại.

Người dùng đưa cho Codex một yêu cầu “sửa lỗi này”, nhiệm vụ sẽ không kết thúc sau một lần gọi mô hình. Agent có thể trước tiên đọc kho lưu trữ, để mô hình xác định bước tiếp theo, sau đó thực thi shell; sau khi nhận được lỗi, thêm nhật ký vào ngữ cảnh và gọi lại mô hình; sau đó sửa mã, chạy kiểm thử, và tiếp tục suy luận dựa trên kết quả mới.

因此，一条 Codex 任务更接近于多轮 Prefill + Decode + Tool 的累加。关键在于，每完成一轮工具调用，下一轮模型所看到的上下文通常比上一轮更丰富。

Lúc bắt đầu nhiệm vụ, mô hình chỉ có yêu cầu của người dùng và một ít mã. Sau một thời gian chạy, nhiều tệp hơn, diff, đầu ra terminal, nhật ký kiểm tra và kết quả công cụ liên tục được đưa vào prompt.

Người dùng có thể chỉ thấy một phần hướng dẫn hoàn thành dài vài trăm từ, nhưng nội dung đã được xử lý qua GPU có thể đã trở nên cực kỳ khổng lồ. Áp lực tiêu tốn token của Agent ẩn chứa trong hành trình công việc không ngừng tăng trưởng này.

Nếu mỗi lần suy luận đều xử lý lại toàn bộ lịch sử, các tác vụ dài sẽ nhanh chóng bị chậm lại do prefill lặp lại, do đó bộ nhớ đệm prompt rất quan trọng đối với Codex.

Giả sử một Agent đã có 100K token ngữ cảnh, sau khi thực hiện công cụ chỉ thêm 3K token nhật ký; nếu phần tiền tố ổn định phía trước có thể khớp bộ nhớ đệm, thì tính toán bổ sung trong lần này chủ yếu tập trung vào phần sau; một khi phần đầu prompt thay đổi gây ra cache miss, hệ thống có thể phải đối mặt lại với một lần prefill rất nặng.

Có một thay đổi quan trọng ở đây: số lượng token logic đã không còn có thể đại diện trực tiếp cho chi phí GPU. Cả hai yêu cầu đều hiển thị 100K token đầu vào, nhưng một yêu cầu phần lớn nội dung đã được lưu vào bộ nhớ đệm, trong khi yêu cầu kia cần tính toán lại, khiến áp lực lên GPU của chúng hoàn toàn khác nhau. Tải của Agent do đó phụ thuộc vào tốc độ tăng ngữ cảnh, tỷ lệ hit cache và số lần một tác vụ được đưa lặp lại vào mô hình.

Sau khi bước vào inference đơn lẻ, prefill và decode lại có nhu cầu phần cứng khác nhau. Prefill xử lý nhiều token đầu vào cùng lúc, kích thước ma trận lớn, dễ tạo ra tải công việc nặng về tính toán; decode mỗi chuỗi mỗi vòng chỉ tạo ra một lượng nhỏ token, nhưng phải truy cập lặp lại trọng số mô hình và KV cache, do đó phụ thuộc nhiều hơn vào băng thông HBM và quy mô đồng thời.

Điều này có nghĩa là nếu chạy riêng lẻ một chuỗi, việc giải mã sẽ rất lãng phí. Trọng số mô hình vẫn giữ nguyên kích thước lớn, và để tạo ra một token, bạn vẫn phải thực hiện một lần tính toán tiến đầy đủ. Máy chủ chỉ có thể làm cho một lần truy cập trọng số đồng thời xử lý nhiều yêu cầu hơn bằng cách đưa nhiều chuỗi vào cùng một batched forward.

Và batch có thể tiếp tục tăng kích thước không, nhưng sẽ bị giới hạn bởi KV cache. Context của mỗi sequence càng dài, thì lượng HBM chiếm dụng càng nhiều. Sau khi số lượng Agent tăng lên, GPU có thể vẫn còn dư năng lực tính toán, nhưng bộ nhớ hiển thị đã không còn dung lượng để chứa thêm các trạng thái đang hoạt động.

Các thiết kế như PagedAttention quản lý KV cache theo cách phân trang, giảm phân mảnh bộ nhớ GPU, về bản chất là tăng số lượng chuỗi hoạt động mà một GPU có thể đồng thời chứa đựng.

Việc gọi công cụ lại tiếp tục chia nhỏ tải của Codex. Khi Agent chạy kiểm thử, biên dịch mã hoặc chờ I/O, GPU không cần tiếp tục xử lý cho nó — CPU, container và hệ thống tệp sẽ tiếp nhận. Khi kết quả quay lại, Agent sẽ bước vào vòng suy luận tiếp theo.

Một Agent chạy trong 60 phút không có nghĩa là chiếm dụng GPU liên tục trong 60 phút. Thời gian nhiệm vụ của nó được chia thành hai phần: tính toán mô hình và thực thi bên ngoài, giúp scheduler có được một không gian mà Sora rất khó cung cấp: khi một Agent đang chạy công cụ, GPU có thể lập tức phục vụ các sequence khác.

Tất nhiên, điều này cũng sẽ tạo ra các vấn đề về bộ nhớ hiển thị. Agent chờ công cụ có nên giữ lại KV cache không? Giữ lại có thể phục hồi nhanh hơn nhưng sẽ chiếm dụng HBM lâu dài; loại bỏ có thể giải phóng không gian, nhưng khi nhiệm vụ quay lại sẽ phải chịu chi phí phục hồi. Số lượng Agent càng nhiều, sự đánh đổi này càng giống như hệ điều hành quản lý một lượng lớn tiến trình đang ngủ và thức dậy.

Tới đây, sự khác biệt giữa Codex và Sora không còn nằm ở “ai nặng hơn”, mà ở việc chi phí đã được tách rời chưa. Tính toán của Sora tập trung trên một đường dẫn sinh liên tục, trong khi tính toán của Codex được phân tán qua nhiều giai đoạn. Chính vì được tách rời, Codex mới có thể bước vào mức tối ưu tiếp theo: để scheduler quyết định cách các giai đoạn này chia sẻ cùng một bộ GPU.

Khi chạy trực tuyến các mô hình lớn, trọng số thường phải được lưu trữ lâu dài trên GPU, đồng thời duy trì trạng thái tensor parallel, giao tiếp giữa các nút và bộ nhớ đệm. Do đó, sự cạnh tranh tài nguyên giữa Sora và Codex thường xảy ra ở cấp độ fleet: một phần GPU được gán lâu dài vào pool phục vụ video, phần còn lại được gán lâu dài vào pool LLM, và hệ thống dung lượng cấp trên sẽ quyết định bên nào cần mở rộng hoặc thu hẹp.

Những điều phức tạp thật sự xảy ra bên trong Codex pool. Giả sử hệ thống đồng thời có 200 chuỗi Agent, một số đang giải mã, một số đang chờ công cụ, và hàng chục chuỗi vừa trở về từ môi trường công cụ, cần xử lý ngữ cảnh dài mới. Scheduler phải đối mặt với các ràng buộc không chỉ bao gồm FLOPs, mà còn gồm dung lượng HBM, băng thông bộ nhớ, độ lưu trú KV cache và ngân sách độ trễ.

Continuous batching trước tiên giải quyết vấn đề sử dụng của decode. Batch tĩnh truyền thống sẽ buộc một nhóm yêu cầu lại với nhau, sau khi các chuỗi ngắn kết thúc, các yêu cầu dài còn lại vẫn chiếm giữ batch.

Continuous batching sẽ thay thế người dùng ở cấp độ lặp lại token, một chuỗi hoàn thành sẽ được loại bỏ và yêu cầu mới sẽ ngay lập tức được bổ sung. Batch càng dày, một vòng tính toán mô hình có thể tiến hành càng nhiều chuỗi, chi phí truy cập trọng số mô hình và băng thông bộ nhớ càng dễ dàng được phân bổ.

Nhưng ở đây sớm sẽ chạm đến giới hạn bộ nhớ video. Bộ nhớ KV cache của nhiều Agent dài sẽ liên tục chiếm dụng HBM, một GPU có thể chưa chạy hết Tensor Core nhưng bộ nhớ video đã đầy không thể chứa thêm chuỗi nào nữa. Lúc này, việc tiếp tục tăng cường sức tính toán là vô nghĩa; yếu tố thực sự giới hạn khả năng xử lý đồng thời là dung lượng bộ nhớ đệm và quản lý bộ nhớ video.

Có một xung đột khác giữa prefill và decode. Giả sử hàng chục sequence đang được decode ổn định, lúc này một Agent quay lại với ngữ cảnh mới 100K token và cần thực hiện prefill lớn. Nếu prefill này chiếm một khoảng thời gian thực thi kéo dài, TPOT của các yêu cầu bên cạnh sẽ bị suy giảm rõ rệt.

Chunked prefill sẽ chia đầu vào dài thành nhiều đoạn nhỏ để thực hiện xen kẽ prefill và decode; cách tiếp cận nâng cao hơn là tách prefill và decode sang các pool GPU khác nhau.

Lý do là hai giai đoạn này vốn có các điểm nghẽn phần cứng khác nhau: prefill thiên về thông lượng tính toán, trong khi decode phụ thuộc nhiều hơn vào băng thông HBM, KV cache và độ trễ ổn định theo từng token. Khi tách riêng, chúng ta có thể cấu hình tài nguyên theo nhu cầu riêng của từng loại.

Điều này cho thấy cốt lõi của Agent serving đã vượt ra ngoài việc “viết nhanh hơn kernel mô hình”. Nhiều cải thiện về dung lượng đến từ việc sắp xếp lại thời điểm và nơi thực hiện nhiệm vụ, những trạng thái nào đáng để giữ trong bộ nhớ GPU, và nên đưa ai vào batch hiện tại.

Do đó, việc sử dụng GPU tại đây đã không còn đủ. Đội ngũ dung lượng cần đồng thời theo dõi GPU-seconds per task, TTFT (thời gian trễ đến từ đầu tiên, quyết định người dùng có cảm thấy giật lag hay không), TPOT (thời gian tạo mỗi từ, quyết định tốc độ “nói” của mô hình), queueing latency, prefix cache hit, KV cache occupancy và SLO goodput (thông lượng hiệu quả, đại diện cho sức mạnh tính toán thực sự có thể sinh lời).

Các chỉ số này cùng trả lời một câu hỏi: Trong độ trễ mà người dùng có thể chấp nhận, một giờ GPU có thể duy trì bao nhiêu nhiệm vụ hiệu quả.

Tính khả năng lập lịch của Codex thể hiện ở đây. Tiền tố ổn định có thể giảm bớt prefill lặp lại, decode có thể thực hiện batch liên tục, KV cache có thể được chia trang và xua đuổi, và khi Agent đang chờ công cụ, nó còn có thể nhường lại GPU. Tải công việc của nó rất nhỏ giọt, nhưng những mảnh vụn này có thể được bộ lập lịch sắp xếp lại.

Điều này cũng tự nhiên đẩy vấn đề lên tầng tài nguyên: nếu cùng một bộ GPU có thể luân phiên phục vụ nhiều Agent dài hạn hơn, thì thời gian làm việc thực tế mà một giờ GPU có thể hỗ trợ có thể cao hơn một giờ.

Giả sử một Codex Agent chạy tổng cộng 60 phút từ khi nhận nhiệm vụ đến khi hoàn thành, trong đó chỉ một phần thời gian thực sự được dùng cho prefill và decode của mô hình, phần còn lại dành cho biên dịch, kiểm thử, đọc ghi tệp hoặc chờ công cụ. Tỷ lệ cụ thể sẽ thay đổi tùy theo nhiệm vụ, nhưng cấu trúc này rất quan trọng: thời gian wall-clock của Agent và thời gian tính toán GPU không nhất thiết bằng nhau.

Nếu trong hệ thống có cùng lúc rất nhiều Agent, chúng sẽ không cùng cần GPU trong cùng một giây. Có người đang prefill, có người đang decode, có người đang chạy kiểm thử, và có người đang chờ hệ thống tệp. Chỉ cần scheduler có thể xen kẽ các giai đoạn này, số GPU hạn chế vẫn có thể duy trì số lượng luồng hoạt động cao hơn nhiều so với số lượng GPU.

Có thể hiểu sơ bộ mối quan hệ này như sau: Agent-hours phụ thuộc vào GPU-hours, tỷ lệ rảnh của mô hình suy luận và hiệu quả lập lịch. Thời gian thực thi công cụ càng nhiều, batch càng dày, tỷ lệ hit cache càng cao thì một giờ GPU càng có nhiều cơ hội hỗ trợ thời gian làm việc thực tế (wall-clock) dài hơn cho Agent.

Điều này sẽ trực tiếp thay đổi ý nghĩa của việc thêm GPU mới. Việc bổ sung một loạt GPU cho Codex không chỉ giúp từng tác vụ nhanh hơn, mà còn có thể cho phép hệ thống duy trì đồng thời nhiều Agent hơn. Một kỹ sư có thể khởi động song song nhiều tác vụ: một tác vụ sửa backend, một tác vụ bổ sung kiểm thử, một tác vụ xử lý kho lưu trữ khác — miễn là các tác vụ này không có phụ thuộc mạnh vào nhau, thời gian làm việc của máy có thể tăng song song.

Đường cong dung lượng của Sora trực tiếp hơn. Thời gian wall-clock dài của một video tự thân đang thúc đẩy diffusion trên GPU, khiến nhiệm vụ đơn lẻ và việc sử dụng GPU gắn kết chặt chẽ hơn. Việc thêm GPU có thể trực tiếp tăng thông lượng video, nhưng khoảng cách giữa thời gian GPU một giờ và thời gian tính toán video rất khó kéo dài đáng kể.

Một tác vụ phần mềm của Codex có thể di chuyển giữa GPU, CPU, container, hệ thống tệp và môi trường công cụ. GPU phụ trách suy luận mô hình, các hệ thống khác thực hiện các nhiệm vụ, nhiều Agent cùng chia sẻ khả năng suy luận thông qua scheduler. Do đó, GPU đã từ một thiết bị chỉ dùng để tạo ra, trở thành nguồn tài nguyên “suy nghĩ” khan hiếm trong toàn bộ hệ thống Agent.

Đó là lý do tại sao Codex, dù cũng có thể xử lý lượng compute lớn, lại dễ dàng获得更多 compute hơn. OpenAI không chỉ cần xem xét chi phí suy luận đơn lẻ, mà còn cần xem liệu năng lực mới có thể nhanh chóng chuyển hóa thành khối lượng công việc song song nhiều hơn hay không.

Khi một lô GPU có thể hỗ trợ nhiều Agent dài hạn hơn, đồng thời các Agent này có thể liên tục nhận các nhiệm vụ phần mềm mới, nguồn lực sẽ dễ dàng tiếp tục chảy theo hướng này.

Do đó, ý nghĩa kỹ thuật của câu nói đó từ Altman trở nên rõ ràng. Năng lực tính toán lớn của Sora bị khóa trong một đường dẫn sinh duy nhất, trong khi năng lực tính toán của Codex được chia thành nhiều giai đoạn có thể xen kẽ. Cả hai đều đắt đỏ như nhau, nhưng đường cong lợi nhuận tài nguyên thì khác nhau.

Giải thích về việc chuyển tài nguyên của Sora và Codex, sản phẩm AI bắt đầu có thêm một biến số trực tiếp ảnh hưởng đến tốc độ mở rộng: workload architecture.

Sử dụng GPU đắt tiền tương tự, một loại nhiệm vụ khóa lượng lớn năng lực tính toán vào một đường dẫn sinh duy nhất, trong khi loại nhiệm vụ khác có thể thông qua bộ nhớ đệm, gộp lô, thực hiện công cụ và lập lịch, xen kẽ cùng một lượng năng lực suy luận cho nhiều luồng công việc hơn, do đó đường cong tài nguyên của chúng tự nhiên sẽ tách biệt.

Vì vậy, trong tương lai, một số vấn đề có vẻ rất cơ bản sẽ ngày càng trở nên gần gũi với các vấn đề sản phẩm. KV cache nên đặt ở đâu, prefill nên chia như thế nào, decode batch có thể nén dày đến mức nào, các agent đang chờ công cụ có nên xóa bộ nhớ đệm hay không — những lựa chọn này cuối cùng sẽ quyết định một cụm GPU có thể duy trì đồng thời bao nhiêu nhiệm vụ.

Sora và Codex khác nhau không chỉ là sự khác biệt giữa video và mã nguồn.

Chúng đang cạnh tranh cùng một giờ GPU, rốt cuộc có thể đảm nhận được bao nhiêu công việc.