ความน่าเชื่อถือของลิงก์และการตรวจติดตามในแฟบริก AI

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

ทำไมลิงก์เดียวจึงสำคัญ

เหตุการณ์	ผลกระทบต่องานเทรน
ลิงก์กระพริบ (ไม่กี่วินาที)	การดำเนินการแบบกลุ่มไทม์เอาต์หรือลองใหม่; เวลาต่อสเต็ปพุ่งขึ้น; ถ้าใช้ NCCL/RCCL การหยุดชะงักที่นานพอจะยกเลิกงานทันที
ลิงก์วิ่งที่ความเร็ว/ความกว้างลดลง	ทุก all-reduce ถูกกำหนดจังหวะโดยลิงก์นี้; ทรูพุตของทั้งคลัสเตอร์ลดลงมาเท่ากับส่วนแบ่งของลิงก์นี้
pre-FEC BER สูงขึ้น แต่ยังไม่มีข้อผิดพลาดที่แก้ไขไม่ได้	ยังไม่มีผลกระทบ — แต่ค่าเผื่อหมดไปแล้ว บ่ายที่อากาศร้อนวันถัดไปมันจะกระพริบ
ข้อผิดพลาด FEC ที่แก้ไขไม่ได้	แพ็กเก็ตสูญหาย → เกิดพายุการส่งซ้ำของ RDMA → หยุดชะงัก
ความล้มเหลวถาวร	งานรีสตาร์ทจากเช็กพอยต์: เสียเวลาประมวลผลทั้งคลัสเตอร์ไปหลายนาทีถึงหนึ่งชั่วโมง

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

เลขคณิตของความล้มเหลว

ความน่าเชื่อถือของทรานซีฟเวอร์ระบุเป็น FIT (จำนวนความล้มเหลวต่อ 10⁹ device-hours) หรือ MTBF

สมมติฐาน	ค่า
ปลายออปติกในฟาบริก	4 000 (คลัสเตอร์สองชั้น GPU 1 024 ตัว)
FIT ต่อปลาย (ออปติก 400G ที่ผ่านการพิสูจน์แล้ว ระบายความร้อนดี)	200–500
ความล้มเหลวถาวรที่คาดไว้ต่อเดือน	4 000 × 350 × 10⁻⁹ × 720 h ≈ 1
อัตราลิงก์กระพริบที่พบจริง	สูงกว่าความล้มเหลวถาวร 5–20 เท่า — สิ่งสกปรก, ค่าเผื่อก้ำกึ่ง, ความร้อน, เฟิร์มแวร์

ดังนั้นความล้มเหลวถาวรจึงพบได้น้อยและคาดการณ์ได้; ลิงก์ที่กระพริบและลิงก์ที่เสื่อมสภาพเป็นสาเหตุหลักและส่วนใหญ่ป้องกันได้ — นี่คือเหตุผลที่การตรวจติดตามและการประกันคุณภาพคุ้มค่าที่ลงทุนไป

ตัวชี้วัดที่ทำนายปัญหาได้

ตัวชี้วัด	แหล่งข้อมูล	ค่าปกติ	ควรทำ
Pre-FEC BER ต่อเลน	VDM ของ CMIS; ตัวนับ FEC ของโฮสต์	< 10⁻⁷	> 10⁻⁶ และเพิ่มขึ้นเรื่อย ๆ; > 10⁻⁵ วางแผนเปลี่ยน
โค้ดเวิร์ดที่ FEC แก้ไขไม่ได้	โฮสต์	0	เพิ่มขึ้นแม้เพียงนิดเดียว = เหตุการณ์ผิดปกติ
ข้อผิดพลาดของสัญลักษณ์ต่อเลน	โฮสต์ (Ethernet) / `perfquery` (IB)	สมดุลกัน, ใกล้ศูนย์	เลนใดเลนหนึ่งสูงกว่าเลนอื่นชัดเจน
กำลังรับ (Rx) ต่อเลน เทียบกับค่าฐาน	DDM	อยู่ในช่วง 1 dB จากวันแรก, แต่ละเลนต่างกันไม่เกิน 2 dB	ต่ำกว่าค่าฐาน 2 dB
แนวโน้ม ไบอัส Tx	DDM	คงที่	สูงกว่าค่าฐาน +15–20 % (ไบอัส Tx และการเสื่อมสภาพของเลเซอร์)
อุณหภูมิโมดูล	DDM	< 60 °C	> 65 °C หรือสูงกว่าโมดูลข้างเคียง +10 °C
eSNR (CMIS)	VDM	> 18–20 dB	ลดลงในเลนใดเลนหนึ่ง
ลิงก์กระพริบ ต่อพอร์ต	ล็อกของสวิตช์, fabric manager	0	เกิดขึ้นแม้ครั้งเดียว
ความเร็ว/ความกว้างที่เจรจาได้	สวิตช์ / `ibstat`	เต็มพิกัด	ต่ำกว่าพิกัด

คำนิยามและรูปแบบ: ค่าตรวจวัด VDM และ FEC, การตรวจติดตาม

สถาปัตยกรรมการตรวจติดตาม

ฟาบริก	การเก็บข้อมูล	เครื่องมือ
InfiniBand	subnet/fabric manager โพลตัวนับและ EEPROM/DDM ของสายทุกพอร์ต	ตัวจัดการระดับ UFM, `ibdiagnet`, `mlxlink -m`
Ethernet (RoCE)	สตรีม gNMI/OpenConfig ของสถานะทรานซีฟเวอร์และ FEC ทุก 10–60 s; SNMP เป็นตัวสำรอง	gnmic → Prometheus/Grafana, เทเลเมทรีของผู้ผลิต (การอ่านค่า DDM ด้วยเครื่องมือ)
ฝั่งโฮสต์	ตัวนับของ NIC: การส่งซ้ำ, CNP, แพ็กเก็ตผิดลำดับ; ล็อกของ NCCL/RCCL สำหรับไทม์เอาต์	node exporter
ฝั่งงาน	ความแปรปรวนของเวลาต่อสเต็ป, การตรวจจับตัวที่ช้าผิดปกติ	ตัวชี้วัดของเฟรมเวิร์กการเทรน

เชื่อมโยงข้อมูลทั้งสามฝั่งเข้าด้วยกัน: เวลาต่อสเต็ปพุ่งขึ้นตอน 14:05, pre-FEC BER ที่ลีฟ 7 เลน 3 กระเพื่อมผิดปกติตอน 14:04 และอุณหภูมิโมดูลในแร็ก 12 พุ่งสูงสุด รวมกันแล้วคือการวินิจฉัยที่ครบถ้วน

การแยกปัญหาและการแก้ไข

ปิดพอร์ตอัตโนมัติ / เลี่ยงเส้นทาง เมื่อข้อผิดพลาดที่แก้ไขไม่ได้หรือการกระพริบเกินค่าเกณฑ์ — fabric manager และ NOS รองรับนโยบายจัดการข้อผิดพลาดของลิงก์; ระหว่างนั้น adaptive routing จะบังคับทราฟฟิกให้เลี่ยงลิงก์ที่เสื่อมสภาพ
ดึงโหนดออกจากงาน ถ้าพอร์ต NIC ของมันเป็นต้นเหตุ; จัดตารางงานให้เลี่ยงโหนดนั้น
นำโมดูลไปตรวจบนโต๊ะทดสอบ: ข้อมูลระบุตัวตน, DDM รายเลนเทียบกับค่าฐานวันแรก, เช็กซัม, เวอร์ชันเฟิร์มแวร์ (Check transceiver, DDM)
ทำความสะอาดและตรวจสอบ MPO ใหม่ ทั้งสองด้านก่อนจะโทษว่าโมดูลเสีย — สิ่งสกปรกเป็นสาเหตุที่พบบ่อยที่สุด (ความไม่ตรงกันทางกายภาพ)
สลับและสังเกตผล: ถ้าข้อผิดพลาดติดตามโมดูลไป ให้ทำ RMA; ถ้าข้อผิดพลาดยังอยู่กับพอร์ตเดิม ให้ตรวจดูเคจ ใยแก้วนำแสง และปลายทางอีกฝั่ง

แนวปฏิบัติที่ช่วยลดอัตราความล้มเหลว

แนวปฏิบัติ	ผลลัพธ์
ตรวจรับเข้าและเบิร์นอิน (24–72 h ภายใต้โหลดและอุณหภูมิใช้งาน)	กำจัดความล้มเหลวช่วงต้นอายุการใช้งานก่อนถึงมือผู้ใช้งานจริง
บันทึกค่าฐาน DDM รายเลนตั้งแต่วันแรก	เปลี่ยนความแม่นยำสัมบูรณ์ (±3 dB) ให้กลายเป็นผลต่างที่แม่นยำ
รักษาอุณหภูมิโมดูลให้ < 60 °C — จัดการไหลเวียนอากาศ, เลือก OSFP แบบมีครีบ/แบบแบนให้ถูกต้อง, ไม่ปิดกั้นช่องรับอากาศ	อายุการใช้งานเพิ่มเป็นสองเท่าทุก −10 °C
ทำความสะอาดคอนเนกเตอร์ทุกครั้งที่เสียบเข้าหากัน; ใส่ฝาครอบพอร์ตที่ไม่ได้ใช้งาน	ลิงก์กระพริบส่วนใหญ่มาจากสิ่งสกปรก
อัปเดตเฟิร์มแวร์ให้ทันสมัย ทั้งโมดูลและโฮสต์	แก้ปัญหาความเข้ากันได้ของ CMIS (ปัญหา CMIS)
ใช้ออปติกชนิดเดียวกันที่ผ่านการตรวจสอบแล้วในแต่ละชั้น	ลดปัญหาความเข้ากันได้ของ DSP ระหว่างโฮสต์กับโมดูลที่ไม่คาดคิด
อะไหล่สำรอง 3–5 % ที่เบิร์นอินและบันทึกค่าฐานไว้แล้ว	เปลี่ยนได้ทันทีโดยไม่เกิดเหตุซ้ำ
ทบทวนแนวโน้มทุกสัปดาห์	เปลี่ยนเลเซอร์ที่เสื่อมสภาพตามกำหนดเวลา ไม่ใช่ตอนที่เสียแล้ว

ทิศทางที่เทคโนโลยีกำลังมุ่งไป

อัตราต่อเลนที่สูงขึ้น (200G/เลน, 1.6T) บีบค่าเผื่อให้แคบลงไปอีก; ออปติกแบบเชิงเส้น (LPO) และ ออปติกแบบรวมแพ็กเกจ (co-packaged) ตัด DSP และการตรวจติดตามของมันออกไป — ผลักภาระการมองเห็น BER ไปที่โฮสต์แทน — พร้อมสัญญาว่าจะมีส่วนประกอบน้อยลงและความร้อนน้อยลง (การมอดูเลตและ DSP, ออปติกใน AI) ไม่ว่าจะใช้โมดูลแบบไหน วินัยพื้นฐานยังคงเดิม: บันทึกค่าฐาน ตรวจติดตามผลต่าง และลงมือทำตามแนวโน้ม

ใน CodingBox

CodingBox คือปลายด้านโต๊ะทดสอบของวงจรนี้: การอ่านค่าตอนตรวจรับเข้าและตอนเบิร์นอิน ค่าฐานรายเลนของวันแรกที่เก็บไว้ตามหมายเลขซีเรียลใน ฐานข้อมูลโค้ด และการอ่านค่าหลังถอดโมดูลออกมาตรวจ — ข้อมูลระบุตัวตน, เฟิร์มแวร์, เช็กซัม และ DDM เทียบกับประวัติของตัวมันเอง — ทำให้การตัดสินใจ RMA อ้างอิงจากข้อมูลจริง ไม่ใช่จากบรรทัดล็อกสุดท้ายของพอร์ต

หากพบข้อมูลที่ไม่ถูกต้องหรือข้อผิดพลาดในบทความนี้ ให้เลือกข้อความส่วนนั้นแล้วกด Ctrl+Enter เพื่อ