เก้าชั่วโมงที่เราเร่งปิดงานค้าง แล้วพบว่าคอขวดไม่ใช่ AI

วันที่ 9 ตุลาคม เราให้ห้อง AI ทุกห้องเร่งปิดรายการงานค้างก้อนเดียวกัน ย้ายไปเครื่องใหญ่ขึ้น ขยายดิสก์ เพิ่มจำนวนงานที่รันพร้อมกัน ถึงเที่ยงคืนปิดได้ 149 รายการ บทความนี้เล่าว่าตัวเลขเดินอย่างไร อะไรพังระหว่างทาง และทำไมข้อสรุปของคืนนั้นคือ งานปิดได้เร็วเท่าที่คนตรวจทัน ไม่ใช่เร็วเท่าที่ AI เขียนทัน

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

ตั้งต้น

บ่ายวันที่ 9 ตุลาคม เรานับรายการงานค้างที่เปิดอยู่ในคลังโค้ดสองคลังได้ 490 รายการ และ 463 รายการเมื่อนับซ้ำตอน 15:45 จากนั้นแบ่งเป็นก้อนให้แต่ละห้องรับผิดชอบ รวม 390 รายการ ซึ่งตอนเริ่มยังเปิดอยู่ 368

"ห้อง" ของเราคือ AI หนึ่งตัวที่ดูแลงานด้านหนึ่ง แต่ละห้องคิดและตรวจเอง แล้วส่งงานเขียนโค้ดให้โมเดลเปิดบนเครื่อง GPU ของเราทำ

ระหว่างวันเราเพิ่มกำลังหลายทาง อัปเกรดเครื่องที่ห้องทำงานอยู่เป็น 32 คอร์ ขยายดิสก์เป็น 1,000 GB ยกเพดานจำนวนงานเขียนโค้ดที่ห้องใหญ่ที่สุดสั่งพร้อมกันได้เป็น 20 งาน จากปกติราว 6 งานต่อห้อง และกลางดึกเครื่อง GPU รับงานพร้อมกันเต็ม 48 งาน

ตัวเลขตอนเที่ยงคืน

เวลา 00:03 เราปิดวันด้วยตัวเลขนี้: ยังเปิดอยู่ 219 จาก 390 เทียบกับฐาน 368 ที่นับไว้ตอนบ่ายสามโมงกว่า เท่ากับปิดได้ 149 รายการ และมีอีกราว 30 รายการที่ปิดได้นอกก้อนที่แบ่งไว้ ตั้งแต่ 15:00 มีงานรวมเข้าสายหลัก 300 ชิ้นในคลังหนึ่ง และ 132 ชิ้นในอีกคลัง

ภาพรวมดูดี แต่เมื่อดูรายห้อง ภาพไม่เท่ากันเลย ห้องที่ดีที่สุดลดงานค้างของตัวเองจาก 43 เหลือ 5 อีกห้องจาก 13 เหลือ 2 ขณะที่มีสี่ห้องปิดไม่ได้เลยสักรายการ บันทึกเขียนเหตุผลไว้สั้นๆ ว่า งานของสี่ห้องนั้นต้องรอเจ้าของหรือรอคน

สิ่งที่พังระหว่างทาง

งานที่รายงานว่าเสร็จแต่ไม่มีอะไรกลับมา ช่วง 17:5x ถึง 19:23 เราส่งงานเขียนโค้ดไปรันบนเครื่องเสริม มี 18 งานที่จบด้วยสถานะสำเร็จแต่ไม่มีโค้ดกลับมาเลย ทีมโครงสร้างพื้นฐานกู้ได้ 16 งาน แล้วเปิดเส้นทางนี้ใหม่ตอน 19:29 พร้อมตัวตรวจที่ร้องดังเมื่อผลว่าง เราจดเรื่องนี้เป็นความผิดทั้งตระกูล ไม่ใช่บั๊กตัวเดียว คือ "เสร็จกลวง" สถานะบอกว่าสำเร็จ แต่ไม่มีของ

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

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

โควตาและดิสก์ ราวสี่ทุ่ม บัญชี Claude บัญชีหนึ่งใช้โควตาไปแล้ว 92% และบันทึกเตือนว่าบัญชีหลักที่ห้องส่วนใหญ่ใช้อาจหมดภายในราวหนึ่งวันถ้าใช้ในอัตราของวันนั้น ส่วนดิสก์ สำเนาโค้ดที่แต่ละงานสร้างไว้ทำงานกินพื้นที่ไป 257 GB มากที่สุดในเครื่อง

การปรับโครงสร้างกลางทาง การเปลี่ยนเครื่อง การย้ายโมเดลของห้อง และการย้ายบัญชี แต่ละครั้งทำให้ห้องว่างงานราว 30 นาที

ข้อสรุปของคืนนั้น

ในบันทึกปิดวัน บรรทัดบทเรียนขึ้นต้นด้วยประโยคนี้: การปิดงานผูกกับการรวมโค้ด ไม่ได้ผูกกับ AI

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

เช้าวันรุ่งขึ้นเรื่องนี้ชัดขึ้นอีก เราตั้งใจจะให้เครื่อง GPU มีงานเต็มถึงเที่ยง แต่หยุดก่อนตอน 10:22 บันทึกให้เหตุผลว่า งานที่ยังไม่มีใครแตะแทบหมดแล้ว มีงานที่เขียนเสร็จ 86 ชิ้นรอตรวจอยู่ และ "งานเพิ่ม = ผลงานที่ไม่มีใครตรวจ"

คำพยากรณ์ที่ไม่เป็นจริง

ตอนปิดวัน เราเขียนคำพยากรณ์ไว้ว่า งานค้างจะเหลือต่ำกว่า 100 รายการราวเจ็ดถึงแปดโมงเช้าวันเสาร์ ถ้าห้องทำงานต่อทั้งคืน

เที่ยงวันเสาร์ ตัวเลขที่จดไว้คือยังเปิดอยู่ 176 รายการ และบันทึกเรียกสถานะนี้ว่า "ชะงัก" เมื่อแยกดู 176 รายการนั้น มี 59 รายการที่ยังไม่มีงานแก้ 45 รายการมีงานแก้เปิดรอตรวจอยู่ 46 รายการมีงานแก้ที่รวมเข้าไปแล้วบางส่วน 3 รายการมีงานที่รวมแล้วอ้างถึง และ 23 รายการรอเจ้าของตัดสิน

ตัวเลขชุดนี้ยืนยันข้อสรุปของคืนก่อน ใน 176 รายการ มีเพียง 59 ที่ยังรอคนเขียน ที่เหลือ 117 รายการรอการตรวจ การปิด หรือการตัดสินใจของคน

สิ่งที่เรายังไม่รู้

• ตัวเลข 176 ตอนเที่ยงวันเสาร์นับบนฐานเดียวกับ 219 จาก 390 ตอนเที่ยงคืนหรือไม่ บันทึกไม่ได้บอก เราจึงไม่ได้คำนวณว่าคืนนั้นปิดเพิ่มได้กี่รายการ
• ฐานตั้งต้นมีสามตัวเลข คือ 490, 463 และ 368 จาก 390 บันทึกไม่ได้อธิบายว่ารายการที่อยู่นอก 390 คืออะไร
• ตัวตรวจ "ร้องดังเมื่อผลว่าง" ที่เพิ่มหลังเหตุการณ์เสร็จกลวง บันทึกของห้องที่แก้เขียนไว้สั้นๆ ว่าทดสอบแล้วสามทาง แต่เราไม่พบตัวผลทดสอบ จึงยืนยันเองไม่ได้ว่าทดสอบอะไรและผ่านอย่างไร
• งานสองชิ้นจาก 18 ที่กู้ไม่ได้ ถูกทำใหม่หรือไม่

ข้อคิดที่เอาไปใช้ได้

1. ก่อนเพิ่มกำลังผลิต ให้หาว่างานไปกองที่ขั้นไหน ถ้ากองอยู่หน้าคนตรวจ การเพิ่มคนเขียนทำให้กองสูงขึ้นเท่านั้น
2. สถานะ "สำเร็จ" ต้องมาพร้อมของ งานที่จบสำเร็จโดยไม่มีผลลัพธ์ควรถูกนับเป็นล้มเหลวโดยอัตโนมัติ
3. อย่าปรับโครงสร้างระหว่างวันที่เร่ง การเปลี่ยนแต่ละครั้งของเราแลกด้วยเวลาว่างราวครึ่งชั่วโมงของทุกห้องที่เกี่ยวข้อง
4. เฝ้าสิ่งที่จะพังจริง การนับจำนวนงานบอกไม่ได้ว่าเครื่องไหวไหม
5. เขียนคำพยากรณ์ลงบันทึก แล้วกลับมาเทียบ คำพยากรณ์ของเราพลาด และการที่มันถูกจดไว้ทำให้เรารู้ว่าพลาดเพราะอะไร