Độ tin cậy và giám sát liên kết trong fabric AI

Một tác vụ huấn luyện là một phép tính đồng bộ trải trên hàng nghìn GPU: mỗi phép toán tập thể đều phải chờ liên kết chậm nhất. Một transceiver chập chờn không chỉ làm chậm một server đi một phần nhỏ — nó khiến toàn bộ tác vụ khựng lại, và nếu hỏng hẳn, tác vụ sẽ khởi động lại từ checkpoint gần nhất. Vì vậy thiết bị quang không còn là một linh kiện đơn thuần mà trở thành một quỹ độ tin cậy. Trang này trình bày bài toán tần suất hỏng hóc, các số liệu dự báo sự cố, cách các fabric giám sát và cô lập liên kết hỏng, cùng các thực hành vận hành giúp giảm tỷ lệ hỏng hóc.

Vì sao một liên kết lại quan trọng

Sự kiện	Ảnh hưởng tới tác vụ huấn luyện
Liên kết chập chờn (vài giây)	phép toán tập thể time out hoặc thử lại; thời gian mỗi bước tăng vọt; với NCCL/RCCL, một lần khựng đủ lâu sẽ hủy tác vụ
Liên kết chạy ở tốc độ/độ rộng giảm	mọi all-reduce đều bị nó ghìm nhịp; thông lượng toàn cụm giảm xuống bằng phần của liên kết đó
BER trước FEC tăng cao, chưa có lỗi không sửa được	chưa có ảnh hưởng — nhưng dự trữ đã hết; buổi chiều nóng tiếp theo nó sẽ chập chờn
Lỗi FEC không sửa được	mất gói → cơn bão truyền lại RDMA → khựng lại
Hỏng hẳn	tác vụ khởi động lại từ checkpoint: mất từ vài phút đến một giờ tính toán trên toàn cụm

Chi phí của một lần khởi động lại từ checkpoint trên một tác vụ nghìn GPU được đo bằng GPU-giờ; đó chính là con số cần so sánh với chi phí cho thiết bị quang tốt hơn và QA tốt hơn.

Bài toán tần suất hỏng hóc

Độ tin cậy của transceiver được công bố bằng FIT (số lần hỏng trên 10⁹ giờ-thiết bị) hoặc MTBF.

Giả định	Giá trị
Số đầu quang trong fabric	4 000 (cụm hai tầng 1 024 GPU)
FIT mỗi đầu (thiết bị quang 400G đã trưởng thành, tản nhiệt tốt)	200–500
Số lần hỏng hẳn dự kiến mỗi tháng	4 000 × 350 × 10⁻⁹ × 720 giờ ≈ 1
Tỷ lệ liên kết chập chờn quan sát được trong thực tế	cao gấp 5–20 × so với hỏng hẳn — bụi bẩn, dự trữ cận biên, nhiệt, firmware

Vậy nên hỏng hẳn là hiếm và có thể dự đoán; chập chờn và liên kết xuống cấp mới chiếm đa số, và phần lớn có thể ngăn ngừa được — đó là lý do vì sao giám sát và QA tự bù đắp được chi phí của chính chúng.

Các số liệu dự báo sự cố

Số liệu	Nguồn	Bình thường	Hành động
BER trước FEC theo từng làn	CMIS VDM; bộ đếm FEC của host	< 10⁻⁷	> 10⁻⁶ và đang tăng; > 10⁻⁵ thì lên lịch thay thế
Codeword FEC không sửa được	host	0	tăng bất kỳ mức nào = sự cố
Lỗi symbol theo từng làn	host (Ethernet) / `perfquery` (IB)	cân bằng, gần bằng 0	một làn trội hẳn lên
Công suất Rx theo từng làn so với giá trị tham chiếu	DDM	lệch không quá 1 dB so với ngày đầu, các làn lệch nhau không quá 2 dB	lệch −2 dB so với giá trị tham chiếu
Xu hướng dòng phân cực Tx	DDM	ổn định	+15–20 % so với giá trị tham chiếu (Dòng phân cực Tx và lão hóa)
Nhiệt độ module	DDM	< 60 °C	> 65 °C hoặc cao hơn các module lân cận 10 °C
eSNR (CMIS)	VDM	> 18–20 dB	giảm trên một làn
Liên kết chập chờn trên mỗi cổng	log của switch, fabric manager	0	bất kỳ
Tốc độ/độ rộng đã đàm phán	switch / `ibstat`	đầy đủ	thấp hơn định mức

Định nghĩa và định dạng: Số liệu VDM & FEC, Giám sát.

Kiến trúc giám sát

Fabric	Thu thập	Công cụ
InfiniBand	subnet/fabric manager truy vấn bộ đếm của từng cổng và EEPROM/DDM của cáp	manager lớp UFM, `ibdiagnet`, `mlxlink -m`
Ethernet (RoCE)	truyền trực tiếp trạng thái transceiver và FEC qua gNMI/OpenConfig mỗi 10–60 s; dự phòng bằng SNMP	gnmic → Prometheus/Grafana, đo từ xa của nhà sản xuất (Đọc DDM bằng công cụ)
Phía host	bộ đếm NIC: truyền lại, CNP, sai thứ tự; log NCCL/RCCL cho timeout	node exporter
Phía tác vụ	biến thiên thời gian mỗi bước, phát hiện worker chậm	số liệu của framework huấn luyện

Hãy đối chiếu cả ba nguồn: một đợt tăng vọt thời gian bước lúc 14:05, một lần BER trước FEC vọt lên ở leaf 7 làn 3 lúc 14:04 và một đỉnh nhiệt độ module ở tủ rack 12 — kết hợp lại là một chẩn đoán hoàn chỉnh.

Cô lập và khắc phục

Tự động vô hiệu hóa cổng / định tuyến vòng tránh khi lỗi không sửa được hoặc số lần chập chờn vượt ngưỡng — fabric manager và NOS đều hỗ trợ chính sách lỗi liên kết; trong lúc đó, định tuyến thích ứng dẫn luồng vòng qua liên kết đang xuống cấp.
Rút node ra khỏi vận hành (drain) nếu cổng NIC của nó là thủ phạm; lên lịch tác vụ tránh node đó.
Đưa module lên bàn thử: thông tin nhận dạng, DDM theo từng làn so với giá trị tham chiếu ngày đầu, checksum, phiên bản firmware (Check transceiver, DDM).
Vệ sinh và soi kiểm tra lại đầu MPO ở cả hai phía trước khi đổ lỗi cho module — bụi bẩn là nguyên nhân phổ biến nhất (Sai lệch vật lý).
Hoán đổi và quan sát: nếu lỗi đi theo module, hãy RMA nó; nếu lỗi ở lại với cổng, hãy xem xét cage, sợi quang và đầu xa.

Các thực hành giúp giảm tỷ lệ hỏng hóc

Thực hành	Hiệu quả
Kiểm tra đầu vào và burn-in (24–72 giờ dưới tải và nhiệt độ vận hành)	loại bỏ các hỏng hóc sớm trước khi module tới tay một tác vụ
Lập giá trị tham chiếu DDM theo từng làn ngay ngày đầu	biến độ chính xác tuyệt đối (±3 dB) thành các độ lệch chính xác
Giữ module < 60 °C — luồng khí, chọn đúng OSFP có cánh tản nhiệt/đỉnh phẳng, không che cửa hút khí	tuổi thọ tăng gấp đôi mỗi khi giảm 10 °C
Vệ sinh mọi đầu nối ở mỗi lần ghép nối; đậy nắp các cổng không dùng	phần lớn hiện tượng chập chờn là do bụi bẩn
Cập nhật firmware cho module và host	các bản sửa lỗi tương thích CMIS (Sự cố CMIS)
Thiết bị quang đồng nhất, đã được kiểm định cho từng tầng	ít bất ngờ về tương thích DSP giữa host và module hơn
Hàng dự phòng đã burn-in và có giá trị tham chiếu, 3–5 %	thay thế được mà không gây thêm sự cố thứ hai
Rà soát xu hướng hằng tuần	thay laser đang lão hóa theo lịch, không đợi tới khi hỏng

Công nghệ đang đi về đâu

Tốc độ mỗi làn cao hơn (200G/làn, 1,6T) càng siết chặt dự trữ; linear (LPO) và co-packaged optics loại bỏ DSP cùng khả năng giám sát của nó — đẩy khả năng quan sát BER về phía host — trong khi hứa hẹn ít linh kiện hơn và ít nhiệt hơn (Điều chế & DSP, Thiết bị quang trong AI). Dù là module nào, nguyên tắc vẫn không đổi: lập giá trị tham chiếu, theo dõi độ lệch, hành động theo xu hướng.

Trong CodingBox

CodingBox là đầu bàn thử của vòng lặp này: các lần đọc khi kiểm tra đầu vào và burn-in, giá trị tham chiếu theo từng làn từ ngày đầu được lưu theo số sê-ri trong code database, và các lần đọc hậu kiểm (post-mortem) của module đã tháo ra — thông tin nhận dạng, firmware, checksum và DDM được so sánh với lịch sử của chính nó — để quyết định RMA dựa trên dữ liệu chứ không phải dòng log cuối cùng của cổng.

Nếu bạn phát hiện thông tin chưa chính xác hoặc lỗi trong bài viết này, hãy chọn đoạn liên quan và nhấn Ctrl+Enter để .