llm-d 1.0: khi nào nên dùng suy luận LLM phân tán?

Một chatbot nội bộ chạy tốt trên một GPU có thể nhanh chóng gặp trần khi số người dùng tăng, ngữ cảnh dài hơn và nhiều nhóm cùng chia sẻ cụm. Khi đó, bài toán không chỉ là thêm GPU. Đội nền tảng cần định tuyến yêu cầu đến nút có dữ liệu phù hợp trong bộ nhớ đệm, kiểm soát từng nhóm và nâng cấp mà không ngắt dịch vụ.

Ngày 20/10/2026, Google Cloud công bố llm-d 1.0, một ngăn xếp mã nguồn mở, hoạt động theo cách tự nhiên của Kubernetes để vận hành suy luận mô hình ngôn ngữ lớn trên nhiều nút. Dự án được đồng sáng lập cùng Red Hat và IBM, đã vào CNCF Sandbox, với hơn 500 người đóng góp từ 25 tổ chức theo công bố của Google.

llm-d giải quyết phần nào của hệ thống?

Suy luận là giai đoạn mô hình đã huấn luyện tạo câu trả lời cho yêu cầu mới. Khi phân tán, nhiều tiến trình phục vụ mô hình cùng chia tải. llm-d đứng ở lớp điều phối: nhận yêu cầu, quyết định điểm đến, quản lý hàng đợi và tận dụng lại dữ liệu trung gian. Nó không phải một mô hình mới và cũng không thay thế Kubernetes, GPU hay công cụ phục vụ mô hình.

Bản 1.0 hỗ trợ vLLM và SGLang, có thể hoạt động với GPU và TPU. Điểm đáng chú ý là định tuyến theo cache: yêu cầu được ưu tiên đưa đến nút đã có phần ngữ cảnh liên quan trong bộ nhớ đệm KV. KV cache lưu trạng thái tính toán của các token trước đó; tái sử dụng đúng chỗ giúp giảm tính toán lặp lại.

Các khả năng mới đáng chú ý

• Điều khiển luồng đa tenant: phân bổ và giới hạn tài nguyên giữa nhiều nhóm dùng chung cụm.
• KV cache nhiều tầng: kết hợp bộ nhớ trên bộ tăng tốc, bộ nhớ máy chủ và lớp lưu trữ để mở rộng dung lượng ngữ cảnh.
• Định tuyến nhận biết phiên: giữ chuỗi trao đổi liên quan trên nơi có trạng thái phù hợp.
• Tính sẵn sàng cao và nâng cấp không gián đoạn: giảm rủi ro khi thay phiên bản thành phần phục vụ.
• Hỗ trợ tải động, gồm một thử nghiệm công bố phục vụ 1.000 tác nhân cách ly qua một điểm cuối.

Đọc benchmark của hãng cho đúng

Google công bố thử nghiệm trên TPU Ironwood cho thấy thời gian tới token đầu tiên, thường gọi là TTFT, giảm hơn 85% và thông lượng tăng 2,4 lần so với dịch vụ Kubernetes thông thường. Một thử nghiệm khác cho biết mức sử dụng bộ tăng tốc nhàn rỗi tăng từ khoảng 40% lên trên 70%. Đây là benchmark do nhà cung cấp công bố trong cấu hình của họ, không phải cam kết áp dụng cho mọi mô hình, GPU, độ dài ngữ cảnh hoặc lưu lượng tại Việt Nam.

Đội triển khai nên đo ba nhóm chỉ số của chính mình: thời gian tới token đầu tiên, tốc độ sinh token sau đó và tỷ lệ yêu cầu đạt mục tiêu thời gian phản hồi. Thêm chi phí vận hành cụm, lưu lượng giữa nút và dung lượng cache. Một kiến trúc có thông lượng cao nhưng tăng độ phức tạp vận hành có thể không phù hợp với dịch vụ quy mô nhỏ.

Khi nào llm-d đáng thử?

Checklist thử nghiệm trước khi dùng thật

1. Chọn một mô hình, độ dài ngữ cảnh và kiểu hội thoại đại diện; tránh benchmark chỉ với câu hỏi ngắn.
2. Đo đường cơ sở trên một điểm cuối vLLM hoặc SGLang hiện tại.
3. Triển khai llm-d trong môi trường thử nghiệm; mô phỏng cache nóng, cache lạnh và lưu lượng tăng đột ngột.
4. Kiểm tra cô lập tenant, hạn mức, tình huống một nhóm gửi quá nhiều yêu cầu và cách hàng đợi phản ứng.
5. Đo băng thông giữa nút, bộ nhớ cache và thời gian phục hồi khi một nút mất kết nối.
6. Thử nâng cấp và quay lại phiên bản cũ; chỉ chuyển lưu lượng thật khi quan sát, cảnh báo và quy trình xử lý sự cố đã đủ.

Nguồn tham khảo

Nếu đội phát triển chatbot đang cân nhắc cụm suy luận nhiều GPU, hãy chuẩn bị tên mô hình, kích thước ngữ cảnh, số người dùng đồng thời, TTFT mục tiêu và mức tải cao điểm. Gửi thông tin qua trang Thuê GPU Server để trao đổi cấu hình thử nghiệm và cách đo trước khi quyết định có cần kiến trúc phân tán hay không.