Binigkas ni Ultraman sa podcast kung bakit hinahatid ng OpenAI ang kanilang mga yaman sa Codex kaysa sa Sora. Ang pagbuo ng video ng Sora ay nangangailangan ng malaking patuloy na computing power, at ang oras ng GPU na ginagamit sa isang tanging gawain ay mahirap i-reuse; samantala, ang Codex ay gumagamit ng mga mekanismo tulad ng KV cache, continuous batching, at pagtawag sa mga kasangkapan upang i-distribute ang computing power sa maraming maaaring magkaka-ugnay na yugto, kaya makakapagbigay ang isang parehong GPU sa mas maraming parallel na workflow. Ang kakayahan sa pag-reuse ng oras ng GPU ay nagsisimula nang humuhula sa bilis ng pagpapalawak ng mga AI product.

May-akda ng artikulo, pinagkukunan: Leifeng.com

Bakit nasakop ni Codex si Sora?

Noong Agosto 23, sinabi ni Otman ang Sora nang mag-isip ng mga pagpipilian sa resource sa loob ng OpenAI sa podcast ni David Senra.

Sinabi niya nang direkta: Ang Sora ay isang magandang produkto, at kung ipagpapatuloy, maaari itong maging isang magandang negosyo, ngunit sobrang kumakain ito ng compute. Samantala, mas mataas ang prioridad ng Codex, kaya ang compute at ang pagkakasundo ng team ay nagsimulang umiikot patungo sa Codex.

Ngunit kasi, ang Codex ay hindi rin nag-iipon ng GPU. Upang makagawa ng isang video ang Sora, kailangan ng maraming pagkakataon ng Transformer computation para sa malaking时空 latent; habang ang Codex, kapag natanggap nito ang utos na “ayusin ang bug na ito,” maaaring magpapatakbo nang maraming beses sa background—basahin ang code, gamitin ang mga tool, i-run ang mga pagsubok, at bumalik na may bagong log at konteksto para magpatuloy sa pag-iisip.

Isang isa ay nagpapress ng computing power sa isang pagkakataon lamang ng video generation, habang ang isa pa ay nagpapalawig ng computing power sa isang Agent workflow na maaaring tumagal ng ilang minuto o higit pa. Kaya, ang totoong pagkakaiba sa pagitan ng Sora at Codex ay nagsisimula sa loob ng data center.

Sa parehong grupo ng GPU, bakit mas mahirap i-allocate ang compute para sa video generation, samantalang ang Coding Agent ay kayang muli nang i-imbak ang compute sa mas maraming concurent na task gamit ang KV cache, continuous batching, prefill/decode scheduling, at paghihintay sa mga tool?

Sa katotohanan, hindi nagwawala ang Sora dahil sa absolute na pagkakagamit ng computing power, kundi dahil sa arkitektura ng workload: ang computing power ng Sora ay tuloy-tuloy at eksklusibo, habang ang computing power ng Codex ay piraso-piraso at maaaring muli gamitin. Ito ang pagkakaiba sa mekanismo ng pagdudulot na nagpapalayo sa bilis ng paglago ng dalawa.

Sa pagtingin sa ibaba ng linya, maaaring makita ang pagkawala ng mga yunit sa Sora, na maaaring nagmumula sa isang pagpili kung paano gamitin ang GPU time.

Ang gastos ng Sora ay maaaring magsimula nang mag-umpisa ang video sa modelo. Una itong i-compress sa latent space, pagkatapos ay hihiwalayin sa spacetime patches, upang ang Transformer ay makapag-kalkula sa mga patch na ito.

Ang text token ay lumalago pangunahin sa direksyon ng sequence, habang ang video patch ay ipinapalabas nang sabay sa oras, taas, at lapad, kaya ang video ay natural na isang may volume na estado sa loob ng modelo.

Sa pangkalahatan, ang bilang ng visual tokens ay maaaring maunawaan bilang N_video ≈ T × H × W. Ang T, H at W ay naka-compress at naka-patch, ngunit ang relasyon ng tatlong dimensyon ay nananatili.

Ang pagpapalawig ng oras ng video ay magdadagdag ng patch sa direksyon ng oras, habang ang pagtaas ng sukat ng imahe ay magpapalawig ng spatial patch. Ibig sabihin, ang haba ng video at ang spatial dimension ay hindi tumataas nang hiwalay sa gastos; kasama nila ito ay magpapalawig ng latent grid.

Pagkatapos ng pagpasok ng grid sa Transformer, kailangan pa itong harapin ang pangalawang antas ng pagkalkula mula sa diffusion. Mula sa may ingay na latent, binabago ng Sora ang bawat round ang video representation batay sa kasalukuyang estado, at ipinapadala ang bagong latent sa susunod na round.

Ang computation ng isang video ay maaaring approximahin bilang C_video ≈ D × C_transformer(N_video), kung saan D ay ang bilang ng sampling iterations. Mas malaki ang video latent, mas mabigat ang bawat iteration; at kapag tumataas ang bilang ng sampling iterations, kailangan muli pang i-run ang network sa parehong video.

Dito makikita ang pangunahing pagkakaiba sa pagitan ng video diffusion at LLM. Habang nagpapagawa ang language model ng susunod na token, ang mga nakaraang Key at Value ay maaaring i-save sa KV cache, kaya hindi kailangan ng model na bumuo muli ng buong kasaysayan sa bawat hakbang.

Pagkatapos ng bawat pag-update sa video diffusion, ang pangunahing latent ay nagsasagawa ng pagbabago, kaya ang sumusunod na pag-update ay tatagpuan ang isang bagong espasyo-time state; kaya ang malaking bahagi ng kalkulasyon para sa pangunahing video ay patuloy na kailangang gawin.

Kaya mahirap malaki ang pagbaba ng gastos ng Sora sa pamamagitan ng “pag-uulit ng kasaysayan”. Mas katulad ito ng isang visual effect shot na pinaproseso sa maraming pagkakataon, kung saan bawat pagkakataon ay kailangang tratuhin ang buong nakabago na larawan. Mas mahaba ang video, mas mataas ang sukat, at mas marami ang sampling, mas mabigat ang generation path.

Dahil sa sapat na bigat ng bawat gawain, ang GPU utilization ng Sora ay maaaring maging maganda. Ang pagkalkula ng malalaking matrix ay nagpapakalusog sa Tensor Core nang matagal, at sa mga grap ng pagmamasid, halos walang pag-antay ang GPU.

Ang mataas na pagkakaroon ng availablity ay nagpapakita lamang na patuloy na gumagana ang chip, at hindi nangangahulugan na maraming gawain ang nadadalhan sa bawat yunit ng oras. Kung isang video ay nagpapakalat nang matagal sa isang grupo ng GPU, kahit gaano pa kasing magandang utilization, ang GPU-seconds na ginagamit sa bawat request ay patuloy na mataas.

Ang video serving ay patuloy na makakahadlang dahil sa mga pagkakaiba sa shape. Ang iba’t ibang haba, resolusyon, at aspect ratio ay magdadala ng iba’t ibang tensor shape. Upang mapabuti ang batch efficiency, ang server ay kailangang ilagay ang mga kahilingan na may magkakaparehong sukat sa parehong bucket. Ang paghintay nang ilang sandali ay maaaring magbigay ng mas malalim na batch, ngunit magdudulot ng mas mahabang delay sa pagsisigla; ang pagpapatakbo nang agad ay maaaring mapabawasan ang paghihintay, ngunit maaaring hindi makapag-umpisa ang buong batch.

Kaya ang karamihan sa gastos ng computing ng Sora ay nakalock na sa sariling path ng paggawa ng isang video. Maaaring bawasan ang bilang ng sampling rounds, maaari pang i-compress ang latent, maaaring i-distill ang model, at maaari pang i-optimize ang kernel, ngunit ang pangunahing bagay na maaaring baguhin ng scheduler ay “paano iskedyul ang mga importanteng gawain na ito,” at mahirap baguhin ang katotohanang “kailangan ng isang video mismo ng malaking halaga ng tuloy-tuloy na computing.”

Ito rin ang pinto patungo sa pag-unawa sa Codex. Ang Codex ay magkakaroon din ng mataas na gastos, ngunit hindi ito isinasaalang-alang ang buong gastos sa isang tuloy-tuloy na bloke ng kalkulasyon, kundi hinati nito ang task sa maraming mga yugto na maaaring ipaupahan, muling i-activate, at muli ay isama.

Binigyan ng user ang Codex ng isang pahayag na “ayusin ang bug na ito”, at hindi tatapos ang gawain sa isang pagtawag sa model. Maaaring unang basahin ng Agent ang repository, hilingin sa model na matukoy ang susunod na hakbang, at pagkatapos ay i-execute ang shell; pagkatapos makakuha ng error, idadagdag ang log sa konteksto at i-reinvoke ang model; susunod ay i-edit ang code, i-run ang test, at patuloy na mag-isip batay sa bagong resulta.

Kaya mas malapit sa maraming round ang isang Codex taskPrefill + Decode + Tool, ang pagkumpul-kumpol. Ang susi ay, bawat pagkumpleto ng isang tool call, ang konteksto na nakikita ng modelo sa susunod na round ay kadalasang mas malaki kaysa sa nakaraang round.

Kapag nagsisimula ang gawain, ang modelo ay maaaring mayroon lamang hiling ng user at kaunting code. Pagkatapos mag-run ng ilang panahon, patuloy na pumapasok sa prompt ang mas maraming mga file, diff, terminal output, test logs, at mga resulta ng mga tool.

Ang huling nakikita ng user ay maaaring isang maikling paliwanag na may ilang sandaling mga salita, ngunit ang nilalaman na pinroseso ng GPU ay maaaring napakalaki na. Ang presyur sa pagkonsumo ng Agent token ay nakatago sa patuloy na lumalaking track ng trabaho.

Kung ang bawat round ng inference ay muling proseso ang buong kasaysayan, ang mga mahabang gawain ay mabilis na haharapin ang pag-uulit ng prefill, kaya mahalaga ang prompt caching para sa Codex.

Kung mayroon nang isang Agent na 100K token ng konteksto, at ang pagpapatupad ng kasangkapan ay nagdagdag ng 3K token lamang ng log, kung ang nakaraang matatag na prefix ay makakasali sa cache, ang pangunahing karagdagang kalkulasyon sa round na ito ay nakatuon sa bahaging ito; kapag nagkakaroon ng cache miss dahil sa pagbabago sa unang bahagi ng prompt, maaaring muling mabuhay ng isang malaking prefill.

Mayroong mahalagang pagbabago dito: ang bilang ng mga logical token ay hindi na direktang nagpapakita ng tunay na gastos sa GPU. Parehong nagpapakita ng 100K input tokens ang dalawang hiling, ngunit ang isa ay karamihan sa nilalaman ay naka-cache, habang ang isa pa ay kailangang muling kalkulahin, at iba-iba ang kanilang presyon sa GPU. Ang load ng Agent ay nakadepende sa bilis ng paglago ng konteksto, cache hit, at kung gaano kadalas muling pumasok ang isang task sa modelo.

Pagkatapos makapasok sa single inference, iba-iba ang mga pangangailangan sa hardware para sa prefill at decode. Ang prefill ay nagtratrabaho sa maraming input token nang isang beses, kaya mas malaki ang matrix dimensions at mas madaling mabuo ang compute-heavy workload; samantalang ang decode ay nagpapalabas ng kaunting token bawat sequence bawat round, ngunit kailangan itong ulitin ang pag-access sa model weights at KV cache, kaya mas nakadepende ito sa HBM bandwidth at concurrency scale.

Ibig sabihin nito na ang decode ay sobrang hindi efisiente kung isasagawa nang hiwalay sa isang sequence. Ang mga timbang ng modelo ay nananatiling malaki, at kahit para lang mag-generate ng isang token, kailangan ng isang buong forward pass. Upang makapagbigay ng mas maraming kahilingan sa isang pag-access sa timbang, kailangan ng server na ilagay ang maraming sequence sa iisang batched forward.

Ang batch ay maaaring palakasin pa, ngunit limitado ng KV cache. Mas mahaba ang konteksto ng bawat sequence, mas marami ang HBM na ginagamit. Pagkatapos magdagdag ng bilang ng mga agent, maaari pa ring mayroong kalabisang compute sa GPU, ngunit ang VRAM ay nasa maximum na kakayahan na upang itago ang mas maraming aktibong estado.

Ang mga disenyo tulad ng PagedAttention ay gumagamit ng pagpapagkakasunod-sunod ng KV cache upang bawasan ang fragmentasyon ng VRAM, at sa本质上 ay nagpapataas ng bilang ng aktibong sequence na maaaring isama ng isang GPU nang sabay-sabay.

Ang paggamit ng mga tool ay nagpapabawas pa ng load ng Codex. Habang ang Agent ay nagpapatakbo ng mga pagsubok, nag-compile ng code, o naghihintay sa I/O, hindi na kailangan ng GPU na magtrabaho para sa kanya—ang CPU, container, at file system ang magpapatuloy. Kapag bumalik ang resulta, babalik ang Agent sa susunod na pagkakataon ng inference.

Kaya ang isang Agent na tumatagal ng 60 minuto ay hindi nangangahulugan na ito ay nagpapakita ng 60 minuto ng GPU nang tuloy-tuloy. Ang oras ng task nito ay nahati sa dalawang bahagi: ang pagkalkula ng model at ang panlabas na pagsasagawa, na nagbibigay sa scheduler ng isang espasyo na mahirap ibigay ng Sora: kapag ang isang Agent ay nagpapatakbo ng tool, agad na maaaring gamitin ng GPU ang ibang sequence.

Oo, ito ay magdudulot din ng mga bagong problema sa VRAM. Dapat ba pangalagaan ng Agent na naghihintay ang KV cache? Ang pagpapanatili nito ay mabilis na muling iuugnay, ngunit magpapalala sa HBM sa mahabang panahon; ang pag-alis nito ay maglalabas ng espasyo, ngunit kapag bumabalik ang gawain, kailangan nito ang gastos sa pagbabalik. Mas maraming Agent, mas parang operasyon ng sistema na nagmamaneho ng maraming proseso na nagpapahinga at nagkukumpleto.

Dito, ang pagkakaiba ng Codex at Sora ay hindi na sa “sino ang mas mabigat”, kundi kung ang gastos ay na-disaggregate na. Ang compute ng Sora ay nakatuon sa isang tuloy-tuloy na pag-generate na path, habang ang compute ng Codex ay nakalat sa maraming mga yugto. Dahil sa pagkakahati, maaari na ang Codex na pumasok sa susunod na antas ng pag-optimize: pagpapasya ng scheduler kung paano magbabahagi ang mga yugto sa iisang grupo ng GPU.

Kapag nagpapatakbo ng malalaking modelo sa online, karaniwang nananatili ang weights sa GPU nang matagal, at kailangan pa ring panatilihin ang tensor parallel, komunikasyon sa node, at estado ng cache. Kaya ang pagkakaroon ng kompetisyon sa mga yunit sa pagitan ng Sora at Codex ay mas madalas mangyari sa antas ng fleet: ang ilang GPU ay nananatili nang matagal sa video serving pool, habang ang iba ay nananatili nang matagal sa LLM pool, at ang mas mataas na sistema ng kapasidad ang magdedesisyon kung saan dapat i-expand o i-reduce.

Ang totoong kumplikadong bagay ay nangyayari sa loob ng Codex pool. Ipagpalagay na may 200 Agent sequence sa sistema, kung saan ang ilan ay nasa pag-decode, ang ilan ay naghihintay ng mga kasangkapan, at mayroon pang ilang dosenang nanggaling mula sa mga environment ng kasangkapan at kailangan pang prosesuhin ang mga bagong mahabang konteksto. Ang mga limitasyon na kinakaharap ng Scheduler ay hindi lamang kasama ang FLOPs, kundi pati na rin ang HBM capacity, memory bandwidth, KV cache residency, at delay budget.

Ang continuous batching ay unang lutasin ang problemang paggamit ng decode. Ang tradisyonal na static batch ay nagpapakita ng isang grupo ng mga kahilingan na nakabukod, at kapag natapos ang mga maikling sequence, ang mga natitirang mahabang kahilingan ay patuloy na nagpapakita ng batch.

Ang continuous batching ay magpapalit ng mga tao sa antas ng token iteration, at agad na aalisin ang isang sequence pagkatapos ito ay matapos, at agad na isasama ang bagong kahilingan. Mas malaki ang batch, mas maraming sequence ang maaaring palakasin sa isang round ng model computation, at mas madaling ma-distribute ang gastos sa pag-access sa model weights at memory bandwidth.

Ngunit malapit nang makarating sa memory wall. Ang malaking dami ng KV cache ng mga mahabang Agent ay magpapatuloy na mag-aabot ng HBM, at baka paano pa lang hindi pa nagpapatakbo ng buong Tensor Core ng isang GPU, ay nakaubos na ang memory para sa karagdagang sequence. Sa puntong ito, ang pagdaragdag ng computing power ay walang kwenta; ang tunay na limitasyon sa concurrency ay ang cache capacity at memory management.

Mayroon pang iba pang konflikto sa pagitan ng prefill at decode. Ipagpalagay na ilang dosenang sequence ay nagde-decode nang matatag, nang biglang bumalik ang isang Agent na may bagong konteksto na 100K token at kailangan ng malaking prefill. Kung ang prefill na ito ay magpapakita ng matagal na execution window, masasira ang TPOT ng mga kasamang hiling.

Ang chunked prefill ay maghahati ng mahabang input sa mga maliit na bahagi upang ang prefill at decode ay maaaring magkasama-samang mag-run; ang mas malalim na pagkakagawa ay ang paghihiwalay ng prefill at decode sa iba’t ibang GPU pool.

Dahil sa katotohanan na ang dalawang yugto ay may sariling pagkakaiba sa mga bottleneck ng hardware: ang prefill ay mas nakadepende sa compute throughput, habang ang decode ay mas nakasalalay sa HBM bandwidth, KV cache, at matatag na latency bawat token. Kapag hihiwalayin sila, maaaring i-configure ang mga yugto ayon sa kanilang sariling pangangailangan.

Ito ay nagpapakita na ang core ng Agent serving ay lumampas na sa "paggawa ng mas mabilis ang model kernel". Maraming pagtaas sa kapasidad ang galing sa pagbabago kung kailan at saan tatanggalin ang mga gawain, alin sa mga estado ang dapat i-retain sa VRAM, at sino ang dapat isama sa kasalukuyang batch.

Kaya ang GPU utilization ay hindi na sapat dito. Kailangan ng capacity team na tingnan ang GPU-seconds per task, TTFT (first token latency, na nagdedesisyon kung gaano kakahina ang user experience), TPOT (time per output token, na nagdedesisyon kung gaano kalakas ang “pagsasalita” ng model), queueing latency, prefix cache hit, KV cache occupancy, at SLO goodput (effective throughput, na nagpapakita ng tunay na computing power na nakakakuha ng kita).

Ang mga indikator na ito ay kasama ang sagot sa isang tanong: Ilan ang epektibong mga gawain na maaaring panatilihin ng isang oras na GPU sa ilalim ng latency na tatanggapin ng user.

Dito nakikita ang pagkakaroon ng schedule ng Codex. Ang stable prefix ay nakakabawas sa pag-uulit ng prefill, ang decode ay maaaring magkaroon ng continuous batch, ang KV cache ay maaaring magkaroon ng paging at eviction, at habang naghihintay ang Agent sa mga tool, maaari itong magbigay-luwag sa GPU. Ang kanyang workload ay maliit-maliit, ngunit ang mga maliit na ito ay maaaring muling ma-organisa ng scheduler.

Ito ay natural na nagdadala sa tanong sa antas ng yunit: kung ang parehong grupo ng GPU ay maaaring maglingkod sa mas maraming pangmatagalang Agent nang paikli-ikli, ang aktwal na oras ng trabaho na maaaring suportahan ng isang oras na GPU ay maaaring mas mataas kaysa sa isang oras.

Kung ang isang Codex Agent ay nagpapatakbo ng 60 minuto mula sa pagtanggap ng gawain hanggang sa pagkumpleto, ang ilang bahagi lamang ng oras ang ginagamit para sa model prefill at decode, habang ang natitirang oras ay ginagamit para sa compilation, pagsubok, pagbasa at pagsulat ng mga file, o paghihintay sa mga kasangkapan. Ang eksaktong proporsyon ay magkakaiba batay sa gawain, ngunit mahalaga ang istruktura: ang wall-clock time ng Agent at ang GPU compute time ay hindi isang-to-one.

Kung may maraming Agent sa sistema, hindi sila lahat kailangan ng GPU sa parehong segundo. Mayroong nagpaprefill, mayroong nagdecode, mayroong nagpapatakbo ng pagsubok, at mayroong naghihintay sa file system. Kung ang scheduler ay makakapag-交错 ng mga yugto na ito, ang limitadong GPU ay maaaring suportahan ang mas maraming aktibong workflow kaysa sa bilang ng GPU.

Maaaring maunawaan nang simpleng paraan ang relasyong ito: ang Agent-hours ay nakadepende sa GPU-hours, ang占空比 ng model inference, at ang efficiency ng scheduling. Mas maraming oras na ginagamit ng tool, mas malaki ang batch, mas mataas ang cache hit rate, at mas maraming pagkakataon ang isang oras ng GPU na suportahan ang mas mahabang Agent wall-clock work.

Ito ay direktang magbabago sa kahulugan ng pagdaragdag ng GPU. Ang pagdaragdag ng isang hanay ng GPU sa Codex ay hindi lamang nagdudulot ng mas mabilis na pagkakagawa ng isang task, kundi maaari ring payagan ang sistema na magpanatili ng higit pang Agent nang sabay-sabay. Maaaring mag-start nang sabay-sabay ng maraming task ang isang engineer—isang task para sa pagbabago sa backend, isang task para sa pagpapabuti ng pagsubok, at isang task para sa pagharap sa ibang repository—kung ang mga task na ito ay walang malakas na pagkakabatay. Ang oras ng paggawa ng machine ay maaaring tumataas nang paralelo.

Mas direkta ang curve ng kapasidad ng Sora. Ang malaking wall-clock time ng isang video ay direktang nagpapagalaw sa diffusion sa GPU, at mas malapit ang ugnayan ng isang task at ang paggamit ng GPU. Ang pagdaragdag ng GPU ay direktang nagpapataas ng throughput ng video, ngunit mahirap makuha ang malaking pagkakaiba sa pagitan ng isang oras ng GPU at ang oras ng pagkalkula ng video.

Ang isang software task sa Codex ay naglalakbay sa pagitan ng GPU, CPU, container, file system, at tool environment. Ang GPU ay responsable sa model inference, habang ang iba pang sistema ay nagpapatupad, at ang mga multiple Agent ay nagbabahagi ng inference capacity sa pamamagitan ng scheduler. Kaya, ang GPU ay naging hindi lamang isang device para sa pagbuo, kundi isang limitadong “resource ng pag-iisip” sa buong Agent system.

Ito ang dahilan kung bakit mas madaling makakuha ng karagdagang compute ang Codex, kahit na parehong makakalabas ng malaking compute. Dapat tingnan ng OpenAI hindi lang ang cost ng isang pagrerepaso, kundi kung maaari bang mabilis na mapalitan ang karagdagang capacity sa mas maraming paralel na trabaho.

Kapag isang batch ng GPU ay makakapagbigay suporta sa higit pang mga tagal na Agent, samantalang ang mga Agent na ito ay patuloy na makakatanggap ng mga bagong software task, madaling magpapatuloy ang paggalaw ng mga yaman patungo sa direksyong ito.

Kaya naging malinaw ang teknikal na kahulugan ng pahayag ni Altman. Ang malaking computing power ng Sora ay nakaputol sa isang solong proseso ng pagbuo, habang ang computing power ng Codex ay nahati sa maraming maaaring magkakasunod na yugto. Parehong mahal ang parehong gawain, ngunit iba-iba ang kurba ng return sa mga yaman.

Ang mga paliwanag sa paglipat ng mga yaman ng Sora at Codex ay nagdadala ng isang bagong variable sa mga AI product na diretso na nakakaapekto sa bilis ng pagpapalawak: workload architecture.

Ginagamit ang parehong mahal na GPU, ang isang uri ng task ay nag-a-iskedyul ng malaking computing power sa isang solong generation path, habang ang iba pang uri ng task ay maaaring gamitin ang caching, batching, tool execution, at scheduling upang i-interleave ang parehong set ng inference capacity sa mas maraming workflow, kaya ang kanilang resource curve ay naturally magkakahiwalay.

Kaya ang ilang mga problema na tila masyadong mababa sa hinaharap ay magiging mas malapit sa mga problema ng produkto. Kung paano ilalagay ang KV cache, paano hihiwalayin ang prefill, gaano kalalim ang decode batch, at kung dapat ba i-evict ang cache ng mga Agent na naghihintay ng mga tool—ang mga desisyong ito ay magpapasya kung ilang task ang maaaring panatiliin ng isang grupo ng GPU nang sabay-sabay.

Ang pagkakaiba ng Sora at Codex ay hindi lamang pagkakaiba ng video at code.

Kanilang pinag-uusapan ay ang parehong oras ng GPU, at gaano karaming trabaho ang kayang suportahan.