08 ส.ค. 2568·3 นาที
Jeff Dean: วิศวกรที่ช่วยปรับขนาด AI ให้กับ Google
มุมมองเชิงปฏิบัติของอาชีพ Jeff Dean และระบบที่ช่วยให้ Google ปรับขนาด AI ได้ — MapReduce, Bigtable และบทเรียนโครงสร้างพื้นฐาน ML สมัยใหม่
มุมมองเชิงปฏิบัติของอาชีพ Jeff Dean และระบบที่ช่วยให้ Google ปรับขนาด AI ได้ — MapReduce, Bigtable และบทเรียนโครงสร้างพื้นฐาน ML สมัยใหม่
Jeff Dean สำคัญกับ AI ด้วยเหตุผลง่าย ๆ: แนวคิด "ก้าวหน้า" หลายอย่างที่คนเชื่อมโยงกับการเรียนรู้ของเครื่องสมัยใหม่จะมีประโยชน์ก็ต่อเมื่อสามารถรันได้อย่างเชื่อถือ ทำซ้ำได้ และคุ้มค่าบนข้อมูลจำนวนมหาศาล งานที่มีอิทธิพลมากของเขาส่วนใหญ่อยู่ในช่องว่างระหว่างไอเดียที่มีศักยภาพกับระบบที่สามารถให้บริการผู้ใช้เป็นล้านคนได้จริง
เมื่อทีมพูดว่าอยาก "ปรับขนาด AI" พวกเขามักจะต้องถ่วงหลายข้อจำกัดพร้อมกัน:
AI ในระดับสเกลไม่ใช่เรื่องของโมเดลตัวเดียว แต่เป็นสายการผลิต: พายไลน์ การจัดเก็บ การรันแบบกระจาย การมอนิเตอร์ และอินเทอร์เฟซที่ชัดเจนซึ่งให้ทีมหลายทีมสร้างได้โดยไม่ชนกัน
นี่ไม่ใช่โปรไฟล์คนดังหรือการอ้างว่าคนเดียว "คิดค้น" AI ของ Google ความสำเร็จของ Google เกิดจากกลุ่มวิศวกรและนักวิจัยขนาดใหญ่ หลายโครงการเขียนและสร้างร่วมกัน
บทความนี้มุ่งที่ รูปแบบวิศวกรรม ที่ปรากฏในระบบที่รายงานกันมากซึ่ง Jeff Dean มีส่วนสร้างหรือผลักดัน—MapReduce, Bigtable และงานโครงสร้างพื้นฐาน ML ยุคหลัง เป้าหมายคือสกัดไอเดียที่ใช้ได้จริง: วิธีออกแบบให้รับความล้มเหลวได้ วิธีทำให้เวิร์กโฟลว์เป็นมาตรฐาน และวิธีทำให้การทดลองเป็นเรื่องปกติแทนที่จะเป็นวีรบุรุษ
ถ้าคุณสนใจการส่งมอบ ML ที่อยู่รอดต่อทราฟิกจริงและข้อจำกัดจริง มุมมองเชิงระบบคือเรื่องราว—และเส้นทางอาชีพของ Jeff Dean เป็นด้ายที่ติดตามได้ดี
Jeff Dean เข้าร่วม Google ในช่วงที่ยังนิยามคำว่า "โปรดักชัน" บนอินเทอร์เน็ตเปิด: บริการจำนวนน้อย ผู้ใช้โตเร็ว และคาดหวังว่าผลลัพธ์การค้นหาต้องปรากฏทันที—ทุกครั้ง
Google ยุคค้นหาต้องเผชิญข้อจำกัดที่ทีมสเกลใด ๆ จะคุ้นเคย:
สิ่งนี้ผลักดันแนวคิดที่เป็นปฏิบัติ: สมมติว่าความล้มเหลวจะเกิดขึ้น ออกแบบการกู้คืน และทำให้ประสิทธิภาพใช้งานได้ในระดับระบบ—ไม่ใช่การปรับทีละเครื่อง
เพราะการค้นหาสัมผัสเครื่องหลายเครื่องต่อคำค้น เล็กน้อยผิดพลาดจะทบต้นอย่างรวดเร็ว ความกดดันนั้นชอบรูปแบบที่:
แม้ Google จะขยายไปสู่การประมวลผลข้อมูลขนาดใหญ่และ ML ลำดับความสำคัญเหล่านี้ก็ยังคงอยู่: ประสิทธิภาพที่คาดการณ์ได้ ความปลอดภัยเชิงปฏิบัติการ และการออกแบบที่ทนต่อการขัดข้องเป็นบางส่วน
ธีมซ้ำ ๆ ที่เกี่ยวโยงกับผลกระทบของ Dean คือเลเวอเรจ แทนจะแก้ปัญหาการสเกลใหม่ทุกครั้ง Google ลงทุนในบล็อกก่อสร้างภายใน—ระบบที่ใช้ร่วมกันซึ่งให้ทีมหลายทีมส่งงานได้เร็วขึ้นโดยมีผู้เชี่ยวชาญน้อยลง
แนวคิดแพลตฟอร์มนี้มีความสำคัญเมื่อคุณมีหลายสิบ (แล้วเป็นร้อย) ทีม ไม่เพียงแต่ทำให้ระบบเดียวเร็วขึ้น แต่ทำให้องค์กรทั้งองค์กรสามารถสร้างระบบเร็วขึ้นโดยไม่ต้องคิดพื้นฐานใหม่ทุกครั้ง
เมื่อเวิร์กโหลดใหญ่กว่าหนึ่งเครื่องคอขวดแรกไม่ใช่ "CPU เพิ่ม" แต่เป็นช่องว่างที่กำลังเติบโตระหว่างสิ่งที่คุณต้องการคำนวณกับสิ่งที่ระบบสามารถประสานงานได้อย่างปลอดภัย การฝึกและการให้บริการระบบ AI กดดันทุกอย่างพร้อมกัน: คอมพิวต์ (เวลา GPU/TPU), ข้อมูล (แบนด์วิดท์และการจัดเก็บ), และความน่าเชื่อถือ (จะเกิดอะไรเมื่อบางอย่างล้มเหลว)
เครื่องเซิร์ฟเวอร์เดียวล้มเป็นเรื่องไม่สะดวก แต่ในฟลีทมันเป็นเรื่องปกติ เมื่อจ็อบกระจายไปยังหลายร้อยหรือหลายพันเครื่อง คุณจะเจอจุดเจ็บปวดที่ทายได้: stragglers (งานช้าที่ทำให้ทุกอย่างติด), การหนาแน่นของเครือข่าย, การอ่านข้อมูลไม่สอดคล้อง, และ retry ที่ลุกลามปัญหาเดิม
Sharding แยกข้อมูลและงานให้เป็นชิ้นจัดการได้เพื่อไม่ให้เครื่องเดียวเป็นคอขวด
Replication เก็บสำเนาหลายชุดเพื่อให้ความล้มเหลวไม่กลายเป็น downtime หรือการสูญหายของข้อมูล
Fault tolerance สมมติการล้มเหลวบางส่วนและออกแบบการกู้คืน: รีสตาร์ทงาน มอบหมายชาร์ดใหม่ ตรวจสอบผล
Backpressure ป้องกันการล้นโดยการชะลอผู้ผลิตเมื่อผู้บริโภคตามไม่ทัน—สำคัญสำหรับคิว พายไลน์ และอินพุตการฝึก
ที่สเกล แพลตฟอร์มที่ทีมหลายทีมใช้ได้ถูกต้องมีค่ามากกว่าระบบประสิทธิภาพสูงเฉพาะทางที่มีแต่ผู้สร้างเท่านั้นที่จะใช้งานได้ ค่าเริ่มต้นที่ชัดเจน API ที่สอดคล้อง และโหมดล้มเหลวที่คาดเดาได้ลดความซับซ้อนที่เกิดจากความบังเอิญ—โดยเฉพาะเมื่อผู้ใช้เป็นนักวิจัยที่วนรอบเร็ว
คุณแทบจะไม่สามารถเพิ่มทั้งสามพร้อมกัน การแคชหนักและการประมวลผลแบบอะซิงโครนัสเพิ่มประสิทธิภาพแต่ทำให้ความถูกต้องซับซ้อน ความสม่ำเสมอและการตรวจสอบเข้มงวดเพิ่มความถูกต้องแต่ลดปริมาณงานได้ การปฏิบัติการ—การดีบัก เมตริก การปล่อยอย่างปลอดภัย—มักตัดสินว่าสระบบจะอยู่รอดเมื่อต้องเผชิญกับโปรดักชันหรือไม่
ความตึงเช่นนี้หล่อหลอมโครงสร้างพื้นฐานที่ Jeff Dean ช่วยผลักดัน: ระบบที่สร้างขึ้นเพื่อสเกลไม่ใช่แค่การคำนวณ แต่รวมถึงความน่าเชื่อถือและการใช้งานของมนุษย์ด้วย
MapReduce เป็นไอเดียเรียบง่ายที่มีผลกระทบมาก: แบ่งงานข้อมูลใหญ่เป็นงานเล็กจำนวนมาก ("map"), รันขนานข้ามคลัสเตอร์ แล้วรวมผลย่อย ("reduce"). ถ้าคุณเคยนับคำจากเอกสารล้านฉบับ จัดกลุ่มล็อกตามผู้ใช้ หรือสร้างดัชนีการค้นหา คุณก็ทำ MapReduce ในหัวแล้ว—แค่อาจไม่ถึงสเกลของ Google
ก่อน MapReduce การประมวลผลชุดข้อมูลขนาดอินเทอร์เน็ตมักหมายถึงโค้ดกระจายเฉพาะทาง โค้ดนั้นเขียนยาก ดูแลยาก และง่ายที่จะผิดพลาด
MapReduce สมมติบางอย่างสำคัญ: เครื่องจะล้ม ไดรฟ์จะตาย เครือข่ายจะสะดุด แทนที่จะถือว่าการล้มเหลวเป็นข้อยกเว้น ระบบถือว่ามันเป็นเรื่องปกติ งานสามารถรันซ้ำได้โดยอัตโนมัติ ผลลัพธ์ระหว่างทางสร้างใหม่ได้ และงานโดยรวมยังจบได้โดยไม่ต้องมีคนคอยดูทุกการชน
มุมมองแบบ "สมมติความล้มเหลวก่อน" มีความหมายกับ ML ภายหลังเพราะพายไลน์การฝึกขนาดใหญ่อาศัยส่วนประกอบเดียวกัน—ชุดข้อมูลมหาศาล หลายเครื่อง งานรันยาว
MapReduce ไม่เพียงแต่เร่งการคำนวณ มันยังทำให้เป็นมาตรฐาน
ทีมสามารถนิยามการประมวลผลข้อมูลเป็นงานที่ทำซ้ำได้ รันบนโครงสร้างพื้นฐานร่วม และคาดหวังพฤติกรรมที่สม่ำเสมอ แทนที่แต่ละกลุ่มจะคิดสคริปต์คลัสเตอร์ มอนิเตอร์ และตรรกะ retry ของตัวเอง พวกเขาพึ่งพาแพลตฟอร์มร่วม ซึ่งทำให้การทดลองเร็วขึ้น (รันงานใหม่ด้วยฟิลเตอร์ต่าง ๆ) ผลลัพธ์ทำซ้ำได้ง่ายขึ้น และลดปัจจัย "วิศวกรฮีโร่"
มันยังช่วยให้ข้อมูลกลายเป็นผลิตภัณฑ์: เมื่องานพายไลน์เชื่อถือได้ คุณสามารถตารางเวลามัน เวอร์ชันมัน และส่งผลลัพธ์ต่อระบบดาวน์สตรีมอย่างมั่นใจ
หลายองค์กรตอนนี้ใช้ระบบอย่าง Spark, Flink, Beam หรือเครื่องมือ ETL บนคลาวด์ ซึ่งยืดหยุ่นกว่า (สตรีมมิ่ง การคิวรีแบบ interactive) แต่บทเรียนแก่นกลางของ MapReduce ยังใช้ได้: ให้การขนานเป็นค่าเริ่มต้น ออกแบบสำหรับ retry และลงทุนในเครื่องมือพายไลน์ร่วมเพื่อให้ทีมมุ่งที่คุณภาพข้อมูลและการสร้างแบบจำลอง—ไม่ใช่การอยู่รอดของคลัสเตอร์
ความก้าวหน้าของ ML ไม่ได้ขึ้นกับโมเดลที่ดีกว่าเท่านั้น แต่ขึ้นกับการนำข้อมูลที่ถูกต้องไปยังงานที่ถูกต้องในสเกลที่ถูกต้อง ที่ Google แนวคิดเชิงระบบที่ Dean ช่วยเสริมยกระดับการจัดเก็บจาก "ท่อหลังบ้าน" ให้เป็นส่วนสำคัญของเรื่องราว ML และการวิเคราะห์ Bigtable กลายเป็นหนึ่งในบล็อกก่อสร้างหลัก: ระบบจัดเก็บที่ออกแบบมาสำหรับ throughput มหาศาล latency ที่คาดการณ์ได้ และการควบคุมเชิงปฏิบัติการ
Bigtable เป็น wide-column store: แทนที่จะคิดเป็นแถวและชุดคอลัมน์คงที่ คุณสามารถเก็บข้อมูลที่กระจัดกระจายและเปลี่ยนแปลงได้ โดยที่แถวต่าง ๆ มี "รูปแบบ" แตกต่างกัน ข้อมูลจะแบ่งเป็น tablets (ช่วงของแถว) ซึ่งสามารถย้ายข้ามเซิร์ฟเวอร์เพื่อถ่วงน้ำหนักโหลด
โครงสร้างนี้เข้ากับรูปแบบการเข้าถึงขนาดใหญ่ที่พบบ่อย:
การออกแบบสตอเรจมีอิทธิพลเงียบ ๆ ต่อฟีเจอร์ที่ทีมสร้างและความน่าเชื่อถือของการฝึก
ถ้าสโตร์ของคุณรองรับการสแกนช่วงและข้อมูลที่มีเวอร์ชันได้อย่างมีประสิทธิภาพ คุณสามารถสร้างชุดฝึกใหม่สำหรับช่วงเวลาเฉพาะ หรือทำซ้ำการทดลองจากเดือนที่แล้วได้ ถ้าการอ่านช้า หรือไม่สม่ำเสมอ การสร้างฟีเจอร์จะเปราะบาง และทีมจะเริ่ม "สุ่มรอบ ๆ" ปัญหา—นำไปสู่ชุดข้อมูลที่มีอคติและพฤติกรรมโมเดลที่ยากจะดีบัก
การเข้าถึงสไตล์ Bigtable ยังส่งเสริมแนวทางปฏิบัติ: เขียนสัญญาณดิบครั้งเดียว แล้วสกัดมุมมองฟีเจอร์หลายแบบโดยไม่ต้องทำซ้ำข้อมูลในฐานข้อมูลเฉพาะกิจ
ที่สเกล การล้มเหลวของสตอเรจไม่ได้ดูเหมือนเหตุการณ์ใหญ่ครั้งเดียว แต่เหมือนแรงเสียดทานเล็ก ๆ ที่เกิดขึ้นตลอดเวลา บทเรียนคลาสสิกของ Bigtable แปลงตรงไปยังโครงสร้างพื้นฐาน ML:
เมื่อการเข้าถึงข้อมูลคาดการณ์ได้ การฝึกก็เป็นเรื่องคาดเดาได้—และนั่นคือสิ่งที่เปลี่ยน ML จากความพยายามด้านวิจัยเป็นความสามารถของผลิตภัณฑ์
การฝึกโมเดลบนเครื่องเดียวเป็นคำถามว่า "กล่องนี้คำนวณได้เร็วแค่ไหน?" การฝึกข้ามหลายเครื่องก่อให้เกิดคำถามยากกว่า: "เราทำอย่างไรให้คนงานหลายสิบหรือหลายพันคนทำงานเหมือนเป็นการรันการฝึกเดียวนึง?" ช่องว่างนี้ทำให้การฝึกแบบกระจายมักซับซ้อนกว่าการประมวลผลข้อมูลแบบกระจาย
กับระบบเช่น MapReduce งานสามารถรันซ้ำและคำนวณใหม่ได้เพราะผลลัพธ์เป็น deterministic: รันอินพุตเดิมจะได้ผลเดิม การฝึกเครือข่ายประสาทเป็นแบบ iterative และมีสเตท ทุกขั้นตอนอัพเดตพารามิเตอร์ร่วม ความต่างเล็ก ๆ ในจังหวะเวลาอาจเปลี่ยนเส้นทางการเรียนรู้ คุณไม่ได้แค่แบ่งงาน แต่ต้องประสานวัตถุที่กำลังเคลื่อนไหว
ปัญหาบางอย่างที่เจอทันทีเมื่อขยายการฝึก:
ภายใน Google งานที่เกี่ยวข้องกับ Jeff Dean ช่วยผลักดันระบบอย่าง DistBelief จากไอเดียวิจัยไปสู่สิ่งที่รันซ้ำได้บนฟลีทจริงด้วยผลลัพธ์ที่คาดเดาได้ การเปลี่ยนแปลงสำคัญคือการปฏิบัติการฝึกเป็นเวิร์กโหลดโปรดักชัน: ความอดทนต่อความผิดพลาดชัดเจน เมตริกประสิทธิภาพชัดเจน และอัตโนมัติรอบการจัดตารางและมอนิเตอร์
สิ่งที่โอนย้ายได้ไม่ใช่สถาปัตยกรรมตรง ๆ แต่เป็นวินัย:
เมื่อ Google Brain ย้าย ML จากโครงการวิจัยไม่กี่ชิ้นไปสู่สิ่งที่หลายทีมผลิตภัณฑ์ต้องการ คอขวดไม่ได้อยู่ที่โมเดลที่ดีกว่าแต่เพียงอย่างเดียว แต่คือการประสานงาน แพลตฟอร์ม ML ร่วมลดแรงเสียดทานโดยเปลี่ยน "เวิร์กโฟลว์ฮีโร่" ให้เป็นทางเดินปูเรียบที่หลายร้อยวิศวกรใช้ได้อย่างปลอดภัย
หากไม่มีเครื่องมือร่วม ทุกทีมจะสร้างพื้นฐานซ้ำ: การสกัดข้อมูล สคริปต์การฝึก โค้ดการประเมิน และกาวการดีพลอย การซ้ำซ้อนนั้นสร้างคุณภาพที่ไม่สอดคล้องและทำให้ยากที่จะเปรียบเทียบผลระหว่างทีม แพลตฟอร์มศูนย์กลางทำให้ส่วนที่น่าเบื่อเป็นมาตรฐานเพื่อให้ทีมมุ่งไปที่ปัญหาที่จะแก้ ไม่ใช่เรียนรู้การฝึกแบบกระจาย การตรวจสอบข้อมูล หรือการปล่อยโปรดักชันใหม่
แพลตฟอร์ม ML ที่ใช้งานได้จริงมักครอบคลุม:
งานแพลตฟอร์มทำให้การทดลองทำซ้ำได้: การรันที่ขับเคลื่อนด้วยคอนฟิก เวอร์ชันของข้อมูลและโค้ด และการติดตามการทดลองที่บันทึกสิ่งที่เปลี่ยนและเหตุผลที่โมเดลดีขึ้น (หรือไม่) นี่น้อยกว่าการคิดค้นสถาปัตยกรรมใหม่ แต่ป้องกันไม่ให้ "เราไม่สามารถทำซ้ำชัยชนะเมื่อสัปดาห์ที่แล้ว" กลายเป็นเรื่องปกติ
โครงสร้างพื้นฐานที่ดีกว่าไม่สร้างโมเดลที่ฉลาดขึ้นเอง แต่ยกฐานคุณภาพให้สูงขึ้น ข้อมูลสะอาด ฟีเจอร์สอดคล้อง การประเมินที่เชื่อถือได้ และการดีพลอยที่ปลอดภัย ลดข้อผิดพลาดที่ซ่อนอยู่ เมื่อเวลาผ่านไป นั่นหมายถึงชัยชนะที่ปลอมลดลง วงรอบเร็วขึ้น และโมเดลที่ทำงานคาดเดาได้ใน production
ถ้าคุณสร้าง "ทางเดินปูเรียบ" แบบนี้ในองค์กรเล็ก ๆ กุญแจยังคงเหมือนเดิม: ลดต้นทุนการประสานงาน หนึ่งวิธีปฏิบัติที่ได้ผลคือการมาตรฐานวิธีที่แอป บริการ และเวิร์กโฟลว์ที่รองรับข้อมูลถูกสร้างขึ้น เช่น Koder.ai เป็นแพลตฟอร์ม vibe-coding ที่ให้ทีมสร้างเว็บ เบ็กเอนด์ และแอปมือถือผ่านการแชท (React บนเว็บ, Go + PostgreSQL บนแบ็กเอนด์, Flutter บนมือถือ). เมื่อใช้ด้วยเหตุผล เครื่องมือนี้สามารถเร่งการสร้างโครงร่างและเครื่องมือภายในรอบ ML — คอนโซลแอดมิน แอปตรวจสอบข้อมูล แดชบอร์ดการทดลอง หรือตัวห่อบริการ — พร้อมทั้งยังคงการส่งออกซอร์สโค้ด การดีพลอย และการย้อนกลับเมื่อคุณต้องการการควบคุมโปรดักชัน
TensorFlow เป็นตัวอย่างว่าบริษัทจะเกิดอะไรขึ้นเมื่อหยุดมองโค้ด ML เป็นชุดโครงการวิจัยครั้งเดียว แล้วเริ่มแพ็กเกจมันเหมือนโครงสร้างพื้นฐาน แทนที่แต่ละทีมจะคิดใหม่ทุกขั้นตอน แพลตฟอร์มร่วมสามารถทำให้ "วิธีปฏิบัติดีฟอลต์" เร็วขึ้น ปลอดภัยขึ้น และง่ายต่อการบำรุงรักษา
ภายใน Google ความท้าทายไม่ได้มีแค่การฝึกโมเดลใหญ่ขึ้น แต่คือการช่วยให้หลายทีมฝึกและส่งโมเดลอย่างสอดคล้อง TensorFlow เปลี่ยนชุดปฏิบัติการภายในเป็นเวิร์กโฟลว์ที่ทำซ้ำได้: นิยามโมเดล รันบนฮาร์ดแวร์ต่าง ๆ กระจายการฝึกเมื่อจำเป็น และส่งออกไปยังระบบโปรดักชัน
การแพ็กเกจเช่นนี้ลดต้นทุนการประสานงาน: เมื่อทีมแชร์ primitive เดียวกัน จะมีเครื่องมือแบบเฉพาะตัวน้อยลง สมมติฐานที่ซ่อนน้อยลง และคอมโพเนนต์นำกลับมาใช้ได้ (เมตริก การประมวลผลอินพุต ฟอร์แมตการให้บริการโมเดล)
TensorFlow ยุคแรกพึ่งพากราฟการคำนวณ: คุณอธิบายสิ่งที่จะคำนวณ แล้วระบบตัดสินใจวิธีรันให้มีประสิทธิภาพ การแยกเช่นนี้ทำให้ง่ายขึ้นที่จะเป้าหมาย CPU, GPU และตัวเร่งเฉพาะทางโดยไม่ต้องเขียนโมเดลใหม่ทั้งหมด
ความพกพาเป็นพลังเงียบ โมเดลที่ย้ายข้ามสภาพแวดล้อม—โน้ตบุ๊กวิจัย คลัสเตอร์ขนาดใหญ่ บริการโปรดักชัน—ลดภาษี "ใช้งานที่นี่ แต่พังที่นั่น" ที่ชะลอทีม
แม้บริษัทของคุณจะไม่เปิดซอร์สอะไรเลย การยอมรับแนวคิด "เครื่องมือเปิด" ก็ช่วยได้: API ชัดเจน ข้อตกลงร่วม การรับประกันความเข้ากันได้ และเอกสารที่คิดถึงผู้ใช้ใหม่ การมาตรฐานเร่งความเร็วเพราะการออนบอร์ดดีขึ้นและการดีบักคาดเดาได้มากขึ้น
ง่ายที่จะอ้างเกินจริงว่าใคร "คิดค้น" อะไร บทเรียนที่นำไปใช้ได้ไม่ใช่นวัตกรรมใหม่ แต่เป็นผลกระทบ: เลือกนามธรรมหลักไม่กี่อย่าง ทำให้ใช้ได้กว้าง และลงทุนให้เส้นทางมาตรฐานเป็นเส้นทางที่ง่ายที่สุด
ดีปเลิร์นนิงไม่ได้แค่ต้องการ "เซิร์ฟเวอร์เพิ่ม" แต่มันต้องการคอมพิวเตอร์ชนิดต่างออกไป เมื่อขนาดโมเดลและชุดข้อมูลโตขึ้น CPU ทั่วไปกลายเป็นคอขวด—ยืดหยุ่นดีแต่ไม่เหมาะกับพีชคณิตเชิงเส้นหนาแน่นที่หัวใจของเครือข่ายประสาท
GPU พิสูจน์ว่า ชิปขนานมหาศาลสามารถฝึกโมเดลได้เร็วขึ้นต่อเงินมากกว่า CPU การเปลี่ยนแปลงทางวัฒนธรรมที่ใหญ่กว่าคือ: การฝึกกลายเป็นสิ่งที่ต้องออกแบบ (แบนด์วิดท์หน่วยความจำ ขนาดแบตช์ ยุทธศาสตร์ขนาน) ไม่ใช่แค่รันแล้วรอ
TPU ไปไกลกว่านั้นโดยปรับฮาร์ดแวร์รอบ ๆ การดำเนินการ ML ที่พบบ่อย ผลลัพธ์ไม่ใช่แค่ความเร็ว แต่คือความคาดเดาได้ เมื่อเวลาฝึกลดจากสัปดาห์เป็นวัน (หรือชั่วโมง) วงรอบการทดลองจะกระชับและงานวิจัยเริ่มดูเหมือนโปรดักชัน
ฮาร์ดแวร์เฉพาะทางมีค่าเมื่อสแตกซอฟต์แวร์สามารถทำให้มันทำงานเต็มเวลา นั่นคือเหตุผลที่คอมไพเลอร์ เคอร์เนล และการจัดตารางมีความหมาย:
กล่าวคือ: โมเดล runtime และชิปคือเรื่องเดียวของประสิทธิภาพ
ที่สเกล คำถามคือ throughput ต่อวัตต์และการใช้ประโยชน์ต่อชั่วโมงของตัวเร่ง ทีมเริ่มปรับขนาดงาน จัดแพ็กโหลด และเลือกการตั้งค่าความแม่นยำ/การขนานที่ได้คุณภาพที่ต้องการโดยไม่เสียพลังงานเปล่า
การรันฟลีทตัวเร่งยังต้องการการวางแผนความจุและวิศวกรรมความน่าเชื่อถือ: จัดการอุปกรณ์ที่มีจำกัด จัดการการถูกยึด มอนิเตอร์ความล้มเหลว และออกแบบการฝึกให้กู้คืนได้อย่างนิ่มนวลแทนการเริ่มต้นใหม่ทั้งหมด
อิทธิพลของ Jeff Dean ที่ Google ไม่ได้อยู่แค่การเขียนโค้ดเร็ว แต่คือการกำหนดวิธีที่ทีมตัดสินใจเมื่อระบบใหญ่เกินกว่าที่คนคนเดียวจะเข้าใจทั้งหมด
ที่สเกล สถาปัตยกรรมไม่ได้ถูกกำหนดโดยไดอะแกรมเดียว แต่มันถูกชี้นำโดยหลักการที่ปรากฏในการรีวิวออกแบบและการตัดสินใจประจำวัน ผู้นำที่ให้รางวัลการเลือกค้าขายแบบสม่ำเสมอ—ความเรียบง่ายเหนือความฉลาด ความเป็นเจ้าของชัดเจนเหนือ "ทุกคนเป็นเจ้าของ" ความน่าเชื่อถือเหนือการเพิ่มสปีดครั้งเดียว—จะค่อย ๆ ตั้งค่าเริ่มต้นของสถาปัตยกรรมทั้งองค์กร
วัฒนธรรมการรีวิวที่เข้มแข็งเป็นส่วนหนึ่งของนั้น ไม่ใช่รีวิวแบบจับผิด แต่เป็นรีวิวที่ถามคำถามที่คาดเดาได้:
เมื่อคำถามเหล่านี้เป็นกิจวัตร ทีมจะสร้างระบบที่ง่ายต่อการปฏิบัติการและง่ายต่อการพัฒนา
การเคลื่อนไหวผู้นำที่ซ้ำ ๆ คือการมองเวลา ของคนอื่น เป็นทรัพยากรมีค่าสูงสุด คำขวัญ "ทำให้ง่ายสำหรับผู้อื่น" แปลงผลผลิตของบุคคลเป็นกำลังการผลิตขององค์กร: ค่าเริ่มต้นที่ดี ข้อผิดพลาดที่ชัดเจน ข้อความผิดที่เข้าใจง่าย และการพึ่งพาที่ซ่อนน้อยลง
นี่คือวิธีที่แพลตฟอร์มชนะภายใน ถ้าทางเดินปูเรียบเรียบจริง การยอมรับจะตามมาโดยไม่ต้องบังคับ
เอกสารออกแบบและอินเทอร์เฟซที่ชัดเจนไม่ใช่ราชการ แต่มันคือวิธีส่งต่อเจตนาในระหว่างทีมและเวลา เอกสารที่ดีทำให้ความไม่เห็นด้วยเป็นเชิงสร้างสรรค์ ("สมมติฐานไหนผิด?") และลดการทำงานซ้ำ อินเทอร์เฟซที่ดีวาดขอบเขตที่ให้ทีมหลายทีมส่งพร้อมกันโดยไม่ชนกัน
ถ้าต้องการจุดเริ่มต้นง่าย ๆ ให้ทำเทมเพลตน้ำหนักเบาสำหรับเอกสารออกแบบและรักษาความสม่ำเสมอระหว่างโครงการ (ดู /blog/design-doc-template)
การขยายคนหมายถึงการจ้างคนที่มีวิจารณญาณ ไม่ใช่แค่ความรู้เชิงเทคนิค และการสอนให้เป็นผู้มีวุฒิภาวะด้านการปฏิบัติการ: ดีบักภายใต้ความกดดัน ทำให้ระบบเรียบอย่างปลอดภัย สื่อความเสี่ยง เป้าหมายคือทีมที่สามารถรับผิดชอบโครงสร้างพื้นฐานสำคัญได้อย่างใจเย็น—เพราะทีมที่ใจเย็นทำผิดพลาดถาวรน้อยกว่า
เรื่องราวของ Jeff Dean มักถูกย่อเป็นนิทาน "วิศวกร 10x": คนคนเดียวพิมพ์เร็วกว่าคนอื่นและคิดค้นสเกลคนเดียว นั่นไม่ใช่ส่วนที่มีประโยชน์
บทเรียนที่ย้ายได้ไม่ใช่ผลผลิตดิบ แต่เป็นเลเวอเรจ งานที่มีค่ามากที่สุดคือสิ่งที่ทำให้วิศวกรคนอื่นเร็วขึ้นและระบบปลอดภัยขึ้น: อินเทอร์เฟซที่ชัดเจน เครื่องมือร่วม ลดกับดัก และการออกแบบที่ยืนได้ตามเวลา
เมื่อคนชี้ไปที่ผลผลิตระดับตำนาน พวกเขามักมองข้ามตัวคูณที่ซ่อนอยู่: ความคุ้นเคยลึกกับระบบ การจัดลำดับความสำคัญอย่างมีวินัย และอคติสู่การเปลี่ยนแปลงที่ลดงานในอนาคต
นิสัยไม่กี่อย่างปรากฏซ้ำในทีมที่สเกล:
นิสัยพวกนี้ไม่ต้องการโครงสร้างพื้นฐานขนาด Google แต่ต้องการความสม่ำเสมอ
เรื่องฮีโร่อาจซ่อนเหตุผลจริงที่สิ่งต่าง ๆ ทำงาน: การทดลองอย่างละเอียด วัฒนธรรมรีวิวที่เข้มแข็ง และระบบที่ออกแบบให้รับความล้มเหลว แทนถามว่า "ใครสร้างมัน?" ให้ถาม:
คุณไม่ต้องการฮาร์ดแวร์เฉพาะทางหรือข้อมูลระดับโลก เลือกข้อจำกัดที่มีเลเวอเรจสูงหนึ่งข้อ—การฝึกช้า พายไลน์เปราะบาง การดีพลอยที่เจ็บปวด—แล้วลงทุนในการปรับปรุงแพลตฟอร์มขนาดเล็ก: เทมเพลตงานที่มาตรฐาน แดชบอร์ดเมตริกร่วม หรือ "ทางเดินปูเรียบ" สำหรับการทดลอง
ตัวเร่งที่มักถูกมองข้ามสำหรับทีมเล็กคือการย่นช่องว่าง "UI โครงสร้างพื้นฐาน" เมื่อต้องสร้างเครื่องมือภายในช้า ทีมจะเลี่ยงการสร้างมัน—แล้วจ่ายต้นทุนด้วยงานแมนนวลตลอดไป เครื่องมืออย่าง Koder.ai สามารถช่วยให้คุณส่งมอบพื้นผิวผลิตภัณฑ์และแพลตฟอร์มรอบ ๆ ได้เร็ว (คอนโซล ops, แอปการติดป้ายชุดข้อมูล, เวิร์กโฟลว์รีวิว) พร้อมฟีเจอร์เช่น snapshot/rollback และการดีพลอย/โฮสติ้งที่สนับสนุนการวิศวกรรมแพลตฟอร์มแบบวนรอบ
งานของ Jeff Dean เป็นเครื่องเตือนว่า "การปรับขนาด AI" ส่วนใหญ่คือวิศวกรรมที่ทำซ้ำได้: เปลี่ยนชัยชนะโมเดลครั้งเดียวให้เป็นโรงงานที่เชื่อถือได้สำหรับข้อมูล การฝึก การประเมิน และการดีพลอย
เริ่มจากชิ้นน่าเบื่อที่เพิ่มเลเวอเรจให้ทุกโครงการในอนาคต:
ความล้มเหลวในการสเกลส่วนใหญ่ไม่ใช่ "ต้องการ GPU เพิ่ม" ตัวบล็อกทั่วไปคือ:
หนี้คุณภาพข้อมูล: ป้ายกำกับเปลี่ยน ความหมายเปลี่ยน ค่า missing เพิ่ม แก้ต้องการความเป็นเจ้าของและ SLA ไม่ใช่ฮีโร่
ช่องว่างการประเมิน: ทีมพึ่งพาเมตริกออฟไลน์เดียว แล้วประหลาดใจในโปรดักชัน เพิ่มการรายงานแบบสไลซ์และกำหนดเกณฑ์ go/no-go
การลอยของการดีพลอย: การฝึกใช้การคำนวณฟีเจอร์แบบหนึ่ง การให้บริการใช้แบบอื่น แก้ด้วยโค้ดฟีเจอร์ร่วม การทดสอบ end-to-end และการสร้างซ้ำได้
เลือกโครงสร้างพื้นฐานและมาตรฐานเวิร์กโฟลว์ที่ลดต้นทุนการประสานงาน: ลดพายไลน์เฉพาะตัว สมมติฐานข้อมูลที่ซ่อนน้อยลง และกฎการโปรโมตที่ชัดเจน การเลือกเหล่านี้จะทบต้น—แต่ละโมเดลใหม่จะถูกกว่า ปลอดภัยกว่า และส่งได้เร็วขึ้น
"การปรับขนาด AI" หมายถึงการทำให้ ML เป็นกระบวนการที่ ทำซ้ำได้และเชื่อถือได้ ภายใต้ข้อจำกัดจริง:
มันใกล้เคียงกับการสร้างสายการประกอบมากกว่าการปรับจูนโมเดลเดี่ยว"
เพราะหลายแนวคิด ML จะมีค่าก็ต่อเมื่อสามารถรันได้อย่าง เชื่อถือได้ ทำซ้ำได้ และคุ้มค่า บนข้อมูลและทราฟิกขนาดใหญ่
ผลกระทบมักอยู่ในระดับกลาง:
ในระดับฟลีท การล้มเหลวเป็นเรื่องปกติ ไม่ใช่ข้อยกเว้น จุดที่มักจะพังก่อนรวมถึง:
การออกแบบเพื่อตั้งต้นการกู้คืน (retry, checkpoint, backpressure) มักสำคัญกว่าความเร็วสูงสุดของเครื่องเดี่ยว"
MapReduce ทำให้การประมวลผลแบบแบตช์ขนาดใหญ่ เป็นมาตรฐานและทนทาน:
เครื่องมือสมัยใหม่ (Spark/Flink/Beam และ ETL บนคลาวด์) มีฟีเจอร์มากกว่า แต่บทเรียนหลักยังคงอยู่: ให้ความขนานและการ retry เป็นค่าเริ่มต้น"
Bigtable คือสโตร์แบบ wide-column ที่ออกแบบมาเพื่อ throughput สูงและ latency ที่คาดการณ์ได้ ข้อคิดหลัก:
สำหรับ ML การเข้าถึงข้อมูลที่คาดการณ์ได้ทำให้ตารางเวลาในการฝึกและการรันทำซ้ำได้เชื่อถือได้มากขึ้น
การออกแบบสตอเรจกำหนดได้ว่าคุณจะสร้างฟีเจอร์และทำซ้ำผลการทดลองได้อย่างไร:
สรุป: สตอเรจที่เสถียรบ่อยครั้งตัดสินว่าการทำ ML เป็นความสามารถของผลิตภัณฑ์หรือเป็นการดับไฟที่เกิดซ้ำ
การฝึกแบบกระจายเป็นงานที่ มีสเตทและเป็นเชิงรอบ จึงยากกว่า:
แนวทางปฏิบัติ: วัดเวลา end-to-end, ทำ topology ให้เรียบก่อน แล้วค่อยเพิ่มการปรับแต่งเมื่อพบคอขวดจริง
แพลตฟอร์มร่วมเปลี่ยน "เวิร์กโฟลว์ฮีโร่" ให้เป็นทางเดินปูเรียบ:
มันลดการทำซ้ำและทำให้ผลลัพธ์เปรียบเทียบกันได้ระหว่างทีม ซึ่งมักช่วยเร่งวัฏจักรมากกว่าการปรับสถาปัตยกรรมของโมเดลเพียงอย่างเดียว
การทำมาตรฐานลดต้นทุนการประสานงาน:
แม้นอกเหนือจาก TensorFlow บทเรียนนี้ยังใช้ได้: เลือกชุดนามธรรมที่เสถียร จัดทำเอกสาร และทำให้เส้นทางมาตรฐานเป็นทางเลือกที่ง่ายที่สุด
คุณสามารถใช้แนวทางได้โดยไม่ต้องมีทรัพยากรระดับ Google:
หากต้องการวิธีเบา ๆ ในการประสานทีม เริ่มจากเทมเพลต design doc ที่สอดคล้อง เช่น /blog/design-doc-template