Ra mắt vLLM AFD Plugin: Tách biệt Attention và FFN để phục vụ MoE linh hoạt

Chúng tôi rất vui được giới thiệu vLLM AFD Plugin, một plugin bên ngoài đang trong giai đoạn thử nghiệm, mang cơ chế Attention-FFN Disaggregation (AFD) vào vLLM.

vLLM AFD Plugin đưa AFD vào các mô hình Mixture-of-Experts (MoE) bằng cách tách Attention và FFN thành các service có thể triển khai độc lập. Plugin vẫn giữ nguyên request lifecycle và OpenAI-compatible serving interface hiện có của vLLM, đồng thời cho phép hai nhánh Attention và FFN được scale độc lập.

Hiện tại, project hỗ trợ NVIDIA GPU và Ascend NPU, các connector synchronous và asynchronous, wrapper cho các model thuộc dòng DeepSeek V2/V3, cùng các execution path eager, graph và dual-batch trong những giới hạn đã được kiểm chứng.

Inference của Mixture-of-Experts (MoE) kết hợp hai loại workload rất khác nhau bên trong mỗi transformer layer.

Attention có trạng thái (stateful) và liên kết chặt chẽ với request scheduling cũng như KV cache. Trong khi đó, FFN, hay expert path, chủ yếu thực hiện routed expert computation và all-to-all communication.

Khi cả hai path sử dụng chung một worker topology, hệ thống serving phải đưa ra cùng một bộ quyết định về scaling và execution cho hai workload vốn có những yêu cầu rất khác nhau.

Để việc tách hai thành phần này trở nên khả thi trong thực tế, hệ thống cần giải quyết một số thách thức về thiết kế:

1. Attention và FFN có yêu cầu scaling khác nhau

Capacity của Attention phụ thuộc vào request state, sequence length và áp lực lên KV cache. Trong khi đó, capacity của Expert phụ thuộc vào token routing và expert load. Do đó, serving system cần hỗ trợ independent scaling, cho phép hai path sử dụng các rank topology khác nhau thay vì bắt buộc phải dùng chung một layout.

2. Attention và FFN có trách nhiệm khác nhau khi runtime

Attention cần đảm nhiệm Scheduling, KV-cache coordination, Sampling. Trong khi FFN chỉ cần Activations,  Routing metadata, cơ chế trả expert outputs về. Việc tách hai service cho phép phía FFN hoạt động như một lightweight connector-driven daemon.

3. Communication phụ thuộc vào backend

CUDA và Ascend cung cấp các collective library, graph runtime và optimized MoE operator khác nhau. Một common connector contract giúp giữ ổn định model-facing flow, đồng thời cho phép mỗi backend tự quản lý data path của mình.

4. Communication và computation có thể được thực hiện đồng thời

Asynchronous dispatch và MoE ubatching có thể overlap các stage độc lập thay vì tuần tự hóa toàn bộ expert workload phía sau Attention path.

Tổng hợp lại, những thách thức trên tạo nên mục tiêu thiết kế cốt lõi của AFD: giữ nguyên Attention path hướng đến request của vLLM, đồng thời đưa FFN execution ra phía sau một connector interface gọn nhẹ, nơi FFN có thể được scale, giao tiếp và thực thi một cách độc lập.

Plugin được tích hợp thông qua vllm.general_plugins entry point của vLLM và --additional-config channel tiêu chuẩn. Plugin không yêu cầu chỉnh sửa vLLM source tree.

Runtime có ba thành phần chính:

• Attention service. Attention worker vẫn giữ lại scheduler, KV cache, batching, model lifecycle và sampling path của vLLM. Một model runner do plugin quản lý sẽ đưa AFD metadata vào forward context, đồng thời truyền data-parallel, ubatch, layer và graph state sang phía FFN.
• FFN service. FFN worker không xử lý request traffic, scheduler hoặc KV cache. Một background loop sẽ nhận metadata và activations, gọi compute_ffn_output() trên model wrapper do plugin quản lý, sau đó gửi kết quả trở lại Attention. Các request luôn được gửi tới Attention API server.
• Connector layer. Tại mỗi split layer, connector truyền Attention hidden states cùng với execution metadata cần thiết cho FFN service, sau đó nhận lại computed FFN outputs. Một backend-neutral connector interface định nghĩa cơ chế trao đổi này, đồng thời cho phép mỗi backend tự triển khai các tối ưu riêng về communication và runtime.

Integration surface này được thiết kế có chủ đích để giữ ở mức tối thiểu. vLLM tiếp tục đảm nhiệm serving control plane ở những phần mà các abstraction hiện có của vLLM có thể đáp ứng, trong khi plugin cung cấp implementation cho AFD workers, model runners, connectors, metadata, model split points và một số compatibility patches được giới hạn theo từng version.

Cách trao đổi dữ liệu ở mức cao giữa các connector là giống nhau: Attention output → FFN → FFN output → Attention. Tuy nhiên, các backend package vẫn được tách riêng để behavior của CUDA graph, ACL graph, NCCL communication, Ascend custom operators không ảnh hưởng lẫn nhau.

• Native vLLM serving surface. Người dùng vLLM hiện tại vẫn khởi chạy bằng vllm serve, gửi request tới một OpenAI-compatible endpoint và cấu hình runtime thông qua --additional-config.
• GPU and NPU implementations. GPU workers mở rộng từ các vLLM v1 classes, trong khi NPU workers mở rộng trực tiếp từ các vLLM-Ascend classes. Các behavior dùng chung được quản lý thông qua configuration, topology, metadata và connector contracts, thay vì sử dụng cross-device inheritance.
• Synchronous AFD for decode throughput. P2pNcclAFDConnector và CAMP2pAFDConnector trao đổi Attention activations và FFN outputs theo cơ chế synchronous, cho phép hai role được scale độc lập trong các decode deployment tập trung vào throughput. Các graph path hiện tại sử dụng semantics FULL_DECODE_ONLY lần lượt trên CUDA và ACL.
• Asynchronous AFD for prefill. CAMAsyncAFDConnector sử dụng CAM asynchronous dispatch và combine operators để tách prefill Attention ranks khỏi expert workers. Kết hợp với AFD-managed MoE ubatching, cơ chế này cho phép overlap các stage Attention và FFN độc lập nhằm giảm pipeline stalls. Path này hiện tập trung vào prefill stage trong một deployment đã disaggregate prefill/decode và hiện chưa hỗ trợ graph execution.
• MoE model integration. Plugin đăng ký các wrapper cho các architecture thuộc dòng DeepSeek V2/V3, bao gồm DeepSeek V3.2 và GLM MoE DSA. Wrapper cung cấp các Attention computation và FFN computation riêng biệt, đồng thời tái sử dụng các upstream layer implementations.
• Graph and ubatching paths. Các synchronous connector trên GPU và NPU hỗ trợ decode-only graph capture. Dual Batch Overlap được hỗ trợ với chính xác hai ubatch, trong khi CAM async cung cấp AFD-managed MoE ubatching cho prefill path của nó.

Synchronous AFD Decode Throughput với CAMP2pAFDConnector

Recipe synchronous decode trong vllm-project/afd-plugin#67 so sánh một deployment EP64 thông thường với các deployment AFD sử dụng CAMP2pAFDConnector cho DeepSeek-V3.2 W8A8 trên Ascend 910C. Benchmark đo saturated decode throughput, không phải online-serving latency.

Throughput được chuẩn hóa theo tổng số deployed dies:

Cả hai workload đều sử dụng fixed-length input và output được phân bố đồng đều trong khoảng 512 đến 1.536 tokens.

EP64 đạt 232,6 tokens/s/die, 48A16F đạt 220,3 tokens/s/die, trong khi 64A16F đạt 258,9 tokens/s/die. So với EP64, kết quả của AFD là -5,3% đối với 48A16F và +11,3% đối với 64A16F.

EP64 đạt 168,2 tokens/s/die, 48A16F đạt 151,4 tokens/s/die, trong khi 64A16F đạt 183,3 tokens/s/die. So với EP64, kết quả của AFD là -10,0% đối với 48A16F và +9,0% đối với 64A16F.

Xét trên cả hai độ dài input, 48A16F đều thấp hơn baseline EP64, trong khi 64A16F đạt throughput được chuẩn hóa cao nhất: +11,3% ở 16K và +9,0% ở 32K. Kết quả này cho thấy việc phân bổ Attention-to-FFN có vai trò quan trọng; chỉ riêng việc disaggregation không đảm bảo throughput sẽ tăng.

Do số lượng máy có hạn, chúng tôi chưa đánh giá các deployment có Attention-to-FFN ratio cao hơn. Xu hướng quan sát được cho thấy, ở các ratio đã thử nghiệm, FFN ranks vẫn còn dư địa về compute (compute headroom) thay vì đã bị giới hạn bởi khả năng tính toán (compute-bound). Vì vậy, việc tăng tỷ lệ Attention ranks có thể giúp đạt được mức throughput cao hơn nữa.

Hiệu năng Asynchronous AFD Prefill với CAMAsyncAFDConnector

Repository bao gồm một thử nghiệm ban đầu về CAM async trên hai node Ascend 910C, sử dụng model DeepSeek V3.2 W8A8 được rút gọn còn 10 layers. Thử nghiệm sử dụng cơ chế forced expert balancing và so sánh baseline DP4PCP8 TP1 với một AFD layout gồm Attention DP3PCP8 TP1 kết hợp với FFN EP8.

Trong các request rate được đo, cấu hình AFD giúp giảm median/P50 time to first token (TTFT). Ở mức 12 requests/second, median TTFT giảm từ 15,1 giây xuống 8,0 giây, tương đương mức giảm khoảng 47%. Ở cả mức 10 và 12 requests/second, khoảng cách đo được là khoảng 7,2 giây.

Lưu ý: Các con số này chỉ nhằm kiểm chứng riêng cho CAM async execution path, không phải là tuyên bố chung về hiệu năng của full DeepSeek V3.2 hay mọi AFD topology. Mức cải thiện hiệu năng cũng có thể thay đổi tùy theo workload.

Cài đặt

Xem các bước cài đặt chi tiết trong README của project.

Deployment Recipes

Các deployment command phụ thuộc vào backend, connector, model và rank topology. Thay vì lặp lại các configuration tại đây, hãy sử dụng các AFD Plugin recipes được duy trì trong repository:

• GPU synchronous AFD: Các DeepSeek V2 Lite P2P NCCL recipes bao gồm các deployment colocated theo hướng decode và prefill/decode-disaggregated, hỗ trợ eager execution, CUDA graph execution và nhiều DP/TP layout khác nhau.
• NPU asynchronous prefill AFD: DeepSeek V3.2 CAM async recipe cung cấp thông tin về environment cần thiết, topology, AFD configuration, benchmark setup và các limitation hiện tại.

Tham khảo repository README và thư mục recipe để xem connector matrix, configuration fields được hỗ trợ mới nhất và các launch command đầy đủ.

Hiện tại, dự án đang chủ động giới hạn phạm vi thử nghiệm trong các ranh giới cụ thể: cố định chính xác phiên bản vLLM, chỉ sử dụng bộ chạy mô hình Model Runner V1, tải đầy đủ trọng số mô hình cho cả hai vai trò, chỉ áp dụng chế độ đồ thị (graph modes) cho giai đoạn dịch mã (decode), giới hạn cứng ở đúng hai vi-lô (ubatches) đối với cơ chế DBO, và quy trình thử nghiệm toàn diện (end-to-end) vẫn đang phụ thuộc vào các cấu hình phần cứng cụ thể.

Giai đoạn phát triển tiếp theo của dự án sẽ tập trung vào các mục tiêu sau:

• Mở rộng khả năng tương thích với vLLM và đồng bộ với bản gốc: Theo dõi và cập nhật theo các phiên bản vLLM mới hơn, đánh giá hiệu năng của Model Runner V2, hạn chế tối đa việc viết các bản vá lỗi (patch) riêng lẻ, và đóng góp ngược lại các cấu trúc trừu tượng có ích cho cộng đồng vLLM gốc khi chúng đã hoàn thiện.

• Cơ chế vận hành linh hoạt hơn: Mở rộng các chế độ đồ thị, cho phép tùy chỉnh số lượng vi-lô, xử lý bất đồng bộ giữa các giai đoạn, và xác thực các cấu trúc liên kết phân mảnh (rank topologies) khác nhau.

• Kiểm định ở quy mô thực tế: Công bố các kết quả có thể tái lập được về độ chính xác, độ trễ, băng thông xử lý, độ ổn định, cũng như hiệu năng trên hệ thống nhiều máy tính (multi-node) với các mô hình đầy đủ và khối lượng công việc thực tế.

• Mở rộng hỗ trợ mô hình và cổng kết nối (connector): Hỗ trợ thêm kiến trúc mô hình MoE (Mixture of Experts) và các phương thức truyền tải dữ liệu nền tảng thông qua các giao diện bọc mô hình (model-wrapper) và cổng kết nối hiện có, đi kèm với hướng dẫn triển khai chi tiết cho từng mô hình và cổng kết nối mới này.

• Tích hợp Đa phương thức và vLLM-Omni: Nghiên cứu cách tích hợp AFD với vLLM-Omni và các chuỗi xử lý đa phương thức hỗn hợp; bao gồm việc áp dụng trong các giai đoạn như Tự hồi quy (AR), Diffusion Transformer (DiT) và các giai đoạn khác – nơi có thể hưởng lợi từ việc chia quy mô độc lập giữa xử lý Attention (Chú ý) và FFN (Mạng truyền thẳng).

• Phục vụ trên phần cứng hỗn hợp và giảm độ trễ tối đa: Thử nghiệm cài đặt các vai trò Attention và FFN trên các loại chip tăng tốc và đường truyền kết nối khác nhau; đi kèm với việc tối ưu hóa cổng kết nối, lập lịch, sắp xếp vị trí và xử lý gối đầu (chồng chéo) giữa tính toán và truyền tải dữ liệu nhằm giảm tối đa thời gian tạo ra token đầu tiên cũng như độ trễ giữa các token tiếp theo.

Plugin vLLM AFD hiện đang ở giai đoạn phát triển ban đầu, và những ý kiến đóng góp từ các cộng đồng phát triển mô hình, dịch vụ lưu trữ (serving) cũng như phần cứng sẽ là yếu tố định hình hướng đi của dự án này.

• Mã nguồn và Tài liệu hướng dẫn: github.com/vllm-project/afd-plugin

• Tài liệu thiết kế thời gian chạy (Runtime): Các thiết kế dành cho GPU Attention/FFN và Ascend Attention/FFN

• Báo lỗi và Yêu cầu tính năng mới: GitHub Issues

Hãy cùng nhau xây dựng một tương lai linh hoạt hơn (composable) và tối ưu tốt hơn theo phần cứng (hardware-aware) cho dịch vụ lưu trữ mô hình MoE!

Với iRender AI, việc triển khai và tối ưu hóa hệ thống AI chưa bao giờ tinh gọn và minh bạch đến thế. Hãy để chúng tôi gánh vác phần hạ tầng phức tạp, giúp bạn tập trung hoàn toàn vào việc phát triển mô hình và tạo ra giá trị đột phá.

Ngoài ra, iRender còn cung cấp cho bạn nhiều hỗ trợ khác, không chỉ những cấu hình mạnh.

1. 1. 1. 1. Hiệu năng thô đạt 100% — Giải quyết triệt để hao hụt tài nguyên do ảo hóa
         2. Băng thông PCIe độc quyền — Triệt tiêu nghẽn cổ chai (I/O Bottleneck) khi chạy RAG
         3. Bảo mật Data Isolation tuyệt đối — Nền tảng cho AI Chủ Quyền
         4. Hạ tầng đặt tại Data Center chuẩn Tier III — Cam kết Uptime 99.98%
         5. Toàn quyền Root Access — Tự do làm chủ môi trường MLOps và Scale Module linh hoạt bằng cách thêm máy
         6. Zero Cold Start — Phản hồi tức thì cho Voice AI và AI Agent
         7. Minh bạch chi phí — Loại bỏ hoàn toàn phí ẩn (Hidden Fee)

✨ [Click vào đây để đăng ký tài khoản] và nhận ngay trải nghiệm dịch vụ iRender.

Nếu bạn cần thêm bất kỳ thông tin chi tiết nào, đừng ngần ngại liên hệ qua Zalo: 0916806116 để được đội ngũ chuyên gia hỗ trợ 24/7.

Trân trọng cảm ơn!

Nguồn: vllm.ai