Nền tảng phục vụ LLM nội bộ của Netflix

• Netflix không tách LLM thành một silo riêng mà vận hành cùng trong hạ tầng ML hiện có, đồng thời kết nối vLLM và Triton vào hệ thống phục vụ thống nhất
• vLLM được chọn làm engine mặc định nhờ hỗ trợ mô hình tùy biến, dễ debug, có hook mở rộng và quen thuộc với môi trường nghiên cứu; backend vLLM của Triton cũng giúp giảm độ kết dính giữa mô hình và frontend
• Dù cung cấp đồng thời gRPC hiện có và API tương thích OpenAI, họ vẫn phải tự khắc phục những khoảng cách bộc lộ trong production như thiếu response_format, lệch phiên bản Triton·vLLM và xử lý mô hình phi tiêu chuẩn
• Để triển khai ổn định, họ ưu tiên chiến lược Red-Black với chi phí thấp, và chỉ dùng chiến lược Versioned duy trì nhiều phiên bản song song khi không thể tránh thay đổi I/O không tương thích
• Họ tái triển khai bộ xử lý logit ép buộc ràng buộc theo từng request trong vòng lặp decoding bằng xử lý batch của vLLM V1 và C++ đa luồng, đồng thời có kế hoạch mở rộng sang kernel hợp nhất trên GPU, lập lịch bất đồng bộ và mô hình độ chính xác thấp trong tương lai

---

Kiến trúc phục vụ tích hợp vào hạ tầng ML hiện có

• Hệ thống phục vụ hợp nhất dựa trên JVM của Netflix xử lý định tuyến và A/B test, sinh ứng viên, tra cứu đặc trưng, suy luận, hậu xử lý và logging theo từng giai đoạn, đồng thời hỗ trợ cả luồng thời gian thực lẫn batch có cache
• Bên gọi có thể truy cập suy luận qua đường gRPC của hệ thống phục vụ hiện có hoặc đường HTTP trực tiếp mới cho các ứng dụng LLM
• Vị trí thực thi thay đổi tùy theo quy mô mô hình
  • Mô hình CPU nhỏ chạy trong tiến trình để tránh chi phí gọi từ xa
  • Mô hình GPU lớn xử lý tiền xử lý và hậu xử lý ở cục bộ rồi giao suy luận cho Model Scoring Service (MSS) từ xa
• MSS cung cấp XGBoost, TensorFlow, PyTorch và LLM qua một giao diện thống nhất; phía dưới, NVIDIA Triton Inference Server phụ trách nạp mô hình, xử lý batch và lập lịch GPU
• Lớp điều khiển Java phía trên Triton xử lý triển khai, quản lý phiên bản, kiểm tra trạng thái, tự động mở rộng và rollout đa vùng
  • Khi nhà phát triển mô hình đóng gói artifact và cấu hình triển khai, hệ thống sẽ cấp phát instance GPU và cấu hình Triton
  • Việc nâng cấp được điều phối theo cách không gián đoạn dịch vụ

Chọn vLLM làm engine suy luận mặc định

• Nền tảng ban đầu dùng TensorRT-LLM, vốn có hiệu năng cao vào thời điểm đó và đã được tích hợp sẵn với Triton trong MSS
• Đến mùa hè năm 2025, các engine mã nguồn mở đã thu hẹp phần lớn chênh lệch hiệu năng với các stack chuyên biệt, còn workload cũng mở rộng sang các dạng sau
  • Tạo embedding
  • Suy luận chỉ-prefill cho xếp hạng và tìm kiếm
  • Decoding tự hồi quy
  • Mô hình tùy biến với logic ràng buộc theo từng bước phức tạp
• Sau khi benchmark lại các workload này, họ chọn vLLM làm engine mặc định dựa trên mức độ phù hợp vận hành
  • Có thể nạp kiến trúc mô hình tùy biến mà không cần biên dịch nhiều giai đoạn, giúp tăng tốc vòng lặp phát triển cho mô hình phi tiêu chuẩn
  • Cung cấp hook mở rộng cho logic decoding tùy biến
  • So với TensorRT-LLM thời đầu là engine biên dịch, việc điều tra sự cố và trạng thái trung gian dễ hơn
  • Nhiều người làm ML đã quen với vLLM từ giai đoạn nghiên cứu nên giảm chi phí chuyển sang production

Cách đóng gói Triton và vLLM

• Triton có hai đường đóng gói là Python backend và backend vLLM; khác biệt cốt lõi nằm ở mức độ gắn kết giữa nâng cấp frontend và artifact mô hình
• Với Python backend, nhà phát triển định nghĩa đặc tả tensor đầu vào/đầu ra tại thời điểm đóng gói
  • Đặc tả được cố định trong artifact và phải khớp với request builder của frontend bên ngoài
  • Nếu I/O thay đổi do nâng cấp frontend thì mã đóng gói cũng phải sửa theo; nếu không, request lúc runtime sẽ thất bại
• Artifact của backend vLLM gồm cấu hình JSON trỏ tới trọng số mô hình và tokenizer
  • Khi triển khai, backend Triton sẽ động tạo đặc tả tensor I/O
  • Nhà phát triển mô hình không cần tự định nghĩa đặc tả tensor, đồng thời có thể thay đổi mô hình và frontend độc lập với nhau
• Dù lựa chọn mặc định là backend vLLM, hai ràng buộc đã xuất hiện trong production
  • Lệch phiên bản: backend Triton được biên dịch theo một API vLLM cụ thể, nên nếu hai phiên bản lệch nhau thì toàn bộ backend sẽ không thể nạp
    • Ví dụ, Triton 25.09 import vllm.engine.metrics, nhưng module này đã bị gỡ trong vLLM 0.11.2
    • Khi tạo image dịch vụ, cần ghim phiên bản tương thích và ngăn nhà phát triển mô hình ghi đè phiên bản vLLM ở bước đóng gói
  • Logic thực thi tùy biến: backend vLLM giả định mô hình chuẩn tương thích HuggingFace và toàn bộ vòng đời suy luận chuẩn
    • Với tiền xử lý/hậu xử lý tùy biến, pipeline ensemble, token hóa riêng hoặc các thực thi phi tiêu chuẩn khác, cần Python backend để kiểm soát execute()
    • Một số mô hình vẫn sẽ tiếp tục cần đường vòng này

gRPC và HTTP API tương thích OpenAI

• Từ ensemble XGBoost đến LLM quy mô lớn đều được đánh giá qua cùng một lời gọi gRPC, giúp tái sử dụng thư viện client, kiểm tra trạng thái và pipeline triển khai hiện có
• Do các engine suy luận, framework điều phối, công cụ đánh giá và thư viện client trong hệ sinh thái LLM sử dụng giao diện tương thích OpenAI, Netflix cung cấp giao diện này song song với gRPC
• Việc giữ nguyên cùng một API giúp giảm thay đổi mã khi chuyển từ mô hình host sẵn sang mô hình tự host đã fine-tune vì lý do chất lượng, độ trễ, chi phí hay quyền riêng tư dữ liệu
• Phần triển khai tái sử dụng frontend tương thích OpenAI của Triton từ NVIDIA
  • Khởi động Triton server nhúng
  • TritonLLMEngine chuyển schema request thành request suy luận Triton
  • Trả response qua FastAPI
  • Đồng thời bật frontend HTTP/gRPC của KServe để lớp điều khiển Java có thể truy cập cùng instance Triton qua gRPC
• Họ phát hiện frontend âm thầm bỏ qua response_format được cho phép trong schema trước khi chuyển sang vLLM
  • Ngay cả khi yêu cầu đầu ra JSON, request vẫn chạy mà không có ràng buộc guided decoding và có thể trả về JSON sai, trong khi nền tảng cũng không báo lỗi
  • Họ đưa frontend vào dưới dạng Git subtree và vá để chuyển request response_format thành tham số guided decoding của vLLM

Chiến lược triển khai mô hình không gián đoạn

• Triển khai GPU có thời gian khởi động dài hơn dịch vụ CPU, và schema I/O cũng có thể thay đổi giữa các phiên bản mô hình, nên rollout không ngắt request cần thêm điều chỉnh
• Triển khai Red-Black dựng phiên bản mới cạnh phiên bản cũ rồi dần chuyển traffic sau khi vượt qua kiểm tra trạng thái
  • Mở rộng và thu hẹp phiên bản mới và cũ theo cùng một tỷ lệ
  • Có thể rollback nguyên tử nếu thất bại ở bất kỳ giai đoạn nào
  • Phù hợp khi giao diện mô hình ổn định
• Khi schema I/O thay đổi, chẳng hạn chiều tensor mới, Red-Black sẽ tạo ra khoảng trống điều phối
  • Bên tiêu thụ phía trên không thể đổi cấu hình trước khi mô hình mới được kích hoạt hoàn toàn
  • Nếu request theo định dạng cũ bị gửi tới deployment mới trong giai đoạn chuyển đổi thì sẽ thất bại
• Triển khai Versioned giải quyết vấn đề này bằng cách duy trì deployment độc lập cho từng cặp (modelId, modelVersion)
  • Vì phục vụ nhiều phiên bản cùng lúc, triển khai mô hình và cập nhật phía tiêu thụ được tách rời
  • Bên tiêu thụ đổi cấu hình sau khi phiên bản mới sẵn sàng hoàn toàn, còn phiên bản cũ tiếp tục xử lý traffic legacy
  • Các deployment cũ không còn hoạt động sẽ bị dọn dẹp, nhưng phiên bản mới nhất luôn được giữ lại
  • Trong giai đoạn các phiên bản chồng lấp khi chuyển đổi, chi phí GPU tạm thời tăng lên
• Họ khuyến nghị đưa các cấu hình có thể thay đổi như shape tensor trực tiếp vào mô hình suy luận để chúng độc lập với phiên bản, từ đó có thể dùng Red-Black với chi phí thấp hơn
• Chỉ dùng Versioned khi không thể tránh thay đổi giao diện không tương thích

Quy trình khởi động và cache mô hình

• Một instance vLLM-on-Triton phải hoàn tất nhiều bước khởi động mới có thể mở cổng gRPC
• Nếu tải trực tiếp LLM lớn từ S3 hoặc Hugging Face lúc khởi động thì thời gian cold start sẽ dài vượt quá ngưỡng mà scheduler cho phép
  • Họ materialize mô hình sẵn vào Amazon FSx tại thời điểm công bố mô hình
  • Sau đó quá trình khởi động dùng hệ thống file hiệu năng cao thay cho object storage
• Với các deployment cần API tương thích OpenAI, Triton chạy như server nhúng bên trong tiến trình frontend đó
  • Các deployment khác chạy Triton ở chế độ độc lập
  • Cách chạy được cấu hình theo từng deployment lúc đóng gói
• Các bước khởi động còn lại gồm giải nén gói mô hình, cài plugin vLLM tùy biến qua Python entry_points, dọn thư mục đa tiến trình của Prometheus và chặn cổng gRPC cho đến khi engine sẵn sàng

Tích hợp metric giữa Triton và vLLM

• vLLM ghi metric vào các file .db trong PROMETHEUS_MULTIPROC_DIR, còn Triton cung cấp metric máy chủ qua một endpoint Prometheus riêng
• Hai hệ thống không nhận biết metric của nhau, và cầu nối tích hợp sẵn trong Triton chỉ lộ ra 9 trong hơn 40 metric của vLLM
  • Throughput token
  • Tỷ lệ sử dụng KV cache
  • Các chỉ số quan trọng như tỷ lệ hit của prefix cache bị thiếu
• Một proxy HTTP gọn nhẹ lấy metric Triton qua HTTP, đồng thời dùng MultiProcessCollector của Prometheus để đọc metric vLLM trên đĩa rồi gộp chúng thành một response /metrics duy nhất
• Các dashboard và cảnh báo hiện có có thể tiếp tục dùng nguyên trạng mà không cần sửa

Ép ràng buộc đầu ra trong quá trình decoding

• Một số workload production cần kiểm soát chi tiết việc sinh token, nên thay vì retry hoặc khôi phục kết quả sai sau suy luận, họ áp dụng ràng buộc ngay trong vòng lặp decoding
• Mỗi ràng buộc được mô hình hóa như một state machine thay đổi trạng thái theo lịch sử token đã sinh và xuất ra mask token hợp lệ ở từng bước
• Họ dùng giao diện logit processor tùy biến của vLLM; vì quy tắc khác nhau theo từng request nên sẽ gán processor được cấu hình riêng cho từng request
• Ban đầu họ dùng vLLM V0 do thiếu tính năng, rồi chuyển sang V1 vào quý 4 năm 2025 khi V1 đã đủ trưởng thành

Nút thắt mở rộng gặp phải trong vLLM V0

• Bản cài đặt thuần Python đầu tiên hoạt động đúng về chức năng nhưng không mở rộng được khi số request đồng thời tăng lên
• Trong vLLM V0, logit processor tùy biến chạy theo từng request
  • GPU sinh logit cho toàn bộ batch
  • CPU sao chép chúng và chờ truyền xong
  • Logic ràng buộc của từng request được chạy tuần tự
• Do GIL của Python, không thể song song hóa công việc theo request, nên thời gian CPU cho xử lý logit tăng tỷ lệ với kích thước batch và độ trễ đuôi cũng tăng theo
• Dù forward của mô hình trên GPU được batch hiệu quả, độ trễ tổng thể vẫn bị CPU ghìm lại
• Nút thắt này không lộ ra trong benchmark một request mà chỉ xuất hiện ở mức đồng thời thực tế

Xử lý theo đơn vị batch của vLLM V1

• vLLM V1 chuyển xử lý logit từ kiểu theo từng request sang theo đơn vị batch
• Họ viết lại processor tùy biến dựa trên cấu trúc dữ liệu batch để tính mask cho nhiều request cùng lúc
• Đường nóng hiệu năng được tái triển khai bằng C++ đa luồng để tránh GIL, nhờ đó thời gian xử lý logit giữ ổn định ngay cả khi kích thước batch tăng
• Trong API của V1, cần theo dõi tường minh sự thay đổi của các thành viên trong batch qua update_state(batch_update)
  • Phức tạp hơn giao diện theo request của V0
  • Nhưng cần thiết để giữ chính xác trạng thái theo từng request trong batch thay đổi động

Củng cố vận hành cho xử lý ràng buộc theo trạng thái

• Sau khi giải quyết nút thắt hiệu năng, hai vấn đề khác tiếp tục xuất hiện trong logic decoding có trạng thái

• Partial prefill

  • V1 thực hiện prefilling theo từng chunk, nên prefill của một request có thể kéo dài qua nhiều bước của engine
  • Chỉ với BatchUpdate thì không thể phân biệt prefill hoàn chỉnh và prefill một phần, nên họ bổ sung cơ chế theo dõi nội bộ

• Preemption

  • Khi thiếu bộ nhớ, vLLM có thể loại bỏ KV cache của một số request chưa hoàn tất rồi lên lịch lại chúng sau đó với danh sách prompt và token đầu ra khác
  • Điều này phá vỡ giả định của state machine rằng danh sách token đầu ra luôn tiếp tục dài ra
  • Họ phát hiện khi lịch sử token bị ngắn đi giữa các bước decoding, sau đó khởi tạo lại state machine và dựng lại nó từ prompt mới

Các hạng mục đầu tư tiếp theo

• Nền tảng hiện tại hướng tới độ trễ thấp, khả năng tùy biến sâu và tích hợp với hạ tầng hiện có, đồng thời cung cấp một con đường từ thử nghiệm đến production thông qua vLLM và Triton cùng API nhất quán
• Họ cải thiện độ ổn định của nền tảng và trải nghiệm lập trình viên bằng cách xử lý các vấn đề như ghim phiên bản, trường API bị bỏ sót âm thầm và đánh đổi trong lựa chọn đóng gói
• Bốn cải tiến tiếp theo được lên kế hoạch
  • Nén system prompt để rút ngắn độ dài prompt mà không làm giảm chất lượng
  • Lập lịch bất đồng bộ của vLLM V1
  • Logit processor vector hóa chạy bằng kernel hợp nhất trên GPU thay cho mã CPU
  • Các biến thể mô hình độ chính xác thấp để giảm dùng bộ nhớ và tăng throughput
• Họ sẽ tiếp tục tận dụng các thư viện ML mã nguồn mở như Triton, vLLM, PyTorch và hợp tác với các cộng đồng liên quan