Không chỉ một mô hình: Fusion trong vLLM Semantic Router

Phục vụ một mô hình duy nhất không còn là giới hạn tối đa đối với các hệ thống AI trong môi trường production. Các ứng dụng hiện đại thường sử dụng một danh mục nhiều mô hình: mô hình tốc độ cao, mô hình chi phí thấp, mô hình riêng tư, mô hình suy luận, API của các nhà cung cấp và các backend vLLM chạy cục bộ. Phần khó nhất là quyết định khi nào chỉ một mô hình là đủ, và khi nào một yêu cầu nên được chuyển thành một hệ thống gồm nhiều mô hình phối hợp với nhau.

Fusion là primitive tiếp theo của vLLM Semantic Router dành cho thế giới đó. Nó cho phép một route chạy một nhóm các mô hình, yêu cầu một mô hình judge phân tích mức độ đồng thuận và những điểm còn thiếu giữa các mô hình, sau đó tổng hợp thành một câu trả lời duy nhất hướng tới người dùng, đồng thời vẫn giữ các chính sách, cấu hình và trace bên trong router.

Trong nhiều năm, câu hỏi mặc định khi triển khai mô hình là khá đơn giản: Mô hình đơn lẻ nào nên xử lý yêu cầu này?

Câu hỏi đó vẫn hữu ích, nhưng không còn đủ nữa. Các hệ thống production hiện nay cần những chính sách có khả năng:

• định tuyến các yêu cầu đơn giản đến những mô hình nhanh, chi phí thấp;
• chuyển các yêu cầu khó sang những mô hình chuyên biệt mạnh hơn;
• duy trì tính liên tục của phiên khi việc chuyển đổi mô hình có thể làm ảnh hưởng đến ngữ cảnh;
• áp dụng các chính sách về quyền riêng tư, an toàn và tenant trước khi thực thi mô hình;
• phân phối một yêu cầu đến nhiều mô hình khi việc các mô hình đưa ra kết quả khác nhau mang lại giá trị;
• ghi lại toàn bộ đường đi của quyết định để các kỹ sư vận hành có thể gỡ lỗi và cải thiện hệ thống.

Đây chính là góc nhìn cốt lõi của vLLM-SR: chất lượng mô hình không chỉ là thuộc tính của một checkpoint. Nó còn là thuộc tính của hệ thống phục vụ (serving system) bao quanh checkpoint đó.

Công trình Mixture-of-Models trên GPU AMD đã đưa ra góc nhìn lấy router làm trung tâm này cho vLLM-SR: thu thập các tín hiệu, lựa chọn mô hình, điều phối các backend không đồng nhất và cung cấp khả năng quan sát route. ReMoM mở rộng định hướng này sang cơ chế cộng tác nhiều mô hình qua nhiều lượt (multi-round model collaboration). Fusion bổ sung một mô hình trực tiếp hơn theo kiểu panel → judge → synthesis, dành cho những yêu cầu mà việc chạy nhiều lượt xử lý độc lập là xứng đáng với phần độ trễ phát sinh.

Fusion không phải là toàn bộ câu chuyện về Mixture-of-Models. Nó là một thuật toán trong bộ công cụ của router.

Trong vLLM-SR, Fusion là một phần của chính sách định tuyến (routing policy) thay vì một endpoint toàn cục cố định:

1. Signals (tín hiệu) mô tả yêu cầu: lĩnh vực, độ phức tạp, ngữ cảnh, mức độ an toàn, phản hồi hoặc các bằng chứng khác.
2. Decisions (quyết định) xác định liệu yêu cầu này nên đi theo route thông thường hay route Fusion.
3. Fusion-only entry với model: “vllm-sr/fusion” giới hạn việc khớp route vào các quyết định có khả năng sử dụng Fusion, nhờ đó yêu cầu vẫn được định tuyến thông minh mà không âm thầm chuyển về route chỉ sử dụng một mô hình.
4. Panel models (các mô hình trong panel) tạo ra những câu trả lời ứng viên độc lập.
5. Judge model (mô hình đánh giá) trích xuất các điểm đồng thuận, mâu thuẫn, phạm vi bao phủ chưa đầy đủ, những insight độc đáo và các điểm mù.
6. Synthesis call (lệnh gọi tổng hợp) tạo ra một câu trả lời duy nhất dành cho người dùng.
7. Trace ghi lại những mô hình nào đã tham gia và quá trình đã diễn ra như thế nào.

Điểm cuối cùng này rất quan trọng. Một model slug được host sẵn thường che giấu phần lớn quá trình này. vLLM-SR làm rõ từng thành phần gồm panel, judge, policy và trace, nhờ đó các kỹ sư vận hành có thể chủ động quyết định khi nào và ở đâu nên sử dụng Fusion, thay vì phải trả chi phí cho Fusion trên mọi yêu cầu.

Phần triển khai được thiết kế xoay quanh một nguyên tắc: Fusion nên là một thuật toán định tuyến (routing algorithm), không phải một thiết lập mô hình toàn cục.

Cấu hình runtime toàn cục chỉ đăng ký những model slug nào sẽ kích hoạt việc thực thi Fusion trực tiếp. Còn panel, judge, chính sách xử lý lỗi, template và các tham số runtime thực tế được đặt trong routing decision tương ứng, bởi những lựa chọn này phụ thuộc vào từng loại workload.

Ví dụ:

• Một route nghiên cứu có thể cần ba nhà cung cấp mô hình khác nhau để tạo ra sự đa dạng.
• Một route review code có thể cần hai mô hình chuyên biệt chạy cục bộ và một mô hình mạnh hơn để tổng hợp kết quả.
• Một route nhạy cảm về quyền riêng tư có thể giữ toàn bộ panel trên các backend vLLM tự host.

vLLM-SR hỗ trợ ba cách để đi vào cùng một thuật toán:

Khi một request đi đến Fusion looper, quá trình thực thi trở nên rõ ràng và có thể quan sát được:

1. Xác định policy. vLLM-SR hợp nhất cấu hình Fusion ở cấp decision, các model ref của decision và các override plugin ở cấp request.
2. Bảo vệ router. Các Fusion slug đã đăng ký không thể được sử dụng làm judge hoặc panel model, vì vậy một request Fusion không thể gọi Fusion theo cách đệ quy.
3. Chạy panel. Các model phân tích được thực thi đồng thời, với số lượng được giới hạn bởi max_concurrent.
4. Xử lý lỗi theo policy. on_error: skip cho phép panel chỉ chạy một phần; on_error: fail khiến lỗi từ provider được hiển thị ngay lập tức.
5. Phân tích sự bất đồng. Judge model tạo ra một bản phân tích có cấu trúc về sự đồng thuận, các mâu thuẫn, phạm vi bao phủ chưa đầy đủ, những insight độc đáo và các điểm mù.
6. Tổng hợp hoặc gọi tool. Lệnh gọi judge/tổng hợp cuối cùng trả về một câu trả lời duy nhất của assistant, hoặc một phản hồi tool_calls tương thích với OpenAI khi client cung cấp tools.
7. Trả về trace và số liệu sử dụng. Response có thể bao gồm dữ liệu Fusion trace, các output trung gian của panel, bản ghi những model bị lỗi và tổng lượng token được sử dụng trong các lần gọi panel, judge và synthesis.

Điểm cuối cùng này là một phần giá trị mà router mang lại. Caller nhận được một response tương thích với OpenAI, trong khi operator vẫn có được góc nhìn ở cấp độ hệ thống: decision nào đã được kích hoạt, những model nào đã tham gia, có bao nhiêu vòng lặp được thực hiện, điều gì đã xảy ra lỗi và toàn bộ quá trình thực thi nhiều mô hình đã tiêu tốn bao nhiêu token.

Bản phát hành này tập trung vào serving primitive: các panel được kiểm soát bằng policy, các contract rõ ràng giữa từng giai đoạn, khả năng tương tác giữa các provider và quá trình thực thi có thể truy vết. Câu hỏi về chất lượng cần một bài đánh giá công khai lớn hơn của riêng nó, trong đó so sánh Fusion, các baseline sử dụng một mô hình đơn lẻ và các panel frontier trên những tác vụ chung.

Fusion hữu ích vì một số request có thể hưởng lợi từ những góc nhìn độc lập của nhiều mô hình. Nó tốn kém vì làm phát sinh các lần gọi đến panel, phân tích của judge, quá trình tổng hợp và thường là độ trễ cao hơn. Câu hỏi trong môi trường production không chỉ là “chúng ta có thể hợp nhất các mô hình không?” mà là “khi nào Fusion đáng để sử dụng?”

Đó là lúc vLLM-SR trở nên quan trọng. model: “vllm-sr/auto” cho phép router quyết định liệu một request có nên sử dụng Fusion hay không. Các prompt đơn giản có thể tiếp tục chạy trên một route nhanh với một mô hình duy nhất. Các tác vụ nghiên cứu khó, phân tích mơ hồ, tổng hợp có tính quan trọng cao hoặc những tác vụ mà sự bất đồng giữa các mô hình mang lại giá trị có thể được khớp với một Fusion decision. Cùng một lớp signal-decision cũng có thể mã hóa các policy về domain, tenant, quyền riêng tư, chi phí, session hoặc an toàn trước khi router phải trả cái giá về độ trễ.

model: “vllm-sr/fusion” là đường dẫn rõ ràng dành cho những client muốn chỉ sử dụng Fusion routing. Nó vẫn sử dụng signals và decisions của vLLM-SR, nhưng thu hẹp phạm vi khớp vào các decision có khả năng sử dụng Fusion, để không âm thầm chuyển sang một route thông thường chỉ sử dụng một mô hình. Các Fusion plugin ở cấp request là đường dẫn override dành cho những client cần cung cấp một panel cho một lần gọi duy nhất.

Note: decision: quy tắc/quyết định định tuyến

Điều đó mang lại cho các operator một control plane hữu ích hơn so với một Fusion slug được host sẵn duy nhất:

Khi một request đi đến một Fusion decision, vLLM-SR chạy một quy trình đa mô hình nhỏ với ranh giới rõ ràng giữa các giai đoạn. Giai đoạn panel trả về các câu trả lời ứng viên độc lập. Giai đoạn judge chuyển những ứng viên đó thành bản phân tích có cấu trúc. Giai đoạn cuối sử dụng bản phân tích đó để tạo ra một câu trả lời duy nhất của assistant, hoặc một tool call khi client cung cấp tools.

Contract giữa các giai đoạn giúp hệ thống có thể được kiểm tra. Nếu một panel model gặp lỗi, on_error: skip có thể tiếp tục với phần bằng chứng chưa đầy đủ trong khi ghi lại model bị lỗi, hoặc on_error: fail có thể dừng ngay lập tức. Nếu output có cấu trúc của judge không thể được phân tích cú pháp, vLLM-SR giữ lại phần phân tích thô và đánh dấu lỗi phân tích cú pháp thay vì che giấu nó. Response cuối cùng có thể bao gồm Fusion trace, các output trung gian của panel, bản ghi các model bị lỗi và tổng lượng token được sử dụng trong toàn bộ quá trình chạy.

Đây là cách Fusion trở thành nhiều hơn một tính năng. Nó trở thành một cách triển khai của control plane Mixture-of-Models có thể lập trình.

Fusion cho thấy tương lai của AI serving không nhất thiết nằm ở việc lựa chọn một mô hình lớn nhất, mà ở khả năng điều phối nhiều mô hình phù hợp cho từng yêu cầu. Với vLLM-SR, doanh nghiệp có thể xây dựng hệ thống Mixture-of-Models linh hoạt, kiểm soát được chi phí, hiệu suất và khả năng quan sát trong quá trình inference.

Để triển khai các workload AI và LLM cần GPU mạnh, hạ tầng iRender GPU Cloud cung cấp tài nguyên GPU hiệu năng cao, phù hợp cho việc chạy vLLM, triển khai mô hình AI và xây dựng các hệ thống inference nhiều mô hình. Kết hợp sức mạnh GPU Cloud với khả năng routing và orchestration của vLLM-SR, doanh nghiệp có thể chủ động xây dựng hạ tầng AI đáp ứng các yêu cầu về hiệu suất, khả năng mở rộng và tối ưu chi phí.

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