Tại sao suy luận LLM cần một loại bộ định tuyến mới Các mô hình ngôn ngữ lớn (LLM) đang thay đổi cách chúng ta tương tác với công nghệ. Tuy nhiên, việc triển khai và quản lý các LLM này đòi hỏi những phương pháp mới, đặc biệt là trong suy luận (inference). Suy luận LLM, quá trình tạo ra phản hồi từ một mô hình đã được huấn luyện, đặt ra những thách thức riêng biệt mà các giải pháp định tuyến truyền thống không thể giải quyết hiệu quả. **Những thách thức của suy luận LLM** 1. **Tính không đồng nhất của mô hình:** Không phải tất cả các LLM đều giống nhau. Có những mô hình nhỏ, chuyên biệt cho các tác vụ cụ thể và những mô hình lớn, đa năng. Mỗi mô hình có yêu cầu về tài nguyên và hiệu suất khác nhau. Một bộ định tuyến truyền thống thường không được thiết kế để phân biệt và định tuyến các yêu cầu đến các loại mô hình khác nhau một cách tối ưu. 2. **Yêu cầu tài nguyên động:** Suy luận LLM có thể rất tốn kém về tài nguyên tính toán, đặc biệt là GPU. Nhu cầu về tài nguyên có thể dao động đáng kể tùy thuộc vào độ phức tạp của yêu cầu và kích thước của mô hình. Các bộ định tuyến hiện có thường thiếu khả năng điều chỉnh tài nguyên động dựa trên tải và yêu cầu cụ thể của LLM. 3. **Độ trễ và thông lượng:** Đối với nhiều ứng dụng, độ trễ thấp và thông lượng cao là rất quan trọng. Việc định tuyến không hiệu quả có thể dẫn đến tắc nghẽn, tăng độ trễ và giảm hiệu suất tổng thể của hệ thống. 4. **Tối ưu hóa chi phí:** Chạy các LLM có thể rất đắt đỏ. Việc định tuyến thông minh có thể giúp tối ưu hóa việc sử dụng tài nguyên, đảm bảo rằng các yêu cầu được xử lý bởi mô hình phù hợp nhất và trên phần cứng hiệu quả nhất, từ đó giảm chi phí vận hành. 5. **Quản lý phiên bản mô hình:** Các LLM thường được cập nhật và cải tiến liên tục. Một bộ định tuyến cần có khả năng quản lý nhiều phiên bản của cùng một mô hình, cho phép thử nghiệm A/B và triển khai dần dần mà không làm gián đoạn dịch vụ. **Nhu cầu về một loại bộ định tuyến mới** Để giải quyết những thách thức này, suy luận LLM cần một loại bộ định tuyến mới, được thiết kế đặc biệt cho các đặc điểm độc đáo của các mô hình ngôn ngữ lớn. Bộ định tuyến này cần có các khả năng sau: * **Định tuyến thông minh dựa trên ngữ cảnh:** Bộ định tuyến phải có khả năng phân tích yêu cầu đầu vào (prompt) và định tuyến nó đến mô hình phù hợp nhất dựa trên nội dung, độ phức tạp và yêu cầu cụ thể. Ví dụ, một yêu cầu đơn giản có thể được xử lý bởi một mô hình nhỏ hơn, trong khi một yêu cầu phức tạp hơn sẽ được gửi đến một LLM lớn hơn. * **Quản lý tài nguyên động:** Khả năng tự động điều chỉnh tài nguyên (ví dụ: số lượng GPU) dựa trên tải hiện tại và dự đoán là rất quan trọng. Điều này bao gồm việc tự động mở rộng (scale up) hoặc thu hẹp (scale down) các phiên bản mô hình để đáp ứng nhu cầu. * **Cân bằng tải nhận biết mô hình:** Thay vì chỉ phân phối yêu cầu đồng đều, bộ định tuyến cần cân bằng tải dựa trên khả năng xử lý và trạng thái hiện tại của từng mô hình. * **Hỗ trợ đa mô hình và đa nhà cung cấp:** Khả năng tích hợp và quản lý các mô hình từ nhiều nhà cung cấp khác nhau (ví dụ: OpenAI, Anthropic, Google) và các mô hình mã nguồn mở là cần thiết để mang lại sự linh hoạt và khả năng phục hồi. * **Giám sát và phân tích hiệu suất:** Cung cấp thông tin chi tiết về hiệu suất của từng mô hình và luồng định tuyến, giúp xác định các điểm nghẽn và tối ưu hóa hệ thống. * **Khả năng chịu lỗi và độ tin cậy:** Đảm bảo rằng hệ thống vẫn hoạt động ngay cả khi một số mô hình hoặc tài nguyên gặp sự cố. Một bộ định tuyến mới cho suy luận LLM không chỉ là một công cụ kỹ thuật mà còn là một thành phần chiến lược, giúp các tổ chức khai thác tối đa tiềm năng của các mô hình ngôn ngữ lớn một cách hiệu quả, tiết kiệm chi phí và đáng tin cậy.

Ngày 8/5/2026 Vì sao suy luận LLM cần một loại bộ định tuyến mới - Phần 1 Aayush Deshpande Deep Dhillon Alexandr Nikitin Michael Dunn-OConnor Kỹ thuật Định tuyến HTTP đã là một vấn đề được giải quyết trong nhiều năm. Các phương pháp như round-robin, consistent hashing, least-connections. Chỉ cần chọn một, đặt nó trước một nhóm máy chủ giống hệt nhau, và lưu lượng truy cập sẽ được phân bổ khá đều. Nhưng sau đó, các Mô hình Ngôn ngữ Lớn (LLM) xuất hiện. Các máy chủ phụ trợ (backend) ở đây không phải là các máy chủ web có thể thay thế cho nhau. Chúng là các pod GPU chứa các bộ nhớ đệm KV cục bộ lớn trong bộ nhớ RAM hoặc SSD băng thông cao. Trạng thái đó tốn kém để xây dựng lại, không có sẵn đồng đều trên toàn cụm và thường quyết định liệu một yêu cầu có được trả về nhanh chóng hay mất vài giây để tính toán lại công việc trước đó. Một số pod có thể chuyên về prefill, một số khác về decode. Các cuộc hội thoại thường kéo dài qua nhiều yêu cầu. Một cuộc gọi suy luận (inference call) đôi khi cần hai máy chủ phụ trợ theo trình tự. Các giả định cũ về "máy chủ phụ trợ có thể thay thế" và "yêu cầu độc lập" không hỗ trợ các yêu cầu này. Định tuyến bộ nhớ đệm: mù quáng so với nhận biết. Định tuyến truyền thống mù quáng với tất cả những điều này. Nó coi mọi máy chủ phụ trợ là có thể thay thế, mọi yêu cầu là độc lập, mọi pod đều tốt như nhau. Các pod GPU không phải là những thứ đó. Chúng có trạng thái, chuyên biệt và không đồng nhất. Định tuyến suy luận phải tính đến điều đó. Đây là bài viết đầu tiên trong loạt ba bài về những gì định tuyến phải trở thành để xử lý khối lượng công việc suy luận. Lớp điều phối của Modular Cloud được xây dựng xung quanh vấn đề định tuyến này, và loạt bài này giải thích cách nó giải quyết vấn đề đó. Nhiều năm định tuyến phi trạng thái Cân bằng tải thời HTTP được xây dựng dựa trên một số thuật toán nhỏ, mỗi thuật toán được điều chỉnh cho một hình dạng triển khai cụ thể. Chúng có các chính sách khác nhau, nhưng chúng chia sẻ cùng một điều kiện tiên quyết: các máy chủ phụ trợ phi trạng thái. Các chiến lược định tuyến cổ điển: Round-robin phân phối các yêu cầu đồng đều trên một nhóm các máy chủ phụ trợ giống hệt nhau. Nó giả định rằng mọi máy chủ phụ trợ phục vụ mọi yêu cầu với cùng một chi phí. Điều này có thể giống như tám bản sao của cùng một dịch vụ web đằng sau một bộ cân bằng tải, mỗi bản sao nhận 12,5% lưu lượng truy cập. Nó đơn giản, công bằng, phi trạng thái. Consistent hashing định tuyến mỗi yêu cầu đến một máy chủ phụ trợ được xác định bằng cách băm một số thuộc tính của yêu cầu (một khóa, URL, định danh phiên), và chọn máy chủ phụ trợ có vị trí trên vòng băm gần nhất. Đây là chiến lược định tuyến được lựa chọn khi bạn muốn cùng một khóa đến cùng một máy chủ phụ trợ, để lưu trữ phía máy khách hoặc duy trì phiên. "Độ dính" của máy chủ phụ trợ là một hàm của khóa yêu cầu, không phải của bất cứ thứ gì máy chủ phụ trợ đang giữ trong bộ nhớ. Least-requests gửi mỗi yêu cầu mới đến máy chủ phụ trợ nào có ít yêu cầu đang hoạt động nhất, với giả định rằng ít yêu cầu đang hoạt động hơn có nghĩa là có nhiều dung lượng dự phòng hơn. Nó hoạt động khi mọi yêu cầu mất khoảng cùng một lượng công việc. Các chính sách này chia sẻ ba giả định giống nhau: Bất kỳ máy chủ phụ trợ nào cũng có thể phục vụ bất kỳ yêu cầu nào. Việc gán là một lựa chọn chính sách chứ không phải là một lựa chọn đúng đắn. Các yêu cầu là độc lập. Những gì xảy ra trên yêu cầu N không thay đổi những gì bạn nên làm trên yêu cầu N+1. Các máy chủ phụ trợ có thể thay thế cho nhau. Bộ cân bằng tải có thể hoán đổi cái này cho cái khác mà không cần máy khách nhận biết. Những giả định đó đúng với các dịch vụ web phi trạng thái. Suy luận LLM phá vỡ cả ba. Nơi LLM phá vỡ mô hình Khối lượng công việc LLM vi phạm các giả định phi trạng thái theo bốn cách cụ thể. Mỗi cách giới thiệu một chiều mà định tuyến truyền thống không có cơ chế để xử lý. Trạng thái bộ nhớ đệm KV Trạng thái bộ nhớ đệm KV: cùng một lời nhắc với sự khác biệt độ trễ 80 lần. Khi một pod phục vụ một yêu cầu suy luận, quá trình chuyển tiếp (forward pass) xây dựng một bộ nhớ đệm KV: trạng thái trung gian của mô hình cho mọi vị trí mã thông báo (token), được giữ trong bộ nhớ GPU. Các công cụ hiện đại giữ lại bộ nhớ đệm đó sau khi phản hồi hoàn tất. Do đó, các yêu cầu sau này có chung tiền tố có thể bỏ qua phần tính toán tương đương. Điều này làm thay đổi đáng kể bài toán định tuyến. Một lời nhắc 100K token đến một pod có 75K token đầu tiên đã được lưu vào bộ nhớ đệm có thể được điền trước trong vài mili giây. Cùng một lời nhắc đến một pod "lạnh" sẽ mất vài giây. Việc định tuyến vòng tròn (round-robin), không biết trạng thái bộ nhớ đệm, sẽ tạo ra thời gian đến token đầu tiên (TTFT) không thể đoán trước cho các yêu cầu giống hệt nhau. Trạng thái bộ nhớ đệm là yếu tố chính gây ra sự biến động độ trễ điền trước ở quy mô lớn. Một bộ định tuyến chọn các pod dựa trên khả năng lưu trú trong bộ nhớ đệm sẽ loại bỏ việc tính toán điền trước tỷ lệ thuận với độ dài tiền tố được chia sẻ cho mỗi lần truy cập. Điều này giải phóng chu kỳ GPU mà cụm sẽ phải dành để tính toán lại công việc đã thực hiện. Chuyên môn hóa phần cứng Suy luận LLM có hai giai đoạn và chúng gây áp lực khác nhau lên phần cứng. Các pod điền trước so với giải mã. Điền trước xử lý toàn bộ lời nhắc song song. Nó bị giới hạn bởi tính toán. Điều này có nghĩa là các lõi GPU được bão hòa khi thực hiện các phép nhân ma trận dày đặc trên hàng nghìn token cùng một lúc. Giải mã tạo ra các token từng cái một một cách tự động hồi quy, mỗi token phụ thuộc vào mọi token trước đó. Nó bị giới hạn bởi băng thông bộ nhớ. Điều này có nghĩa là hầu hết thời gian của GPU được dành để tìm nạp trọng số mô hình và bộ nhớ đệm KV từ bộ nhớ băng thông cao (HBM), và hầu hết các tính toán đều ở trạng thái nhàn rỗi. Chạy cả hai giai đoạn trên cùng một pod có nghĩa là phần cứng không bao giờ được điều chỉnh cho cả hai. Điền trước cần tính toán dày đặc; giải mã cần băng thông bộ nhớ. Một pod được tối ưu hóa cho một cái sẽ sử dụng không hiệu quả những gì cái kia yêu cầu. Các triển khai tách rời sử dụng các pod được điều chỉnh riêng cho từng giai đoạn. Một yêu cầu của khách hàng chia công việc cho cả hai. Các công cụ hiện đại sử dụng tính năng điền trước theo khối để xen kẽ hai giai đoạn trên cùng một pod, làm mờ ranh giới. Nhưng sự khác biệt cơ bản giữa tính toán và băng thông vẫn tồn tại, và khi bạn tách rời ở cấp độ triển khai, bộ định tuyến của bạn phải biết pod nào có thể làm gì. Tính liên tục của cuộc hội thoại Hội thoại đa lượt và tính liên kết phiên. Hầu hết lưu lượng truy cập LLM là đa lượt. Người dùng gửi tin nhắn. Trợ lý trả lời. Người dùng gửi một tin nhắn khác, và tin nhắn đó ngầm chứa toàn bộ lịch sử cuộc hội thoại dưới dạng ngữ cảnh. Lượt N+1 chia sẻ tiền tố với lượt N: lời nhắc hệ thống, tất cả các lượt trước đó, tất cả các câu trả lời trước đó của trợ lý. Nếu bộ nhớ đệm KV từ lượt N vẫn còn trên một pod nào đó, lượt N+1 thực sự miễn phí để điền trước cho phần được chia sẻ.