vLLM hỗ trợ TML Inkling ngay khi ra mắt với hiệu năng tối ưu

vLLM đã chính thức hỗ trợ mô hình TML Inkling ngay khi ra mắt. Cả hai phiên bản thinkingmachines/Inkling-NVFP4 và thinkingmachines/Inkling (BF16) đều được hỗ trợ với hiệu năng tối ưu và đầy đủ tính năng tương đương (full feature parity).

TML Inkling là mô hình đa phương thức (multimodal) có 1 nghìn tỷ tham số (1T parameters), được huấn luyện bởi Thinking Machines Lab. Mô hình có thể nhận đầu vào văn bản, hình ảsnh và âm thanh một cách tự nhiên, đồng thời sinh ra văn bản với độ dài ngữ cảnh lên tới 1 triệu token. Inkling giới thiệu nhiều thành phần kiến trúc mới như relative attention, short convolution và shared expert sinks, và tất cả hiện đã được tích hợp hiệu quả vào vLLM.

vLLM cung cấp hỗ trợ mạnh mẽ cho TML Inkling:

• Mô hình: hỗ trợ cả thinkingmachines/Inkling-NVFP4 và thinkingmachines/Inkling  (BF16)
• Phần cứng: GPU NVIDIA Blackwell và Hopper
  • Hỗ trợ thêm nhiều phần cứng khác đang được phát triển, và sẽ sớm được cập nhật trong các version tới.
• Đa phương thức: đầu vào văn bản / hình ảnh / âm thanh → đầu ra văn bản
• Độ dài ngữ cảnh: hỗ trợ gốc lên tới 1 triệu token (Tinker hiện cung cấp cửa sổ ngữ cảnh 64K và 256K)
• Tính năng: LoRA, speculative decoding (MTP), TP/DP/EP/PP, prefix caching, disaggregated serving và nhiều tính năng khác
• Tối ưu hóa: TP sharding nhận biết Sconv, fused collectives độ trễ thấp, kernel fusion, multi-streaming, PDL và nhiều tối ưu khác
• Hiệu năng: lên tới 380 token/giây/người dùng (có MTP) và 140 token/giây/người dùng (không MTP) 
• Độ chính xác: chất lượng mô hình và khả năng phân tích công cụ đã được xác minh bằng các benchmark MMAU, MMMU-Pro, BFCL, NIAH-1M và HLE

• Modality

TML Inkling là mô hình đa phương thức (multimodal) được thiết kế gốc với 1 nghìn tỷ tham số (1T parameters). Ngoài văn bản và hình ảnh, mô hình còn có thể nhận đầu vào âm thanh (audio) và sinh ra văn bản. Inkling sử dụng một bộ mã hóa hình ảnh cực kỳ nhẹ (hMLP) và các embedding âm thanh (dMel), như được mô tả trong bài giới thiệu mô hình tương tác của TML. Các embedding thu được sau đó được xử lý bởi kiến trúc Transformer chỉ có decoder (decoder-only Transformer backbone).

• Attention. 

Backbone của mô hình gồm 66 tầng: 11 tầng attention toàn phần (full-attention) và 55 tầng attention cửa sổ trượt (sliding-window attention). Việc sử dụng dày đặc sliding-window attention chính là yếu tố giúp mô hình hỗ trợ ngữ cảnh dài tới 1 triệu token một cách hiệu quả. Tất cả các tầng attention đều dùng Grouped-Query Attention (GQA) với kích thước head là 128.

Một lựa chọn thiết kế nổi bật của Inkling là sử dụng relative attention làm cơ chế vị trí. Thay vì dùng RoPE, Inkling cộng thêm một thành phần vị trí tương đối đã được học vào các giá trị attention logits trước bước softmax. 

• Sconv. 

Inkling sử dụng rất mạnh cơ chế short convolution (sconv) với kích thước cửa sổ bằng 4. Mỗi tầng chứa 4 mô-đun sconv, được áp dụng cho attention keys, attention values, attention output và đầu ra của MoE. Sconv hoạt động giống như một attention cục bộ nhỏ nhưng chỉ tạo thêm chi phí tính toán và bộ nhớ ở mức tối thiểu.

• MoE. 

Mỗi tầng có 256 expert được định tuyến (top-6) cùng với 2 expert dùng chung, vì vậy mỗi token được xử lý bởi tổng cộng 8 expert. Tuy nhiên, khác với các mô hình hiện có, Inkling giới thiệu khái niệm expert sink: hai expert dùng chung vẫn tham gia vào quá trình tính điểm định tuyến (hấp thụ một phần xác suất), nhưng không được đưa vào danh sách ứng viên khi chọn top-6 expert.

Trong mô hình thinkingmachines/Inkling-NVFP4, chỉ các expert được định tuyến mới được lượng tử hóa sang NVFP4; tất cả các tham số còn lại, bao gồm các expert dùng chung và các lớp tuyến tính qkvr, vẫn giữ ở định dạng BF16. Trong thinkingmachines/Inkling, các trọng số MoE cũng ở BF16.

• MTP. 

Inkling được trang bị 8 đầu MTP (Multi-Token Prediction) để phục vụ cơ chế giải mã suy đoán (speculative decoding), cho phép mô hình sinh tối đa 9 token trong mỗi bước forward. Các đầu MTP được xâu chuỗi (chained): mỗi head sẽ nhận hidden states và token nháp đã được lấy mẫu từ head trước đó. Mỗi head MTP là một Transformer một tầng với attention toàn phần hoặc attention cửa sổ trượt và một MLP dạng dense. Tất cả trọng số của MTP đều ở định dạng BF16.

vLLM triển khai mô hình một cách hiệu quả thông qua một loạt tối ưu hóa. Những điểm nổi bật chính:

Quản lý bộ nhớ đệm sconv. Phép tích chập ngắn (short convolution) yêu cầu lưu giữ các trạng thái ẩn (hidden states) của W-1 token cuối cùng. vLLM quản lý bộ nhớ đệm sconv này bằng cách coi nó như bộ nhớ đệm KV (KV cache) của một lớp attention cửa sổ trượt (sliding-window attention) ảo. Điều này cho phép vLLM xử lý bộ nhớ đệm sconv một cách gọn gàng thông qua trình quản lý KV cache hợp nhất của nó: các trạng thái nằm ngoài cửa sổ sẽ được đánh dấu là có thể thu hồi (evictable), và cơ chế lưu đệm tiền tố (prefix caching) hoạt động liền mạch với bộ nhớ đệm sconv.

TP sharding nhận biết sconv (Sconv-aware TP sharding). Một cách triển khai TP (Tensor Parallelism) trực tiếp cho mô hình này sẽ là: all-reduce (ví dụ sau o_proj) → sconv → kết nối residual → RMSNorm. Tuy nhiên, cách này áp dụng sconv lên toàn bộ hidden states trên mọi GPU, dẫn đến việc vừa nhân bản phần tính toán sconv vừa nhân bản cả bộ nhớ đệm sconv trên các rank.

Để loại bỏ sự nhân bản này, vLLM phân mảnh mô hình theo cách khác. Vì sconv hoạt động độc lập theo chiều kênh (channel dimension), chúng tôi phân mảnh sconv theo các kênh: thay vì dùng all-reduce, chúng tôi dùng reduce-scatter và all-gather trên chiều kênh. Khi đó, mỗi GPU chỉ lưu một mảnh (shard) của bộ nhớ đệm sconv và chỉ tính toán phần kênh thuộc về nó. Ý tưởng này tương tự sequence parallelism, nhưng việc phân mảnh được áp dụng lên chiều kênh thay vì chiều token.

Các collective hợp nhất độ trễ thấp (Low-latency fused collectives). vLLM tiếp tục triển khai một số kernel hợp nhất để tối ưu sơ đồ phân mảnh mới này. Cụ thể, chúng tôi xây dựng các kernel reduce-scatter và all-gather độ trễ thấp (được hợp nhất với các phép toán xung quanh) bằng cách mở rộng thiết kế giao thức Lamport của kernel all-reduce độ trễ thấp trong FlashInfer. Giao thức Lamport cho phép kernel đồng bộ bằng cách thăm dò giá trị dữ liệu thay vì dùng barrier tường minh, giúp giảm thời gian kernel ở batch size 1 từ 40 µs xuống 8 µs (nhanh hơn 5 lần).

FA4 với sheared bias. Attention tương đối làm phức tạp mẫu truy cập bộ nhớ, khiến pipeline tính toán của kernel attention chậm đi đáng kể. Để khắc phục điều này, TML phối hợp với Colfax Research đã phát hành một kernel FA4 mới với kỹ thuật sheared-bias, và vLLM tích hợp trực tiếp kernel này. Ngoài ra, vLLM còn chọn hệ số num_splits của FA4 cho từng cấu hình — có tính đến batch size, kích thước TP và độ dài KV — để tối đa hóa hiệu năng.

Tính toán lại bộ nhớ đệm KV của MTP. Vì mỗi đầu MTP nhận token dự thảo (draft token) của đầu trước làm đầu vào, nên bộ nhớ đệm KV của nó sẽ trở nên lỗi thời mỗi khi một draft token bị từ chối. vLLM xử lý việc này cẩn thận: nó lưu cache hidden states của mô hình gốc cho vài token cuối cùng và chạy lại các đầu MTP với những token đã được chấp nhận sau bước lấy mẫu từ chối (rejection sampling).

Ngoài các tối ưu trên, phần triển khai mô hình của vLLM còn bao gồm thêm các kỹ thuật hợp nhất kernel, PDL và multi-streaming để đạt hiệu năng gần mức giới hạn phần cứng (speed-of-light performance). 

Nhờ các tối ưu hóa sâu rộng ở trên, vLLM đạt 380 token/giây/người dùng (tok/s/user) khi sử dụng MTP8 (độ dài chấp nhận trung bình là 4,5 token) và 140 token/giây/người dùng khi không sử dụng MTP trên hệ thống 4 GPU.

Kết quả được đo trên các prompt có 8K token đầu vào được lấy mẫu từ SPEED-Bench, với 1K token đầu ra được sinh cho mỗi yêu cầu.

Tính chính xác của phần triển khai trong vLLM bằng các bộ benchmark toàn diện, bao phủ mọi phương thức và khả năng của mô hình:

• Âm thanh (Audio): MMAU
• Thị giác (Vision): MMMU-Pro
• Gọi công cụ (Tool calling): BFCL
• Lập luận (Reasoning): HLE
• Ngữ cảnh dài (Long context): NIAH

vLLM khớp với phần triển khai tham chiếu trên tất cả các hạng mục.

Đối với ngữ cảnh dài, vLLM cho kết quả khớp hoàn toàn với bản tham chiếu đến 221K token và duy trì sai lệch trong khoảng ~1 điểm phần trăm (pp) đến 513K token. Ở các độ dài ngữ cảnh cực lớn (trên 800K token), điểm số NIAH cho thấy độ biến thiên giữa các lần chạy cao hơn đối với benchmark này.

Như đã mô tả ở trên, vLLM cung cấp mức hỗ trợ rất mạnh cho TML Inkling. Trong thời gian tới, chúng tôi nhận thấy một số hướng cải thiện tiềm năng:

• FP8 cho global attention: Inkling hiện đang sử dụng BF16 cho global attention, điều này có thể trở thành nút thắt cổ chai cả về năng lực tính toán lẫn dung lượng bộ nhớ đệm KV. Chúng tôi dự định khám phá việc sử dụng FP8 ở phần này bằng cách sửa đổi kernel FA4 mới.
• CUDA Graphs cho bộ mã hóa hình ảnh và âm thanh: Các bộ mã hóa hình ảnh và âm thanh hiện đang chạy ở eager mode. Mặc dù đây thường không phải vấn đề lớn vì chúng chạy trong giai đoạn prefill, chúng tôi dự định áp dụng CUDA Graphs cho chúng để loại bỏ hoàn toàn overhead từ CPU.
• Hỗ trợ GPU AMD: GPU AMD hiện chưa được hỗ trợ cho mô hình này, do cơ chế attention tương đối mới yêu cầu một kernel chuyên biệt. 

Sự xuất hiện của TML Inkling cùng với khả năng hỗ trợ từ vLLM cho thấy hệ sinh thái AI inference đang tiến rất nhanh theo hướng đa phương thức, ngữ cảnh dài và hiệu năng cao. Tuy nhiên, để khai thác hiệu quả các tối ưu như MTP, FA4, FP8 và Tensor Parallelism, hạ tầng GPU đóng vai trò quyết định.

Nếu bạn đang muốn triển khai vLLM cho các mô hình LLM/VLM quy mô lớn, benchmark hiệu năng, xây dựng hệ thống RAG hoặc phục vụ suy luận đa GPU, dịch vụ GPU Cloud của iRender có thể giúp bạn bắt đầu nhanh chóng với các cấu hình 1/2/4/6 RTX 4090, RTX 5090, hỗ trợ đầy đủ môi trường CUDA, Docker và vLLM.

iRender – Hạ tầng GPU hiệu năng cao cho AI, Machine Learning và vLLM Inference tại Việt Nam.

Nguồn tham khảo: https://vllm.ai/