ZenteiQ thay round-robin bằng GKE Inference Gateway và llm-d cho pipeline vLLM
Case study trên Google Cloud Blog: ZenteiQ bỏ cân bằng tải round-robin của ClusterIP, dùng GKE Inference Gateway và llm-d để định tuyến theo hàng đợi và prefix cache, tăng throughput sinh dữ liệu khoảng 4 lần.
Vibe DevOps biên soạn ngày · khoảng 559 từ
Điểm chính từ bài gốc
- ZenteiQ chạy pipeline sinh dữ liệu tổng hợp theo lô trên GKE, tách worker pod chuẩn bị prompt khỏi các pool vLLM nhiều node.
- Round-robin qua ClusterIP không thấy hàng đợi của vLLM nên dồn request vào pod đang bận, trong khi node bên cạnh còn trống.
- Khoảng 70% đến 80% nội dung prompt trong một lô giống nhau, nhưng round-robin rải request khắp các instance khiến prefix phải tính lại.
- GKE Inference Gateway dựa trên llm-d theo dõi độ sâu hàng đợi và mức dùng KV cache để chọn node, đồng thời gom prompt cùng prefix về node có cache ấm.
- Theo ZenteiQ, throughput tổng tăng khoảng 4 lần, tỷ lệ trúng prefix cache tăng 14 điểm phần trăm và lịch pre-training ổn định hơn.
Theo bài gốc
Bối cảnh và nút thắt
Đây là bài case study do khách hàng và Google Cloud cùng viết trên blog của nhà cung cấp, không phải thông báo ra mắt tính năng mới. ZenteiQ là startup tách ra từ Viện Khoa học Ấn Độ, xây mô hình nền tảng khoa học và cần lượng lớn dữ liệu suy luận tổng hợp để pre-train bằng MaxText trên GKE.
Mỗi lô dữ liệu đi qua bốn bước: mở rộng khái niệm gốc thành prompt, sinh lời giải bằng mô hình generator, chấm điểm bằng mô hình evaluator và kiểm tra guardrail bằng một họ mô hình khác. Khi mở rộng cho các mô hình 9B và 35B tham số, việc định tuyến round-robin khiến throughput dao động tới một nửa ngay trong một lần chạy. Hệ quả là dữ liệu ra chậm, cụm accelerator dành cho pre-training phải ngồi chờ.
Theo bài gốc
Điểm thay đổi trong lớp định tuyến
ZenteiQ đặt một deployment GKE Inference Gateway duy nhất trước toàn bộ pool vLLM, dùng chung cho request sinh dữ liệu, chấm điểm và guardrail thay vì định tuyến riêng cho từng tầng mô hình. Quyết định chọn node dựa trên tín hiệu sống từ vLLM: node đang giải mã chuỗi suy luận dài sẽ không nhận thêm việc, còn prompt cùng chỉ dẫn được đưa về node đã có KV cache của prefix đó.
Từng pool mô hình ghi nhận mức tăng từ 3,5 đến 5,5 lần, và kế hoạch tiếp theo là dùng cùng cách định tuyến cho vòng reinforcement learning nhiều lượt.
Bình luận của Vibe DevOps — không phải nội dung bài gốc
Góc nhìn vận hành
Góc nhìn Vibe DevOps: Bài học chính là Service Kubernetes mặc định không hiểu tải thực của một server suy luận. Với workload LLM có độ dài phản hồi chênh lệch lớn và prompt chung nhiều phần, đội vận hành nên đo phân bố hàng đợi và tỷ lệ trúng cache trên từng replica trước khi thêm GPU.
- Thu thập metric hàng đợi và KV cache của vLLM theo từng pod.
- Thử trên một pool nhỏ và so sánh throughput trước khi áp dụng rộng.
⚠️ Lưu ý và giới hạn
- Số liệu do ZenteiQ và Google Cloud công bố trên blog của nhà cung cấp, chưa được kiểm chứng độc lập.
- GKE Inference Gateway là dịch vụ riêng của Google Cloud; llm-d là dự án mã nguồn mở, cách dùng ngoài GKE cần xem tài liệu gốc.