Lời nói đầu

Cuốn sách trước của tôi, Hiểu thấu AI Agents (Understanding AI Agents in Depth), bàn về thiết kế kiến trúc và thực hành kỹ thuật của các agent. Trong quá trình trò chuyện với độc giả và trả lời câu hỏi của họ, tôi ngày càng nhận ra rằng phát triển các ứng dụng model tốt cũng đòi hỏi phải hiểu hạ tầng mà những ứng dụng đó chạy trên đó. Một mặt là bản thân model: nó xử lý đầu vào như thế nào, sinh đầu ra ra sao, và tương tác với context cũng như môi trường như thế nào. Mặt khác là hệ thống thực thi của model: tham số và trạng thái context được lưu ở đâu, tính toán được thực hiện ra sao, nhiều accelerator hợp tác với nhau như thế nào, và các lời gọi model kết nối với chương trình công cụ theo cách nào. Cuốn sách này ra đời từ chính nhận thức đó — nó bàn về hạ tầng hỗ trợ quá trình training và inference của model: AI Infrastructure.

Để hiểu vì sao các nhà phát triển ứng dụng cũng cần kiến thức nền tảng này, hãy xét một phép so sánh quen thuộc. Hầu hết kỹ sư phần mềm không cần tự phát triển hệ điều hành, trình biên dịch hay chip, nhưng họ vẫn cần học về hệ điều hành, lý thuyết trình biên dịch và kiến trúc máy tính. Kiến thức này giúp chúng ta hiểu các tầng trừu tượng (abstraction) mà chương trình phụ thuộc vào, cùng các cài đặt phía sau những tầng trừu tượng đó. Cấp một khối bộ nhớ, đọc một file, gọi một hàm — những thao tác này trông có vẻ đơn giản, nhưng mỗi cái đều mang theo chi phí tài nguyên và thời gian riêng. Hiểu được những chi phí này mới giúp ta giải thích vì sao một chương trình chạy chậm và làm sao để cải thiện nó. Phát triển ứng dụng dựa trên model cũng cần một nền tảng tương tự. Chọn model lớn bao nhiêu, giữ lại bao nhiêu context, cho phép bao nhiêu request đồng thời, đặt tác vụ ở local hay trên cloud — tất cả những lựa chọn này đều thay đổi khối lượng công việc mà hệ thống cần hoàn thành.

Sự dịch chuyển của tầng trừu tượng lập trình: từ hệ điều hành đến model context

Trừu tượng hóa lập trình đang dịch chuyển dần về phía model. Các ứng dụng không còn được mô tả chỉ bằng code; khả năng xử lý bất ngờ của model cho phép một ứng dụng được xác định bằng code + model + context. Khi model trở thành hạt nhân của ứng dụng, hạ tầng mà model chạy trên nó trở thành hạ tầng mà ứng dụng phụ thuộc vào. Laptop và PC có thể chạy một cửa sổ hội thoại, nhưng không đủ tài nguyên để xử lý hàng triệu người dùng tương tác qua model. Việc di chuyển lớp trừu tượng này kéo theo sự di chuyển của kiến thức hệ thống mà lập trình viên cần: từ việc quản lý ghi chép, đọc/ghi và lập lịch của hệ điều hành, sang việc ước lượng các phép tính và truyền dữ liệu mà model yêu cầu.

Ràng buộc là nguồn gốc của thiết kế

Ràng buộc là nguồn gốc của thiết kế. Năm 2016, khi thực tập tại Microsoft Research Asia, tôi cùng một nhóm nghiên cứu việc dùng FPGA để tăng tốc các mạng nơ-ron sâu dùng trong xếp hạng tìm kiếm của Microsoft Bing. Trọng số model liên tục được di chuyển từ bộ nhớ ngoài chip vào trong chip, điều này giới hạn tốc độ tính toán. Tôi tự hỏi: liệu có thể chia model ra nhiều FPGA, giữ mỗi phần trong bộ nhớ on-chip của riêng nó, và chỉ truyền các kết quả trung gian qua mạng tốc độ cao? Tôi hào hứng kể ý tưởng này cho cố vấn của mình, Giáo sư Ningyi Xu, và ông nói: “Đó gọi là ‘model parallelism’.” Tính toán nên được đặt ở đâu, dữ liệu nên chảy theo cách nào, và sự chuyên biệt hóa có thể tiết kiệm được gì — đó là những câu hỏi tôi đã trăn trở lặp đi lặp lại thời bấy giờ. Trong những năm đó, cố vấn của tôi, Tiến sĩ Lintao Zhang, nhiều lần nhắc tôi: tối ưu hóa phải được đẩy tới giới hạn mà vật lý cho phép. Về sau, trong bài báo KV-Direct, tôi viết “tiến sát giới hạn vật lý của phần cứng bên dưới,” và từ đó tôi hình thành một thói quen: trước tiên tính toán, từ những nguyên lý đầu tiên, trần (ceiling) mà phần cứng cho phép, rồi xem hệ thống cách cái trần đó bao xa. Thói quen này xuyên suốt các công việc sau này của tôi, và nó cũng xuyên suốt cuốn sách này.

Sau khi gia nhập Huawei năm 2019, tôi làm việc với AKG, dự án sinh operator tự động cho framework học sâu MindSpore. Công việc này tiếp nối cách tiếp cận thiết kế đồng phần cứng–phần mềm trước đó: biến đổi tính toán của model thành các chương trình phù hợp để chạy trên NPU Ascend, với trình biên dịch sắp xếp việc tiling dữ liệu, lưu trữ và thứ tự thực thi. Tôi vẫn nhớ việc tìm khắp nơi một thuật toán phù hợp để fusion operator softmax. Sau khi đọc nghiên cứu năm 2018 của NVIDIA về online softmax, cuối cùng tôi cũng tìm ra cách để đạt được việc fusion đó. Mãi về sau tôi mới nhận ra rằng hồi đó tôi đã tình cờ chạm vào một trong những ý tưởng cốt lõi đằng sau thứ sau này trở thành thuật toán FlashAttention: kết hợp giảm chiều online (online reduction) với tiling và fusion để giảm lưu trữ cùng việc đọc/ghi các kết quả trung gian.

Năm 2020, tôi gia nhập dự án Unified Bus (UB) và bắt đầu nghiên cứu sự hợp tác giữa các accelerator ở quy mô lớn hơn nhiều: làm sao để hàng chục nghìn bộ xử lý có thể phối hợp hiệu quả để hoàn thành một phép tính duy nhất?

Khi mới bắt đầu thúc đẩy hướng này trong Huawei, chúng tôi gặp không ít hoài nghi từ các bộ phận khác. Lúc đó có người hỏi: “Hiện tại model train nhiều nhất trên tám card — anh đang xây thứ cho mười nghìn card, khi nào thì anh mới có mười nghìn card?” Thời đó, cả công ty cũng không có mười nghìn card. Đối với những người quen với việc train trên một máy nhiều card, thiết kế interconnect cho quy mô mười nghìn card quả thực trông xa rời mọi nhu cầu trước mắt.

Lý do chúng tôi đưa ra nhận định này là vì chúng tôi nhìn thấy một mảnh bằng chứng khác. Năm 2019, Tiến sĩ Kun Tan vẽ xu hướng tăng trưởng nhu cầu tính toán AI thành một biểu đồ phân tán và thấy rằng nhu cầu đang tăng nhanh hơn nhiều so với mức cải thiện năng lực của một chip đơn, điều này thúc đẩy việc nghiên cứu interconnect hiệu năng cao nhắm tới hàng chục nghìn card. Tôi gia nhập dự án năm 2020, và việc công bố bài báo GPT-3 cung cấp thêm bằng chứng cho hướng đi này. Nếu nhu cầu tính toán cho việc train model cứ tiếp tục tăng như vậy, thì càng nhiều accelerator sẽ cần phải phối hợp với nhau; nghiên cứu và triển khai kiến trúc interconnect cần thời gian, và nếu chỉ bắt đầu sau khi nhu cầu đã thể hiện trọn vẹn thì có lẽ đã quá muộn.

Ngày nay, UB đã được áp dụng trong các hệ thống Ascend 910C và 950. Tính đến thời điểm viết những dòng này, kiến trúc cụm training NPU dựa trên UB là kiến trúc nội địa duy nhất hỗ trợ quy mô vượt mười nghìn card. Nhìn lại bây giờ, sự cần thiết của việc train trên mười nghìn card không khó để hiểu. Thiết kế hệ thống cần nhìn cả khối lượng công việc trước mắt lẫn những điều kiện đang thay đổi. Việc tám card đủ xử lý những tác vụ quen thuộc lúc bấy giờ là kinh nghiệm trực tiếp; việc nhu cầu tính toán lớn hơn sẽ thúc đẩy hợp tác ở quy mô lớn hơn là một phán đoán về tương lai. Để thuyết phục người khác, bạn cần trình bày rõ ràng xu hướng, tài nguyên và chi phí làm nền cho phán đoán đó.

Từ tăng tốc model inference đến AKG, rồi đến UB, công việc này trải qua những quy mô rất khác nhau, nhưng vấn đề tôi cứ gặp đi gặp lại vẫn là một: dữ liệu mà phép tính cần đang nằm ở đâu, và chi phí di chuyển dữ liệu đó có lớn hơn phép tính cần thiết hay không? Nếu chúng ta thay đổi tầng trừu tượng của hệ thống và của ứng dụng để hệ thống tiếp cận được nhiều thông tin hơn từ ứng dụng, thì có thể giảm được chi phí di chuyển dữ liệu không?

Sau khi rời Huawei để khởi nghiệp vào năm 2023, những câu hỏi này quay lại với tôi dưới một hình thức khác. Các agent chúng tôi xây dựng cần tương tác với con người bằng giọng nói theo thời gian thực. Sau khi người dùng nói xong một câu, họ phải chờ bao lâu trước khi nghe thấy phản hồi? Nếu một cuộc gọi kéo dài nửa tiếng, chi phí để phục vụ nó là bao nhiêu?

Năm 2024, chúng tôi ra mắt tính năng tương tác giọng nói thời gian thực trước khi GPT-4o được phát hành. Về sau, khi so sánh với API giọng nói thời gian thực dựa trên GPT-4o, chi phí vận hành của chúng tôi chỉ bằng khoảng một phần trăm chi phí gọi API đó. Tôi vẫn nhớ độ trễ của bản demo cuộc gọi thoại đầu tiên vào cuối năm 2023 lên tới 5 giây. Chúng tôi phá toàn bộ pipeline tương tác ra, đầu tiên ước lượng một lần model inference cần bao nhiêu tính toán và đọc bao nhiêu dữ liệu, rồi cải thiện từng bước một; sau đó chúng tôi tiếp tục tối ưu truyền mạng, truy cập cơ sở dữ liệu, v.v. Độ trễ theo cách đó giảm từ 5 giây xuống 2,5 giây, rồi 1 giây, và cuối cùng xuống còn khoảng 500–600 mili-giây.

Trải nghiệm này dạy cho tôi rằng có một mối liên hệ rất trực tiếp giữa phát triển ứng dụng và hạ tầng. Với cùng kịch bản giọng nói thời gian thực, chênh lệch độ trễ vài lần có thể tạo ra trải nghiệm sản phẩm hoàn toàn khác; chênh lệch chi phí một bậc độ lớn có thể thay đổi cả những mô hình kinh doanh nào là khả thi.

Điều tôi hy vọng cuốn sách này làm rõ

Mối liên hệ giữa ứng dụng và hạ tầng cũng tồn tại ngay bên trong quá trình phát triển model. Trong số những đội model nền tảng giỏi nhất, tôi ngày càng thấy một cách làm việc vượt qua ranh giới phân công lao động: người hiểu Infra nhất lại làm thuật toán, người hiểu thuật toán nhất lại làm dữ liệu, và người hiểu dữ liệu nhất lại làm Infra. Điều mà cách làm này thể hiện là độ sâu của sự hiểu biết lẫn nhau. Chỉ khi người thiết kế thuật toán biết năng lực, băng thông và giới hạn truyền thông của phần cứng, họ mới có thể khai thác những điều kiện đó trong kiến trúc model; chỉ khi kỹ sư dữ liệu hiểu model học như thế nào, họ mới có thể đánh giá mẫu nào và tác vụ training nào là quý giá nhất; chỉ khi kỹ sư Infra hiểu tổ chức, độ dài và kiểu sử dụng của dữ liệu, họ mới có thể thực sự hướng tài nguyên hệ thống vào việc training và inference hiệu quả.

Kiểu phối hợp xuyên tầng này đã xuất hiện trong những thiết kế model gần đây. DeepSeek V4 và V4.1 là những ví dụ tốt. V4 tính toán đầy đủ hiệu quả Infra trong kiến trúc model của mình: kết hợp cửa sổ local, nén context và chọn lọc thưa (sparse selection) để giảm trạng thái phải lưu cho context dài và dữ liệu phải đọc lặp đi lặp lại. Các ràng buộc giữa dung lượng bộ nhớ GPU, băng thông lưu trữ và tính toán đã trực tiếp định hình cách model biểu diễn và sử dụng context.

V4.1 Flash đi xa hơn, dùng kiến trúc Causal Encoder-Decoder (CED) bất đối xứng để phân lại trách nhiệm giữa hiểu và sinh, tái phân bổ đầu tư tính toán cho các tác vụ agent có đầu vào nặng và đầu ra tương đối nhẹ (xem Mục 1.1.3) — cho thấy yêu cầu về hiệu quả hệ thống có thể thúc đẩy sự đổi mới trong chính kiến trúc model.

Tôi hy vọng độc giả cũng có thể xây dựng kiểu hiểu biết xuyên tầng này: khi thấy một cấu trúc model, hình dung được nó yêu cầu accelerator làm những công việc gì; khi thấy một năng lực phần cứng, đánh giá được model và cách thực thi của nó nên thay đổi thế nào để thực sự tận dụng năng lực đó.

Một sợi chỉ xuyên suốt toàn bộ phân tích này là di chuyển dữ liệu (data movement). Các đơn vị tính toán cần lấy trọng số và kết quả trung gian, nhiều accelerator cần trao đổi dữ liệu mà mỗi cái đã tính, và các dịch vụ từ xa cần nhận đầu vào và trả về kết quả. Điều chúng ta thấy là model sinh ra một câu trả lời; điều diễn ra bên dưới là một chuỗi các thao tác đọc, tính, lưu và bàn giao. Dữ liệu nằm ở đâu, nó được tái sử dụng bao nhiêu lần, nó phải đi qua những interface nào, và liệu công việc phía sau có phải chờ nó hay không — tất cả điều này ảnh hưởng đến hiệu quả thực thi.

Vì lý do đó, cuốn sách này lặp đi lặp lại năm câu hỏi: cái gì đang được di chuyển, bao nhiêu, mấy lần, qua đâu, và ai phải chờ nó. Từ hệ phân cấp bộ nhớ trên một chip, đến supernode (một nhóm accelerator hợp tác chặt chẽ qua interconnect băng thông cao) và mạng trung tâm dữ liệu, đến sự phân chia lao động giữa terminal, edge và cloud (phối hợp edge–cloud), năm câu hỏi này giúp chúng ta tìm ra những đại lượng cần được tính tại mỗi tầng. Giữ lại dữ liệu có thể giảm tính toán dư thừa, nhưng nó tiêu tốn dung lượng; mở rộng quy mô song song có thể dàn trải công việc, nhưng nó làm tăng truyền thông; giảm truyền tải có thể đòi hỏi nhiều tính toán local hơn, và cũng có thể làm thay đổi chất lượng kết quả.

Trả lời năm câu hỏi này đòi hỏi phải tính toán tường minh mọi đại lượng, vì thế cuốn sách lấy “Phân tích định lượng và thiết kế hệ thống” (Quantitative Analysis and System Design) làm phụ đề. Computer Architecture: A Quantitative Approach là một hình mẫu xuất sắc cho phong cách phân tích này. Cuốn sách này cũng hướng tới việc mang thói quen ước lượng nói trên vào mọi tầng thiết kế: bắt đầu từ khối lượng công việc của model, đối chiếu với các ràng buộc tài nguyên, giải thích vì sao một cách thực thi cụ thể được chọn, và cách lựa chọn đó nên được xem xét lại khi điều kiện thay đổi.

Cấu trúc cuốn sách

Mười hai chương triển khai theo thứ tự “hiểu yêu cầu của công việc — hiểu tài nguyên thực thi — tổ chức hệ thống hoàn chỉnh”, như trong Hình 0-1. Phần I là Models and Workloads (Chương 1–3), thiết lập phương pháp phân tích và giải thích tính toán, khối lượng dữ liệu và phụ thuộc tác vụ đến từ đâu. Phần II là Chips and Systems (Chương 4–7), đi từ thực thi trên một accelerator đến hợp tác nhiều accelerator, giải thích cách tài nguyên đảm nhận công việc này. Phần III là Inference and Training Systems (Chương 8–12), nghiên cứu cách tổ chức request, trạng thái model và quá trình training, rồi mở rộng ra môi trường thực thi tác vụ và triển khai edge–cloud.

Dưới đây là những câu hỏi chính mà mỗi chương hướng tới trả lời. Bạn có thể bắt đầu bằng việc tìm những câu hỏi mình quan tâm, rồi kiểm tra xem những chương nào trước đó cung cấp nền tảng cho chúng.

Phần I: Models and Workloads

• Chương 1, Cái nhìn đầu tiên về AI Infrastructure: Làm thế nào để có được bức tranh tổng thể về hệ thống, và dùng một vài chỉ số quan trọng để ước lượng một lần thực thi model?
• Chương 2, Kiến trúc Model: Tính toán, tham số và trạng thái context của model làm phát sinh các yêu cầu tài nguyên như thế nào?
• Chương 3, Inference và Training Workloads: Sự đến của request, lời gọi nhiều vòng, đầu vào đa phương thức và quá trình training làm thay đổi yêu cầu tài nguyên cũng như thời gian chờ như thế nào?

Phần II: Chips and Systems

• Chương 4, Kiến trúc Accelerator: Tính toán, lưu trữ và đường dữ liệu của một chip phối hợp với nhau ra sao, và chúng phù hợp với những workload nào?
• Chương 5, Operator và Runtime: Operator và việc thực thi nên được tổ chức thế nào để giảm đọc/ghi dư thừa, submission và chờ đợi?
• Chương 6, Supernode: Một model nên chia công việc cho nhiều accelerator theo cách nào, và nhóm hợp tác nên lớn đến đâu?
• Chương 7, Mạng trung tâm dữ liệu: Dữ liệu được truyền giữa các accelerator như thế nào, và các quy tắc bàn giao, tắc nghẽn và sự cố ảnh hưởng đến tính toán ra sao?

Phần III: Inference and Training Systems

• Chương 8, Tối ưu hóa Inference: Batching, request và caching nên được sắp xếp thế nào để nâng cao hiệu quả serving với một cấu hình accelerator cho trước?
• Chương 9, Inference phân tán: Tính toán và trạng thái nên được đặt ở đâu, và việc phân chia lao động, chia sẻ cũng như mở rộng quy mô nên được tổ chức ra sao?
• Chương 10, Hệ thống Training: Trạng thái training, truyền thông và phục hồi nên được sắp xếp thế nào để tiến trình training diễn ra hiệu quả trong một hạn mức thời gian?
• Chương 11, Lập lịch tài nguyên và môi trường thực thi: Các dịch vụ model, môi trường công cụ và tài nguyên dùng chung được tổ chức thành một hệ thống tác vụ hoàn chỉnh như thế nào?
• Chương 12, Phối hợp Edge–Cloud: Với các yêu cầu truyền tải và tương tác trong thế giới thực, vị trí triển khai một tác vụ giữa terminal, edge và cloud nên được chọn như thế nào?

Khi bạn đọc sâu hơn, phân tích của cùng một câu hỏi liên tục được bổ sung điều kiện mới: ban đầu chỉ xét dung lượng trọng số, sau đó trạng thái context cũng phải được tính đến; ban đầu chỉ so sánh các lần thực thi đơn lẻ, sau đó phải đối mặt với sự đồng thời, bàn giao và phục hồi sau sự cố. Tôi hy vọng bạn sẽ theo dõi những thay đổi này và quay lại kiểm chứng những phán đoán bạn đã đưa ra trước đó. Đây cũng chính là lý do tôi đặt model, chip, mạng và hệ thống dịch vụ trong cùng một cuốn sách: cùng nhau, chúng quyết định một tác vụ thực sự được hoàn thành như thế nào.

Cách đọc cuốn sách này

Nếu bạn muốn xây dựng một nền tảng hiểu biết có hệ thống từ con số không, tôi khuyên nên đọc Chương 1–3 trước, học cách ước lượng một lần thực thi và hiểu những yêu cầu mà model cùng workload đặt ra, rồi đọc hai phần còn lại theo thứ tự. Độc giả có nền tảng khác nhau cũng có thể, trên nền tảng chung này, tự chọn điểm tập trung của mình.

• Nhà phát triển model và ứng dụng có thể muốn tập trung vào phần serving inference ở Chương 8 và 9, cùng phần môi trường tác vụ và triển khai ở Chương 11 và 12. Khi gặp vấn đề về dung lượng, operator hay truyền thông, hãy quay lại Chương 4–7 để truy tìm nguyên nhân.
• Kỹ sư hệ thống và mạng có thể muốn tập trung vào việc thực thi và hợp tác accelerator ở Chương 5–7, rồi xem Chương 9 và 10 để hiểu những cơ chế này ảnh hưởng đến inference phân tán và training ra sao.
• Kỹ sư chip và kiến trúc có thể muốn tập trung vào Chương 4–7, và kết hợp chúng với các ví dụ tính toán trong các chương sau để kiểm chứng cách các chỉ số phần cứng họ đã biết chuyển hóa thành năng lực serving thực tế.

Dù chọn con đường đọc nào, tôi đặc biệt khuyên bạn hãy thử tự ước lượng trước khi nhìn đáp án. Lấy một tờ giấy và viết ra khối lượng dữ liệu, năng lực xử lý và các bước phải chờ đợi, và bạn thường sẽ tìm ra điều gì đó đáng để hỏi sâu hơn. Nếu kết quả của bạn khác với cuốn sách, trước tiên hãy kiểm tra xem cả hai bên có dùng cùng điều kiện hay không; nếu điều kiện khớp nhau, hãy tiếp tục tìm phần công việc đã bị bỏ sót hoặc bị đếm hai lần. Kiểu kiểm tra đi qua đi lại như vậy thường có giá trị hơn việc đơn thuần ghi nhớ một kết luận.

Bài tập trong sách được chia thành bài tập cốt lõi và bài tập mở rộng: bài tập cốt lõi giúp bạn hoàn thành quá trình suy luận chính của chương, còn bài tập mở rộng có thể lựa chọn theo sở thích và nhu cầu dự án. Các thí nghiệm đồng hành, công cụ tính toán và tài liệu tham khảo được tổ chức trong kho mã nguồn mở của cuốn sách:

Kho mã nguồn mở đồng hành: https://github.com/bojieli/ai-infra-book

Kho chứa ba loại tài liệu, dùng chung với phần nội dung chính:

• Thí nghiệm và tính toán. Các thí nghiệm được tổ chức theo chương, kèm hướng dẫn chạy, điều kiện đầu vào và nhật ký kết quả; các công cụ tính toán đồng hành giúp bạn tính lại những con số trong sách, hoặc thay đổi một bộ điều kiện và quan sát cách các kết luận dịch chuyển.
• Bài báo và tài liệu kỹ thuật. Chỉ mục và bản ghi nguồn cho các bài báo liên quan, phần mềm nguồn mở và tài liệu kỹ thuật chính thức, để dễ dàng tiếp tục đọc theo các câu hỏi được đặt ra trong sách và kiểm chứng các khẳng định cụ thể với nguồn của chúng.
• Bảng tham số chip và model. Thông số kỹ thuật phần cứng và cấu hình model thu thập từ nghiên cứu, bao gồm năng lực tính toán, dung lượng và băng thông lưu trữ, năng lực interconnect, cũng như số lớp model, kích thước chiều, cấu hình mixture-of-experts và trạng thái context — những thông tin cần thiết cho các ước lượng này. Các bảng tham số được thiết kế để dùng cùng với nguồn và công cụ tính toán, giúp bạn kiểm tra điều kiện mà một con số áp dụng trước khi đưa nó vào phân tích của riêng mình.

Bạn có thể điều hướng từ trang chủ của kho đến các thư mục thí nghiệm, tính toán định lượng và tài liệu tham khảo, và chạy theo hướng dẫn của từng dự án. Các thí nghiệm cần một accelerator cụ thể sẽ ghi rõ môi trường và điều kiện accelerator yêu cầu; nếu bạn không có accelerator tương ứng, bạn có thể bắt đầu bằng việc phân tích các bản ghi hiện có rồi tính lại sau khi thay đổi đầu vào. Model và phần cứng liên tục thay đổi, và tài liệu này sẽ tiếp tục được bổ sung và sửa đổi cùng với cuốn sách.

Khi đọc cuốn sách này, bạn cũng có thể mang theo model, máy móc và bài toán kinh doanh của riêng mình. Thay các đầu vào dùng trong sách và xem các kết luận có thay đổi không, rồi quyết định điều gì đáng đo tiếp theo. Tôi hy vọng những ví dụ này có thể làm điểm khởi đầu cho việc phân tích các vấn đề của riêng bạn.

Điều kiện tiên quyết

Cuốn sách này nhắm tới những độc giả có kinh nghiệm lập trình và muốn hiểu về việc thực thi model cùng thiết kế hệ thống. Những nền tảng sau sẽ giúp bạn theo kịp các suy luận và thí nghiệm trong sách.

• Lập trình và công cụ. Có thể đọc và sửa các chương trình Python đơn giản, thoải mái với dòng lệnh và cài đặt dependency cơ bản. Các bài tập nền tảng bắt đầu từ tính toán tay, script nhỏ và nhật ký thí nghiệm có sẵn; các thí nghiệm dùng accelerator cụ thể sẽ ghi rõ điều kiện yêu cầu.
• Toán học. Hiểu vector, phép nhân ma trận và đại số cơ bản, và có thể làm chuyển đổi đơn vị. Kiến thức cơ bản về trung bình và xác suất giúp phân tích workload và thời gian chờ; trực giác về đạo hàm và gradient giúp đọc các chương về training.
• Hệ thống máy tính. Hiểu các mục đích cơ bản của tiến trình, bộ nhớ, file và truyền thông mạng. Cấu trúc model, chiến lược song song và cơ chế phần cứng chuyên biệt sẽ được giới thiệu dần khi chúng xuất hiện.

Nếu bạn đã gọi một API model, hoặc đã chạy một model trên máy của mình, bạn có thể mang trải nghiệm đó vào các ví dụ tính toán trong sách: vì sao context dài làm mọi thứ chậm lại, vì sao mọi người phải chờ lâu hơn khi độ đồng thời tăng, vì sao đổi accelerator lại không mang lại mức tăng tốc như bạn kỳ vọng? Tất cả đều là những điểm khởi đầu tuyệt vời để đọc.

Bạn không cần phải đợi đến khi quen thuộc với mọi tầng rồi mới bắt đầu đọc. Trong nghiên cứu hệ thống và thực hành kỹ thuật, tôi luôn phải học kiến thức của các tầng lân cận quanh một vấn đề cụ thể. Khi gặp một khái niệm xa lạ, bạn có thể nắm trước vấn đề nó được tạo ra để giải quyết, rồi quay lại các chi tiết triển khai sau.

Tôi hy vọng rằng sau khi đọc xong cuốn sách này, đối mặt với một model mới, một accelerator mới hay một yêu cầu triển khai mới, bạn sẽ có thể phác họa quá trình thực thi, tính một vài chỉ số then chốt, xác định giả định cần kiểm chứng nhất, và sửa đổi lựa chọn của mình dựa trên những gì quan sát được. Kết luận của bạn có thể khác với cuốn sách; có thể giải thích sự khác biệt đến từ đâu chính là một dấu hiệu cho thấy bạn đã hiểu hệ thống.

Lời cảm ơn

Trước hết, cảm ơn model GPT-6 Astra. Tôi đã muốn viết một cuốn sách như thế này từ lâu, chưng cất nhiều năm suy nghĩ của mình về hệ thống máy tính và AI Infrastructure, nhưng chưa bao giờ tìm đủ thời gian. Cách đây một thời gian, cuối cùng tôi cũng chưng cất suy nghĩ của mình thành một dàn ý. Sau khi GPT-6 Astra được phát hành, tôi đã để một agent làm việc liên tục trong một tuần, giúp tôi nghiên cứu các bài báo liên quan, theo dõi tiến độ của phần mềm nguồn mở, chạy thí nghiệm, và dần dần biến tất cả thành một cuốn sách. Điều bạn đang đọc bây giờ vẫn chỉ là một bản thảo đầu tiên. Tôi vẫn đang tiếp tục chưng cất suy nghĩ của mình và sửa đổi nội dung cuốn sách.

Cảm ơn các cộng sự nhiều năm trong lĩnh vực mạng, hệ thống và AI Infrastructure, những người đã cùng tôi nghiên cứu và đồng tác giả các bài báo. Cảm ơn các lãnh đạo, chuyên gia và đồng nghiệp tại Microsoft và Huawei, những người đã chỉ dẫn và cùng tôi làm việc trên các dự án như tăng tốc NIC lập trình được, sinh operator và interconnect mạng quy mô lớn Unified Bus. Tôi không thể liệt kê tên từng người ở đây, nhưng từ việc đề xuất giả thuyết, qua phân tích lý thuyết và kiểm chứng thí nghiệm, đến việc thực sự xây dựng những hệ thống cấp sản xuất, tôi đã học được rất nhiều từ tất cả các bạn. Nhiều ý tưởng trong cuốn sách này mang dáng dấp của những ngày chúng ta cùng thảo luận, suy luận, làm thí nghiệm và giải quyết vấn đề.

Cuối cùng, tôi muốn cảm ơn vợ tôi, Jiaying Meng. Cũng như khi viết Hiểu thấu AI Agents, cô ấy luôn ủng hộ tôi hoàn thành những gì tôi đã đặt ra. Mấy ngày gần đây, cô ấy thậm chí còn nhường cho tôi cả hạn mức token Codex của riêng mình, để tôi có đủ token tiếp tục đẩy cuốn sách này tiến về phía trước.