Suy luận Disaggregated đa node: DeepSeek R1 671B trên GPU AMD Instinct MI300X

Giới thiệu

Suy luận LLM tự hồi quy bao gồm hai giai đoạn riêng biệt: prefill xử lý song song toàn bộ prompt đầu vào để xây dựng KV cache, và decode sinh ra các token đầu ra từng cái một bằng cách sử dụng các key và value đã được lưu trong bộ nhớ đệm. Hai giai đoạn này có các đặc tính thực thi rất khác nhau — prefill xử lý nhiều token cùng lúc trong một bước chạy dài, trong khi decode chạy nhiều vòng lặp ngắn với tần suất cao — tuy nhiên trong các hệ thống serving truyền thống, chúng chia sẻ cùng tài nguyên GPU, gây ra sự can nhiễu lẫn nhau làm giảm cả thông lượng và độ trễ.

Prefill-decode disaggregation (còn được gọi là disaggregated serving) giải quyết vấn đề này bằng cách gán mỗi giai đoạn cho một nhóm node GPU chuyên dụng, để prefill và decode không còn cạnh tranh tài nguyên trên cùng GPU nữa. Khái niệm này được chính thức hóa lần đầu trong DistServe (Zhong và cộng sự, OSDI 2024), kể từ đó đã được áp dụng rộng rãi, nhưng để khai thác hết tiềm năng của nó trong môi trường sản xuất đòi hỏi một giải pháp phần mềm toàn diện được tối ưu hóa cao — từ hiệu suất tính toán ở cấp kernel đến lập lịch cấp cụm và truyền tải KV cache.

Trong báo cáo này, chúng tôi sử dụng MoAI Inference Framework — framework suy luận cấp sản xuất của Moreh được tối ưu hóa cho disaggregated serving hiệu năng cao trên GPU AMD — để đo lường tác động của prefill-decode disaggregation trên cụm 5 node AMD Instinct MI300X chạy DeepSeek R1 671B. Đầu tiên, chúng tôi chứng minh lợi thế của disaggregated serving so với baseline colocated, sau đó xem xét tỷ lệ node prefill-to-decode tối ưu thay đổi như thế nào theo mẫu yêu cầu bằng cách so sánh hai cấu hình: 2P3D (2 Prefill + 3 Decode node) và 1P4D (1 Prefill + 4 Decode node).

Bối cảnh: Tại sao cần tách biệt Prefill và Decode?

Vấn đề can nhiễu

Khi prefill và decode được colocated trên cùng GPU, chúng can nhiễu lẫn nhau theo nhiều cách:

• Đột biến độ trễ. Prefill xử lý nhiều token cùng lúc trong một bước GPU có thể kéo dài. Khi một prefill có ngữ cảnh dài đến, nó chiếm GPU trong thời gian dài, làm đình trệ tất cả các vòng lặp decode đang chạy trên cùng thiết bị. Điều này làm tăng P99 inter-token latency (ITL) — đôi khi lên nhiều bậc cường độ — và phá vỡ trải nghiệm streaming mượt mà mà người dùng mong đợi.
• Xung đột lập lịch. Prefill và decode có ưu tiên lập lịch đối lập: prefill muốn xử lý các yêu cầu mới nhanh chóng để giảm thiểu time-to-first-token (TTFT), trong khi decode cần các vòng lặp thường xuyên, không bị gián đoạn để duy trì inter-token latency thấp. Một instance serving duy nhất phải liên tục phân xử giữa hai bên, và bất kỳ sự thỏa hiệp nào cũng làm giảm ít nhất một chỉ số.
• Mở rộng liên kết. Các nhà vận hành không thể bổ sung dung lượng prefill hoặc decode một cách độc lập; mỗi node mới phải phục vụ cả hai giai đoạn, dẫn đến việc cung cấp dư thừa cho giai đoạn ít bị tắc nghẽn hơn.

Cách hoạt động của Disaggregated Serving

Disaggregated serving chia cụm thành các node prefill và node decode riêng biệt. Mỗi nhóm giữ toàn bộ trọng số mô hình (không có model sharding giữa các nhóm), nhưng chỉ xử lý giai đoạn được chỉ định. Sau khi một node prefill hoàn thành việc xử lý đầu vào, nó truyền KV cache đã tạo đến node decode qua kết nối băng thông cao (ví dụ: RDMA), node này sau đó tiếp tục sinh token mà không bị can nhiễu.

Sự tách biệt này mang lại một số lợi thế chính. Ngay cả trên một cụm đồng nhất nơi mọi node có cùng loại GPU, disaggregation cung cấp:

• Loại bỏ can nhiễu prefill-decode. Các node decode sinh token với tốc độ ổn định, không bị gián đoạn bởi công việc prefill đến, tạo ra inter-token latency thấp hơn đáng kể và dễ dự đoán hơn.
• Mở rộng độc lập. Các nhà vận hành có thể điều chỉnh tỷ lệ node prefill-to-decode để phù hợp với phân bố độ dài đầu vào/đầu ra của workload, tránh cung cấp dư thừa.
• Tối ưu hóa theo giai đoạn. Mỗi nhóm có thể áp dụng các chiến lược song song hóa, chính sách lập lịch và cấu hình batching khác nhau, được điều chỉnh độc lập cho giai đoạn của nó, mà không ảnh hưởng đến giai đoạn kia.

Trong các cụm không đồng nhất, disaggregation mở ra một chiều tối ưu hóa bổ sung: vì prefill bị giới hạn bởi tính toán trong khi decode bị giới hạn bởi băng thông bộ nhớ, các nhà vận hành có thể gán GPU mật độ tính toán cao cho nhóm prefill và GPU tối ưu băng thông cho nhóm decode, khớp đặc tính phần cứng với điểm tắc nghẽn của mỗi giai đoạn. Báo cáo này tập trung vào cụm AMD MI300X đồng nhất, cô lập các lợi ích từ việc loại bỏ can nhiễu, mở rộng và tối ưu hóa theo giai đoạn khỏi bất kỳ hiệu ứng kết hợp phần cứng nào.

Thiết lập thí nghiệm

Môi trường kiểm thử

Tất cả các thí nghiệm được thực hiện trên cụm GPU 5 node. Mỗi node là máy chủ Gigabyte G593-ZX1-AAX1 trang bị hai CPU AMD EPYC 9474F (48 nhân, 3.6 GHz), 2,304 GB bộ nhớ chính, và 8 GPU AMD Instinct MI300X (192 GB HBM3e mỗi card). Các node được kết nối với nhau qua InfiniBand HDR.

Các cấu hình

Chúng tôi đánh giá ba cấu hình, tất cả sử dụng cùng cụm 5 node:

• Colocated (Baseline): Cả 5 node xử lý đồng thời prefill và decode. Cân bằng tải phân phối yêu cầu giữa các node.
• Disaggregated 2P3D: 2 node chuyên dụng cho prefill, 3 node chuyên dụng cho decode. Phân bổ nhiều dung lượng hơn cho prefill so với 1P4D.
• Disaggregated 1P4D: 1 node chuyên dụng cho prefill, 4 node chuyên dụng cho decode. Phân bổ nhiều dung lượng hơn cho decode so với 2P3D.

Kịch bản đánh giá hiệu năng

Tất cả các benchmark được chạy bằng vllm bench serve. Chúng tôi kiểm thử bốn tổ hợp ISL/OSL (Input Sequence Length / Output Sequence Length) ở các mức đồng thời khác nhau. Các tổ hợp này được thiết kế để tạo áp lực lên các phần khác nhau của pipeline serving thay vì mô phỏng các ứng dụng cụ thể:

• 1K/1K: Độ dài đầu vào và đầu ra cân bằng
• 1K/8K: Đầu vào ngắn, đầu ra dài (decode nặng)
• 8K/1K: Đầu vào dài, đầu ra ngắn (prefill nặng)
• 8K/8K: Đầu vào dài và đầu ra dài

Đối với mỗi kịch bản, tải lưu lượng được kiểm soát bởi hai tham số: N_REQs (tổng số yêu cầu) và REQ_RATE (tốc độ đến của yêu cầu, đơn vị req/s). N_REQs được đặt bằng 2 lần mức đồng thời cho tất cả các kịch bản. REQ_RATE được đặt cao hơn cho các kịch bản đầu ra ngắn (3–6 req/s cho 1K/1K, 2–4 req/s cho 8K/1K) và thấp hơn cho các kịch bản đầu ra dài (2 req/s cho 1K/8K và 8K/8K), phản ánh thực tế rằng các yêu cầu sinh dài chiếm tài nguyên GPU trong thời gian lâu hơn. Khi REQ_RATE được chỉ định, nó — cùng với N_REQs — xác định mẫu lưu lượng thực tế chính xác hơn so với chỉ dựa vào mức đồng thời danh nghĩa.

Kết quả: So sánh Disaggregated và Colocated Serving

Trước tiên, chúng tôi so sánh cấu hình disaggregated 2P3D (2 prefill + 3 decode node) với baseline colocated trong đó cả 5 node xử lý cả hai giai đoạn. Với 40% tài nguyên tính toán của cụm được dành cho prefill, 2P3D đóng vai trò là cấu hình disaggregation chính của chúng tôi trên cả bốn kịch bản ISL/OSL.

Độ trễ đầu-cuối

Disaggregated 2P3D đạt được cải thiện trung bình hình học 1.35 lần về độ trễ đầu-cuối trung vị trên tất cả các cấu hình được kiểm thử.

Cải thiện lớn nhất xuất hiện ở kịch bản 8K/1K (prefill nặng), đạt tới 1.84 lần tại CON=160. Điều này nằm trong dự kiến: với các node prefill chuyên dụng, các chuỗi đầu vào dài không còn chặn các hoạt động decode, và các node prefill có thể xử lý chúng theo batch hiệu quả hơn.

Tổng thông lượng

Disaggregated 2P3D đạt được cải thiện trung bình hình học 1.20 lần về tổng thông lượng (tokens per second).

Độ trễ so với Thông lượng

Các biểu đồ phân tán sau đây trực quan hóa sự đánh đổi giữa độ trễ và thông lượng cho mỗi kịch bản ISL/OSL. Các điểm gần phía trên bên trái (độ trễ thấp hơn, thông lượng cao hơn) là tốt hơn. Mỗi điểm đại diện cho một mức đồng thời khác nhau.

Hiệu quả chi phí (Token/Dollar)

Vì disaggregated serving sử dụng cùng tổng số GPU như baseline colocated, cải thiện thông lượng trực tiếp chuyển thành tiết kiệm chi phí trên mỗi token. Cấu hình 2P3D đạt trung bình hình học 107.57% hiệu quả token/dollar so với baseline colocated, nghĩa là các nhà vận hành có thể phục vụ nhiều hơn 7.57% token với cùng chi phí hạ tầng.

Kết quả: Tác động của tỷ lệ Prefill-to-Decode

Sau khi xác lập rằng disaggregated serving vượt trội hơn colocated serving, chúng tôi đặt câu hỏi tiếp theo: các node trong cụm nên được phân chia giữa prefill và decode như thế nào? Để trả lời câu hỏi này, chúng tôi so sánh cấu hình 2P3D (2 prefill + 3 decode) với 1P4D (1 prefill + 4 decode) trên kịch bản decode nặng 1K/8K, nơi việc chuyển một node từ prefill sang decode có tác động rõ ràng nhất.

Độ trễ đầu-cuối: 2P3D vs. 1P4D (1K/8K)

Tổng thông lượng: 2P3D vs. 1P4D (1K/8K)

Với workload decode nặng này, 1P4D nhất quán vượt trội hơn 2P3D. Node decode bổ sung cung cấp nhiều dung lượng decode tổng hợp hơn, mang lại độ trễ đầu-cuối thấp hơn và thông lượng cao hơn — đặc biệt ở mức đồng thời cao khi decode trở thành nút thắt cổ chai. Tại CON=480, 1P4D đạt 6,082.84 TPS so với 5,668.40 TPS của 2P3D.

So sánh hiệu quả chi phí

Về hiệu quả token/dollar (trung bình hình học), 1P4D đạt 111.07% trong khi 2P3D đạt 107.57% so với baseline colocated. Với các workload decode nặng, node decode bổ sung trực tiếp chuyển thành hiệu quả chi phí tốt hơn.

Tóm tắt: Nên chọn tỷ lệ nào?

2P3D mang lại cải thiện độ trễ trung bình hình học 1.80 lần trên workload prefill nặng 8K/1K, nhưng trên workload decode nặng 1K/8K, lợi thế thu hẹp còn 1.08 lần. Trong trường hợp đó, 1P4D dẫn trước với cải thiện E2EL 1.13 lần và hiệu quả token/dollar 111%, nhờ vào node decode bổ sung. Trong môi trường sản xuất, workload thực tế hiếm khi đồng nhất — hỗn hợp các truy vấn ngắn, RAG có ngữ cảnh dài, và yêu cầu suy luận đến đồng thời, và tỷ lệ tối ưu có thể thay đổi trong suốt cả ngày khi mẫu lưu lượng thay đổi.

Điều này khiến việc cấu hình thủ công tỷ lệ prefill/decode vốn dĩ mong manh: một tỷ lệ được điều chỉnh cho lưu lượng giờ cao điểm có thể không tối ưu trong giờ thấp điểm, và ngược lại. Thách thức không chỉ là chọn đúng tỷ lệ một lần, mà là liên tục thích ứng với nó.

Độ ổn định độ trễ: P99 Inter-Token Latency

Một trong những lợi ích có tác động lớn nhất của disaggregated serving là sự cải thiện đáng kể về tail latency. Trong thiết lập colocated, các yêu cầu prefill dài gián đoạn chặn các bước decode, khiến P99 inter-token latency (ITL) tăng vọt đến vài giây. Điều này trực tiếp làm giảm trải nghiệm người dùng trong các ứng dụng streaming.

Với disaggregated serving, prefill và decode không bao giờ cạnh tranh cùng tài nguyên GPU. Kết quả là, P99 ITL giảm đáng kể:

Điều này có nghĩa là với disaggregated serving, người dùng trải nghiệm streaming token nhất quán, mượt mà ngay cả trong điều kiện workload hỗn hợp — một yêu cầu thiết yếu cho các ứng dụng chat và suy luận trong môi trường sản xuất.

Kết luận

Prefill-decode disaggregation mang lại những cải thiện rõ ràng, có thể đo lường được so với colocated serving cho suy luận mô hình MoE quy mô lớn. Trên cụm 5 node AMD MI300X chạy DeepSeek R1 671B:

• Cả hai cấu hình disaggregated đều vượt trội hơn baseline colocated trên tất cả các kịch bản được kiểm thử, với cải thiện độ trễ đầu-cuối lên tới 1.84 lần và giảm P99 inter-token latency 12–51 lần.
• 2P3D (nhiều node prefill hơn) xuất sắc ở các workload prefill nặng, đạt cải thiện E2EL trung bình hình học 1.80 lần trên 8K/1K.
• 1P4D (nhiều node decode hơn) mang lại hiệu quả chi phí tốt hơn trên các workload decode nặng, đạt 111% token/dollar trên 1K/8K.

Tuy nhiên, tỷ lệ prefill-to-decode tối ưu không phải là tĩnh — nó phụ thuộc vào phân bố độ dài đầu vào/đầu ra và mức đồng thời của workload, cả hai đều thay đổi theo thời gian trong môi trường sản xuất. Chọn sai tỷ lệ có thể khiến dung lượng prefill hoặc decode không được sử dụng hết, xói mòn chính những lợi ích mà disaggregation mang lại.

MoAI Inference Framework giải quyết vấn đề này bằng cách tự động hóa cấu hình disaggregated serving. Thay vì yêu cầu các nhà vận hành phải chọn và duy trì thủ công một tỷ lệ prefill/decode cố định, MoAI tự động điều chỉnh phân bổ dựa trên các đặc điểm workload được quan sát — cùng với expert parallelism, routing, và các tối ưu hóa suy luận phân tán khác — để các nhà vận hành có thể khai thác đầy đủ lợi ích của disaggregation trên cụm GPU AMD Instinct mà không cần điều chỉnh thủ công.