Nền tảng Dữ liệu
Các vấn đề về dữ liệu hiếm khi lộ diện như “vấn đề dữ liệu”; chúng thường hiện ra dưới dạng một lần huấn luyện mãi không nhanh hơn, một bộ tăng tốc ngồi không, hoặc độ chính xác tụt dần dù dashboard vẫn báo xanh. Để phần lập luận của chương tập trung vào thiết kế hệ thống, phụ lục này gom các phép tính nháp và công cụ thống kê giúp lần từ những triệu chứng đó về các nút thắt dữ liệu đo được: thời gian truyền, chi phí bố trí lưu trữ, chẩn đoán trôi dạt và các công cụ ổn định số. Các công cụ ở đây dựa trên xác suất cơ bản và vế dữ liệu của định luật sắt.
Cách sử dụng Phụ lục này
Phụ lục này được thiết kế như một tài liệu tham khảo. Hãy mở nó khi bạn cần gỡ lỗi “huấn luyện chậm”, “bộ tăng tốc ít được sử dụng” hoặc “độ chính xác môi trường sản xuất bị trôi dạt”, và cần con đường nhanh nhất từ triệu chứng đến phép đo.
Các quy ước được sử dụng ở đây tuân theo ký hiệu chung của sách (ví dụ, \(B\) được dành cho kích thước batch và \(\text{BW}\) biểu thị băng thông).
- Khi dữ liệu không di chuyển được: Bắt đầu với table 1 và phương trình thời gian truyền tải trong section 1.1.1.
- Khi bộ tăng tốc bị đói: Sử dụng table 2 và thảo luận về bố cục trong section 1.1.3.
- Khi các pipeline bùng nổ về chi phí: Sử dụng các phép cơ bản trong section 1.1.4, đặc biệt là các xáo trộn do phép nối gây ra.
- Khi “trung bình có vẻ ổn” nhưng người dùng phàn nàn: Sử dụng section 1.2.1 và xác suất đuôi ở mức phiên.
- Khi độ chính xác trôi dạt một cách âm thầm: Sử dụng section 1.2.2 để so sánh các phân phối đầy đủ.
Bức tranh dữ liệu có thể giống như một vườn bách thú của các định dạng, mã hóa và các trường hợp edge, nhưng phụ lục này tập trung vào những hằng số cấu trúc ràng buộc mọi hệ thống ML.
Với những điểm tham chiếu đó đã được thiết lập, phụ lục bắt đầu với các ràng buộc vật lý của kỹ thuật dữ liệu và sau đó chuyển sang việc giám sát thống kê giúp duy trì sức khỏe cho các hệ thống ML. Từ các định dạng lưu trữ quyết định thông lượng I/O đến các chỉ số trôi dạt phát hiện lỗi âm thầm, những nền tảng này kết nối trực tiếp với các pipeline dữ liệu trong Kiến trúc pipeline dữ liệu và giám sát vận hành trong Giám sát mô hình và hạ tầng.
Nền tảng Kỹ thuật Dữ liệu
Hiểu các ràng buộc phần cứng mới chỉ là một nửa vấn đề; chúng ta còn phải định hình dữ liệu cho phù hợp với chúng. Kỹ thuật dữ liệu áp dụng các nguyên tắc của hệ thống phân cấp bộ nhớ vào định dạng lưu trữ và thiết kế pipeline, để bộ tăng tốc không bao giờ thiếu dữ liệu. Quá trình này bắt đầu từ việc nhận ra rằng dữ liệu là thứ vật lý—nó có dung lượng, cần thời gian để di chuyển và tiêu tốn năng lượng để đọc, giải mã.
Tính nhẩm: Vật lý của trọng lực dữ liệu
Trọng lực dữ liệu1 là một phép ẩn dụ dựa trên các phép tính về thời gian truyền. Khác với năng lực tính toán tăng lên qua từng năm, tốc độ ánh sáng là hằng số và băng thông mạng là tài nguyên hữu hạn. Khi các tập dữ liệu đủ lớn, quán tính thực tế của chúng tăng lên—việc di chuyển chúng có thể tốn nhiều thời gian và năng lượng hơn là đưa tính toán tới nơi dữ liệu đang nằm.
1 Trọng lực dữ liệu: Được Dave McCrory đặt ra vào năm 2010 để mô tả cách các tập dữ liệu lớn thu hút các dịch vụ và ứng dụng đến gần chúng, giống như các vật thể có khối lượng lớn hút các vật thể nhỏ hơn trong vật lý (McCrory 2010). Sự so sánh này rất phù hợp: “vận tốc thoát” cần thiết để di chuyển một tập dữ liệu quy mô petabyte thường được đo bằng tuần.
Thời gian truyền lý tưởng ở tốc độ đường truyền là \(T = D_{\text{vol}}/\text{BW}\) sau khi chuyển đổi dung lượng dữ liệu và băng thông về cùng đơn vị (các phép tính dưới đây chuyển đổi rõ ràng giữa byte thập phân và bit trên giây). Với các dung lượng lớn như ở đây, độ trễ có thể bỏ qua; phương trình đầy đủ được trình bày trong Băng thông so với độ trễ. Table 1 đưa ra các giới hạn dưới; chi phí giao thức và giới hạn của điểm cuối sẽ làm tăng các giá trị này.
| Khối lượng dữ liệu | 1 Gbps (WAN tiêu chuẩn) | 10 Gbps (WAN cao cấp) | 100 Gbps (Kết nối trực tiếp) | Xe tải (Minh họa) |
|---|---|---|---|---|
| 1 TB | 2.2 hours | 13.3 minutes | 80 seconds | N/A |
| 100 TB | 9 days | 22.2 hours | 2.2 hours | N/A |
| 1 PB | 3 months | 9 days | 22.2 hours | 2 days |
Chi phí của tuần tự hóa
Ngay cả khi dữ liệu đã đến máy, chi phí tuần tự hóa vẫn là một trở ngại cuối cùng.2 Như table 2 chỉ ra, nhiều kỹ sư rất tỉ mỉ tối ưu hóa các kernel của bộ tăng tốc nhưng lại bỏ qua chi phí CPU để giải mã dữ liệu. Việc xử lý các định dạng văn bản như JavaScript Object Notation (JSON) hay CSV tiêu tốn rất nhiều tài nguyên CPU, thường khiến bộ tăng tốc phải chờ trong khi CPU vất vả chuyển các chuỗi thành số dấu phẩy động.
2 Tuần tự hóa: Từ tiếng Latin serialis (có nghĩa là tạo thành một chuỗi). Đây là quá trình chuyển đổi các cấu trúc dữ liệu trong bộ nhớ thành một luồng byte để lưu trữ hoặc truyền tải, và quá trình ngược lại (giải tuần tự hóa). Trong các pipeline ML, việc chọn định dạng tuần tự hóa có thể ảnh hưởng rất lớn đến tổng thời gian huấn luyện; Thu nạp dữ liệu sẽ trình bày các chiến lược thiết kế pipeline để giảm thiểu chi phí này.
| Định dạng | Tốc độ giải mã (MB/s) | Chi phí giải mã CPU tương đối | Phù hợp |
|---|---|---|---|
| CSV/JSON | ~100 MB/s | High | Kiểm tra/trao đổi |
| Protobuf | ~300 MB/s | Medium | RPC/Tin nhắn |
| Parquet | ~1,000 MB/s | Low | Lưu trữ dạng cột |
Định dạng theo hàng và theo cột
Việc chọn định dạng tệp quyết định “cơ chế” dữ liệu được đọc. Các định dạng hướng hàng như CSV và JSON lưu dữ liệu theo từng bản ghi, nên để đọc trường age vẫn phải phân tích từng hàng. Cách này hợp với các log ghi nối tiếp, nhưng không phù hợp khi phân tích các đặc trưng đã chọn. Parquet lưu các khối cột nén trên đĩa, còn Arrow cung cấp định dạng cột trong bộ nhớ và IPC. Trình đọc Parquet có thể dùng projection pushdown để lấy các khối cột được chọn, và cả hai định dạng đều hỗ trợ xử lý vector hóa. So sánh hai cách sắp xếp trong figure 1 để thấy vì sao truy cập theo cột giúp tránh quét những byte không cần thiết.
Các bố cục trong figure 1 khác nhau ở lượng byte thừa lọt vào đường dữ liệu huấn luyện.
Systems Perspective 1.1: Vấn đề bộ tăng tốc bị bỏ đói
Đại số của dữ liệu
Kỹ thuật đặc trưng biến các bản ghi thô thành các cột mà mô hình có thể học, và phép biến đổi đó thường là bài toán luồng dữ liệu trước khi là bài toán mô hình. Một pipeline trước hết thu hẹp tập dữ liệu, sau đó chọn đặc trưng, rồi gắn thêm ngữ cảnh từ các bảng khác. Ba bước này tương ứng với ba phép cơ bản trong Ngôn ngữ truy vấn có cấu trúc (SQL), và chi phí tính toán của chúng quyết định liệu tác vụ đặc trưng được xử lý cục bộ, phải quét các byte không cần thiết, hay biến thành một thao tác xáo trộn qua mạng.
- Lựa chọn (\(\sigma\)): Lọc các hàng (ví dụ,
WHERE age > 30).- Chi phí: \(\mathcal{O}(\log N + K)\) nếu tra cứu chỉ mục B-tree trả về \(K\) hàng; \(\mathcal{O}(N)\) cho một lần quét toàn bộ.
- Phép chiếu (\(\pi\)): Chọn các cột (ví dụ,
SELECT age).- Chi phí: Gồm các khối dữ liệu được chọn, cộng thêm giải mã và siêu dữ liệu trong các định dạng cột. Ví dụ định dạng hàng này phải đọc 1 KB cho một số nguyên 4-byte, lãng phí 99.6 percent lượng đọc.
- Join (\(\bowtie\)): Kết hợp các bảng. Đây là phép toán tốn kém nhất.
- Shuffle Join: Cả hai bảng được phân vùng theo khóa và trao đổi qua mạng.
- Chi phí: Việc xáo trộn lại cả hai bảng 1 TB di chuyển khoảng ~2 TB; việc phân vùng và tính cục bộ có thể giảm điều này.
- Broadcast Join: Một bảng nhỏ được gửi đến tất cả các worker.
- Chi phí: \(S(W-1)\) byte; bảng kích thước \(S\)-byte phải nằm trên mỗi worker trong số \(W\) worker.
- Shuffle Join: Cả hai bảng được phân vùng theo khóa và trao đổi qua mạng.
Việc nắm rõ các định dạng dữ liệu, chi phí tuần tự hóa và các phép toán đại số cơ bản giúp chúng ta biết cách di chuyển dữ liệu hiệu quả. Tuy nhiên, ngay cả một pipeline được thiết kế hoàn hảo cũng có thể âm thầm gặp lỗi nếu dữ liệu mà nó mang theo thay đổi đặc tính theo thời gian. Để phát hiện sự thay đổi đó—và định lượng mức độ ảnh hưởng của nó—chúng ta cần một bộ công cụ khác: xác suất và thống kê.
Xác suất và Thống kê
Khi dữ liệu đã luân chuyển qua các pipeline, chúng ta cần các công cụ toán học để đảm bảo chất lượng và tính nhất quán của nó. Xác suất và thống kê cung cấp ngôn ngữ để giám sát tình trạng hệ thống, phát hiện các lỗi âm thầm do trôi dạt dữ liệu, và quản lý sự không chắc chắn.
Các phân phối và đuôi dài
Trong các hệ thống, giá trị trung bình thường dễ gây hiểu lầm. Các phân phối độ trễ thường có đuôi dài, và các dịch vụ mà người dùng nhìn thấy thường bị chi phối bởi hành vi ở các phân vị cao hơn là thời gian phản hồi trung bình (Dean and Barroso 2013). Độ trễ “P99” (phân vị thứ 99) là 500 ms có nghĩa là tối đa 1 phần trăm yêu cầu mất hơn 500 ms; với nhiều yêu cầu trong một phiên, tỷ lệ người dùng thấy ít nhất một yêu cầu chậm có thể cao hơn nhiều. Ở quy mô lớn (1M người dùng), ngay cả tỷ lệ 1 phần trăm người dùng bị ảnh hưởng cũng sẽ tác động đến 10,000 users người dùng.
Napkin Math 1.1: Trải nghiệm trung vị
Hiểu biết về hệ thống: Theo mô hình này, một phiên gồm 100 yêu cầu có khả năng cao hơn 50% sẽ xuất hiện một sự kiện vượt quá P99. Các đợt chậm có tương quan có thể làm thay đổi xác suất này (Dean and Barroso 2013).
Đo lường sự trôi dạt (phân kỳ)
Vì các phân phối có đuôi dài, nơi ẩn chứa những lỗi nguy hiểm nhất, nên các số liệu đơn giản như “mean shift” là không đủ. Chúng ta cần các công cụ có thể so sánh toàn bộ hình dạng của phân phối. Phát hiện trôi dạt giữa phân phối phục vụ (serving) (\(P_t\)) và phân phối huấn luyện (\(P_0\)) đòi hỏi phải đo “khoảng cách” giữa các phân phối.
Đối với các kết quả rời rạc \(x\), equation 1 diễn giải độ phân kỳ KL3 như chi phí mã hóa bổ sung kỳ vọng khi xấp xỉ \(P_t\) bằng \(P_0\) (Kullback and Leibler 1951; Cover and Thomas 2006). Dạng này chỉ hữu hạn khi \(P_0(x) > 0\) ở mọi nơi \(P_t(x) > 0\); vì vậy, các triển khai trong môi trường sản xuất cần làm mịn tường minh hoặc xử lý giá trị bằng 0. \[ \mathcal{D}_{\text{KL}}(P_t \lVert P_0) = \sum_x P_t(x) \log \frac{P_t(x)}{P_0(x)} \tag{1}\]
3 Độ phân kỳ KL: Được đặt theo tên của Solomon Kullback và Richard Leibler, những người đã giới thiệu khái niệm này vào năm 1951. Còn gọi là entropy tương đối, nó đo lượng thông tin bổ sung dự kiến cần để mã hóa các mẫu từ một phân phối bằng một mã được tối ưu cho một phân phối khác. Trong theo dõi trôi dạt ở cuốn sách này, hướng chuẩn là \(\mathcal{D}_{\text{KL}}(P_t \lVert P_0)\). Với logarit tự nhiên, như ví dụ ở trên, đơn vị là nats; với logarit cơ số 2, đơn vị là bit. Trong ML sản xuất, độ phân kỳ KL là nền tảng lý thuyết của nhiều chỉ số phát hiện trôi dạt.
Napkin Math 1.2: Ví dụ minh họa: Độ phân kỳ KL để phát hiện sự trôi dạt
Toán học:
Phân phối huấn luyện \(P_0\): [0.60, 0.30, 0.10]. Phân phối phục vụ (serving) \(P_t\): [0.45, 0.40, 0.15].
\[\begin{gather*} \mathcal{D}_{\text{KL}}(P_t \lVert P_0) = 0.45 \log\frac{0.45}{0.60} + 0.40 \log\frac{0.40}{0.30} + 0.15 \log\frac{0.15}{0.10}\end{gather*}\] \[\begin{gather*} = 0.45 \times (-0.2877) + 0.40 \times (0.2877) + 0.15 \times (0.4055) \\[-1pt] = -0.1295 + 0.1151 + 0.0608 = 0.0464\text{ nats}\end{gather*}\] \[\begin{gather*} \mathcal{D}_{\text{KL}}(P_0 \lVert P_t) = 0.60 \log\frac{0.60}{0.45} + 0.30 \log\frac{0.30}{0.40} + 0.10 \log\frac{0.10}{0.15}\end{gather*}\] \[\begin{gather*} = 0.60 \times 0.2877 + 0.30 \times (-0.2877) + 0.10 \times (-0.4055) \\[-1pt] = 0.1726 + (-0.0863) + (-0.0405) = 0.0458\text{ nats}\end{gather*}\]
Lưu ý sự bất đối xứng: \(\mathcal{D}_{\text{KL}}(P_0 \lVert P_t) \neq \mathcal{D}_{\text{KL}}(P_t \lVert P_0)\). Chỉ số ổn định quần thể (PSI) giúp làm đối xứng điều này; phép tính dưới đây sử dụng logarit tự nhiên:
\[\begin{gather*} \text{PSI} = \sum (P_{0,i} - P_{t,i}) \log\frac{P_{0,i}}{P_{t,i}} = (0.15)(0.2877) + (-0.10)(-0.2877) + (-0.05)(-0.4055) \\[-1pt] = 0.04315 + 0.02877 + 0.02027 = 0.0922 \end{gather*}\]
Góc nhìn hệ thống: Vì PSI = 0.0922 < 0.2, sự trôi dạt này chưa vượt qua ngưỡng minh họa cho việc xem xét thủ công được dùng ở đây. Phản ứng đúng là giữ đặc trưng này trên bảng điều khiển giám sát và tìm thêm các tín hiệu trôi dạt để đối chiếu, thay vì chỉ huấn luyện lại dựa trên thống kê này.
Ngưỡng này vẫn mang tính minh họa: ý nghĩa của nó phụ thuộc vào kích thước mẫu, cách phân nhóm (binning), làm mịn (smoothing) và xử lý số 0. Việc huấn luyện lại đòi hỏi bằng chứng về chất lượng mô hình.
Cả độ phân kỳ KL và PSI đều dựa trên một framework sâu hơn—lý thuyết thông tin—framework này cung cấp các đơn vị và giới hạn, giúp các chỉ số này có cơ sở bài bản thay vì tùy tiện.
Lý thuyết thông tin cho các hệ thống
Một lần huấn luyện có thể dùng nhiều ví dụ hơn, chạy lâu hơn, nhưng vẫn ngừng cải thiện nếu dữ liệu bổ sung mang quá ít tín hiệu hữu ích. Lúc đó, nút thắt không chỉ là tính toán hay băng thông; mà là lượng thông tin mà pipeline dữ liệu chuyển tới bộ học. Đường mái thông tin (điểm đến) xem giới hạn chất lượng dữ liệu này như một ràng buộc chẩn đoán, và lý thuyết thông tin cung cấp các đơn vị để lập luận về nó.
Entropy (\(H\))4 là mức độ không chắc chắn trung bình của một phân phối, được định nghĩa \(H(X) = -\sum p(x) \log p(x)\). Cơ số logarit quyết định đơn vị: logarit tự nhiên cho nats, còn \(\log_2\) cho bit. Một phân phối đều có entropy cực đại, nhưng chỉ trên một miền hỗ trợ hữu hạn cố định. Điều này liên hệ trực tiếp với độ phân kỳ KL ở trên: \(\mathcal{D}_{\text{KL}}\) đo chi phí mã hóa phát sinh thêm khi dùng sai phân phối.
4 Entropy: Shannon đã đưa ra thuật ngữ này vào năm 1948 để định lượng lượng thông tin (Shannon 1948). Trong ngữ cảnh hệ thống, entropy Shannon là giới hạn dưới của độ dài mã không mất mát trung bình. Các mã tiền tố thực tế có thể tiến sát giới hạn này, và các mã khối có thể đạt tới nó một cách tiệm cận. Với \(\log_2\), đơn vị là bit; dùng logarit tự nhiên thì đơn vị là nats. Những giới hạn này giúp xác định tỷ lệ nén và kích thước của pipeline dữ liệu.
Mật độ thông tin được dùng ở đây như một heuristic ở cấp độ cuốn sách để chỉ lượng tín hiệu hữu ích cho việc học trên mỗi đơn vị lưu trữ, chứ không phải một đại lượng chuẩn của lý thuyết thông tin.
Tỷ lệ tín hiệu trên nhiễu (SNR) là tỷ số giữa công suất tín hiệu và công suất nhiễu. Trong ML, sách này dùng SNR thấp theo nghĩa định tính để chỉ dữ liệu mà cấu trúc liên quan đến tác vụ yếu so với nhiễu; thêm compute cũng không bù được phần tín hiệu liên quan đến tác vụ bị thiếu.
Logits và độ ổn định số
Các bộ phân loại dùng mạng nơ-ron thường trả về một vector các logits5 \(\mathbf{z}\) (các điểm chưa được chuẩn hóa). Với chỉ số lớp \(i\), softmax chuẩn hóa \(z_i\) trên tất cả các chỉ số lớp \(j\) để tạo ra xác suất:
5 Logit: Joseph Berkson đã đặt ra thuật ngữ này vào năm 1944, theo phép đặt tên tương tự probit. Hàm logit là hàm nghịch đảo của hàm logistic (sigmoid): \(\text{logit}(p) = \log(p/(1-p))\). Trong deep learning, “logits” thường được dùng rộng rãi để chỉ đầu ra thô, chưa được chuẩn hóa của lớp tuyến tính cuối cùng, trước khi áp dụng bất kỳ hàm activation nào.
\[ \text{Softmax}(z_i) = \frac{e^{z_i}}{\sum e^{z_j}} \]
Vấn đề là nếu \(z_i\) rất lớn (ví dụ, 100), thì \(e^{z_i}\) sẽ tràn trên các định dạng số phổ biến dùng trong huấn luyện và suy luận như FP32, BF16 và FP16. FP64 có thể biểu diễn giá trị cụ thể này, nhưng các kernel ML trong môi trường sản xuất hiếm khi dùng FP64 cho softmax. Giải pháp là tính trong không gian logarit: thủ thuật “Log-Sum-Exp” cho phép tính \(\log\left(\sum e^{z_j}\right)\) mà không cần trực tiếp tính các số mũ khổng lồ, giúp giữ được độ chính xác số học.6
6 Log-sum-exp: Được cài đặt dưới dạng torch.logsumexp trong PyTorch và scipy.special.logsumexp trong SciPy. Thủ thuật này dựa trên đẳng thức \(\log\left(\sum e^{x_i}\right) = a + \log\left(\sum e^{x_i - a}\right)\), trong đó \(a = \max(x_i)\). Khi đó, các giá trị đã dịch chuyển \(x_i - a\) luôn \(\le 0\), đảm bảo hàm mũ không bị tràn.
Một ví dụ nhỏ có tính minh họa cho thấy vì sao thủ thuật này quan trọng trong thực tế, ngay cả với các giá trị logit lớn nhưng vẫn hợp lý:
Napkin Math 1.3: Log-sum-exp minh họa
Không dùng thủ thuật (softmax thông thường): \[\text{ $\exp(100) \approx 2.7 \times 10^{43}$, $\exp(101) \approx 7.3 \times 10^{43}$, $\exp(102) \approx 2.0 \times 10^{44}$}\]
Các số này có thể biểu diễn trong FP64 nhưng vượt quá khả năng của FP32 (tối đa \(\approx 3.4 \times 10^{38}\)). Với FP16 (tối đa \(\approx 65{,}504\)), ngay cả \(e^{12}\) cũng bị tràn. Các logit thô hiếm khi đạt đến độ lớn 100, nhưng các giá trị trung gian lớn vẫn có thể xuất hiện (ví dụ: điểm chú ý chưa được điều chỉnh tỷ lệ hoặc đầu ra quá tự tin). Vì FP16 và BF16 là độ chính xác tiêu chuẩn trong huấn luyện, softmax thông thường có nguy cơ tràn đủ thường xuyên, nên dạng ổn định được dùng mặc định.
Với thủ thuật: Trừ đi \(a = \max(\mathbf{z}) =\) 102:
Các logit đã dịch chuyển: \(\mathbf{z} - a =\) \(\lbrack -2, -1, 0 \rbrack\)
Các giá trị sau khi lấy mũ: \(\exp(-2) \approx 0.135\), \(\exp(-1) \approx 0.368\), \(\exp(0) = 1.0\)
Tổng = 1.503. LogSumExp = 102 \(+ \log(1.503) = 102.408\).
Softmax: \(\lbrack 0.135/1.503,\; 0.368/1.503,\; 1.0/1.503 \rbrack = \lbrack 0.090,\; 0.245,\; 0.665 \rbrack\)
Góc nhìn hệ thống: Các giá trị đã dịch chuyển sau khi lấy mũ và các xác suất softmax thu được đều nằm trong khoảng \([0, 1]\)—không có nguy cơ tràn, ngay cả với FP16.
Tổng hợp lại, các ví dụ minh họa này kết nối trọn chuỗi, từ việc di chuyển dữ liệu ở mức vật lý đến dịch chuyển phân phối và ổn định số.
Tóm tắt
Các công cụ trong phụ lục này—độ đo nhận biết phần đuôi, các độ phân kỳ trôi dạt, các cận theo lý thuyết thông tin và các kỹ thuật ổn định số—giúp chẩn đoán định lượng các lỗi liên quan đến dữ liệu, thay vì chỉ dựa vào các giải thích mang tính giai thoại.