Cloud đa chip cho AI inference: nhanh hơn không đồng nghĩa rẻ hơn

Cloud đa chip chạy một yêu cầu suy luận AI trên nhiều loại bộ xử lý thay vì giao toàn bộ quy trình cho một kiến trúc duy nhất. Hệ thống có thể tách prefill và decode sang các cụm chuyên biệt, còn CPU hoặc dịch vụ bên ngoài đảm nhiệm điều phối và công cụ của agent.

Cách phân công này có thể giảm độ trễ hoặc tăng thông lượng, nhưng không tự động giảm hóa đơn. Tài liệu disaggregated serving của NVIDIA mô tả prefill tạo rồi chuyển KV cache sang worker decode, đồng thời cho biết cấu hình gộp thường tránh được chi phí truyền và phân mảnh pool khi mức đồng thời thấp.

Một yêu cầu đi qua prefill, decode và công cụ ra sao

Ở prefill, mô hình đọc prompt và tạo trạng thái trung gian dưới dạng KV cache. Prompt dài làm tăng khối lượng tính toán ban đầu; chỉ số người dùng cảm nhận rõ nhất là time to first token (TTFT), tức thời gian chờ token đầu tiên.

Sang decode, mô hình dùng trạng thái đã tạo để sinh lần lượt các token tiếp theo. Quá trình này liên tục truy cập trọng số và KV cache, nên dung lượng bộ nhớ, băng thông và số phiên đồng thời có ảnh hưởng lớn. Các phép đo phù hợp gồm thời gian giữa hai token, thông lượng token đầu ra và tỷ lệ yêu cầu đạt mục tiêu độ trễ.

Với agent, decode có thể dẫn tới một lần tìm kiếm, truy vấn cơ sở dữ liệu, thực thi mã hoặc gọi API. Kết quả công cụ quay lại ngữ cảnh rồi kích hoạt vòng suy luận mới. Vì thế, chip nhanh hơn không loại bỏ thời gian chờ dịch vụ ngoài, giới hạn tốc độ API hay hàng đợi điều phối.

Mỗi loại tải đòi hỏi thế mạnh phần cứng khác nhau

Không có ánh xạ chip cố định cho mọi mô hình và lưu lượng. Nghiên cứu của Usami, Vishwanath và Bethel trên Llama2-7B cho thấy lợi thế của GPU và accelerator thay đổi theo pha và chỉ số: GPU mạnh ở prefill thiên về tính toán, trong khi lợi thế decode cũng đổi khi tăng batch. Vì vậy, một con số token mỗi giây không đủ để chọn kiến trúc.

• Prefill dài hoặc theo lô: chú trọng năng lực tính toán, xử lý ma trận và mức sử dụng thiết bị khi độ dài prompt thay đổi.
• Decode nhiều phiên: chú trọng băng thông, dung lượng dành cho trọng số và KV cache, cùng độ ổn định giữa các token.
• Thực thi công cụ: nút thắt có thể nằm ở CPU, mạng, lưu trữ hoặc dịch vụ được gọi thay vì accelerator AI.
• Chia theo lớp hoặc operation: có thể đặt attention, feed-forward hay phần khác của mô hình lên thiết bị riêng, nhưng mỗi ranh giới đều phát sinh truyền dữ liệu và đồng bộ.

Mô tả nền tảng của Gimlet Labs cho biết hãng phân rã workload qua GPU, CPU, near-memory compute và kiến trúc dataflow, rồi lập lịch theo SLA và phần cứng sẵn có. Mức tăng tốc 5–10 lần với cùng mức điện năng là kết quả do chính công ty công bố, không phải dự báo chi phí có thể áp dụng trực tiếp cho workload khác.

Hiệu năng bị ăn mòn tại các điểm bàn giao

Chi phí trực tiếp nhất là chuyển KV cache hoặc tensor giữa thiết bị. Khi các worker nằm trên nhiều node, độ trễ mạng, băng thông hữu dụng, tranh chấp liên kết và sao chép dữ liệu đều tham gia vào thời gian đầu-cuối. Nếu pha sau phải đợi trạng thái từ pha trước, accelerator nhanh vẫn có thể đứng nhàn.

Tách pool giúp prefill và decode mở rộng độc lập, nhưng cũng tạo phân mảnh công suất. Tỷ lệ prompt dài, độ dài đầu ra và số phiên biến động có thể khiến một pool đầy hàng đợi trong khi pool kia dư thiết bị. Dự phòng thêm replica để chịu đỉnh tải lại làm tăng chi phí cố định.

Compiler, runtime và scheduler vì thế trở thành một phần của bài toán kinh tế. Model phải được hỗ trợ trên từng accelerator; kernel, kiểu dữ liệu và lượng tử hóa phải tương thích; router phải theo dõi tải và trạng thái cache. Mỗi lần đổi model, driver hoặc backend có thể kéo theo biên dịch, kiểm thử và duy trì thêm chuỗi phát hành.

Độ phức tạp còn xuất hiện trong quan sát và xử lý lỗi: trace phải nối qua nhiều thiết bị, đội vận hành phải phân biệt lỗi mạng với lỗi worker, còn cơ chế chuyển tải cần giữ đúng mục tiêu độ trễ. Sự phụ thuộc nhà cung cấp có thể nằm ở compiler, định dạng model, API lập lịch hoặc giao thức chuyển cache chứ không chỉ ở chip.

Dữ liệu phải có trước khi tin một benchmark

Nhà cung cấp nên chạy workload đại diện và giao cả điều kiện lẫn dữ liệu đo, thay vì chỉ đưa một tỷ lệ tăng tốc tổng hợp. So sánh giữa cụm đồng nhất và cụm đa chip phải giữ nguyên model, chất lượng đầu ra, precision, giới hạn batch và mục tiêu dịch vụ.

• Phân bố độ dài prompt và đầu ra, số phiên đồng thời, tỷ lệ cache hit và tỷ lệ yêu cầu gọi công cụ là bao nhiêu?
• TTFT, thời gian giữa token, độ trễ đầu-cuối và tỷ lệ đạt SLO ở các phân vị cao được đo thế nào?
• Benchmark đã tính chuyển KV cache, đồng bộ, xếp hàng, retry và thời gian gọi dịch vụ ngoài chưa?
• Thông lượng được tính theo chip, toàn cụm hay đơn vị điện năng; thời gian thiết bị nhàn có được ghi nhận không?
• Chi phí có gồm giá thuê hoặc phần cứng, mạng, điện, bộ nhớ, phần mềm, quan sát hệ thống và nhân sự vận hành không?
• Khi một accelerator thiếu công suất hoặc lỗi, workload chuyển sang đâu và chi phí thay đổi thế nào?
• Model mới cần bao lâu để port, biên dịch và xác minh; dữ liệu benchmark cùng trace có xuất được khi đổi nền tảng không?

Chỉ số TCO hữu ích hơn là chi phí trên mỗi yêu cầu đạt cả SLO lẫn yêu cầu chất lượng, không phải chi phí danh nghĩa trên mỗi token. Với agent, phép tính còn phải bao gồm số vòng suy luận, lần gọi công cụ thất bại và phần công việc phải thực hiện lại.

Khi nào cloud đa chip đáng cân nhắc

Kiến trúc đa chip hợp lý hơn khi lưu lượng đủ lớn, từng pha có nút thắt rõ và lợi ích sử dụng phần cứng còn tồn tại sau khi tính chi phí truyền cùng tài nguyên dự phòng. Nó kém thuyết phục với tải nhỏ, biến động khó dự báo, model đổi thường xuyên hoặc kết nối không đủ nhanh để chuyển trạng thái trung gian.

Quyết định cuối cùng phải dựa trên workload thật, SLO, chất lượng và tổng chi phí có thể tái lập. Nếu benchmark chỉ chứng minh một cấu hình sinh token nhanh hơn mà không tính mạng, thời gian nhàn và vận hành, nó chưa chứng minh cloud đa chip rẻ hơn.

Đọc thêm:

• Trao quyền cho AI agent: thiếu “nút ngắt” có thể mở rộng vùng thiệt hại
• Jalapeño nhanh hơn nhưng chưa bán: giới hạn lớn trong chip AI của OpenAI
• Hai SOC cùng bị chiếm domain, chỉ một bên phát hiện: công cụ không phải khác biệt