โอตต์มันเปิดเผยในพอดีกว่าทำไม OpenAI จึงให้ความสำคัญกับ Codex มากกว่า Sora การสร้างวิดีโอของ Sora ต้องการทรัพยากรการประมวลผลอย่างต่อเนื่องจำนวนมาก เวลา GPU ที่ใช้สำหรับงานแต่ละชิ้นยากต่อการใช้ซ้ำ ในขณะที่ Codex ใช้กลไกต่างๆ เช่น KV cache, continuous batching และการเรียกใช้เครื่องมือ เพื่อกระจายทรัพยากรการประมวลผลไปยังหลายขั้นตอนที่สามารถสลับกันได้ ทำให้ GPU เดียวกันสามารถรองรับงานพร้อมกันได้มากขึ้น ความสามารถในการใช้ซ้ำเวลา GPU กำลังเริ่มกำหนดความเร็วในการขยายตัวของผลิตภัณฑ์ AI

ผู้เขียนบทความ แหล่งที่มา: LeFeng.com

ทำไม Sora ถึงแพ้ Codex?

วันที่ 23 สิงหาคม ออตติมันได้พูดถึง Sora อย่างสมัครใจขณะพูดถึงการตัดสินใจด้านทรัพยากรภายใน OpenAI บนพอดีของเดวิด เซนรา

เขาพูดตรงไปตรงมา: Sora เป็นผลิตภัณฑ์ที่ดี และหากดำเนินต่อไปก็สามารถกลายเป็นธุรกิจที่ดีได้ แต่มันใช้ทรัพยากรการคำนวณมากเกินไป ในช่วงเวลาเดียวกัน ลำดับความสำคัญของ Codex สูงกว่า ดังนั้นจึงเริ่มมีการจัดสรรทรัพยากรการคำนวณและทีมงานไปยัง Codex

แต่น่าสนใจคือ Codex ก็ไม่ได้ประหยัด GPU เลย การสร้างวิดีโอโดย Sora ต้องให้ latent แบบสเปซไทม์ขนาดใหญ่ผ่านการคำนวณหลายรอบของ Transformer; ในขณะที่ Codex เมื่อได้รับคำสั่งว่า “แก้บั๊กนี้ให้หน่อย” ระบบพื้นหลังอาจรันการอนุมานหลายรอบ อ่านโค้ด ใช้งานเครื่องมือ รันการทดสอบ แล้วกลับมาพร้อมบันทึกและบริบทใหม่เพื่อทำการอนุมานต่อ

หนึ่งใช้พลังการประมวลผลทั้งหมดไปกับการสร้างวิดีโอเพียงครั้งเดียว อีกอันหนึ่งกระจายพลังการประมวลผลไปยังกระบวนการทำงานของเอเจนต์ที่อาจใช้เวลาหลายสิบนาทีหรือนานกว่านั้น ดังนั้น จุดที่ Sora และ Codex แยกออกจากกันอย่างแท้จริงจึงเริ่มปรากฏภายในศูนย์ข้อมูล

เช่นเดียวกับ GPU ชุดเดียวกัน ทำไมการสร้างวิดีโอจึงใช้การคำนวณที่ยากกว่าในการกระจายโหลด ในขณะที่ Coding Agent สามารถนำพลังการประมวลผลกลับมาใช้ใหม่ในงานพร้อมกันมากขึ้นได้ผ่าน KV cache, continuous batching, การจัดตาราง prefill / decode และการรอเครื่องมือ?

ที่จริงแล้ว Sora ไม่ได้แพ้เพราะการใช้พลังการประมวลผลในค่าสัมบูรณ์ แต่แพ้เพราะโครงสร้างงานโหลด: พลังการประมวลผลของ Sora เป็นแบบต่อเนื่องและผูกขาด ในขณะที่พลังการประมวลผลของ Codex เป็นแบบแตก碎片และสามารถใช้ซ้ำได้ ความแตกต่างในกลไกการจัดการนี้เองที่ทำให้ความเร็วในการขยายตัวของทั้งสองระบบต่างกัน

เลื่อนลงตามเส้นนี้ จะพบว่าทรัพยากรส่วนที่ Sora สูญเสียไป อาจเป็นผลมาจากการตัดสินใจว่าควรใช้เวลา GPU อย่างไร

ต้นทุนของ Sora อาจเริ่มเพิ่มขึ้นตั้งแต่วิดีโอเข้าสู่โมเดลแล้ว มันจะบีบอัดวิดีโอต้นฉบับลงใน latent space ก่อน แล้วตัดเป็น spacetime patches เพื่อให้ Transformer คำนวณบน patch เหล่านี้

โทเค็นข้อความเติบโตหลักตามทิศทางของลำดับ ในขณะที่พัทวิดีโอถูกวางพร้อมกันบนเวลา ความสูง และความกว้าง จึงทำให้วิดีโอเป็นสถานะที่มีปริมาตรโดยธรรมชาติภายในโมเดล

โดยคร่าวๆ จำนวนโทเค็นภาพสามารถเข้าใจได้ว่า N_video ≈ T × H × W โดยที่ T、H และ W ได้รับการบีบอัดและแบ่งเป็นแพทช์แล้ว แต่ความสัมพันธ์การคูณแบบสามมิติยังคงมีอยู่

การยืดระยะเวลาของวิดีโอจะเพิ่ม patch ตามทิศทางเวลา ขณะที่การเพิ่มขนาดภาพจะขยาย patch ทางพื้นที่ กล่าวอีกนัยหนึ่ง ความยาวของวิดีโอและขนาดพื้นที่ไม่ได้เพิ่มต้นทุนอย่างอิสระต่อกัน แต่จะร่วมกันขยายตาราง latent

หลังจากเข้าสู่ Transformer พื้นที่นี้ยังต้องเผชิญกับการคำนวณระดับที่สองที่เกิดจาก diffusion Sora เริ่มต้นจาก latent ที่มีสัญญาณรบกวน แต่ละรอบจะอัปเดตการแสดงผลวิดีโอตามสถานะปัจจุบัน แล้วส่ง latent ใหม่ไปยังรอบถัดไป

การคำนวณสำหรับวิดีโอหนึ่งชิ้นสามารถเข้าใจคร่าวๆ เป็น C_video ≈ D × C_transformer(N_video) โดยที่ D คือจำนวนรอบการสุ่มตัวอย่าง ยิ่ง latent ของวิดีโอใหญ่เท่าไร แต่ละรอบก็จะหนักขึ้น; หากเพิ่มจำนวนรอบการสุ่มตัวอย่าง วิดีโอเดียวกันก็ต้องวิ่งผ่านเครือข่ายเพิ่มอีกหลายรอบ

ที่นี่สามารถมองเห็นความแตกต่างสำคัญระหว่างวิดีโอ diffusion กับ LLM เมื่อโมเดลภาษาสร้าง token ถัดไป คีย์และค่าก่อนหน้าสามารถเก็บไว้ใน KV cache ได้ โมเดลจึงไม่จำเป็นต้องสร้างสถานะประวัติทั้งหมดขึ้นใหม่ในแต่ละขั้นตอน

เมื่อการอัปเดตแต่ละรอบของวิดีโอ diffusion แล้ว finish ร่าง latent หลักจะเปลี่ยนไป รอบถัดไปจะต้องเผชิญกับสถานะช่วงเวลาใหม่ ดังนั้นการคำนวณจำนวนมากสำหรับหัวข้อวิดีโอยังคงต้องดำเนินการต่อไป

ดังนั้นต้นทุนของ Sora จึงยากที่จะลดลงอย่างมากผ่านการ “ใช้ซ้ำข้อมูลในอดีต” มันคล้ายกับการประมวลผลฉากภาพเคลื่อนไหวหลายรอบ โดยแต่ละรอบต้องจัดการกับภาพทั้งหมดที่เปลี่ยนไปแล้ว ยิ่งวิดีโอยาวขึ้น ขนาดสูงขึ้น และตัวอย่างที่ใช้มากขึ้น เส้นทางการสร้างนี้ก็จะยิ่งหนักขึ้น

เนื่องจากงานแต่ละงานมีภาระหนักพอสมควร การใช้งาน GPU ของ Sora จึงอาจดูดีมาก การคำนวณเมทริกซ์ขนาดใหญ่ทำให้ Tensor Core ทำงานอย่างต่อเนื่อง ทำให้กราฟการตรวจสอบแสดงว่า GPU แทบไม่มีช่วงว่าง

การใช้งานสูงหมายเพียงว่าชิปกำลังทำงานอยู่ต่อเนื่อง ไม่ได้หมายความว่าส่งงานจำนวนมากในหน่วยเวลาเดียวกัน หากวิดีโอหนึ่งเรื่องยึดชุด GPU ไว้นานมาก การใช้งานจะดูดีเพียงใดก็ตาม ปริมาณ GPU-seconds ที่ใช้ต่อคำขอเดียวยังคงสูงอยู่

วิดีโอ serving ยังคงติดขัดจากความแตกต่างของรูปร่าง ความยาว ความละเอียด และอัตราส่วนภาพที่ต่างกันจะสร้าง tensor shape ที่แตกต่างกัน ฝั่งเซิร์ฟเวอร์เพื่อเพิ่มประสิทธิภาพการ batch จะต้องจัดกลุ่มคำขอที่มีขนาดใกล้เคียงกันไว้ใน bucket เดียวกัน การรอสักครู่จะช่วยรวม batch ที่หนาแน่นกว่า แต่จะเพิ่มความล่าช้าในการรอ; การดำเนินการทันทีจะลดเวลาการรอ แต่ batch อาจไม่เต็ม

ดังนั้น ต้นทุนการประมวลผลส่วนใหญ่ของ Sora จึงถูกล็อกไว้ในเส้นทางการสร้างวิดีโอของตัวเองเอง จำนวนรอบการสุ่มตัวอย่างสามารถลดลงได้ latent สามารถบีบอัดต่อไปได้ โมเดลสามารถถูกกลั่นกรอง และ kernel ก็สามารถปรับปรุงต่อไปได้ แต่สิ่งที่ scheduler สามารถปรับเปลี่ยนได้หลักๆ คือ “การจัดลำดับงานหนักเหล่านี้อย่างไร” ไม่สามารถเปลี่ยนข้อเท็จจริงที่ว่า “วิดีโอหนึ่งชิ้นจำเป็นต้องใช้การคำนวณต่อเนื่องจำนวนมาก”

นี่คือจุดเริ่มต้นในการเข้าใจ Codex Codex ก็มีราคาแพงเช่นกัน แต่มันไม่ได้กดภาระค่าใช้จ่ายทั้งหมดไว้ที่บล็อกการคำนวณต่อเนื่องเดียว แต่แบ่งงานออกเป็นหลายขั้นตอนที่สามารถหยุดชั่วคราว ฟื้นฟู และรวมกลับใหม่ได้

ผู้ใช้ให้ Codex คำสั่งว่า “แก้บั๊กนี้” งานนี้จะไม่จบด้วยการเรียกโมเดลเพียงครั้งเดียว ตัวแทนอาจเริ่มด้วยการอ่านรีโพสิทอรี ให้โมเดลตัดสินขั้นตอนถัดไป แล้วดำเนินการ shell; เมื่อได้รับข้อผิดพลาด ให้เพิ่มบันทึกเข้าไปในบริบทแล้วเรียกโมเดลอีกครั้ง; จากนั้นแก้ไขโค้ด รันการทดสอบ และใช้ผลลัพธ์ใหม่เพื่อให้เหตุผลต่อไป

ดังนั้นภารกิจหนึ่งของ Codex จึงใกล้เคียงกับการสะสมหลายรอบ Prefill + Decode + Tool โดยจุดสำคัญคือ หลังจากเสร็จสิ้นการเรียกใช้เครื่องมือแต่ละรอบ บริบทที่โมเดลเห็นในรอบถัดไปมักจะหนาแน่นกว่ารอบก่อนหน้า

เมื่อเริ่มต้นงาน โมเดลอาจมีเพียงคำขอของผู้ใช้และโค้ดจำนวนน้อยเท่านั้น หลังจากทำงานไปสักพัก ไฟล์เพิ่มเติม ดิฟ ผลลัพธ์จากเทอร์มินัล บันทึกการทดสอบ และผลลัพธ์จากเครื่องมือจะค่อยๆ ถูกส่งเข้ามาในพรอมต์

ผู้ใช้อาจเห็นเพียงคำอธิบายสั้นๆ ไม่กี่ร้อยคำ แต่เนื้อหาที่ GPU ประมวลผลระหว่างทางอาจมีขนาดใหญ่โตมากแล้ว ความกดดันจากการใช้โทเค็นของเอเจนต์ซ่อนอยู่ในเส้นทางงานที่เพิ่มขึ้นอย่างต่อเนื่องนี้

หากต้องประมวลผลประวัติทั้งหมดซ้ำทุกครั้งในการ inference งานที่ยาวจะถูกชะลออย่างรวดเร็วจากการ prefill ซ้ำ ดังนั้นการแคชพรอมต์จึงมีความสำคัญอย่างยิ่งต่อ Codex

สมมติว่า Agent มีบริบท token 100K แล้ว การดำเนินการเครื่องมือเพิ่มบันทึกเพียง 3K token หาก prefix ที่คงที่ด้านหน้าสามารถจับคู่แคชได้ การคำนวณที่เพิ่มขึ้นในรอบนี้จะมุ่งเน้นที่ส่วนท้ายนี้เท่านั้น; หากส่วนหน้าของ prompt เปลี่ยนแปลงทำให้เกิด cache miss ระบบอาจต้องเผชิญกับ prefill ที่หนักอีกครั้ง

มีการเปลี่ยนแปลงสำคัญเกิดขึ้นที่นี่: จำนวนโทเค็นตรรกะไม่สามารถแสดงต้นทุน GPU จริงได้อีกต่อไป คำขอทั้งสองแสดงผลที่ 100K โทเค็นอินพุต แต่คำขอหนึ่งมีเนื้อหาส่วนใหญ่ถูกแคชไว้แล้ว ในขณะที่อีกคำขอต้องคำนวณใหม่ทั้งหมด ซึ่งสร้างภาระต่อ GPU ต่างกันอย่างมาก โหลดของเอเจนต์จึงขึ้นอยู่กับอัตราการเติบโตของบริบท ความสำเร็จของการแคช และจำนวนครั้งที่งานเดียวกันถูกส่งเข้าสู่โมเดลซ้ำๆ

หลังจากเข้าสู่การ inference แบบครั้งเดียว กระบวนการ prefill และ decode จะมีความต้องการฮาร์ดแวร์ที่แตกต่างกัน โดย prefill จะประมวลผล token จำนวนมากในครั้งเดียว มีขนาดเมทริกซ์ใหญ่ และง่ายต่อการสร้างภาระงานที่ต้องใช้การคำนวณสูง ส่วน decode แต่ละลำดับจะสร้าง token จำนวนน้อยในแต่ละรอบ แต่ต้องเข้าถึงน้ำหนักโมเดลและ KV cache ซ้ำๆ จึงขึ้นอยู่กับแบนด์วิดธ์ของ HBM และขนาดของการประมวลผลแบบขนาน

หมายความว่าถ้ารัน sequence เดียวแบบแยกกัน จะสิ้นเปลืองอย่างมาก น้ำหนักโมเดลยังคงมีขนาดใหญ่เท่าเดิม และต้องใช้การคำนวณแบบฟอร์เวิร์ดเต็มรูปแบบเพื่อสร้าง token เดียว เซิร์ฟเวอร์ต้องรวมหลาย sequence เข้าไปใน batched forward เดียวกัน เพื่อให้การเข้าถึงน้ำหนักครั้งเดียวสามารถดำเนินการคำขอได้หลายคำขอพร้อมกัน

แต่ขนาดของ batch ไม่สามารถเพิ่มขึ้นต่อไปได้อีก เนื่องจากถูกจำกัดโดย KV cache ยิ่งความยาวของบริบทในแต่ละ sequence มากเท่าใด ก็จะใช้หน่วยความจำ HBM มากขึ้นเท่านั้น เมื่อจำนวน Agent เพิ่มขึ้น GPU อาจยังมีกำลังการประมวลผลเหลืออยู่ แต่หน่วยความจำแสดงผลกลับไม่สามารถเก็บสถานะที่ใช้งานอยู่เพิ่มเติมได้

การออกแบบเช่น PagedAttention ใช้การจัดการ KV cache แบบแบ่งหน้า เพื่อลดความแตกแยกของหน่วยความจำ GPU โดยพื้นฐานแล้วเป็นการเพิ่มจำนวนลำดับที่ใช้งานอยู่ที่ GPU หนึ่งหน่วยสามารถรองรับได้พร้อมกัน

การเรียกใช้เครื่องมือช่วยแบ่งโหลดของ Codex ออกอีกครั้ง เมื่อ Agent รันการทดสอบ คอมไพล์โค้ด หรือรอ I/O GPU ไม่จำเป็นต้องทำงานต่อไป แต่ CPU คอนเทนเนอร์ และระบบไฟล์จะรับหน้าที่แทน เมื่อผลลัพธ์กลับมา Agent จะเข้าสู่รอบการประมวลผลถัดไป

ดังนั้น การรัน Agent ที่ใช้เวลา 60 นาที จึงไม่ได้หมายความว่าจะใช้ GPU ต่อเนื่องตลอด 60 นาที งานของมันถูกแบ่งออกเป็นสองส่วนคือการคำนวณแบบจำลองและการดำเนินการภายนอก ซึ่งทำให้ scheduler ได้รับพื้นที่ที่ Sora ให้ไม่ได้: เมื่อ Agent ใดๆ ไปเรียกใช้เครื่องมือ GPU สามารถทันทีไปให้บริการลำดับอื่นๆ

แน่นอน นี่ก็จะสร้างปัญหาหน่วยความจำแสดงผลใหม่ขึ้นมา ตัวแทนที่รอเครื่องมือควรเก็บ KV cache ไว้หรือไม่? การเก็บไว้จะช่วยให้ฟื้นตัวได้เร็วขึ้น แต่จะใช้พื้นที่ HBM อย่างต่อเนื่อง; การขับออกจะปล่อยพื้นที่ว่าง แต่เมื่อภารกิจกลับมา จะต้องรับต้นทุนในการกู้คืน ยิ่งมีตัวแทนมากเท่าใด การตัดสินใจเหล่านี้ก็ยิ่งคล้ายกับระบบปฏิบัติการที่จัดการกับกระบวนการจำนวนมากที่เข้าสู่สภาวะหลับและตื่นขึ้น

ที่นี่ ความแตกต่างระหว่าง Codex และ Sora ไม่ได้อยู่ที่ “ใครหนักกว่า” แต่อยู่ที่ต้นทุนถูกแยกออกหรือไม่ Sora ใช้พลังการประมวลผลแบบรวมอยู่ในเส้นทางการสร้างต่อเนื่องเดียว ในขณะที่ Codex กระจายพลังการประมวลผลออกเป็นหลายขั้นตอน ด้วยเหตุนี้จึงสามารถเข้าสู่การปรับปรุงระดับถัดไป: ให้ scheduler ตัดสินใจว่าขั้นตอนเหล่านี้จะแบ่งปัน GPU เดียวกันอย่างไร

ในระหว่างการดำเนินงานแบบออนไลน์ของโมเดลขนาดใหญ่ น้ำหนักมักจะต้องคงอยู่บน GPU เป็นระยะเวลานาน และต้องรักษาสถานะการขนานแบบเทนเซอร์ การสื่อสารระหว่างโหนด และแคช ดังนั้นการแข่งขันทรัพยากรระหว่าง Sora และ Codex มักเกิดขึ้นในระดับฟลีต: GPU บางส่วนจะถูกจัดให้อยู่ในกลุ่มให้บริการวิดีโออย่างถาวร ในขณะที่อีกบางส่วนจะถูกจัดให้อยู่ในกลุ่ม LLM อย่างถาวร ระบบจัดการความสามารถระดับบนจะตัดสินใจว่าควรขยายหรือลดขนาดฝั่งใด

สิ่งที่ซับซ้อนจริงๆ เกิดขึ้นภายใน Codex pool สมมติว่าในระบบมี Agent sequence อยู่พร้อมกัน 200 เส้น บางส่วนกำลัง decode บางส่วนรอเครื่องมือ และอีกหลายสิบเส้นเพิ่งกลับมาจากสภาพแวดล้อมเครื่องมือ ต้องจัดการกับบริบทยาวใหม่ Scheduler ต้องเผชิญกับข้อจำกัดไม่เพียงแต่ FLOPs เท่านั้น แต่ยังรวมถึงความจุ HBM แบนด์วิดธ์หน่วยความจำ การอยู่รอดของ KV cache และงบประมาณความล่าช้า

Continuous batching แก้ปัญหาการใช้งานการถอดรหัสก่อน แบบ batch แบบคงที่แบบดั้งเดิมจะผูกคำขอชุดหนึ่งไว้ด้วยกัน หลังจาก sequence สั้นเสร็จสิ้น คำขอที่ยาวกว่ายังคงใช้ batch อยู่

การจัดกลุ่มอย่างต่อเนื่องจะเปลี่ยนผู้ใช้งานแบบไดนามิกในระดับการวนซ้ำของโทเค็น เมื่อหนึ่งลำดับเสร็จสิ้น จะถูกลบออก และคำขอใหม่จะเข้ามาทันที ยิ่งกลุ่มมีขนาดใหญ่เท่าใด การคำนวณแบบโมเดลหนึ่งรอบก็จะสามารถดำเนินการลำดับได้มากขึ้น ต้นทุนของการเข้าถึงน้ำหนักโมเดลและแบนด์วิธหน่วยความจำจึงสามารถกระจายได้ดีขึ้น

แต่ที่นี่จะพบกับกำแพงหน่วยความจำกราฟิกในเร็วๆ นี้ แคช KV ของ Agent ที่ยาวจำนวนมากจะใช้ HBM อย่างต่อเนื่อง อาจยังไม่ได้ใช้งาน Tensor Core ให้เต็มประสิทธิภาพ แต่หน่วยความจำกราฟิกก็เต็มแล้วและไม่สามารถรับ sequence เพิ่มเติมได้ ในสถานการณ์นี้ การเพิ่มพลังการประมวลผลต่อไปจะไม่มีความหมาย ข้อจำกัดที่แท้จริงต่อการประมวลผลแบบขนานคือความจุแคชและการจัดการหน่วยความจำกราฟิก

ยังมีความขัดแย้งอีกประเภทหนึ่งระหว่าง prefill กับ decode โดยสมมติว่ามีลำดับหลายสิบลำดับกำลัง decode อย่างเสถียร แต่แล้วตัวแทนหนึ่งกลับมาพร้อมกับบริบทใหม่ 100K token ที่ต้องดำเนินการ prefill ขนาดใหญ่ หาก prefill นี้ใช้ช่วงเวลาการประมวลผลนานเกินไป ค่า TPOT ของการร้องขออื่นๆ ที่อยู่ข้างเคียงจะลดลงอย่างชัดเจน

Chunked prefill จะแบ่งอินพุตที่ยาวออกเป็นชิ้นเล็กๆ เพื่อให้ prefill และ decode ทำงานสลับกัน; วิธีที่ล้ำกว่านั้นคือการแยก prefill และ decode ไปยัง GPU pool ที่ต่างกัน

เนื่องจากสองระยะนี้มีข้อจำกัดด้านฮาร์ดแวร์ที่ต่างกัน: prefill มุ่งเน้นที่ความจุการคำนวณ ในขณะที่ decode ขึ้นอยู่กับแบนด์วิดธ์ HBM, KV cache และความล่าช้าแบบทีละโทเค็นที่มีเสถียรภาพ เมื่อแยกออกแล้ว สามารถจัดสรรทรัพยากรตามความต้องการของแต่ละระยะได้

สิ่งนี้ชี้ให้เห็นว่าแกนหลักของ Agent serving ได้ vượtพ้นแค่ “การเขียน kernel ของโมเดลให้เร็วขึ้น” ความเพิ่มขึ้นของความจุจำนวนมากมาจากการจัดเรียงใหม่เกี่ยวกับว่าเมื่อใดและที่ไหนควรรันงาน สถานะใดควรเก็บไว้ในหน่วยความจำ GPU และควรใส่ใครไว้ใน batch ปัจจุบัน

ดังนั้น การใช้งาน GPU ที่นี่จึงไม่เพียงพออีกต่อไป ทีมความสามารถต้องพิจารณาพร้อมกันที่ GPU-seconds per task, TTFT (เวลาหน่วงของคำแรก ซึ่งกำหนดว่าผู้ใช้รู้สึกติดขัดหรือไม่), TPOT (เวลาในการสร้างคำเดียว ซึ่งกำหนดว่าโมเดล “พูด” ได้เร็วแค่ไหน), queueing latency, prefix cache hit, KV cache occupancy และ SLO goodput (ปริมาณการใช้งานที่มีประสิทธิภาพ ซึ่งแสดงถึงพลังการประมวลผลที่สามารถสร้างรายได้ได้จริง)

ตัวชี้วัดเหล่านี้ร่วมกันตอบคำถามว่า: ในระยะเวลารอที่ผู้ใช้ยอมรับได้ หนึ่งชั่วโมง GPU สามารถรักษาภาระงานที่มีประสิทธิภาพได้กี่งาน

ความยืดหยุ่นของ Codex แสดงให้เห็นที่นี่: ค่า prefix คงที่สามารถลดการ prefill ซ้ำซ้อน การ decode สามารถทำการ batch แบบต่อเนื่อง KV cache สามารถแบ่งเป็นหน้าและขับออกได้ และเมื่อ Agent รอเครื่องมือ ยังสามารถคืน GPU ได้ งานของมันมีความละเอียดอ่อน แต่ชิ้นส่วนเล็กๆ เหล่านี้สามารถถูก scheduler จัดเรียงใหม่ได้

สิ่งนี้ยังทำให้คำถามแปรเปลี่ยนไปสู่ระดับทรัพยากรโดยธรรมชาติ: หาก GPU ชุดเดียวกันสามารถให้บริการ Agent ระยะยาวได้มากขึ้นแบบสลับกัน ชั่วโมง GPU หนึ่งชั่วโมงอาจสามารถรองรับเวลาการทำงานได้มากกว่าหนึ่งชั่วโมง

สมมติว่า Codex Agent ใช้เวลาทั้งหมด 60 นาทีตั้งแต่รับงานจนเสร็จสิ้น โดยมีเพียงบางส่วนของเวลาเท่านั้นที่ใช้ในการ prefill และ decode แบบจำลอง ส่วนเวลาที่เหลือใช้สำหรับการคอมไพล์ การทดสอบ การอ่านและเขียนไฟล์ หรือการรอเครื่องมือ อัตราส่วนที่แน่นอนจะแตกต่างกันไปตามงาน แต่โครงสร้างนี้มีความสำคัญ: เวลาแบบ wall-clock ของ Agent และเวลาการคำนวณของ GPU ไม่ได้เท่ากันแบบ 1:1

หากมีตัวแทนจำนวนมากอยู่ในระบบพร้อมกัน พวกเขาจะไม่ต้องการ GPU ทั้งหมดในเวลาเดียวกันในหนึ่งวินาที บางคนกำลังทำ prefill บางคนกำลัง decode บางคนกำลังรันการทดสอบ และบางคนกำลังรอระบบไฟล์ ตราบใดที่ scheduler สามารถสลับขั้นตอนเหล่านี้ให้สลับกันได้ GPU ที่มีจำกัดก็สามารถรองรับจำนวนงานที่ใช้งานอยู่ได้มากกว่าจำนวน GPU อย่างมาก

สามารถเข้าใจความสัมพันธ์นี้แบบคร่าวๆ ได้ว่า: Agent-hours ขึ้นอยู่กับ GPU-hours อัตราการใช้งานของโมเดลในการให้บริการ และประสิทธิภาพการจัดตาราง เวลาที่เครื่องมือใช้ทำงานยิ่งมาก แบตช์ยิ่งหนา และอัตราการเข้าถึงแคชยิ่งสูง ก็ยิ่งทำให้ GPU หนึ่งชั่วโมงมีโอกาสสนับสนุนงานของ Agent แบบ wall-clock ได้นานขึ้น

สิ่งนี้จะเปลี่ยนความหมายของการเพิ่ม GPU ใหม่โดยตรง การเพิ่ม GPU จำนวนมากให้กับ Codex ไม่เพียงแต่ทำให้ภารกิจเดียวเร็วขึ้น แต่ยังอาจช่วยให้ระบบสามารถรักษา Agent จำนวนมากไว้พร้อมกันได้ วิศวกรสามารถเริ่มต้นภารกิจหลายอย่างพร้อมกัน เช่น เปลี่ยนแบ็กเอนด์หนึ่งภารกิจ ปรับปรุงการทดสอบอีกหนึ่งภารกิจ และจัดการคลังอีกหนึ่งแห่ง โดย只要这些任务之间没有强依赖，机器工作时间就可以并行增长。

เส้นโค้งความจุของ Sora ตรงไปตรงมามากกว่า เวลาแบบ wall-clock ที่ใช้ในการสร้างวิดีโอหนึ่งเรื่องนั้นเองก็กำลังขับเคลื่อน diffusion บน GPU โดยตรง ทำให้ภาระงานแต่ละงานและการใช้งาน GPU ผูกติดกันอย่างแน่นหนา การเพิ่ม GPU สามารถเพิ่มปริมาณวิดีโอที่ประมวลผลได้โดยตรง แต่ความแตกต่างระหว่างเวลา GPU หนึ่งชั่วโมงกับเวลาการคำนวณวิดีโอจะยากที่จะขยายให้กว้างขึ้นมาก

งานซอฟต์แวร์หนึ่งงานของ Codex จะเคลื่อนย้ายระหว่าง GPU, CPU, คอนเทนเนอร์, ระบบไฟล์ และสภาพแวดล้อมเครื่องมือ GPU รับผิดชอบการอนุมานแบบจำลอง ระบบอื่นๆ รับผิดชอบการดำเนินการ ตัวแทนหลายตัวจะแบ่งปันความสามารถในการอนุมานผ่าน scheduler แบบสลับกัน ดังนั้น GPU จึงเปลี่ยนจากอุปกรณ์สร้างเพียงอย่างเดียว ให้กลายเป็นทรัพยากรการคิดที่หายากในระบบตัวแทนทั้งหมด

นี่คือเหตุผลที่ Codex แม้จะสามารถใช้ทรัพยากรการคำนวณจำนวนมากได้เช่นกัน แต่กลับสามารถรับทรัพยากรการคำนวณใหม่ได้ง่ายกว่า OpenAI ต้องพิจารณาไม่เพียงแค่ต้นทุนการประมวลผลแต่ละครั้ง แต่ยังต้องดูว่าความสามารถใหม่สามารถแปลงเป็นปริมาณงานแบบขนานได้เร็วเพียงใด

เมื่อชุด GPU หนึ่งชุดสามารถรองรับ Agent ระยะยาวได้มากขึ้น และ Agent เหล่านี้สามารถรับงานซอฟต์แวร์ใหม่ๆ อย่างต่อเนื่อง ทรัพยากรก็จะไหลเวียนไปในทิศทางนี้ได้อย่างง่ายดาย

ความหมายทางเทคนิคของคำพูดของ Altman จึงชัดเจนขึ้น ทรัพยากรการประมวลผลจำนวนมากของ Sora ถูกล็อกไว้ในเส้นทางการสร้างเพียงเส้นเดียว ในขณะที่ทรัพยากรการประมวลผลของ Codex ถูกแบ่งออกเป็นหลายขั้นตอนที่สามารถสลับกันได้ ทั้งสองฝ่ายมีต้นทุนเท่ากัน แต่เส้นโค้งผลตอบแทนของทรัพยากรกลับต่างกัน

คำอธิบายการถ่ายโอนทรัพยากรของ Sora และ Codex ผลิตภัณฑ์ AI เริ่มมีตัวแปรใหม่ที่ส่งผลกระทบโดยตรงต่อความเร็วในการขยายตัว: workload architecture

การใช้ GPU ที่มีราคาแพงเช่นกัน งานประเภทหนึ่งจะผูกทรัพยากรการประมวลผลจำนวนมากไว้กับเส้นทางการสร้างเพียงเส้นเดียว ในขณะที่งานอีกประเภทหนึ่งสามารถใช้แคช การจัดกลุ่ม การดำเนินการด้วยเครื่องมือ และการจัดตาราง เพื่อสลับทรัพยากรการประมวลผลเดียวกันให้กับเส้นทางการทำงานหลายเส้น จึงทำให้เส้นโค้งทรัพยากรของทั้งสองประเภทแยกออกจากกันโดยธรรมชาติ

ดังนั้นในอนาคต ปัญหาที่ดูเหมือนพื้นฐานบางอย่างจะเข้าใกล้ปัญหาผลิตภัณฑ์มากขึ้น การจัดเก็บ KV cache ควรทำอย่างไร การแบ่ง prefill ควรทำอย่างไร การจัดการ decode batch สามารถบรรจุได้หนาแค่ไหน ตัวแทนที่รอเครื่องมือควรขับไล่แคชหรือไม่ การตัดสินใจเหล่านี้จะกำหนดจำนวนงานที่ GPU หนึ่งชุดสามารถรักษาไว้ได้พร้อมกัน

ความแตกต่างระหว่าง Sora และ Codex ไม่ได้จำกัดอยู่แค่ความแตกต่างระหว่างวิดีโอและโค้ด

พวกเขาแข่งขันกันเพื่อใช้ GPU หนึ่งชั่วโมงเดียวกัน ว่าจะรองรับงานได้มากแค่ไหน