vLLM x TileRT: Tối ưu AI inference độ trễ thấp với decode chuyên biệt

vLLM x TileRT là một hướng tiếp cận mới cho AI inference độ trễ thấp, trong đó prefill và decode được tách rời để tối ưu đồng thời thông lượng và tốc độ phản hồi trên mỗi người dùng.

Phục vụ suy luận tách rời (disaggregated serving), vốn tách pha prefill bị giới hạn bởi năng lực tính toán (compute-bound) khỏi pha decode bị giới hạn bởi băng thông bộ nhớ (memory-bandwidth-bound), đang ngày càng trở thành mô hình tiêu chuẩn cho AI inference và LLM serving ở quy mô lớn, và vLLM hỗ trợ mô hình này thông qua một giao diện connector hạng nhất (first-class connector interface).

Sự chuyển dịch về kiến trúc đó mang lại một lợi ích rất dễ bị bỏ qua: một khi prefill và decode được tách rời, phía decode trở thành thành phần có thể hoán đổi (pluggable). Các chế độ phục vụ khác nhau sẽ ưu tiên các thiết kế engine khác nhau. Cụm prefill, bộ lập lịch (scheduler), lớp bộ nhớ đệm (caching layer) và API phục vụ vẫn giữ nguyên vị trí của chúng, trong khi cụm decode trở thành một lựa chọn có chủ đích.

Hôm nay, chúng ta cùng đến với vLLM prefill kết hợp với TileRT decode, được tích hợp thông qua giao diện connector công khai của vLLM V1 và phát hành cùng với TileRT 0.1.5. Đối với các khối lượng công việc yêu cầu độ trễ cực thấp, sự kết hợp này mang lại tốc độ decode trên mỗi người dùng ở mức gốc (native) của TileRT, trong khi mọi thành phần khác của hệ thống triển khai vẫn là vLLM nguyên bản (stock vLLM).

Decode gốc của vLLM hiện tại là lựa chọn mặc định đúng đắn: nó được xây dựng để phục vụ suy luận theo lô với thông lượng cao trên một phạm vi rất rộng các mô hình và phần cứng. Tuy nhiên, đang xuất hiện một nhóm workload ngày càng lớn – ví dụ như vòng lặp agentic, trợ lý lập trình tương tác, giọng nói thời gian thực – trong đó chỉ số quan trọng không phải là thông lượng tổng thể, mà là tốc độ token đến được với từng người dùng riêng lẻ. Các workload này bị giới hạn bởi độ trễ, và chúng đòi hỏi một engine decode được thiết kế ngay từ đầu cho chính chế độ hoạt động đó. Decode gốc và TileRT nhắm đến những điểm khác nhau trên cùng một đường biên thông lượng – độ trễ (throughput-latency frontier), vì vậy chúng có thể kết hợp với nhau.

TileRT là một engine như vậy: một runtime suy luận mới được xây dựng xoay quanh mục tiêu duy nhất là đẩy tốc độ decode trên mỗi người dùng tiến gần tới giới hạn của phần cứng. 

Vậy, liệu bạn có thể áp dụng một engine decode chuyên biệt mà không phải từ bỏ hệ sinh thái mà bạn đang phụ thuộc vào, chẳng hạn như API tương thích OpenAI, bộ lập lịch, prefix caching, tool calling và mức độ trưởng thành trong vận hành của vLLM hay không?

Sự tích hợp này được thiết kế để làm cho sự đánh đổi đó nhỏ nhất có thể:

• Prefill vẫn là vLLM. Bộ lập lịch, chunked prefill, prefix caching – hoàn toàn không thay đổi.
• Bề mặt phục vụ (serving surface) vẫn là vLLM. Cùng API, cùng định dạng request, cùng hệ sinh thái công cụ.
• Chỉ decode thay đổi, và chỉ đối với phần lưu lượng bạn gửi sang đó. Stack ghép với TileRT chạy song song với deployment vLLM hiện có của bạn; mỗi workload sẽ chọn endpoint phù hợp với nó.

Nguyên tắc thiết kế cốt lõi là không thay đổi gì đối với vLLM: không fork, không vá (patch), không bọc (wrap) các worker nội bộ. Toàn bộ phần tích hợp nằm hoàn toàn phía sau bề mặt mở rộng công khai của vLLM V1, cụ thể là một phần triển khai KVConnectorBase_V1, được kết hợp dưới MultiConnector và được nạp thông qua cơ chế tiêu chuẩn kv_connector_module_path.

Điều này quan trọng vượt ra ngoài khía cạnh thẩm mỹ kỹ thuật: việc bổ sung một cụm decode TileRT không thể làm mất ổn định deployment vLLM mà bạn đang vận hành, và khi nâng cấp vLLM, bạn không cần phải re-port một bản fork.

Cùng tồn tại theo thiết kế: lưu lượng nhạy cảm với độ trễ được bộ định tuyến TileRT PD đánh dấu và được bộ kết nối TileRT tiếp nhận, trong khi lưu lượng thông thường đi qua đường dẫn phân tách (disaggregation) nguyên bản; cả hai đều được phục vụ bởi một nhóm tài nguyên prefill vLLM tiêu chuẩn duy nhất được thiết lập theo cơ chế MultiConnector.

Routing: Một bộ định tuyến nhẹ nằm phía trước cụm TileRT. Với mỗi yêu cầu, nó đặt max_tokens=1 (vLLM thực hiện prefill và sinh ra token đầu tiên) và gắn nút decode đích vào trường pass-through tiêu chuẩn: kv_transfer_params = {“tilert_host”: …, “tilert_ctrl_port”: …}. Lưu lượng dành cho cụm decode gốc vẫn đi qua proxy disaggregation thông thường, không có bất kỳ thay đổi nào.

Claim filtering: Connector của TileRT chỉ nhận những yêu cầu mang dấu đánh dấu này và hoàn toàn là no-op nghiêm ngặt đối với mọi yêu cầu khác. Vì vậy, hai cụm decode có thể dùng chung một instance prefill (thậm chí trong cùng một forward batch). Việc áp dụng TileRT cho một phần lưu lượng sẽ không làm thay đổi điều gì đối với phần lưu lượng còn lại.

Một producer thuần túy: Connector hoạt động chỉ với vai trò kv_producer; nó không bao giờ can thiệp vào quá trình lập lịch (scheduling) hay lấy mẫu (sampling). Nhiệm vụ của nó là trích xuất và gửi trạng thái sau khi prefill hoàn tất. Ở mọi khía cạnh khác, instance prefill vẫn là một máy chủ vLLM nguyên bản (stock vLLM server).

Để mô hình disaggregation xuyên giữa các engine (cross-engine disaggregation) trở nên thực tế, cần thỏa mãn ba điều kiện: quá trình truyền phải nhanh, không được làm chậm nút prefill, và engine decode phải tiếp tục chính xác từ vị trí mà prefill đã dừng lại.

Data plane: Sau khi prefill hoàn tất, trạng thái attention của yêu cầu (bao gồm KV đã nén, các bộ nhớ đệm chỉ mục attention thưa (sparse-attention index caches), và một lượng nhỏ metadata được chuyển sang nút decode bằng các thao tác RDMA one-sided write trực tiếp vào các buffer GPU đã được đăng ký trước, với Mooncake hoặc NIXL làm engine truyền dữ liệu. Không có bước tuần tự hóa (serialization) trung gian, không có bước đệm qua bộ nhớ host. Bản thân giao thức bàn giao hoàn toàn độc lập với engine truyền dữ liệu bên dưới; nhiệm vụ của engine chỉ là di chuyển các byte dữ liệu.

Chồng lấp hoàn toàn với prefill: Việc trích xuất trạng thái diễn ra ngay bên trong cửa sổ forward: trạng thái của yêu cầu được sao chép sang một buffer tạm trước khi các block cache của nó có thể được tái sử dụng, và một tiến trình gửi nền (background sender) thực hiện việc truyền mạng thực tế. Một yêu cầu được chuyển tới TileRT không bao giờ chặn vòng lặp prefill tiếp theo, kể cả đối với các yêu cầu thuộc cụm decode gốc đang dùng chung cùng một batch.

Tiêm vào một engine đang chạy (Injection into a live engine): Khi đến nơi, trạng thái được chuyển đổi sang bố cục gốc (native layout) của TileRT và được tiêm trực tiếp vào một engine đang hoạt động; quá trình decode bắt đầu ngay lập tức, với speculative decoding đa token được kích hoạt ngay từ bước đầu tiên.

Tốc độ sinh token của GLM-5.1-FP8 trên hệ thống 8× NVIDIA B200 sử dụng TileRT v0.1.5. Độ dài đầu ra là 1K token, độ dài đầu vào dao động từ 1K đến 192K token. Các thanh biểu đồ so sánh hiệu năng giữa TileRT không dùng MTP, TileRT dùng MTP với độ dài chấp nhận trung bình là 3,2, và mức đỉnh đạt được khi độ dài chấp nhận của MTP ở mức tối ưu là 4,0.

Hãy định tuyến sang TileRT decode khi tốc độ sinh token trên mỗi người dùng là ràng buộc quan trọng nhất, ví dụ như các tác vụ agent tương tác, trợ lý thời gian thực, suy luận có SLA độ trễ nghiêm ngặt, và mô hình nằm trong danh sách được TileRT hỗ trợ.

Tiếp tục sử dụng native vLLM decode khi mục tiêu là thông lượng tổng thể tối đa, batching với độ đồng thời cao, và hỗ trợ dải mô hình cũng như tính năng rộng mà cơ chế decode đa dụng của vLLM cung cấp.

Cả hai stack đều cung cấp cùng một bề mặt API tương thích OpenAI, vì vậy việc chuyển một workload giữa chúng chỉ là thay đổi định tuyến (routing change) chứ không phải thay đổi phía client.

Các giới hạn hiện tại. Trong bản phát hành này, một nút TileRT decode chỉ phục vụ một yêu cầu đang xử lý tại một thời điểm, với bộ định tuyến đảm nhiệm việc phân phối có kiểm soát (gated dispatch) và điều áp ngược (back-pressure). Phạm vi mô hình được hỗ trợ ở phiên bản hiện tại bao gồm GLM-5/5.1 và DeepSeek-V3.2, và sẽ còn được mở rộng thêm trong thời gian tới.

TileRT 0.1.5 hiện đã có trên PyPI (pip install tilert; hỗ trợ Python 3.12 và các gói wheel cho CUDA 13) và trong kho mã nguồn TileRT.

Hãy cài đặt TileRT trên cả nút prefill và nút decode; phía prefill cần TileRT để sử dụng plugin connector.

# 0. One-time: convert the HF checkpoint to TileRT’s weight format
python -m tilert.models.preprocess.weight_converter \
–model_type glm-5 \
–model_dir /path/to/GLM-5.1 \
–save_dir /path/to/tilert-glm5.1-weights

# 1. Start the TileRT decode node
python -m tilert.pd_vllm.decode_server \
–engine tilert \
–model glm5 \
–model-weights-dir /path/to/tilert-glm5.1-weights \
–with-mtp \
–max-seq-len 202752 \
–kv-cache-dtype fp8 \
–ctrl-port 5556 \
–http-port 5557

# 2. Start the vLLM prefill node (stock vLLM; connector loaded as a plugin)
# The MTP speculative config is required because prefill populates
# the draft-layer KV that decode-side speculation resumes from.
vllm serve /path/to/GLM-5.1 \
–served-model-name glm5.1 \
–port 8000 \
–tensor-parallel-size 8 \
–enforce-eager \
–trust-remote-code \
–return-tokens-as-token-ids \
–gpu-memory-utilization 0.8 \
–kv-cache-dtype fp8_ds_mla \
–speculative-config ‘{“method”: “mtp”, “num_speculative_tokens”: 1}’ \
–kv-transfer-config ‘{
“kv_connector”: “TileRTConnector”,
“kv_connector_module_path”: “tilert.pd_vllm.prefill_connector”,
“kv_role”: “kv_producer”,
“kv_connector_extra_config”: {
“tilert_host”: “[TILERT_DECODE_SERVER_IP]”,
“tilert_ctrl_port”: 5556,
“tilert_model”: “glm5”,
“tilert_max_seq_len”: 202752
}
}’

# 3. Start the OpenAI-compatible router for the TileRT pool
python -m tilert.pd_vllm.pd_router \
–vllm-url http://prefill-node:8000 \
–decode decode-node:5556:5557 \
–model-path /path/to/GLM-5.1 \
–port 23333

Chạy đồng thời TileRT và native vLLM decode trên cùng một cụm prefill

Để chạy một cụm TileRT decode và một cụm native vLLM decode phía sau cùng một instance prefill dùng chung, hãy kết hợp cả hai connector dưới MultiConnector.

Cấu hình mà chúng tôi đã xác thực sử dụng NIXL xuyên suốt toàn bộ đường truyền: NixlConnector tiêu chuẩn của vLLM cho cụm native, và connector của TileRT ở chế độ NIXL cho cụm TileRT. Nhờ vậy, instance prefill dùng chung chỉ cần một thư viện truyền dữ liệu duy nhất; phần thay đổi duy nhất là tham số –kv-transfer-config của prefill.