Bí quyết mạng ngược đời đằng sau 131,000 GPU của OpenAI

Mở đầu: Khi những nguyên tắc networking bị đảo ngược

Nếu bạn làm việc trong lĩnh vực mạng máy tính, chắc chắn bạn đã được rèn giũa bởi những nguyên tắc "bất di bất dịch". Định tuyến động phải có. Packet loss là kẻ thù. OSPF, BGP, hay các giao thức tương tự là nền tảng của mọi hệ thống mạng nghiêm túc. Nhưng nếu tôi nói với bạn rằng OpenAI – một trong những tổ chức tiên phong về AI – đã phớt lờ tất cả những điều trên để xây dựng hạ tầng mạng cho 131,000 GPU của họ, bạn sẽ nghĩ sao?

Chính xác, họ đã làm điều đó! Không một giao thức định tuyến nào, chấp nhận mất gói dữ liệu như một phần của thiết kế, và giải quyết mọi thứ bằng một giao thức hoàn toàn mới – MRC (Multipath Reliable Connection). Đây không chỉ là một bài học kỹ thuật, mà còn là minh chứng rằng đôi khi, để đạt được hiệu suất tối đa, ta phải dám phá vỡ các nguyên tắc quen thuộc.

Quyết định 1: Loại bỏ hoàn toàn Layer 3

Một trong những điều gây sốc nhất về MRC là họ đã loại bỏ toàn bộ Layer 3 – phần kiểm soát định tuyến động trong mạng. Không OSPF, không BGP, không IS-IS. Điều này có nghĩa là các switch trong hệ thống không lưu trữ bất kỳ trạng thái định tuyến động nào. Tất cả đều hoạt động dựa trên các tuyến tĩnh được lập trình sẵn.

Vậy tại sao lại làm điều này? Ở quy mô 100,000+ GPU, một sự cố nhỏ ở một tuyến mạng có thể gây ra hiệu ứng domino, khiến hàng chục nghìn GPU phải chờ đợi để hoàn tất một tác vụ duy nhất. Thay vì cố gắng kiểm soát sự phức tạp của Layer 3, OpenAI chọn cách đơn giản hóa: tránh hoàn toàn các giao thức định tuyến động và sử dụng các tuyến tĩnh để giảm thiểu khả năng thất bại toàn cục.

Điều này làm tôi nhớ đến câu "Keep It Simple, Stupid!" (KISS). Đôi khi, sự đơn giản hóa triệt để lại là chìa khóa giải quyết những vấn đề tưởng như phức tạp nhất.

Quyết định 2: Chấp nhận packet loss như một "tính năng"

Trong hầu hết các hệ thống mạng, mất gói dữ liệu (packet loss) là điều tối kỵ. Nhưng với MRC, họ không chỉ chấp nhận packet loss mà còn coi đó là một phần của thiết kế. Điều này nghe có vẻ điên rồ, nhưng thực tế, đây là quyết định hoàn toàn có cơ sở.

Khi bạn truyền tải dữ liệu giữa hàng trăm nghìn GPU, việc đảm bảo không có gói nào bị mất là một nhiệm vụ gần như bất khả thi. Thay vì tốn công cố gắng giảm thiểu mất mát, MRC chọn cách "sống chung với lũ". Họ thiết kế giao thức để có thể xử lý việc mất gói một cách hiệu quả, sử dụng các cơ chế bù đắp và tái truyền tải thông minh.

Hãy tưởng tượng bạn đang chơi một trò chơi xếp hình (puzzle) với hàng trăm mảnh ghép. Nếu thiếu vài mảnh, bạn không cần phải dừng lại hoàn toàn. Bạn có thể tiếp tục với những mảnh còn lại và ghép bổ sung sau. Đó chính là cách MRC hoạt động.

Quyết định 3: Phun dữ liệu trên hàng trăm tuyến ngẫu nhiên

Nếu bạn từng nghe về phương pháp "multipathing" trong networking, bạn có lẽ quen thuộc với ý tưởng chia dữ liệu thành nhiều tuyến đường để giảm tải. Nhưng MRC đưa ý tưởng này đi xa hơn: họ không chỉ chia dữ liệu mà còn phun nó ngẫu nhiên trên hàng trăm tuyến khác nhau.

Mục tiêu ở đây là tránh tắc nghẽn trên bất kỳ tuyến nào. Thay vì cố gắng tối ưu hóa từng đường truyền, họ chọn cách "rải đều" và xử lý các vấn đề phát sinh sau đó. Điều này đảm bảo rằng ngay cả khi một vài tuyến bị tắc, toàn bộ hệ thống vẫn có thể hoạt động mà không bị nghẽn cổ chai.

Ví dụ, trong một mạng truyền thống, nếu một đường truyền bị tắc, các gói dữ liệu sẽ phải chờ đợi cho đến khi đường truyền được giải phóng. Nhưng với MRC, dữ liệu sẽ tự động chuyển sang các tuyến khác, giảm thiểu độ trễ tổng thể.

Quyết định 4: Tận dụng NIC tốc độ cao và silicon chuyên dụng

Một yếu tố quan trọng giúp MRC khả thi là sự hỗ trợ từ phần cứng. OpenAI đã hợp tác với các hãng như NVIDIA, AMD, và Broadcom để phát triển các NIC (Network Interface Card) tốc độ 800 Gb/s. Những NIC này không chỉ nhanh mà còn được tối ưu hóa để xử lý các giao thức phức tạp của MRC.

Điều này minh chứng rằng đôi khi, phần mềm không thể tự mình giải quyết tất cả. Để đạt được hiệu suất tối đa, sự kết hợp giữa phần mềm và phần cứng là điều tất yếu. Nếu bạn là một developer, đây cũng là một bài học quý giá: đừng chỉ tập trung vào code, hãy nghĩ đến cả hệ sinh thái mà code của bạn vận hành.

Quyết định 5: Đánh đổi để tối ưu hóa hiệu suất toàn cục

Cuối cùng, MRC là một bài học về sự đánh đổi (trade-off). Bằng cách chấp nhận mất mát nhỏ lẻ và loại bỏ phức tạp không cần thiết, OpenAI đã tối ưu hóa hiệu suất toàn cục của hệ thống. Điều này khiến tôi nhớ đến một câu nói trong giới lập trình: "Perfect is the enemy of good." Nếu bạn cố gắng đạt được sự hoàn hảo ở mọi khía cạnh, bạn có thể bỏ lỡ bức tranh lớn hơn.

Trong trường hợp của OpenAI, mục tiêu không phải là xây dựng một mạng hoàn hảo, mà là một mạng hoạt động hiệu quả nhất ở quy mô khổng lồ. Và họ đã làm được.

Góc nhìn cá nhân: Liệu developer Việt có thể học gì từ đây?

Từ câu chuyện của MRC, tôi nghĩ chúng ta có thể rút ra nhiều bài học. Đầu tiên, đừng ngần ngại thách thức các nguyên tắc quen thuộc nếu chúng không còn phù hợp. Thế giới công nghệ thay đổi rất nhanh, và những gì là tiêu chuẩn hôm nay có thể trở thành rào cản ngày mai.

Thứ hai, hãy luôn tìm kiếm sự cân bằng giữa đơn giản và hiệu quả. Trong ngành phần mềm, quá nhiều người bị ám ảnh bởi việc tối ưu hóa từng chi tiết nhỏ mà quên mất mục tiêu lớn hơn. Hãy nhớ rằng đôi khi, một giải pháp "đủ tốt" là tất cả những gì bạn cần.

Cuối cùng, nếu bạn đang làm việc trong lĩnh vực AI hoặc hạ tầng mạng, đây là thời điểm tuyệt vời để học hỏi. Với sự bùng nổ của AI, những kỹ năng liên quan đến tối ưu hóa hệ thống và thiết kế mạng đang trở nên cực kỳ giá trị. Đừng bỏ lỡ cơ hội này!

Tôi rất mong chờ ngày các công ty công nghệ Việt Nam cũng dám nghĩ lớn và thử nghiệm những ý tưởng táo bạo như OpenAI. Biết đâu, một ngày nào đó, chúng ta cũng sẽ tạo ra những công nghệ khiến thế giới phải kinh ngạc.