การฝึก LLM ตั้งแต่ศูนย์ในสตาร์ทอัพ
(yitay.net)- Reka สร้างโครงสร้างพื้นฐานสำหรับฝึกโมเดลภาษาขนาดใหญ่และโมเดลมัลติโมดัลขึ้นใหม่ทั้งหมด โดยคอขวดที่ใหญ่กว่าการหา compute ให้ได้คือ ความแปรปรวนของคุณภาพคลัสเตอร์ และความไม่เสถียรในการปฏิบัติการ
- แม้จะเป็น GPU H100 รุ่นเดียวกัน แต่ความล้มเหลวของโหนด ปัญหาการเดินสาย ข้อผิดพลาดของ GPU คอขวดด้าน I/O และไฟล์ซิสเต็ม การลบ checkpoint และการส่งมอบล่าช้า ล้วนแตกต่างกันตามผู้ให้บริการและคลัสเตอร์ จนเกิดสถานการณ์คล้าย ลอตเตอรี่ฮาร์ดแวร์
- ต่างจากประสบการณ์กับ TPU และโครงสร้างพื้นฐานภายในของ Google สภาพแวดล้อม GPU ภายนอกมีความแตกต่างสูงในด้านการฝึกแบบ multi-node การเดินสาย และคุณภาพการซัพพอร์ต ทำให้ MFU และ downtime แตกต่างกันมากในแต่ละคลัสเตอร์
- ต้องยอมรับข้อจำกัดของหลายคลัสเตอร์ การย้ายข้อมูลขนาดใหญ่ และข้อจำกัดของ codebase ภายนอก โดย Reka ย้ายมาใช้ฐาน PyTorch และสร้าง monitoring, checkpoint ที่มีประสิทธิภาพ และไฟล์ซิสเต็มแบบกำหนดเองด้วยตนเอง
- เนื่องจาก compute จำกัด จึงไม่สามารถทำ scaling อย่างเป็นระบบแบบ Big Tech ได้ ต้องพึ่งการทดลอง ablation สั้น ๆ จำนวนไม่มากและ Yolo run ซึ่งท้ายที่สุดทำให้สร้าง Reka Flash 21B และโมเดล edge 7B ได้
การสร้างโครงสร้างพื้นฐานการฝึกจากศูนย์
- ระหว่างฝึก โมเดลภาษามัลติโมดัลที่แข็งแกร่ง Reka ได้สร้างโครงสร้างพื้นฐานใหม่ที่จำเป็นต่อการ ฝึกจากศูนย์ สำหรับโมเดลภาษาขนาดใหญ่และโมเดลมัลติโมดัล
- ความยากหลักไม่ใช่การเลือกระหว่าง TPU กับ GPU แต่คือการทำให้ได้ คุณภาพการปฏิบัติการ ที่เพียงพอสำหรับรันการฝึกจริงอย่างเสถียรบนโครงสร้างพื้นฐานและสภาพแวดล้อมโค้ดภายนอก
ลอตเตอรี่ฮาร์ดแวร์ในยุค LLM
- เงื่อนไขแรกของการฝึกโมเดลคือการหา compute ให้ได้ แต่ในทางปฏิบัติ ความแปรปรวนของคุณภาพผู้ให้บริการ คลัสเตอร์ และการเชื่อมต่อ accelerator กลายเป็นตัวแปรที่ใหญ่ที่สุด
- แม้จะเป็น GPU H100 รุ่นเดียวกัน คุณภาพโดยรวมของคลัสเตอร์ก็แตกต่างกันมาก และฮาร์ดแวร์ในที่นี้ใกล้เคียงกับ คุณภาพของทั้งคลัสเตอร์ มากกว่าชิปเพียงอย่างเดียว
- Reka เช่าคลัสเตอร์ขนาดตั้งแต่หลายร้อยถึงหลายพันชิปจากผู้ให้บริการ compute หลายราย โดยสภาพมีตั้งแต่ระดับที่แก้ไขได้ค่อนข้างง่าย ไปจนถึงระดับที่ล้มเหลวทุกไม่กี่ชั่วโมง
- บางคลัสเตอร์มีโหนดล้มเหลวเป็นรอบสั้น ๆ เพราะปัญหาการเดินสายหรือข้อผิดพลาดของฮาร์ดแวร์ GPU
- แม้แต่คลัสเตอร์จากผู้ให้บริการรายเดียวกัน ความทนทานก็แตกต่างกันมาก
- ต่อให้มีโหนดที่เสถียร หาก I/O และไฟล์ซิสเต็มแย่ การบันทึก checkpoint อาจ timeout หรืออัตราการใช้งานคลัสเตอร์อาจลดลงอย่างมาก
- แหล่ง compute บางแห่งต้องใช้เลเยอร์ซอฟต์แวร์ที่ต่างไปโดยสิ้นเชิงเพื่อให้รันได้ ทำให้ทีมที่นำ codebase ของตัวเองไปใช้ต้องแบก ต้นทุนการย้ายระบบ เพิ่มเติม
- เป็นเรื่องยากที่จะรู้ล่วงหน้าว่าจะได้ฮาร์ดแวร์แบบใด และประสบการณ์ที่ได้จะทนทานและรองรับความขัดข้องได้มากแค่ไหน
- หากผู้ให้บริการส่งมอบไม่ทันเวลา อาจล่าช้าเป็นเดือน ๆ และอาจเกิดสถานการณ์ที่หาไม่ได้จากแหล่งอื่นเป็นเวลาหลายสัปดาห์หรือหลายเดือนเช่นกัน
- ผู้ให้บริการบางรายเผลอลบ checkpoint ด้วย
เครื่องมือภายในสำหรับ MFU และการรับมือกับความขัดข้อง
- Model Flop Utilisation(MFU) แตกต่างกันไปในแต่ละคลัสเตอร์ และเมื่อเจอโหนดที่เดินสายผิดหรือปัญหาจากผู้ให้บริการ compute จำนวนไม่น้อยก็สูญเปล่า
- ในสภาพแวดล้อมที่ไฟล์ซิสเต็มไร้ประสิทธิภาพมาก แค่มีใครเริ่มโอนข้อมูลจำนวนมากระหว่างคลัสเตอร์ MFU ของการรันฝึกก็อาจร่วงลงอย่างหนัก
- ระดับการซัพพอร์ตจากผู้ให้บริการก็แตกต่างกันมาก
- มีตั้งแต่การซัพพอร์ตอย่างสุภาพ ไปจนถึงการตอบสนองแบบไม่ใส่ใจ
- ยังมีการตอบแบบสำเร็จรูปสไตล์ “ChatGPT” หรือการโยนความผิดทุกปัญหาให้ผู้ใช้ด้วย
- แต่ละคลัสเตอร์มีความเจ็บปวดและ failure mode เฉพาะตัว ราวกับว่าทุกคลัสเตอร์ต้องมี hotfix แยกกัน
- Reka สร้างเครื่องมือภายในหลายอย่างเพื่อทำให้เกิดสภาพแวดล้อมที่ใช้งานได้
- เครื่องมือ monitoring
- checkpoint ที่มีประสิทธิภาพ
- การปรับแต่งหลายอย่าง
- การติดตั้งไฟล์ซิสเต็มแบบกำหนดเองสำหรับ data storage ที่ขยายได้
- การผสมผสานเครื่องมือเหล่านี้ช่วยลด downtime และปรับปรุง MFU ได้อย่างมีนัยสำคัญ แม้บนฮาร์ดแวร์ที่มีคุณภาพย่ำแย่
ความแตกต่างระหว่างประสบการณ์ GPU และ TPU
- Reka ฝึกโมเดลส่วนใหญ่ด้วย GPU
- เมื่อเทียบกับประสบการณ์ที่ Google ซึ่งใช้ TPUs เป็นหลักในการฝึกโมเดลภาษาขนาดใหญ่ CUDA และ nccl เป็นสภาพแวดล้อมที่ไม่คุ้นเคย
- อัตราความขัดข้องของ GPU แตกต่างจากประสบการณ์การใช้ TPUs ที่ Google อย่างมาก
- UL2 20B ของ Google เคยรันต่อเนื่องหนึ่งเดือนโดยไม่ตั้งใจ แต่ไม่ล้มเหลว
- มองว่าถ้าเป็นสภาพแวดล้อม GPU ก็น่าจะล้มเหลวภายในไม่กี่วันแรก
- อย่างไรก็ตาม ความแตกต่างนี้อาจเกี่ยวข้องกับ ขีดความสามารถของทีมฮาร์ดแวร์ ที่ดูแล accelerator และคุณภาพการซัพพอร์ตของผู้ให้บริการ มากกว่าตัวชิปเอง
- การฝึกแบบ multi-node ในสภาพแวดล้อม GPU ให้ความรู้สึกไม่เหมือน TPU pod ที่มอง distributed training เป็นแนวคิดระดับ first-class แต่เหมือนเป็นองค์ประกอบที่ถูกเสริมเข้ามาทีหลัง
- วิธีการเดินสายที่ทำให้ฝึกแบบ multi-node ได้ดูแตกต่างกันไปตามผู้ให้บริการ และความแตกต่างนี้ทำให้ความแปรปรวนระหว่างสถานที่สูงขึ้น
ภาระของการดำเนินงานหลายคลัสเตอร์
- โครงสร้างพื้นฐานภายในของ Google เป็นสภาพแวดล้อมที่เข้าถึงได้จากทุกที่บน Borg, Xmanager, Colossus
- ในสภาพแวดล้อมภายนอก ต้องตั้งค่าสภาพแวดล้อมใหม่บนหลายคลัสเตอร์ด้วยตัวเอง ซึ่งแตกต่างจากประสบการณ์ก่อนหน้าอย่างมาก
- หากไม่ได้สร้าง pool ของ accelerator ขนาดใหญ่ไว้เองในที่เดียว ดูเหมือนหลีกเลี่ยงไม่ได้ที่จะต้องใช้ pool ของ accelerator จากหลายคลัสเตอร์
- การขาดแคลน GPU ทำให้การจัดหาเกิดขึ้นในรูปแบบ คลัสเตอร์แบบกระจาย โดยธรรมชาติ
- การฝึกโมเดลขนาดใหญ่ต้องใช้ข้อมูลระดับหลายสิบ TB การย้ายข้อมูลจึงเป็นภาระใหญ่ในตัวเอง
- ในสเกลที่ใหญ่มาก การทำสำเนาข้อมูลก็ไม่ง่ายและมีต้นทุนสูง
- รูปแบบในอุดมคติคือเลเยอร์ orchestration ที่ส่งงานไปยังหลายเซิร์ฟเวอร์ แต่สตาร์ทอัพใหม่ที่ยังคล่องตัวสูงยากที่จะมีโครงสร้างพื้นฐาน ML training ที่ซับซ้อนเช่นนี้ตั้งแต่ช่วงแรก
- Reka บรรเทาปัญหาด้วย workflow ภายในหลายอย่าง และยังคงเดินหน้าสู่โครงสร้างพื้นฐานการทดลองระดับโลก
- ได้ยินมาว่าการตั้งค่าแบบ scrappy เช่นนี้โดยทั่วไปพบได้ทั่วไปในองค์กรที่ไม่ใช่ระดับท็อปสุดหรือบริษัทใหญ่
codebase ภายนอกและการเลือก PyTorch
- codebase ที่ชอบคือ T5X และ Mesh Tensorflow แต่ที่ Reka ไม่ใช่ตัวเลือกที่เป็นจริงได้
- มีการซัพพอร์ตนอก Google ไม่มาก
- อยู่ในสถานะ deprecated พอสมควร
- ไม่เป็นมิตรกับคนในทีมที่ไม่ได้มาจาก Google
- Reka เลือก PyTorch ซึ่งใกล้เคียง vanilla มากกว่า ดูเสถียร และใช้กันแพร่หลาย
- ช่วงแรกต้องปรับตัวกับสภาพแวดล้อมพัฒนาภายนอกอย่าง pip, git, docker
- เป็นไปได้ว่า codebase ของ Google อาจใช้งานนอกองค์กรให้เสถียรและเป็นมิตรต่อผู้ใช้ได้ยาก
- รู้สึกว่าคุณภาพ codebase ภายนอกตามหลัง codebase ที่คุ้นเคยใน Google อยู่มาก
- มองว่า codebase ภายใน Google มักเขียนโดยนักวิจัย ML อย่าง Noam Shazeer, Barret Zoph, Adam Roberts, Hyung Won Chung โดยตรง
- ในบรรดาโค้ดที่บริษัทอื่นทำ มีบางกรณีที่คุณภาพโค้ดน่าผิดหวังเป็นพิเศษ
- ในบาง codebase ต้องเขียนตัวแปลงแยกเพื่อเปลี่ยนการตั้งค่า model parallelization และไม่ได้มีการเปลี่ยน parallelization ให้อัตโนมัติ
- การซัพพอร์ตการฝึก encoder-decoder ขนาดใหญ่หรือ prefixLM training ก็ยังไม่เพียงพอ
- ว่ากันว่า flash attention ยังไม่รองรับ prefixLM training หรือก็คือ custom mask support ต่อไป แม้ใน GitHub issue จะมีความต้องการที่สมเหตุสมผล
- มีความรับรู้ว่าควรใช้ Jax แต่เพื่อให้เคลื่อนไหวได้เร็วในสตาร์ทอัพจึงเลือก PyTorch
compute จำกัดและ Yolo run
- การทำ model scaling อย่างเป็นระบบมักเป็นการรันการทดลองหลายขั้นจากโมเดลเล็กไปหาใหญ่ เช่น 1B → 8B → 64B → 300B แล้วเลือกผู้ชนะมาขยายต่อ
- ในสตาร์ทอัพ มี compute น้อยกว่ามากสำหรับทำ sweep ขนาดใหญ่เพื่อตรวจสอบ hyperparameter
- Reka พึ่งพา Yolo run จำนวนมาก และมองว่าท้ายที่สุดออกมาดี
- ด้วยการทดลอง ablation ที่เล็กกว่าและสั้นกว่าเพียงไม่กี่ครั้ง ก็สามารถไปถึง Reka Flash 21B ที่แข็งแกร่ง โมเดล edge 7B และโมเดล core ที่ใหญ่ที่สุดที่กำลังจะมาได้
- การหา recipe ที่ดีด้วยจำนวนรันจำกัดเป็นเรื่องยาก และ search space กว้างมากจนต้องเปลี่ยนตัวแปรจำนวนมากในครั้งเดียว
- แทนที่จะใช้ความเป็นระบบแบบ Big Tech ต้องพึ่ง Yolo, ความรู้สึก และสัญชาตญาณอย่างมาก
- สัญชาตญาณที่สมาชิกทีมสะสมจากเส้นทางอาชีพ ML ก่อนหน้า ช่วยให้ปรับให้เข้าที่ได้ภายในจำนวนครั้งลองที่น้อย
- แม้จะเคยมีประสบการณ์ฝึกโมเดลที่ดีในที่ทำงานก่อนหน้า แต่ความแตกต่างด้านโครงสร้างพื้นฐานการฝึก ข้อมูล การผสานไอเดียใหม่ และปัญหาสภาพแวดล้อม อาจสร้างความแตกต่างต่อผลลัพธ์ได้ไม่น้อย
- ประสบการณ์ล่วงหน้าที่แข็งแกร่งช่วยลด search space ได้มาก และถือเป็นหนึ่งในคำอธิบายที่ง่ายว่าทำไมจึงฝึกโมเดลที่แข็งแกร่งได้ด้วยจำนวนครั้งลอง ทรัพยากร และการทดลองที่น้อย
ผลลัพธ์ในเวลาไม่ถึง 1 ปีและโจทย์ที่เหลือ
- การขาด compute และผู้ให้บริการ compute ที่ไม่เสถียรสร้างความยากลำบากมากกว่าที่คาดไว้มาก
- Reka เริ่มบริษัท ระดมทุน ซื้อชิป แล้วสร้างทุกอย่างขึ้นจากศูนย์
- ในเวลาไม่ถึง 1 ปี มีการกล่าวว่าเทียบชั้น Gemini Pro/GPT-3.5 และเหนือกว่าโมเดลจำนวนมาก
- data pipeline และ human evaluation ยังเป็นหัวข้อที่ต้องกล่าวถึงต่อไป
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ในบริบทนี้ สตาร์ทอัพดูเหมือนจะหมายถึงองค์กรที่มี คนจำนวนน้อย และมี เงินก้อนใหญ่ สำหรับใช้กับคลัสเตอร์ฝึกโมเดลในท้ายที่สุด
บทความตั้งสมมติฐานว่ามีผู้ให้เช่าเซิร์ฟเวอร์หลายราย และเซิร์ฟเวอร์เหล่านั้นถูกส่งต่อไปยังสตาร์ทอัพหรือบริษัทเดิมหลายแห่ง
สุดท้ายผู้สร้าง LLM หลายรายก็ฝึกข้อความและภาพด้วยฮาร์ดแวร์ที่คล้ายกันและข้อมูลที่คล้ายกัน ทำสิ่งเดียวกันเป็นส่วนใหญ่ และต่างพยายามสร้างความแตกต่างด้วย “สูตรลับ” ของตัวเอง
สูตรลับแบบนั้นอาจสร้างความต่างในคุณภาพผลลัพธ์ของ LLM ได้ แต่โดยรวมแล้วดูเหมือนงานซ้ำซ้อนขนาดมหึมาที่ใช้พลังงานมาก
ท้ายที่สุดแล้วจะมีเพียงสัดส่วนเล็กมากที่ประสบความสำเร็จได้พอประมาณ แต่ในแนวหน้าของความก้าวหน้าก็เป็นต้นทุนที่ต้องจ่าย
การผูกขาดที่วางแผนไว้ล่วงหน้าอาจมีประสิทธิภาพกว่า แต่โครงสร้างแบบนั้นแทบไม่ค่อยชนะตลาดในเรื่องนวัตกรรม
ผู้ก่อตั้งดูเหมือนหวังจะถูกซื้อกิจการเพียงเพราะสามารถฝึก LLM ที่ “เกือบล้ำสมัย” ได้ และความสามารถกับโครงสร้างพื้นฐานระดับนั้นก็อาจมีคุณค่าพอให้สร้างบางอย่างต่อยอดขึ้นไปได้
แต่เรื่องนั้นอธิบายให้นักลงทุนเข้าใจได้ยากกว่ามาก
ในความเป็นจริง ผมคิดว่าสตาร์ทอัพจำนวนมากกำลังจ้างนักเขียนและช่างภาพมาสร้างข้อมูลฝึกที่ไม่ปนเปื้อนและติดป้ายกำกับอย่างดีมาก
ถ้าดูฝั่ง civitai จะเห็นได้ว่าด้วยงบประมวลผลเล็กน้อย แค่การติดป้ายกำกับอย่างละเอียดก็ไปได้ไกลแค่ไหน
กรณีใช้งานส่วนใหญ่ของ LLM สามารถรองรับได้ด้วยการ fine-tune โมเดลฐาน สำเร็จรูป
ถ้าฝึกโมเดลฐานตั้งแต่แรก ก็เท่ากับเข้าไปในตลาดที่ทำเงินได้ยาก และผู้เล่นรายใหญ่แค่ออกโมเดลฐานใหม่มาหนึ่งตัว ก็อาจทำสิ่งที่โมเดลของคุณทำได้มากกว่า 95% ไปแล้ว
ตามบริบท Yi Tay เคยเป็น tech lead ของ Google PaLM, UL2, Flan, Bard ฯลฯ และตอนนี้เป็นผู้ร่วมก่อตั้ง Reka
Reka เคยปล่อยโมเดลมัลติโมดัลขนาดเล็กที่น่าสนใจ ซึ่งเคยถูกนำมาโพสต์ที่นี่ด้วย
เพราะเขาเป็นคนจาก Google ที่ไปอยู่ในสถานะฝึก LLM ในสตาร์ทอัพอิสระ จึงมีคนขอให้เขาเขียนบทความนี้: https://twitter.com/YiTayML/status/1765105066263052718
มีบันทึกเสียงการสนทนาอยู่ที่นี่: https://sub.thursdai.news/p/thursdai-feb-15-2024-openai-chan...
บทความนี้ทำให้ผมรู้จัก reka.ai และดูเหมือนใน HN ยังไม่ได้พูดถึง LLM ของ Reka กันมากนัก [1]
ด้วยความอยากรู้อยากเห็น ช่วงหนึ่งชั่วโมงที่ผ่านมา ผมลองทดสอบพรอมป์ผ่านอินเทอร์เฟซแชต [2] เทียบกับ ChatGPT 4, Gemini Advanced, Claude 3 และ Mistral Large แล้วเอาผลลัพธ์ไปโพสต์ไว้ที่ [3]
โดยรวมแล้ว Reka Flash ดูไม่ได้แย่หรือดีกว่าโมเดลอื่นอย่างชัดเจน
แน่นอนว่าถ้าจะให้เห็นชัด ต้องทดสอบมากกว่านี้อีกมาก
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
[2] https://chat.reka.ai/chat
[3] https://gally.net/temp/20240307llmcomparison.html
จุดที่ควรพูดถึงคือผู้เขียนเหมารวมไปเลยว่าผู้อ่านเข้าใจ “แดนทุรกันดาร” ว่าเป็น ที่ที่ไม่ใช่ Google
บทความนี้ยกเครดิตให้ทีมโครงสร้างพื้นฐานและฮาร์ดแวร์ของ Google ไว้มาก และผมก็อยากอ่านมุมมองของคนที่เคยอยู่ข้างในนั้นแล้วไปทำงานเกี่ยวข้องกันที่อื่นด้วย
ถ้าพูดให้แม่นกว่านั้นคือ “ตลอดอาชีพผมใช้ Google TPU ภายใน Google และคุ้นกับรูปแบบการเสียของมัน แต่ไม่รู้รูปแบบการเสียของ GPU เลย”
ตอนที่ผมใช้ GPU เป็นหลักแล้วลองใช้ TPU งานล้มเหลวซ้ำ ๆ ด้วยเหตุผลที่ดีบักยาก
เลเยอร์อ้อมระหว่างชิป x86 กับอุปกรณ์ TPU ทำให้ต้องนั่งกุมขมับเป็นชั่วโมงอยู่บ่อย ๆ และเป็นปัญหาประเภทที่ไม่เจอใน x86+NVIDIA+PyTorch
เมื่อ 10–15 ปีก่อน Google ผลิตนักวิทยาศาสตร์ข้อมูลมูลค่ากว่า 10 ล้านดอลลาร์ออกมาจำนวนมาก นั่นคือวิศวกร Sawzall และพวกเขาก็ออกไปสู่ “แดนทุรกันดาร” แล้วมีปฏิกิริยาคล้ายกัน
บทความนี้ดูเหมือนมีลักษณะโปรโมตบริษัทของผู้เขียนและ personal brand ของเขามากกว่าจะเป็นการทิ้งบันทึกที่มีประโยชน์ต่อชุมชน
ในความคิดผม แม้กับการฝึกขนาดใหญ่ก็ไม่เคยเจอ GPU เสีย
งาน batch ฝึกที่รันอยู่ตอนนี้เป็นไฟล์ JSON ขนาด 20GB ที่แค่โหลดก็ใช้เวลา 6 ชั่วโมง และรันมาเกิน 15 วันโดยไม่มีปัญหา โดยใช้ Tesla T4 ที่เก่ากว่าด้วย
GPU มีปัญหาเรื่องข้อจำกัดหน่วยความจำ แต่ถ้าวางแผนและหาทางเลี่ยงได้ จริง ๆ แล้วผมไม่เคยเห็นมัน crash เลย
ดูเป็นอุปมาที่ค่อนข้างชัดเจน และถ้าเป็นสตาร์ทอัพที่ทำโปรเจกต์โครงสร้างพื้นฐานขนาดใหญ่ ก็ต้องสร้าง ระบบโลจิสติกส์ เองเหมือนตั้งแคมป์ในแดนทุรกันดารจริง ๆ
อ่านแล้วเหมือนฉากที่ Seven of Nine หลุดออกจาก Collective แล้วตระหนักว่าต้องพึ่งพาความสามารถอันต่ำต้อยของมนุษย์
ข้อมูลเชิงลึกเกี่ยวกับซัพพลายเออร์มีประโยชน์
คงไม่ถึงกับสูญเสียความคืบหน้าในการฝึกทั้งหมดใช่ไหม ดังนั้นความเจ็บปวดหลัก ๆ คือการวินิจฉัยปัญหาและเปิดคลัสเตอร์ขึ้นมาใหม่ ส่วนเรื่องข้อมูลสูญหายไม่ต้องกังวลหรือเปล่า?
แล้ว ผลิตภัณฑ์ ที่พวกเขาขายคืออะไร?
หน้าแรกของ Reka.AI ดูเหมือนโคลน ChatGPT ทั่วไปที่คิดเงินตามจำนวนโทเคน
ไม่รู้ว่าแตกต่างจากบริษัทอื่นอย่างไร และราคาก็ดูคล้ายกับ ChatGPT 3.5-Turbo
ประเด็นเรื่องการฝึก LLM ตั้งแต่ต้นเป็นหัวข้อสำคัญมาก ซึ่งส่งผลต่อความเร็วและขอบเขตของการทำซ้ำใน AI พอ ๆ กับการปรับปรุงฮาร์ดแวร์ดิบ
บทความนี้สนุก แต่ค่อนข้างตื้น และถ้าเคยจัดการคลัสเตอร์ GPU ในรูปแบบใดรูปแบบหนึ่งมาหลายปีแล้ว ก็ไม่ได้ลึกหรือชวนประหลาดใจในเชิงเทคนิค
มุมมองของอดีต Googler นั้นดี แต่ก็ยังไม่ค่อยเข้าใจว่าทำไมอดีตเพื่อนร่วมงานถึงแนะนำ JAX มากกว่า PyTorch เมื่อต้องทำ LLM นอก Google
หวังว่าสตาร์ทอัพนี้จะออกรายงานเชิงเทคนิคมากขึ้นเกี่ยวกับเส้นทางการฝึกโมเดลในภายหลัง เช่น PDF นี้: https://github.com/facebookresearch/metaseq/tree/main/projec...
อคติแบบ Google ก็น่าจะปนอยู่ด้วย
คำถามใหญ่คือ สตาร์ทอัพขนาดเล็กที่ไม่มี ภูมิหลังและสายเลือดที่ถูกต้อง จะระดมทุนด้วยผลิตภัณฑ์ LLM ได้อย่างไร
โลกของสตาร์ทอัพ LLM กำลังเริ่มคล้ายโลกของเฮดจ์ฟันด์และไพรเวตอิควิตี้
เงื่อนไขตั้งต้นของการลงทุนรอบ seed และการระดมทุนดูเหมือนจะเป็น A) ประวัติการทำงานจากสถาบันชั้นนำและสายเลือดที่ถูกต้อง, B) เครือข่ายนักลงทุนที่แข็งแกร่งซึ่งพร้อมกระโจนเข้ามาก่อนที่ผลิตภัณฑ์จะเริ่มด้วยซ้ำ
เหตุผลที่ VC ลงทุนในบริษัทแบบนี้ก็น่าจะเป็นเพราะอย่างนั้น
คนทั่วโลกที่มีประสบการณ์ที่ถูกต้องพอจะระดมทุนได้นั้นมีจำกัดมาก และมีแต่คนที่ระดมทุนได้เท่านั้นจึงจะสะสมประสบการณ์แบบนั้นได้ จึงเกิด กำแพงกีดกันการเข้าสู่ตลาด ขึ้นตามธรรมชาติ
อย่างน้อยก็น่าจะเป็นเช่นนั้นจนกว่าต้นทุนการคำนวณจะถูกลงพอ
จากประโยคที่ว่า “ตั้งบริษัท หาเงิน ซื้อชิป และสร้างทุกอย่างตั้งแต่ต้นภายในไม่ถึงหนึ่งปี พร้อมทั้งทัดเทียม Gemini Pro/GPT 3.5 และเหนือกว่าโมเดลจำนวนมาก” ก็สงสัยว่างบประมาณที่ใช้ไปกับชิปหรือ GPU บนคลาวด์เพื่อไปถึง LLM ระดับ GPT 3.5 นั้นอยู่ระดับไหน
ถ้าประเมินคร่าว ๆ ตามหลักจำนวนหลัก อาจเป็นราว 2–5 ล้านดอลลาร์ หรือเปล่า?
รู้สึกว่าชื่อเรื่องควรเป็น “from the ground up” มากกว่า “ground zero” หรือเปล่า: https://en.wikipedia.org/wiki/Hypocenter
ในฐานะสำนวน ถือว่าเป็นการใช้ที่ยอมรับได้โดยสิ้นเชิง
อาจหมายความว่า LLM เป็น ระเบิดนิวเคลียร์ เชิงเปรียบเทียบต่อวงการเทคโนโลยี แต่พูดตรง ๆ ผมเองก็สับสนเหมือนกัน
ผมคงไม่อยากเรียนรู้จากผู้เขียนประเภทนั้น
เหตุผลที่ระบบของ Google เสถียรคือ Google ลงทุน หลายหมื่นล้านดอลลาร์ ตลอด 25 ปีไปกับการพัฒนาฮาร์ดแวร์ดาต้าเซ็นเตอร์ ซอฟต์แวร์ และกระบวนการ
แม้แต่ทีมที่มีความสามารถสูงมากในองค์กรที่เล็กกว่าและยังเติบโตไม่เต็มที่ ก็ย่อมต้องให้ผลลัพธ์ที่คุณภาพต่ำกว่ามากเสมอ
อีกอย่างที่ต้องพิจารณาคือลำดับความสำคัญ
Google ให้ความสำคัญกับเสถียรภาพ และจะปลดระวางชิ้นส่วนที่ล้มเหลวซ้ำ ๆ แม้ความเสียหายนั้นจะเกิดขึ้นค่อนข้างน้อย
ดาต้าเซ็นเตอร์ที่เล็กกว่าและซับซ้อนน้อยกว่าอาจยังใช้ชิ้นส่วนที่เสียบ่อยต่อไป หรือแม้แต่ไม่ติดตามอัตราความเสียหายของชิ้นส่วนบางชนิดเลย
ดาต้าเซ็นเตอร์ขนาดเล็กยังอาจซื้อชิ้นส่วนเก่าและชิ้นส่วนที่ความน่าเชื่อถือต่ำของ Google มาใช้ด้วย
ดังนั้นการที่เครื่องไม่เสถียรไม่ได้บอกถึงความสามารถของทีมฮาร์ดแวร์เสมอไป
หากความเสถียรต่ำของฮาร์ดแวร์ทำให้งานช้าลง ก็แค่ปรับปรุงซอฟต์แวร์ให้ทนต่อฮาร์ดแวร์ที่ไม่เสถียรได้ หรือย้ายไปใช้ผู้ให้บริการฮาร์ดแวร์ที่เสถียรกว่าและแพงกว่า