Khung phân loại D·A·M

Một hệ thống chạy chậm hiếm khi tự nói vì sao. Một bộ tăng tốc nhàn rỗi có thể bắt nguồn từ pipeline đầu vào thiếu dữ liệu (Data), một thuật toán có cường độ số học quá thấp (Algorithm), hoặc bus bộ nhớ bị bão hòa (Machine). Phụ lục này hệ thống hóa khung phân loại chẩn đoán cho nút đơn của cuốn sách, ánh xạ trực tiếp các triệu chứng và phép đo từ profiler vào trục thật sự đang kìm hãm việc thực thi trước khi bắt đầu tối ưu hóa. Độc giả nên mang theo ba trục từ các chương mở đầu và định luật sắt dùng để định lượng chúng.

Cách sử dụng Phụ lục này

Hãy sử dụng khung phân loại D·A·M khi một hệ thống không đạt được mục tiêu về hiệu suất, chi phí hoặc chất lượng mà nguyên nhân chưa rõ ràng. Hãy áp dụng framework này theo bốn bước sau:

  1. Nêu triệu chứng và ngân sách vận hành: Ghi lại mục tiêu end-to-end bị lỡ, khối lượng công việc (workload) và ngữ cảnh triển khai.
  2. Xác định trục hoặc ranh giới tiềm năng: Sử dụng table 1 cho bước phân tích ban đầu và table 2 khi bằng chứng cắt qua nhiều trục.
  3. Kiểm tra giả thuyết: Ánh xạ các bằng chứng vào định luật sắt và cường độ số học, sau đó thu thập các phép đo xác nhận với table 6 và table 7.
  4. Can thiệp và đo lường lại: Chọn một giải pháp từ table 4 và lặp lại phép đo tổng thể. Nếu mục tiêu không cải thiện, hãy điều chỉnh giả thuyết.

Triệu chứng sẽ xác định điểm khởi đầu hữu ích nhất. Mức sử dụng bộ tăng tốc thấp hoặc giao batch chậm nên bắt đầu với section 1.5 và section 1.8. Một mục tiêu mức dịch vụ (SLO) bị lỡ nên chuyển từ thời gian các pha và độ sâu hàng đợi trong table 5 sang hạng mục tương ứng trong định luật sắt. Khi chất lượng chững lại, hãy kiểm tra ranh giới Data/Algorithm và section 1.11 trước khi cấp thêm tài nguyên tính toán. Trong mọi trường hợp, nhãn trục là một giả thuyết, không phải kết luận: các trục chồng lấn, và một chẩn đoán hữu ích có thể nêu cả trục chi phối lẫn hiệu ứng ở ranh giới.

Tóm tắt chẩn đoán

Khung phân loại này ánh xạ trực tiếp đến định luật sắt của các hệ thống ML đã được thiết lập trong Định luật sắt của hệ thống ML. Table 1 tóm tắt vai trò, ràng buộc vật lý chính và lộ trình tối ưu hóa cốt lõi cho mỗi trục.

Table 1: Tham khảo Trục D·A·M: Mỗi trục tương ứng với một loại ràng buộc và một chiến lược tối ưu hóa. Bạn hãy đưa ra giả thuyết, kiểm chứng bằng các phép đo, rồi xem chương tương ứng.
Trục Vai trò Ràng buộc vật lý Tối ưu hóa đòn bẩy cao
Dữ liệu (D) Thông tin (Nhiên liệu) Khối lượng, chất lượng, tốc độ đến Lựa chọn dữ liệu (Lựa chọn dữ liệu)
Thuật toán (A) Logic (Bản thiết kế) Các hoạt động và sự phụ thuộc Nén mô hình (Nén mô hình)
Máy (M) Vật lý (Động cơ) Tính toán, bộ nhớ, I/O Tăng tốc phần cứng (Tăng tốc phần cứng)

Việc phân tách ban đầu này rất hữu ích, nhưng các hệ thống sản xuất hiếm khi gặp nút thắt cổ chai chỉ do một trục gây ra. Thường thì, vấn đề nằm ở ranh giới giữa hai trục—chẳng hạn như lựa chọn định dạng dữ liệu quyết định liệu GPU có thể được sử dụng hết công suất hay không, hoặc một chiến lược tỉa (pruning) làm thay đổi cách truy cập bộ nhớ. Để xử lý các trường hợp này, chúng ta cần ánh xạ các giao điểm.

Toàn cảnh các giao điểm

Chương mở đầu sử dụng Bức tranh giao thoa D·A·M để phác thảo bức tranh khái niệm. Ở đây, figure 1 biến bản đồ đó thành một quy trình chẩn đoán. Đầu tiên, hãy xác định trục gây ràng buộc, sau đó xem xét một sự can thiệp vào trục đó sẽ làm thay đổi hai trục còn lại như thế nào.

Figure 1: Bộ ba Trục D·A·M: Một góc nhìn chẩn đoán súc tích về Dữ liệu, Thuật toán và Máy móc dưới dạng ba trục phụ thuộc lẫn nhau. Các liên kết hai chiều nhấn mạnh rằng một sự can thiệp vào một trục sẽ thay đổi các ràng buộc trên hai trục còn lại.

Sau khi đã xác định được trục chính ban đầu, table 2 mở rộng các giao điểm từng cặp và giao điểm ba chiều thành các kỹ thuật cụ thể cùng các chương sách liên quan.

Table 2: Tham chiếu Giao điểm D·A·M: Mỗi vùng ánh xạ các kỹ thuật cụ thể đến các trục mà chúng bao phủ và các chương đề cập đến chúng. Các giao điểm từng cặp đòi hỏi phải suy luận về hai miền đồng thời; phần trung tâm đòi hỏi cả ba.
Vùng Tên Các kỹ thuật chính Nội dung sách
Dữ liệu Thông tin Định dạng lưu trữ, chất lượng dữ liệu, phân phối Kỹ thuật dữ liệu
Thuật toán Logic Các hàm mất mát, kiến trúc, gradient Tính toán nơ-ron, Kiến trúc mạng
Dữ liệu \(\cap\) Thuật toán Học từ đâu Lựa chọn dữ liệu, học tập theo chương trình, mở rộng tối ưu tính toán Lựa chọn dữ liệu, Huấn luyện mô hình
Dữ liệu \(\cap\) Máy Cách di chuyển thông tin Băng thông I/O, tìm nạp trước, định dạng dữ liệu Kỹ thuật dữ liệu, Tăng tốc phần cứng
Thuật toán \(\cap\) Máy Cách thực thi hiệu quả Lượng tử hoá, tỉa (pruning), hợp nhất kernel, độ chính xác hỗn hợp Các Framework ML, Nén mô hình
Máy Vật lý Silicon, hệ thống phân cấp bộ nhớ, FLOP/s đỉnh Tăng tốc phần cứng
Dữ liệu \(\cap\) Thuật toán \(\cap\) Máy Kỹ thuật Hệ thống ML Iron law, Roofline, các vòng lặp huấn luyện, phục vụ (serving) Huấn luyện mô hình, Phục vụ mô hình, Benchmarking

Trong từ viết tắt D·A·M, Dữ liệu, Thuật toán và Máy móc là các trục phân loại. Chúng không phải là các biến toán học; các đại lượng hình thức vẫn tuân theo chương ký hiệu, trong đó \(D\) biểu thị kích thước tập dữ liệu hoặc các token huấn luyện.

Các vùng tập trung vào trục chứa các khái niệm chủ yếu thuộc về một trục: ví dụ, định dạng lưu trữ và phân phối nhấn mạnh Dữ liệu; các hàm mất mát và gradient nhấn mạnh Thuật toán; còn vật lý silicon và FLOP/s đỉnh nhấn mạnh Máy móc. Chuyên môn một miền có thể giới thiệu chúng, nhưng hành vi khi triển khai vẫn có thể phụ thuộc vào các trục khác.

Các giao điểm đôi một là nơi tư duy hệ thống bắt đầu. \(\mathsf{Data} \cap \mathsf{Algorithm}\) (Học từ gì) bao gồm việc chọn dữ liệu, học theo chương trình (curriculum learning), học tích cực (active learning) và các quy luật mở rộng quy mô như Chinchilla (\(D \approx 20P\) cho chế độ mô hình ngôn ngữ tự hồi quy dày đặc được nghiên cứu) (Hoffmann et al. 2022). Tất cả những điều này đều đòi hỏi suy luận đồng thời về nội dung thông tin và năng lực thuật toán. Thêm dữ liệu mà không xét xem mô hình có học được từ đó hay không sẽ lãng phí tài nguyên tính toán; chọn kiến trúc mà không tính đến dữ liệu sẵn có sẽ lãng phí thời gian kỹ thuật. \(\mathsf{Data} \cap \mathsf{Machine}\) (Cách di chuyển thông tin) bao quát băng thông I/O, các chiến lược tìm nạp trước (prefetching), định dạng dữ liệu và bất biến di chuyển năng lượng. Ở giao điểm này, “trọng lực dữ liệu” bộc lộ rõ: chi phí vật lý để di chuyển các byte qua hệ thống phân cấp bộ nhớ quyết định liệu máy có được cấp dữ liệu đủ nhanh hay không. \(\mathsf{Algorithm} \cap \mathsf{Machine}\) (Cách thực thi hiệu quả) trải từ lượng tử hoá, tỉa (pruning), hợp nhất kernel, độ chính xác hỗn hợp đến tối ưu hóa đồ thị tính toán. Một chiến lược tỉa (pruning) làm giảm FLOPs nhưng phá vỡ mẫu truy cập bộ nhớ có thể làm chậm việc thực thi trên phần cứng thực.

Trung tâm—\(\mathsf{Data} \cap \mathsf{Algorithm} \cap \mathsf{Machine}\)—là điểm hội tụ của cả ba trục. Định luật sắt, Mô hình Roofline, các vòng lặp huấn luyện end-to-end, các pipeline phục vụ (serving) và benchmark toàn diện đều đòi hỏi suy luận đồng thời về luồng dữ liệu, độ phức tạp thuật toán và mức độ sử dụng phần cứng. Trung tâm này không phải là một kỹ thuật đơn lẻ; nó chính là bản thân lĩnh vực này.

Hiểu bức tranh tổng thể cho thấy một kỹ thuật nằm ở đâu. Bước tiếp theo là định lượng xem trục nào chiếm ưu thế với một khối lượng công việc (workload) cụ thể—và điều đó đòi hỏi định luật sắt.

Ánh xạ Định luật Sắt

Với các pha tuần tự, định luật sắt ánh xạ khối lượng công việc trên các trục D·A·M sang thời gian thực thi. Ở đây, \(T\) và \(L_{\text{lat}}\) là thời gian (tính bằng giây); \(D_{\text{vol}}\) là số byte đã di chuyển và \(\text{BW}\) là băng thông (số byte mỗi giây); \(O\) là khối lượng công việc tính bằng FLOPs, \(R_{\text{peak}}\) là FLOP/s, và \(\eta_{\text{hw}}\) là hiệu suất phần cứng không thứ nguyên. Các đại lượng này được ánh xạ tới các trục như sau: \[ T = \underbrace{ \frac{D_{\text{vol}}}{\text{BW}} }_{\text{Data/Machine}} + \underbrace{ \frac{O}{R_{\text{peak}} \cdot \eta_{\text{hw}}} }_{\text{Algorithm/Machine}} + \underbrace{ L_{\text{lat}} }_{\text{Cross-axis overhead}} \]

Thuật toán và Máy đều liên quan đến khía cạnh tính toán, nhưng khác nhau ở biến số mà kỹ sư có thể kiểm soát. Giảm tổng số phép toán (\(O\)) là đòn bẩy thuộc về Thuật toán, còn cải thiện thông lượng đỉnh của phần cứng (\(R_{\text{peak}}\)) hoặc hệ số sử dụng (\(\eta_{\text{hw}}\)) là đòn bẩy thuộc về Máy.

Phương trình này biến việc gỡ lỗi hiệu suất từ một trò đoán mò định tính thành một bài toán kỹ thuật định lượng. Khoản chi phí lớn nhất đo được sẽ xuất hiện trong một trong các hạng mục này. Một hệ thống chậm có thể do di chuyển quá nhiều dữ liệu (\(D_{\text{vol}}\)), thiếu băng thông (\(\text{BW}\)), thực hiện quá nhiều phép toán (\(O\)), không tận dụng được khả năng đỉnh của phần cứng (\(\eta_{\text{hw}}\)), hoặc chịu chi phí chéo trục (\(L_{\text{lat}}\)). Các đòn bẩy dưới đây liên hệ những tối ưu hoá cụ thể với các biến số mà chúng cải thiện.

Các đòn bẩy thành phần

  • Đòn bẩy Dữ liệu: Giảm số byte được di chuyển (\(D_{\text{vol}}\)) thông qua loại bỏ trùng lặp, lựa chọn, hoặc dùng biểu diễn độ chính xác thấp hơn, hoặc tăng băng thông I/O (\(\text{BW}\)).
  • Đòn bẩy Thuật toán: Giảm số phép toán (\(O\)) thông qua tỉa (pruning) hoặc tinh chỉnh kiến trúc. Lượng tử hoá thu hẹp biểu diễn và có thể tăng thông lượng phần cứng; nói chung nó không làm giảm số lượng phép toán.
  • Đòn bẩy Máy: Tăng mẫu số của thành phần tính toán bằng cách cải thiện thông lượng đỉnh (\(R_{\text{peak}}\)) hoặc tăng hệ số sử dụng (\(\eta_{\text{hw}}\)) thông qua hợp nhất kernel.

Phối hợp D·A·M: Từ tổng đến tối đa

Định luật sắt cộng tính biểu diễn thực thi tuần tự. Gọi \(T_{\text{sequential}}\) là thời gian không có chồng chéo và \(T_{\text{pipelined}}\) là thời gian đo được có chồng chéo. Sự chồng chéo có thể đưa tổng thời gian tiến gần đến giá trị lớn nhất, nhưng các phụ thuộc, tranh chấp và chồng chéo không hoàn chỉnh khiến thời gian đo được vẫn cao hơn giới hạn dưới lý tưởng này: \[ T_{\text{sequential}} = \frac{D_{\text{vol}}}{\text{BW}} + \frac{O}{R_{\text{peak}} \cdot \eta_{\text{hw}}} + L_{\text{lat}} \quad \xrightarrow{\text{overlap}} \quad T_{\text{pipelined}} \geq \max\left(\frac{D_{\text{vol}}}{\text{BW}}, \frac{O}{R_{\text{peak}} \cdot \eta_{\text{hw}}}\right) + L_{\text{lat}} \]

Nhiệm vụ của kỹ sư hệ thống là làm cho các thành phần này chạy song song, không phải nối tiếp. Table 3 tóm tắt các kỹ thuật phối hợp D·A·M chính giúp chồng chéo công việc trên các trục:

Table 3: Các Kỹ thuật Chồng chéo D·A·M: Mỗi kỹ thuật giúp chồng chéo công việc trên các trục, đưa thời gian Dữ liệu/Máy và Thuật toán/Máy (vốn được cộng tuần tự) tiến gần hơn đến giới hạn dưới lý tưởng của chúng: tức là giá trị lớn hơn trong hai hạng mục. Các phụ thuộc và tranh chấp sẽ giới hạn mức độ chồng chéo thực tế đạt được.
Kỹ thuật Các Trục D·A·M Chồng Chéo Triển khai
Tìm nạp trước D chồng chéo M DataLoader với prefetch_factor, pin_memory=True
CUDA Streams D chồng chéo M Tách biệt các luồng cho truyền H2D và tính toán
Đồng bộ Gradient Bất đồng bộ M (truyền thông) chồng chéo A Chồng chéo AllReduce theo nhóm với tính toán lan truyền ngược còn lại
Double Buffering D chồng chéo M Điền bộ đệm N+1 trong khi tính toán trên bộ đệm N

Việc chồng chéo mang lại tăng tốc lớn nhất khi các thành phần thời gian D·A·M tương đối cân bằng. Nếu một thành phần lấn át (ví dụ bị giới hạn nặng bởi bộ nhớ), chồng chéo phần nhỏ hơn với phần lớn hơn hầu như không giúp gì—giới hạn tối đa vẫn bị chi phối bởi đúng nút thắt cổ chai đó. Sự cân bằng này xuất hiện khi \(D_{\text{vol}}/\text{BW} \approx O/(R_{\text{peak}} \cdot \eta_{\text{hw}})\). Thành phần độ trễ cần được xử lý riêng.

Systems Perspective 1.1: Overhead không thể ẩn
Thành phần độ trễ không thể ẩn \(L_{\text{lat}}\) (khởi chạy kernel, rào cản đồng bộ, điều phối Python) chứa các điểm tuần tự hóa không thể chồng chéo hoàn toàn. Hợp nhất kernel có thể giảm thành phần này bằng cách gộp các phép toán, nhưng không thể loại bỏ hết overhead khởi chạy, lập lịch hay đồng bộ.

Định luật sắt cho kỹ sư biết mỗi thành phần mất bao nhiêu thời gian. Còn một câu hỏi then chốt: trần hiệu năng do di chuyển dữ liệu hay do thông lượng tính toán quyết định? Câu trả lời nằm ở một tỉ lệ duy nhất.

Ranh giới cường độ số học

Ranh giới giữa thành phần bộ nhớ Dữ liệu/Máy và thành phần tính toán Thuật toán/Máy không phải tùy tiện; nó được xác định một cách toán học bởi cường độ số học1 (\(I\)) của khối lượng công việc (workload).

1 Cường độ số học: Trong cuốn sách này, thuật ngữ này được dùng để chỉ số phép toán dấu phẩy động trên mỗi byte dữ liệu truyền đi. Williams et al. (2009) gọi đại lượng DRAM đo được là cường độ hoạt động trong Mô hình Roofline. So sánh tỉ lệ của khối lượng công việc với điểm đỉnh phần cứng (\(R_{\text{peak}}/\text{BW}\)) cho phép chẩn đoán ở mức giới hạn trên việc thực thi đang bị giới hạn bởi bộ nhớ hay bởi tính toán.

Williams, Samuel, Andrew Waterman, and David Patterson. 2009. “Roofline: An Insightful Visual Performance Model for Multicore Architectures.” Communications of the ACM 52 (4): 65–76. https://doi.org/10.1145/1498765.1498785.

Mô hình Roofline cung cấp một giới hạn hiệu suất tối đa khi lưu lượng và tốc độ đạt được được đo nhất quán. Trong lúc xử lý sự cố sản xuất, các heuristic sàng lọc nhanh có thể chỉ ra những phép đo cần thu thập tiếp theo.

Nguyên tắc kinh nghiệm

Giữa một sự cố sản xuất, hiếm khi có thời gian để giải trọn vẹn phương trình định luật sắt. Các kỹ sư hệ thống dày dạn thường dựa vào các heuristic định lượng để nhanh chóng thu hẹp không gian tìm kiếm; các ngưỡng dưới đây là tín hiệu sàng lọc cần được đối chiếu với dấu vết từ profiler và bộ đếm phần cứng.

  • Mức sử dụng bộ tăng tốc thấp (< 80%): Rà soát nguy cơ thiếu dữ liệu, thiếu CPU hoặc thiếu nguồn cho khởi chạy. Xác nhận bằng các chỉ số: thời gian chờ của pipeline đầu vào, mức bão hòa CPU máy chủ, bộ đếm băng thông bộ nhớ, và các khoảng trống trong trace.
  • Mức sử dụng bộ tăng tốc cao (> 95%): Chỉ coi đây là bị giới hạn bởi Máy (machine bound) khi các đơn vị tính toán luôn bận và băng thông bộ nhớ chưa bão hòa. Nếu băng thông bộ nhớ đã bão hòa, nút thắt vẫn ở ranh giới Dữ liệu/Máy.
  • Nếu kích thước batch là 1: Xem đây là cảnh báo rằng độ trễ hoặc chi phí khởi chạy có thể quan trọng; hãy xác nhận bằng trace trước khi gán nhãn bản thân thuật toán là nút thắt cổ chai.
  • Cường độ tính toán thấp (dưới ngưỡng ridge của phần cứng): Khối lượng công việc (workload) nhiều khả năng bị giới hạn bởi bộ nhớ (ranh giới Dữ liệu/Máy). Ranh giới chính xác là \(R_{\text{peak}}/\text{BW}\) và phụ thuộc vào phần cứng và độ chính xác.
  • Nếu hệ thống chạy ổn ở dev nhưng hỏng ở prod: Xem trôi dữ liệu (data drift) là một giả thuyết, bên cạnh khác biệt về cấu hình, tải, phụ thuộc và runtime.

Các nhãn phổ biến trong ngành có thể cắt ngang các trục. Thực thi bị giới hạn bởi bộ nhớ (memory-bound execution) nằm trên ranh giới Dữ liệu/Máy vì cả số byte di chuyển và băng thông khả dụng đều quan trọng. Thực thi bị giới hạn bởi tính toán (compute-bound execution) gắn công việc của Thuật toán với thông lượng của Máy. Thực thi bị giới hạn bởi độ trễ (latency-bound execution) có thể phản ánh độ sâu tuần tự của thuật toán, điều phối runtime, đồng bộ hóa, hoặc xếp hàng.

Chẩn đoán nút thắt cổ chai

Khi profiling đã xác định được thành phần chi phối trong “định luật sắt”, các tối ưu hóa phải nhắm đúng vào trục đó. Table 4 đối chiếu các can thiệp đem lại tăng tốc end-to-end với những tối ưu hóa không ràng buộc, gây lãng phí công sức kỹ thuật:

Table 4: Điều gì hiệu quả và Điều gì lãng phí: Tối ưu hóa một yếu tố không phải nút thắt cổ chai sẽ đem lại rất ít hoặc không cải thiện được end-to-end. Ví dụ, một mô hình ngôn ngữ lớn bị giới hạn bởi bộ nhớ sẽ không được lợi nhiều chỉ từ việc tăng thêm FLOP/s đỉnh, dù một bộ tăng tốc có băng thông bộ nhớ lớn hơn có thể giúp.
Nếu khối lượng công việc (workload) là… Thành phần Chi phối Tối ưu hóa Hiệu quả Tối ưu hóa Lãng phí
Giới hạn bởi Bộ nhớ \(D_{\text{vol}}/\text{BW}\) Lượng tử hoá; tỉa (pruning) có cấu trúc; gom batch để tái sử dụng trọng số; hợp nhất loại bỏ lưu lượng trung gian Bộ tăng tốc nhanh hơn (nhiều FLOP/s hơn sẽ không giúp ích)
Giới hạn bởi Tính toán \(O/(R_{\text{peak}} \cdot \eta_{\text{hw}})\) Kernel tốt hơn, Tensor Cores, bộ tăng tốc nhanh hơn, độ chính xác thấp hơn Băng thông bộ nhớ nhiều hơn (không phải thành phần ràng buộc)
Giới hạn bởi Độ trễ \(L_{\text{lat}}\) Giảm độ sâu tuần tự; hợp nhất hoặc điều phối bất đồng bộ; gom batch trong giới hạn ngân sách Tính toán hoặc băng thông nhiều hơn trừ khi dấu vết cho thấy nó là ràng buộc

Biết điều gì hiệu quả cũng đồng nghĩa với việc nhận ra điều gì không hiệu quả. Trên thực tế, các nhóm làm việc dưới áp lực thời hạn thường lặp lại cùng một cái bẫy—tự tin tối ưu hóa nhầm trục. Những kiểu lỗi này phổ biến đến mức xứng đáng có tên gọi riêng.

Phản mẫu

Chẩn đoán hệ thống thường là một quá trình loại trừ. Trước khi lao vào các tối ưu hóa kernel phức tạp, hãy để ý những cái bẫy phổ biến sau có thể khiến công sức kỹ thuật bị lãng phí.

  • Cậy phần cứng: Mua bộ tăng tốc (Machine) nhanh hơn để chữa trình tải dữ liệu Python (Data) chậm. Phần cứng mới sẽ chỉ… nhàn rỗi nhanh hơn.
  • Điều chỉnh mô hình vô tội vạ: Thay đổi kiến trúc mạng nơ-ron (Algorithm) trong khi nút thắt cổ chai thực sự là băng thông mạng hoặc I/O đĩa.
  • Tối ưu sớm: Viết các kernel CUDA tùy chỉnh (Machine) trước khi kiểm chứng xem Algorithm có đang làm quá nhiều phép toán không cần thiết hay không.

Mỗi phản mẫu đều có cùng một nguyên nhân gốc: hành động trước khi chẩn đoán. Các nghiên cứu điển hình sau đây cho thấy chẩn đoán đúng nên như thế nào—bắt đầu từ một triệu chứng khó hiểu và lần lượt thu hẹp có hệ thống về trục D·A·M chi phối.

Các nghiên cứu điển hình D·A·M

Những ràng buộc lý thuyết thường hiện ra thành các triệu chứng khó hiểu trong môi trường sản xuất. Các kịch bản đại diện dưới đây minh họa cách áp dụng hệ thống phân loại. Mỗi ca đều theo cùng ba bước chẩn đoán: triệu chứng, chẩn đoán và khắc phục.

Trường hợp 1: Bộ tăng tốc bị đói (Dữ liệu)

Một nhóm cấp phát một phiên bản GPU A100 lớn để tăng tốc huấn luyện, nhưng thời gian huấn luyện hầu như không cải thiện và nvidia-smi cho thấy mức sử dụng GPU dao động từ 10 đến 40 phần trăm. Mẫu này gợi ý bộ tăng tốc đang bị đói nhưng chưa rõ nguyên nhân. Nếu các trace cho thấy có khoảng chờ đầu vào kèm bão hòa ở lưu trữ hoặc CPU do giải mã, thì đường dẫn dữ liệu đang ràng buộc. Khi đó cần can thiệp ở phía trước mô hình. Hãy tối ưu quy trình trích xuất, chuyển đổi, tải (ETL) bằng cách chuyển từ JPEG thô tốn CPU giải mã sang các định dạng tuần tự như TFRecords hoặc WebDataset, tăng mức song song của data loader, và prefetch các batch vào bộ nhớ của bộ tăng tốc.

Trường hợp 2: Vách đá độ trễ (đa trục)

Một dịch vụ đề xuất thời gian thực không đạt SLA về độ trễ 20 ms, trong khi mức sử dụng bộ tăng tốc thấp và kích thước batch là một. Sự kết hợp này gợi ý vấn đề nằm ở chi phí khởi chạy, lưu lượng bộ nhớ hoặc độ sâu tuần tự của mô hình, chứ không phải do chip bị bão hòa. Nếu dấu vết (trace) xác nhận đường dẫn các lớp tuần tự chiếm ưu thế, thêm phần cứng cũng không loại bỏ được nút thắt này; khi đó, tỉa (pruning) hoặc chưng cất tri thức có thể giảm khối lượng công việc cho mô hình. Ngược lại, nếu lưu lượng trọng số chiếm ưu thế, lượng tử hoá có thể giảm số byte phải di chuyển bằng cách dùng INT8, miễn là độ chính xác cho phép. Các phép đo sẽ quyết định cách xử lý.

Trường hợp 3: Bức tường tính toán (Máy)

Bộ tăng tốc được sử dụng tới 99%, băng thông bộ nhớ chưa bão hòa, và quá trình huấn luyện ổn định nhưng kéo dài ba tuần. Nếu các bộ đếm của profiler cũng cho thấy mức chiếm dụng pipeline tính toán cao và Model FLOPs Utilization (MFU) cao, thì khối lượng công việc (workload) bị giới hạn bởi tính toán (compute bound). Đường dữ liệu đang nuôi đủ cho bộ tăng tốc, nên bước tiếp theo phải thay đổi hạng mục tính toán trong “định luật sắt”. Nhóm có thể nâng cấp từ A100 lên bộ tăng tốc lớp H100, mở rộng theo hướng song song dữ liệu, hoặc hạ độ chính xác từ FP32/TF32 xuống BF16 khi an toàn về số học. Trên các đường NVIDIA Tensor Core, thông lượng đỉnh của BF16 thường khoảng 2\(\times\) TF32, còn mức tăng tốc thực tế phụ thuộc vào các kernel và nút thắt cổ chai (Choquette 2023). Tổng lại, ba trường hợp cho thấy cùng một con số sử dụng có thể dẫn đến các bước tiếp theo khác nhau, tùy thuộc vào hành vi hàm mất mát, kích thước batch và áp lực bộ nhớ.

Choquette, Jack. 2023. “NVIDIA Hopper H100 GPU: Scaling Performance.” IEEE Micro 43 (3): 9–17. https://doi.org/10.1109/mm.2023.3256796.
Checkpoint 1.1: Kiểm tra chẩn đoán D·A·M
  1. Một tác vụ huấn luyện cho thấy bộ tăng tốc được sử dụng 95% nhưng hàm mất mát đã chững lại trong hai epoch. Những trục D·A·M nào có thể là nguyên nhân, và tại sao chỉ riêng mức độ sử dụng lại không đủ để phân biệt các nguyên nhân này?
  2. Đồng nghiệp của bạn đề xuất thêm worker cho bộ tải dữ liệu (data loader) vào một tác vụ mà nvidia-smi báo cáo GPU đang được sử dụng 98%. Cần những bằng chứng theo dõi (trace evidence) nào trước khi quyết định liệu việc này có hiệu quả hay không?
  3. Một máy chủ suy luận đáp ứng được mục tiêu mức độ dịch vụ (SLO) về độ trễ khi kích thước batch là 1, nhưng lại thất bại khi kích thước batch là 16. Những yếu tố nào trong “định luật sắt” và những hiệu ứng xếp hàng nào có thể đã thay đổi, và những phép đo nào sẽ giúp xác định yếu tố gây tắc nghẽn?

Ba trường hợp này cho thấy các nút thắt cổ chai có thể vượt qua ranh giới giữa các trục. Sự cố sản xuất hiếm khi gọn gàng như vậy—các triệu chứng thường chồng chéo, và trục chi phối có thể thay đổi trong lúc gỡ lỗi. Phần tiếp theo cung cấp một ma trận khắc phục sự cố có hệ thống cho những kịch bản thực tế phức tạp hơn.

Khắc phục sự cố sản xuất

Để xác định nguyên nhân gốc của các nút thắt cổ chai về hiệu suất, cần loại trừ một cách có hệ thống. Table 5 cung cấp một ma trận chẩn đoán cho các kiểu lỗi phổ biến thường thấy trong quá trình triển khai sản xuất.

Ma trận chẩn đoán gợi ý nghi ngờ điều gì. Câu hỏi tiếp theo là làm sao xác nhận nghi ngờ đó bằng bằng chứng—điều này đòi hỏi các công cụ phân tích hiệu năng (profiling tools) phù hợp.

Table 5: Ma trận chẩn đoán D·A·M: Các giả thuyết và phép đo ban đầu cho những lỗi thường gặp. Hãy xác nhận yếu tố gây tắc nghẽn trước khi can thiệp.
Triệu chứng Giả thuyết Xác nhận bằng Hành động sau Xác nhận
Mức sử dụng Bộ tăng tốc Thấp Thiếu hụt dữ liệu/tài nguyên host Khoảng trống theo dõi; trình tải, CPU, bộ nhớ, bộ đếm khởi chạy Tải trước, song song hóa hoặc cắt giảm khởi chạy.
Độ trễ cao (P99) Thuật toán/runtime/hàng đợi Giai đoạn p99 và độ sâu hàng đợi Tối ưu hóa giai đoạn chiếm ưu thế.
Chi phí huấn luyện cao Hiệu quả công việc hữu ích thấp MFU, giao tiếp, thời gian nhàn rỗi Giảm tổn thất lớn nhất hoặc thay đổi kích thước.
Chi phí chung giữa các GPU cao Giới hạn bởi giao tiếp Dấu vết thiết bị; khoảng trống tập thể Bucket AllReduce; điều chỉnh sự chồng chéo song song dữ liệu.
Hết bộ nhớ (OOM) Thuật toán/Khớp máy Trọng số đỉnh, trạng thái, activation Checkpoint, phân đoạn, lượng tử hoá hoặc thu nhỏ batch.

Bản đồ công cụ

Khi đã có giả thuyết (ví dụ: “khối lượng công việc (workload) có vẻ bị ràng buộc bởi ‘Machine’”), chúng ta cần bằng chứng để xác nhận. Các khái niệm trừu tượng phải được đo lường bằng những tiện ích cụ thể. Table 6 kết nối các thành phần lý thuyết với các công cụ phân tích hiệu năng cụ thể của Linux và Python để kiểm chứng chúng.

Table 6: Bản đồ công cụ D·A·M: Các tiện ích phân tích hiệu năng dùng để chẩn đoán các nút thắt cổ chai theo từng trục D·A·M. Hãy bắt đầu với công cụ chính để phân loại nhanh; dùng các công cụ phụ để phân tích chuyên sâu khi kết quả từ công cụ chính chưa đủ thuyết phục.
Trục Chỉ số chính Công cụ chính Công cụ phụ
Dữ liệu Tải batch và Thời gian chờ Dấu vết profiler của framework iostat, pidstat (I/O/CPU)
Thuật toán FLOPs, Độ sâu mô hình PyTorch Profiler DeepSpeed Flops Profiler
Máy Mức sử dụng bộ tăng tốc, Mức chiếm dụng SM Nsight Compute nvidia-smi, Nsight Systems

Các công cụ phân tích hiệu năng tạo ra những con số thô—tỷ lệ sử dụng, số lượng FLOP và các phép đo băng thông. Chúng chỉ hữu ích khi đặt trong ngữ cảnh của khối lượng công việc (workload) và phần cứng. Thẻ điểm D·A·M cung cấp các tín hiệu sàng lọc chứ không phải tiêu chuẩn chung, giúp thu hẹp những phép đo và biện pháp can thiệp đáng chú ý.

Thẻ điểm D·A·M

Để vượt khỏi việc phỏng đoán định tính, các chỉ số hiệu quả trong table 7 giúp quyết định bước điều tra tiếp theo. Cách trình bày dạng thẻ báo cáo này hỗ trợ so sánh ban đầu, nhưng không có hàng nào đưa ra điểm số chung cho mọi trường hợp. MFU2 đặc biệt hữu ích cho việc huấn luyện các mô hình lớn.

2 MFU (mức sử dụng FLOPs của mô hình): Tỷ lệ giữa FLOP/s mà mô hình thực sự đạt được so với FLOP/s đỉnh lý thuyết của phần cứng, được giới thiệu trong bài báo PaLM (Chowdhery et al. 2022). Khác với mức sử dụng bộ tăng tốc ở dạng thô (tính mọi công việc mà bộ tăng tốc thực hiện), MFU đo tốc độ tính toán của mô hình so với thông lượng đỉnh của phần cứng, nên các công việc không thuộc mô hình và chi phí hệ thống không được tính vào FLOPs mô hình đạt được. Xác định nút thắt cổ chai trình bày MFU như một công cụ chẩn đoán trong huấn luyện.

Chowdhery, Aakanksha, Sharan Narang, Jacob Devlin, Maarten Bosma, Gaurav Mishra, Adam Roberts, Paul Barham, et al. 2022. “PaLM: Scaling Language Modeling with Pathways.” arXiv Preprint arXiv:2204.02311.
Table 7: Các chỉ số sàng lọc D·A·M: Đây là những tín hiệu phụ thuộc ngữ cảnh để phục vụ điều tra, không phải điểm số mang tính phổ quát.
Trục Chỉ số Định nghĩa Điều tra Tín hiệu mạnh
Dữ liệu Chi phí chung I/O \(\dfrac{\text{Data Wait Time}}{\text{Total Step Time}}\) \(>\) 10% (screen) \(<\) 1% (strong)
Thuật toán Công việc có thể tránh được Profiler hoặc ablation tìm thấy các hoạt động dư thừa Tìm thấy công việc dư thừa Khối lượng công việc đầu cuối giảm
Máy MFU \(\dfrac{\text{Achieved model FLOP/s}}{\text{Peak FLOP/s}}\) \(<\) 30% (mô hình lớn) \(>\) 50% (cùng chế độ)

Thẻ điểm và Mô hình Roofline đều trả lời các câu hỏi về hiệu quả, nhưng ở các thang khác nhau. Thẻ điểm sàng lọc hệ thống hiện tại bằng các chỉ số tùy ngữ cảnh. Còn các quy luật mở rộng và ẩn dụ roofline về thông tin đặt câu hỏi về những gì có thể xảy ra khi hệ thống mở rộng vượt ra ngoài kích thước hiện tại.

Các quy luật mở rộng so với Roofline

Trong kỹ thuật hệ thống, cần phân biệt giữa quỹ đạo tăng trưởng và giới hạn cơ bản.

Các quy luật mở rộng (hành trình)

Các quy luật mở rộng3 là những quy luật lũy thừa thực nghiệm, dự đoán độ lỗi trên tập giữ lại thay đổi ra sao khi tăng tài nguyên trong phạm vi đã được khớp. Hai kết quả tiêu biểu là quy luật mở rộng của Kaplan (Kaplan et al. 2020), nghiên cứu độ lỗi theo số lượng tham số (\(P\)), dữ liệu (\(D\)), và tổng số phép toán (\(O\)); và quy luật mở rộng của Chinchilla (Hoffmann et al. 2022), ước tính điểm cân bằng tối ưu về tính toán cho miền mô hình ngôn ngữ tự hồi quy dày đặc được nghiên cứu, thường được tóm tắt là khoảng 20 token huấn luyện cho mỗi tham số (\(D \approx 20P\)).

3 Các quy luật mở rộng: Đây là các mối quan hệ thực nghiệm, thường là các quy luật lũy thừa với số mũ âm đã được khớp, dùng để dự đoán loss của mô hình dựa trên kích thước tập dữ liệu, số lượng tham số hoặc ngân sách tính toán. Kaplan et al. (2020) đã nghiên cứu các mối quan hệ này cho các mô hình ngôn ngữ thần kinh tại OpenAI; sau đó, Hoffmann et al. (2022) ước tính sự đánh đổi huấn luyện tối ưu về mặt tính toán cho miền mô hình ngôn ngữ dày đặc mà họ khảo sát. Biên tối ưu tính toán phát triển chi tiết biên tối ưu theo tính toán và phép chẩn đoán thiếu dữ liệu đi kèm.

Kaplan, J., S. McCandlish, T. Henighan, T. B. Brown, B. Chess, R. Child, S. Gray, A. Radford, J. Wu, and D. Amodei. 2020. “Scaling Laws for Neural Language Models.” ArXiv Preprint abs/2001.08361.
Hoffmann, Jordan, Sebastian Borgeaud, Arthur Mensch, Elena Buchatskaya, Trevor Cai, Eliza Rutherford, Diego de Las Casas, et al. 2022. “Training Compute-Optimal Large Language Models.” Advances in Neural Information Processing Systems (NeurIPS) 35: 30016–30. https://doi.org/10.52202/068431-2176.

Ở góc độ kinh tế, các mô hình khớp này ước tính loss trên tập giữ lại thay đổi theo mức compute như thế nào trong phạm vi đã quan sát. Chúng không đảm bảo giảm tỷ lệ lỗi của tác vụ, và cũng không thể ngoại suy nguyên xi sang các kiến trúc và phân phối dữ liệu khác.

Đường mái thông tin (điểm đến)

Đường mái thông tin ở đây được dùng như một ẩn dụ mang tính chẩn đoán, chứ không phải một quy luật định lượng tiêu chuẩn. Hình ảnh “điểm đến” của nó gợi ý những giới hạn về những gì có thể học được từ dữ liệu sẵn có. Trong bài toán phân loại, với một phân phối dữ liệu và hàm lỗi cố định, tỷ lệ lỗi Bayes4 là một ngưỡng lỗi tối thiểu không thể giảm được (error floor), chứ không phải là một giới hạn trên (ceiling). Nhiễu, nhãn mơ hồ, lỗ hổng độ bao phủ, và dịch chuyển phân phối có thể tạo ra các giới hạn về chất lượng dữ liệu, nhưng chúng không xác định một độ dốc hay điểm gãy phổ quát nào.

4 Tỷ lệ lỗi Bayes: Tỷ lệ lỗi thấp nhất có thể đạt được với hàm mất mát 0–1 cho bất kỳ bộ phân loại nào trên một phân phối dữ liệu nhất định, được xác định bởi xác suất tiên nghiệm của các lớp và mức độ chồng lấn giữa các phân phối điều kiện theo lớp (Goodfellow et al. 2016). Dù có bao nhiêu dữ liệu, tham số hay tài nguyên tính toán cũng không thể giảm lỗi xuống dưới mức sàn lý thuyết này.

Goodfellow, Ian, Yoshua Bengio, and Aaron Courville. 2016. Deep Learning. MIT Press.

Bài học chẩn đoán ở đây hẹp hơn. Các định luật mở rộng mô tả một quỹ đạo cải thiện đã được khớp, trong khi ẩn dụ ‘đường mái thông tin’ gợi ý ta tìm các giới hạn do chất lượng dữ liệu đặt ra. Nếu đường cong hàm mất mát chững lại so với xu hướng đã khớp, hãy kiểm tra tối ưu hóa, năng lực mô hình, nhiễu trong đánh giá và chất lượng dữ liệu; bản thân việc đường cong chững lại không cho biết nguyên nhân nào là chủ đạo. Mức sàn Bayes mô tả bộ phân loại tốt nhất có thể đạt được cho phân bố đã chỉ định. Việc thêm bộ tăng tốc hay tham số chỉ vô ích sau khi các phép đo xác nhận rằng chất lượng dữ liệu đang là yếu tố giới hạn. Dù bạn đang gỡ lỗi một bước huấn luyện, đánh giá mức sử dụng phần cứng, hay lập kế hoạch mở rộng, hãy đo xem trục nào đang là giới hạn trước khi chọn đòn bẩy.

Tóm tắt

Các công cụ này tạo thành một quy trình chẩn đoán thống nhất. D·A·M giúp xác định các nguyên nhân tiềm năng trên ba khía cạnh: Dữ liệu, Thuật toán và Máy. Định luật sắt và cường độ số học chuyển các nguyên nhân đó thành thời gian, phép toán và byte, trong khi các nghiên cứu điển hình, các anti-pattern, bản đồ công cụ và bảng điểm cho thấy cách kiểm tra chúng trong môi trường sản xuất. Các định luật mở rộng và ‘đường mái thông tin’ sau đó giúp tách quỹ đạo cải thiện quan sát được khỏi các giới hạn do chất lượng dữ liệu. Hãy dùng framework này như một vòng lặp, không phải như một cái nhãn.

Key Takeaways: Nên bắt đầu từ đâu
  • Hãy bắt đầu với các giả thuyết cắt ngang các khía cạnh; một triệu chứng hiếm khi tự chỉ ra nguyên nhân.
  • Chuyển mỗi giả thuyết thành thuật ngữ tương ứng trong định luật sắt và một phép đo có thể bác bỏ nó.
  • Sử dụng cường độ số học và bảng điểm để xác định yếu tố đang giới hạn, chứ không phải để chấm điểm chung chung.
  • Áp dụng đòn bẩy tương ứng và đo lường lại từ đầu đến cuối; một lợi ích cục bộ mà không làm thay đổi yếu tố đang giới hạn thì không phải là cải tiến ở cấp hệ thống.
Back to top