Xây dựng hệ thống kết hợp nhiều mô hình với vLLM Semantic Router

Hầu hết các ứng dụng AI hiện nay đều được xây dựng xoay quanh một model endpoint duy nhất. Tuy nhiên, khi mô hình, thiết bị và các yêu cầu triển khai ngày càng đa dạng, sẽ không có một mô hình nào phù hợp nhất cho mọi yêu cầu hay mọi môi trường. Câu hỏi thực tế là làm thế nào để phối hợp, đánh giá và phục vụ nhiều mô hình chuyên biệt thông qua một giao diện duy nhất. vLLM gọi cách tiếp cận này là Mixture-of-Models (MoM).

Chưa đầy một năm kể từ khi ra mắt công khai, vLLM Semantic Router đã đạt 5.000 stars, có hơn 150 contributors và hơn 300.000 lượt tải cộng dồn trên toàn bộ nhóm model của vLLM trên Hugging Face. Qua ba phiên bản lớn là Iris, Athena và Themis, phạm vi của hệ thống đã chuyển từ việc lựa chọn một mô hình sang quản lý quá trình suy luận với nhiều mô hình, rồi tiến tới duy trì trạng thái và phối hợp giữa các phiên làm việc. Những phiên bản này đã xây dựng nền tảng cho kiến trúc MoM được định hướng ngay từ ngày đầu.

Bài viết này trình bày bước phát triển tiếp theo của vLLM Semantic Router: từ việc định tuyến giữa các mô hình sang xây dựng các hệ thống mô hình đáng tin cậy từ chính những mô hình đó. Thông qua một contract được quản lý theo phiên bản, các mô hình độc lập, chính sách, tùy chọn người dùng và các luồng thực thi có thể được kết hợp thành một hệ thống duy nhất, có thể train, đánh giá, export, import, triển khai và gọi thông qua một giao diện. Mục tiêu của vLLM là đưa vLLM Semantic Router trở thành một engine cho việc training, đánh giá và inference của Mixture-of-Models.

Bài viết đầu tiên về vLLM Semantic Router đặt ra một câu hỏi rất thực tế: tại sao phải dành cùng một mức tài nguyên suy luận cho cả những yêu cầu đơn giản lẫn những yêu cầu phức tạp? Một bộ phân loại nhẹ sử dụng các nhãn miền cố định để lựa chọn giữa luồng xử lý nhanh và luồng suy luận, giúp vLLM phân bổ tài nguyên tính toán cho inference có chọn lọc hơn.

Khi đưa vào môi trường production, lưu lượng thực tế nhanh chóng cho thấy giới hạn của thiết kế này. Chỉ dựa vào miền nội dung không thể thể hiện đầy đủ các yếu tố như quyền riêng tư, an toàn, ngữ cảnh, ngôn ngữ, modality, công cụ, tùy chọn người dùng, độ trễ và quyền truy cập. Một nhãn cố định cũng không thể xử lý tình huống một endpoint có chi phí thấp nhưng đang quá tải, có năng lực cao nhưng ở xa, hoặc không an toàn để chuyển sang giữa chừng trong một phiên agent.

vLLM xây dựng lại lớp classifier dựa trên kiến trúc hỗ trợ mô hình dạng module, tính toán LoRA dùng chung, inference bằng Rust/Candle và tích hợp với Go. Sau đó, vLLM thay thế cơ chế phân loại cố định bằng kiến trúc Signal–Decision, trong đó bằng chứng quan sát được tách biệt khỏi chính sách và quá trình thực thi. Kiến trúc này trở thành nền tảng cho ba phiên bản tiếp theo.

Iris đưa việc định tuyến trở nên linh hoạt và có thể kết hợp. Các tín hiệu về lĩnh vực, từ khóa, embedding, độ chính xác thực tế, phản hồi và sở thích được đưa vào các quyết định rõ ràng. Trong khi đó, các chức năng như bảo mật, bảo vệ PII, caching, phát hiện hallucination và lựa chọn công cụ được áp dụng riêng cho từng tuyến xử lý. Iris cũng giới thiệu dòng model MoM và định hướng vLLM-SR như một hệ thống cung cấp trí tuệ ở cấp độ hệ thống cho kiến trúc Mixture-of-Models.

Athena bổ sung khả năng lựa chọn model, memory và RAG, đồng thời mở rộng hệ thống với các model đa ngôn ngữ, multimodal, tăng tốc bằng ROCm và dashboard vận hành. Từ đây, dự án không còn chỉ là một bộ phân loại đứng trước vLLM, mà dần trở thành hệ thống điều khiển toàn bộ quá trình inference với nhiều model.

Themis tiếp tục biến hệ thống này thành một nền tảng có thể vận hành và kiểm soát rõ ràng:

Themis bổ sung khả năng định tuyến theo trạng thái cho các tác vụ agent, lưu lại trace để có thể chạy lại, tăng cường hỗ trợ giao thức, cung cấp giao diện cho người vận hành và hỗ trợ nhiều môi trường chạy, gồm AMD ROCm, NVIDIA CUDA, Intel OpenVINO và CPU. Hệ thống cũng giúp giải thích rõ lý do một tuyến xử lý được lựa chọn: người vận hành có thể xem tín hiệu đầu vào, chính sách, thuật toán và model thực tế đứng sau mỗi quyết định.

Ba phiên bản trên đã xây dựng phần nền tảng vận hành. Hai công trình nghiên cứu tiếp theo giải thích kiến trúc đứng phía sau hệ thống.

White paper, Signal Driven Decision Routing for Mixture-of-Modality Models trình bày rõ cách tách bằng chứng do neural model tạo ra khỏi chính sách do hệ thống quy định. Các heuristic đơn giản và classifier đã được huấn luyện biến prompt, ngữ cảnh, danh tính, yếu tố an toàn và modality thành một tập tín hiệu có cấu trúc. Sau đó, Boolean engine kết hợp các tín hiệu này để tạo thành chính sách có thể kiểm tra và truy vết.

Một DSL neural-symbolic có kiểu dữ liệu rõ ràng sẽ phân tích và kiểm tra chính sách trước khi biên dịch thành cấu hình có thể triển khai. Tại thời điểm white paper được công bố, hệ thống đã hỗ trợ 13 loại tín hiệu và 13 thuật toán lựa chọn model, cùng các plugin riêng cho từng quyết định như caching, RAG, memory, safety, xử lý provider và kiểm tra phản hồi.

Vision paper, The Workload–Router–Pool Architecture for LLM Inference Optimization mở rộng cách nhìn này. Công trình cho rằng cần thiết kế đồng thời ba yếu tố:

• Workload: loại tác vụ như chat hay agent, một lượt hay nhiều lượt, phiên chạy nóng hay lạnh, thiên về prefill hay decode.
• Router: chính sách semantic cố định, điều chỉnh dựa trên feedback hoặc bandit, lựa chọn bằng RL và các mô hình cascade có xét đến chất lượng.
• Pool: hệ thống accelerator đồng nhất hoặc hỗn hợp, cách bố trí prefill/decode, vị trí đặt model và cách quản lý KV-cache.

Ba yếu tố này không thể tối ưu riêng lẻ. Đặc điểm của workload ảnh hưởng đến chính sách routing phù hợp, trong khi chính sách routing lại quyết định quy mô và cách bố trí của pool. Ngược lại, trạng thái của pool cũng ảnh hưởng đến việc tuyến xử lý nào có hiệu quả nhất.

Các yêu cầu về safety và privacy xuyên suốt cả ba lớp. Trong khi đó, chi phí, chất lượng, độ trễ và mức tiêu thụ năng lượng cùng xác định giới hạn tối ưu của hệ thống. Công trình nghiên cứu mô hình hóa các hướng nghiên cứu này thành ma trận WRP 3 × 3, đồng thời chỉ ra 21 hướng còn cần được nghiên cứu để kết nối ba chiều Workload, Router và Pool một cách hoàn chỉnh.

Hai công trình này cùng đặt nền móng để biến việc định tuyến thành một cơ chế có thể lập trình, đồng thời gắn nó với workload và phần cứng. Đây cũng là hai nền tảng mà kiến trúc Mixture-of-Models muốn đưa vào cùng một bộ quy tắc chung cho model.

Trong khi đó, hệ thống vận hành cũng đã vượt ra ngoài việc chỉ chọn một model. Các cơ chế như Fusion, ReMoM, Confidence, Ratings và Workflows có giới hạn cho phép một yêu cầu được nhiều model phối hợp xử lý theo một quy trình được kiểm soát. Như công việc về Micro-Agent đã cho thấy, phía ứng dụng có thể chỉ gọi một tên model, trong khi hệ thống phía sau tự chọn quy trình phù hợp, phân công cho nhiều worker, kiểm tra hoặc tổng hợp kết quả rồi trả về một phản hồi duy nhất như bình thường.

Định tuyến vẫn giữ vai trò nền tảng. Đây là cách Mixture-of-Models phân chia công việc, áp dụng chính sách và điều phối các thành phần của hệ thống. Tuy nhiên, định tuyến chỉ là cơ chế để thực hiện điều đó. Sản phẩm cuối cùng là cả hệ thống model.

Hệ thống AI hiện nay đang bị phân mảnh theo bốn phương diện chính:

• • • • Model bị phân mảnh. Có model đóng thuộc nhóm tiên tiến, model mở dùng cho nhiều mục đích, model chuyên ngành, model nhỏ chạy tại chỗ, model kiểm chứng và model multimodal. Không có một model nào đồng thời vượt trội về chất lượng, chi phí, độ trễ, độ tin cậy, quyền riêng tư và mức độ phù hợp với từng lĩnh vực.
      • Năng lực tính toán bị phân mảnh. GPU, CPU, accelerator chuyên dụng, thiết bị biên, tài nguyên cloud và cụm máy riêng có bộ nhớ, kernel, khả năng cung cấp, chi phí và mức tiêu thụ năng lượng khác nhau. Vì vậy, việc chọn model và quyết định đặt model ở đâu ngày càng trở thành cùng một bài toán.
      • Nơi xử lý bị phân mảnh. Inference có thể diễn ra trên cloud, trong trung tâm dữ liệu hoặc ngay tại thiết bị biên. Yêu cầu về quyền riêng tư hoặc nơi lưu trữ dữ liệu có thể khiến một model mạnh trên máy chủ từ xa không được phép sử dụng, trong khi một workload chạy tại chỗ vẫn có thể cần gọi đến một model chuyên biệt trên cloud khi cần.
      • Nhu cầu và sở thích bị phân mảnh. Không tồn tại một lựa chọn “tốt nhất” cho mọi trường hợp. Mỗi sản phẩm và người dùng có thể ưu tiên khác nhau giữa độ chính xác, độ trễ, chi phí, quyền riêng tư, an toàn, phong cách trả lời và khả năng multimodal. Những ưu tiên này cần được đưa trực tiếp vào cách hệ thống thực hiện yêu cầu.

Hiện nay, mỗi ứng dụng phải tự giải quyết và kết nối những mảnh ghép này với nhau.

Mixture-of-Models đưa trách nhiệm này vào bên trong một ranh giới mô hình thống nhất.

Tại ranh giới đó, phân bổ thông minh trở thành một phần của chính mô hình. Hệ thống xác định mô hình nào đủ điều kiện được sử dụng, tác vụ có thể chạy ở đâu, các mô hình có cần phối hợp với nhau hay không, đồng thời bảo đảm các ràng buộc bắt buộc được đáp ứng.

Năng lượng khiến bài toán phân bổ không thể tách rời khỏi hiệu quả sử dụng tài nguyên. Phần cứng và các engine suy luận cải thiện phía cung bằng cách tạo ra nhiều token hơn trên mỗi watt và mỗi đơn vị chi phí. Lớp phân bổ kiểm soát phía cầu: tác vụ nào xứng đáng được cấp tài nguyên, mô hình nào hoặc phương án phối hợp nào có thể xử lý tác vụ trong giới hạn chất lượng, độ trễ và mức tiêu thụ năng lượng yêu cầu.

Ứng dụng chỉ cần chọn một danh tính mô hình được quản lý theo phiên bản và nhận về một kết quả duy nhất, có thể truy xuất nguồn gốc. Phần triển khai thực tế phía sau vẫn có thể kết hợp mô hình mã nguồn mở và mô hình đóng, môi trường cloud và edge, cũng như nhiều thế hệ bộ tăng tốc khác nhau.

Sự phân mảnh vẫn tồn tại, nhưng nó được xử lý bên trong hệ thống mô hình thay vì trở thành gánh nặng mà từng ứng dụng phải tự giải quyết.

Mixture-of-Models là một mô hình tổng hợp được quản lý theo phiên bản. Hệ thống xử lý từng yêu cầu thông qua một quy trình được lựa chọn dựa trên nhu cầu và sở thích, đồng thời tuân theo các giới hạn về tài nguyên, với sự tham gia của nhiều mô hình và thành phần xử lý độc lập. Đối với người dùng, toàn bộ hệ thống được cung cấp thông qua một giao diện mô hình duy nhất và trả về một kết quả duy nhất có thể xác định nguồn gốc.

Một cổng kết nối nhiều mô hình có thể chuyển tiếp yêu cầu đến nhiều hệ thống phía sau, nhưng không nhất thiết chịu trách nhiệm về chất lượng tổng thể của hệ thống. Ngược lại, MoM xác định rõ mục tiêu, tiêu chuẩn đánh giá, cách kết hợp có thể tái tạo và môi trường thực thi để vận hành toàn bộ hệ thống.

MoM cũng khác với Mixture-of-Experts (MoE). MoE phân phối các token giữa những expert bên trong một lần forward pass, trong khi MoM điều phối các mô hình độc lập, vốn có thể khác nhau về kiến trúc, đơn vị phát triển, giấy phép, phương thức xử lý dữ liệu, giao thức, độ dài ngữ cảnh và phần cứng. Một mô hình MoE đã được huấn luyện cũng có thể trở thành một thành phần trong MoM.

Vì vậy, một MoM có thể mang đi và tái sử dụng được cần nhiều hơn trọng số và cấu hình. Nó cần có danh sách các thành phần, thông tin về khả năng của từng thành phần, các kịch bản định tuyến và phối hợp, chính sách, tùy chọn, bộ kiểm thử đánh giá, giới hạn khi chạy, thông tin nguồn gốc và lịch sử phiên bản.

Các mô hình đã được công khai có thể được đóng gói cùng hệ thống. Trong khi đó, các mô hình đóng vẫn được giữ dưới dạng tham chiếu bên ngoài đã xác thực, kèm theo hợp đồng rõ ràng về khả năng và chính sách sử dụng. Việc xuất một MoM không khiến mô hình độc quyền trở nên có thể mang đi. Nó giúp toàn bộ hệ thống mô hình có thể được tái tạo một cách nhất quán.

Các nhu cầu sử dụng trở nên cụ thể khi được công bố dưới dạng những danh tính mô hình riêng. Một họ MoM có thể cung cấp nhiều cách vận hành khác nhau:

Mỗi tên là một hợp đồng mô hình có phiên bản, chứ không phải một cấu hình định tuyến được thiết lập sẵn. Ứng dụng lựa chọn cách vận hành phù hợp với nhu cầu, còn vLLM-SR lựa chọn và phối hợp các mô hình để đáp ứng yêu cầu đó, đồng thời duy trì những ràng buộc bắt buộc về quyền riêng tư, nơi lưu trữ dữ liệu, quyền truy cập và an toàn.

Đối với ứng dụng, toàn bộ hệ thống vẫn hoạt động giống như một lời gọi mô hình thông thường:

{
  "model": "vllm-sr/mom-v1-ultra",
  "messages": [
    {"role": "user", "content": "Review this design and identify its weakest assumption."}
  ]
}

Danh tính đó có thể chọn một mô hình duy nhất, chuyển sang mô hình khác theo từng cấp, so sánh nhiều câu trả lời chạy song song, yêu cầu kiểm tra tính có căn cứ hoặc thực hiện một quy trình phối hợp có giới hạn. Tất cả đều diễn ra mà không cần thay đổi giao diện bên ngoài, phiên bản hay cam kết về định dạng phản hồi.

Bốn lớp trách nhiệm

Một hệ thống triển khai cần ánh xạ các yêu cầu logic vào những model và máy chủ hiện có trong môi trường vận hành. Đề xuất này sử dụng bốn đối tượng:

• • • • Gói triển khai (bundle) xác định giao diện, cấu trúc hệ thống, chính sách, biến thể hoạt động, các giới hạn và những thành phần ngữ nghĩa không được thay đổi.
      • Liên kết triển khai (binding) ánh xạ các thành phần logic vào những môi trường triển khai phù hợp, nhưng không làm thay đổi cách model đưa ra quyết định.
      • Khóa phiên bản triển khai (resolution lock) cố định phiên bản của các thành phần, runtime, image, bộ tăng tốc và thông tin quan sát từ nhà cung cấp.
      • Bản ghi thực thi (run record) ghi nhận và quy trách nhiệm cho mọi quyết định, lần gọi model, lần kiểm tra ràng buộc, chi phí và kết quả, đồng thời liên kết chúng với bundle, binding và resolution lock đã tạo ra chúng.

Cách phân tách này giúp khả năng mang hệ thống sang môi trường khác được rõ ràng và thực tế hơn. Cùng một mom-v1-ultra có thể được triển khai trên ROCm, CUDA, một máy chủ CPU hoặc NPU riêng, hoặc một hệ thống kết hợp, mà không cam kết rằng các nhà cung cấp không minh bạch sẽ luôn tạo ra kết quả giống hệt nhau. Thay vào đó, hệ thống giữ nguyên cách thức kiểm soát, công khai những thành phần được thay thế và cung cấp cùng một hệ thống đã được xác định cụ thể cho cả quá trình phục vụ lẫn đánh giá.

Huấn luyện, đánh giá và suy luận phải dùng chung một hợp đồng. Nếu không, quá trình nghiên cứu, kiểm thử và vận hành thực tế sẽ dần phát triển thành những hệ thống khác nhau.

Huấn luyện MoM bao gồm các embedding do bộ định tuyến quản lý, bộ mã hóa tín hiệu, model về nhu cầu và an toàn, cùng các bộ chọn. Hệ thống cũng học cách phân bổ và phối hợp: quy trình nào phù hợp với một loại công việc và ngân sách nhất định, khi nào nên dừng một chuỗi xử lý, cách một nhóm model đánh giá hoặc tổng hợp kết quả, và khi nào một phiên làm việc của agent cần chuyển sang model khác.

Vì các thành phần có thể hoạt động độc lập hoặc là model đóng, quá trình cải thiện không nhất thiết phải truyền gradient qua toàn bộ hệ thống. Chính sách, ngưỡng, cụm model, prompt, hợp đồng và cấu trúc triển khai có thể được tối ưu dựa trên các dấu vết thực thi và kết quả thu được.

Mục tiêu là tìm ra điểm cân bằng giữa chất lượng, độ trễ, chi phí, an toàn, quyền riêng tư, độ tin cậy, vị trí xử lý và mức tiêu thụ năng lượng. Dữ liệu replay và kết quả thực tế đưa kinh nghiệm từ môi trường production trở lại quá trình huấn luyện offline, nhưng không cho phép hệ thống âm thầm thay đổi chính sách ngay trong quá trình phục vụ.

Việc đánh giá phải đo lường toàn bộ định danh model từ đầu đến cuối. Các benchmark riêng của từng backend chỉ là dữ liệu đầu vào, không phải kết quả cuối cùng.

Một bảng đánh giá có phiên bản nên đo lường mức độ sai lệch trong lựa chọn route, lợi ích từ việc phối hợp nhiều model, khả năng phục hồi, khả năng duy trì phiên, độ trễ ở mức cao, chi phí, an toàn, quyền riêng tư và năng lượng. Hệ thống cũng cần được kiểm thử trong các tình huống như nhà cung cấp gặp sự cố, thiết bị bị mất kết nối, các model đưa ra kết quả trái ngược nhau, đặc điểm workload thay đổi hoặc nhu cầu của người dùng thay đổi.

Mỗi cách vận hành được công bố cũng cần có bài kiểm thử riêng. Chẳng hạn, flash phải được đánh giá trên tương quan giữa độ trễ và chất lượng, light phải đáp ứng mức chất lượng tối thiểu, còn ultra phải hoạt động trong phạm vi ngân sách đã đặt ra.

Tiêu chuẩn đánh giá về mặt khoa học còn nghiêm ngặt hơn việc chỉ hỏi liệu tăng số lần gọi model có cải thiện benchmark hay không. Với cùng lượng tài nguyên tính toán thực tế được sử dụng, một hệ thống có khả năng lựa chọn theo điều kiện có khai thác tốt hơn những điểm mạnh và cách thức thất bại bổ sung cho nhau so với model cố định tốt nhất hay không?

Nếu không kiểm soát yếu tố này, MoM có thể che giấu việc tăng tài nguyên một cách đơn thuần phía sau một cấu trúc xử lý được thiết kế khéo léo. Vì vậy, kết quả đánh giá cần công bố số lần gọi model, số token, chi phí, độ trễ và mức tiêu thụ năng lượng cùng với chất lượng, đồng thời phải chỉ rõ những trường hợp mà việc kết hợp nhiều model không mang lại lợi ích.

Ở thời điểm suy luận, engine sẽ quyết định liệu chỉ một model có đủ hay không. Hệ thống có thể chọn một model chuyên biệt chạy tại chỗ, duy trì một phiên đang hoạt động sẵn, chuyển sang model khác khi độ tin cậy giảm, yêu cầu truy xuất hoặc kiểm chứng, chạy một nhóm model để tổng hợp kết quả, hoặc thực hiện một quy trình có giới hạn.

Runtime chịu trách nhiệm quản lý ngân sách, cấu trúc triển khai, phương án dự phòng, dấu vết thực thi và hợp đồng phản hồi. Ứng dụng vẫn chỉ cần thực hiện một lời gọi model thông thường.

Mục tiêu là xây dựng một MoM hoàn chỉnh có thể được tạo, xuất, nhập, quản lý phiên bản, đánh giá, triển khai và gọi như một model thống nhất. Một đặc tả logic sẽ được biên dịch thành một gói không thể thay đổi, gắn với một môi trường, xác định cấu hình triển khai cụ thể và vẫn giữ nguyên định danh trong cả quá trình phục vụ lẫn đánh giá.

Gói này cần có thể chạy trên máy của nhà phát triển, cụm máy riêng, hệ thống cloud và các môi trường edge, trong khi cách triển khai vật lý có thể thay đổi. Một model chuyên biệt có thể được ánh xạ tới checkpoint cục bộ phù hợp hoặc một endpoint được quản lý; runtime dành cho bộ tăng tốc cũng có thể được thay thế.

Nếu yêu cầu về quyền riêng tư khiến một model chuyên biệt từ xa không thể được sử dụng, engine sẽ thực hiện phương án dự phòng hoặc từ chối xử lý đã được khai báo. Một binding không được tự ý thay đổi cấu trúc hệ thống, nới lỏng quy tắc bảo vệ hoặc biến một nhóm model chạy song song thành một chuỗi chuyển tiếp. Những thay đổi như vậy phải tạo thành một phiên bản model mới.

Chạy trên mọi loại phần cứng là một yêu cầu về kiến trúc, không phải tuyên bố rằng mọi thành phần hiện nay đều có thể mang sang mọi thiết bị.

Dự án hiện đã hỗ trợ các hướng triển khai trên ROCm, CUDA, OpenVINO và CPU. Bước tiếp theo là đưa khả năng phần cứng và vị trí triển khai vào hợp đồng MoM, để engine có thể ánh xạ hệ thống model vào những tài nguyên thực tế đang có.

Tiêu chuẩn cho trải nghiệm người dùng rất đơn giản:

Nếu ứng dụng phải biết submodel nào thuộc nhà cung cấp nào, chạy trên thiết bị nào hoặc cần thực hiện cấu trúc dự phòng nào, thì lớp trừu tượng đã bị phá vỡ.

Giai đoạn tiếp theo tập trung vào bốn hướng có liên kết chặt chẽ:

• • • • Xây dựng đặc tả MoM có thể mang sang nhiều môi trường: Đóng gói các thành phần, mục tiêu, chính sách, nhu cầu ưu tiên, quy trình đánh giá, ràng buộc và cách thức thực thi thành một artifact có phiên bản thống nhất.
      • Khép kín vòng lặp huấn luyện, đánh giá và suy luận: Cải thiện model và công thức phối hợp dựa trên kết quả đánh giá và dữ liệu replay, sau đó phát hành thông qua quy trình có thể xem xét và khôi phục an toàn.
      • Xây dựng runtime hỗ trợ hạ tầng đa dạng: Triển khai cùng một MoM trên cloud, trung tâm dữ liệu và edge, đồng thời sử dụng phần cứng, vị trí dữ liệu, năng lượng và ranh giới dữ liệu làm các yếu tố đầu vào.
      • Giữ giao diện model đơn giản: MoM cần dễ nhập, triển khai và gọi gần như một model đơn lẻ.

Đây là một chương trình nghiên cứu nhằm tìm hiểu cách các mô hình độc lập có thể chuyên môn hóa, cạnh tranh, kiểm chứng và phối hợp với nhau; cách đo lường hiệu quả của toàn bộ hệ thống; và cách duy trì một hợp đồng mô hình thống nhất trên nhiều thiết bị và môi trường khác nhau. Sứ mệnh của vLLM là:

vLLM sẽ nghiên cứu khi nào việc kết hợp nhiều mô hình có thể tạo ra năng lực vượt xa một checkpoint đơn lẻ, xem việc phân bổ mô hình và mức tiêu thụ năng lượng là một phần của năng lực thông minh, đồng thời duy trì cùng một hợp đồng mô hình từ edge đến cloud và từ nghiên cứu đến môi trường production.

Xây dựng Mixture-of-Models đòi hỏi nhiều hơn việc định tuyến. Công việc này bao gồm huấn luyện mô hình, đánh giá, hệ thống serving, phần cứng và vận hành trong môi trường production.

Iris, Athena và Themis đã được cải thiện nhờ những đóng góp từ cộng đồng, khi các contributor mang đến workload thực tế, bổ sung backend, huấn luyện mô hình, công bố benchmark, phát hiện các trường hợp lỗi và đề xuất những giao diện tốt hơn. MoM cũng cần một phạm vi đóng góp tương tự: phân bổ có học, tối ưu hóa theo sở thích, phối hợp giữa các mô hình, inference có tính đến năng lượng, artifact có tính di động, đánh giá mở và runtime hỗ trợ nhiều loại phần cứng.

Nếu bạn đang làm việc trong những lĩnh vực này, vLLM muốn tìm hiểu từ workload và số liệu đo lường của bạn. Hãy xây dựng một operating point, bổ sung một runtime, thử nghiệm một cách phối hợp giữa các mô hình hoặc công bố một trường hợp cho thấy việc kết hợp mô hình không mang lại hiệu quả. MoM sẽ mạnh hơn khi những giả định của nó được kiểm chứng công khai.

Hiện nay có rất nhiều tùy chọn cho AI/Học máy với vLLM trong và ngoài nước. Tuy nhiên, những dịch vụ đó thường khá khó sử dụng đối với những người mới bắt đầu. Việc tính toán giá cả cũng phức tạp với nhiều chi phí ẩn mà bạn cần các khóa học để giúp bạn hiểu nó hoạt động thế nào, làm sao để không bị mất tiền vô nghĩa.

iRender AI áp dụng chính sách giá trọn gói cố định minh bạch theo giờ hoặc theo ngày. Doanh nghiệp hoàn toàn kiểm soát được dòng tiền và ngân sách vận hành dự án AI mà không lo sợ bất kỳ khoản chi phí phát sinh bất ngờ nào.

Tham khảo thêm chi phí và cấu hình của iRender tại đây.

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)

Bạn có thể đăng ký tài khoản qua link này ngay hôm nay để trải nghiệm dịch vụ của iRender. Hoặc liên hệ qua Zalo 0916806116 để được tư vấn và hỗ trợ.

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

Nguồn: vllm.ai