Ollama hay vLLM: tám luồng có thể đổi lựa chọn

Với thử nghiệm cá nhân, Ollama là điểm khởi đầu thuận tiện; với máy chủ phải trả lời nhiều yêu cầu cùng lúc, vLLM đáng ưu tiên nếu mô hình và bộ nhớ ngữ cảnh còn vừa VRAM. Trong phép đo của Vikas Goenka trên RTX 5070 Ti 16 GB, tải tám client với Gemma 4 12B cho thông lượng đầu ra tổng 419 token/giây ở vLLM, 78 ở Ollama mặc định và 232 ở llama.cpp. Đây là kết quả của các cấu hình được thử trên một máy, không phải tốc độ cố hữu của từng engine trên mọi GPU.

Điểm có thể làm thay đổi lựa chọn là số yêu cầu thực sự chồng lên nhau, chứ không phải số người có tài khoản. Một người cho nhiều tác vụ tự động chạy cùng lúc có thể tạo tải lớn hơn một nhóm người dùng gửi yêu cầu lần lượt. Trong phép đo này, Ollama giữ thiết lập xử lý song song mặc định; vì thế khoảng cách quan sát được cũng là lý do để thử cấu hình phù hợp trước khi quyết định đổi engine.

Khi tải tăng, chỉ số nào đổi ý nghĩa?

Ở một phiên trò chuyện, cảm giác nhanh thường đến từ thời gian chờ token đầu tiên và nhịp sinh phần trả lời tiếp theo. Máy chủ phục vụ nhiều người còn phải hoàn tất cả nhóm yêu cầu trong khi giữ thời gian chờ của từng người ở mức chấp nhận được. Tốc độ giải mã tốt cho một câu trả lời không cho biết các câu trả lời khác phải nằm trong hàng đợi bao lâu.

Hướng dẫn benchmark của vLLM định nghĩa TTFT là thời gian từ lúc client gửi yêu cầu tới token đầu tiên và tách thông lượng token đầu ra khỏi thông lượng gồm cả đầu vào. Lệnh vllm bench serve cho phép đặt tốc độ gửi yêu cầu và giới hạn số yêu cầu đồng thời. Tài liệu cũng cảnh báo việc chạy lại cùng prompt có thể tái sử dụng bộ nhớ đệm tiền tố, khiến thông lượng đo được tăng.

TTFT: thời gian chờ ở từng yêu cầu, đặc biệt khi nhiều prompt dài cùng đến. Giá trị trung bình có thể che những yêu cầu chờ lâu.
Tốc độ giải mã: nhịp tạo token sau khi phản hồi bắt đầu; hữu ích cho trò chuyện cá nhân và câu trả lời dài.
Thông lượng đầu ra tổng: số token trả lời cả máy chủ tạo ra trong một khoảng thời gian. Cần phân biệt nó với chỉ số cộng cả token đầu vào.
Mức đồng thời và hàng đợi: số yêu cầu client phát đi, số yêu cầu engine đang xử lý và thời gian các yêu cầu còn lại chờ được nhận.
VRAM và công triển khai: bộ nhớ còn lại sau khi nạp mô hình, phần dành cho ngữ cảnh và mức công cần bỏ ra để vận hành máy chủ.

Phép đo trên một GPU giới hạn kết luận ra sao?

Các vòng thử đặt mô hình vào những trạng thái bộ nhớ khác nhau: vừa sát GPU, vượt GPU và còn khoảng trống. Ở vòng vừa sát, vLLM phải chuyển một phần trọng số sang RAM hệ thống để chạy, làm tốc độ giải mã giảm mạnh. Ở vòng còn khoảng trống, mô hình nằm trên GPU và tải đồng thời mới cho thấy lợi thế thông lượng của cấu hình vLLM. Kích thước tệp và khoảng VRAM còn trống vì vậy là điều kiện của kết quả.

Phép thử dùng cùng máy và bộ prompt, mỗi lần chỉ chạy một engine trên GPU, nhưng không ép mọi thiết lập mặc định phải giống nhau. vLLM và llama.cpp được đặt khả năng phục vụ song song tương ứng với tải, còn Ollama giữ cấu hình ban đầu. Các tệp lượng tử Gemma dùng cho vLLM và các engine kia cũng khác dung lượng; ở vòng mô hình lớn hơn, định dạng lượng tử giữa các engine khác nhau. Nhãn “lượng tử bốn bit” chưa đủ để coi đây là phép so sánh tuyệt đối về lõi suy luận.

Sự khác biệt tệp còn quan trọng khi xem tốc độ một luồng: tệp lớn hơn có thể buộc GPU đọc nhiều dữ liệu hơn mỗi lần sinh token. Một engine có thông lượng nhiều client cao vẫn có thể giải mã từng yêu cầu chậm hơn. Thứ hạng trên GPU khác, phiên bản phần mềm khác hoặc prompt dài hơn không thể suy ra trực tiếp từ phép đo desktop này.

Bộ nhớ quyết định ngưỡng đồng thời thế nào?

Mô hình nạp được lên GPU mới chỉ qua cửa đầu tiên. Mỗi yêu cầu đang hoạt động còn dùng bộ nhớ cho ngữ cảnh và quá trình suy luận, nên tăng đồng thời khi VRAM gần đầy có thể làm giảm mức xử lý khả dụng. Hướng dẫn bộ nhớ của vLLM nêu hai giới hạn max_model_len và max_num_seqs để thu hẹp độ dài ngữ cảnh và kích thước lô tối đa. Giảm chúng tiết kiệm bộ nhớ, nhưng cũng thu hẹp loại yêu cầu và mức đồng thời có thể phục vụ.

FAQ của Ollama cho biết OLLAMA_NUM_PARALLEL mặc định là 1; nhu cầu bộ nhớ tăng theo mức song song nhân với độ dài ngữ cảnh, còn hàng đợi quá tải có thể trả lỗi 503. Các yêu cầu gửi cùng lúc vì thế có thể vẫn lần lượt được suy luận. Tăng mức song song có thể giảm chờ đợi nếu còn đủ VRAM cho phần ngữ cảnh tăng thêm; tăng giới hạn hàng đợi chỉ giữ lại nhiều yêu cầu hơn, không làm GPU xử lý chúng nhanh hơn.

Không có ngưỡng đồng thời phổ quát tách Ollama khỏi vLLM. Ngưỡng thực tế xuất hiện khi cấu hình đang chạy không theo kịp nhịp yêu cầu đến, hoặc khi TTFT và hàng đợi vượt mức ứng dụng chấp nhận. Mô hình vừa VRAM lúc rảnh cũng chưa bảo đảm nó vừa khi nhiều ngữ cảnh dài cùng hoạt động.

Chọn engine cho hai kiểu sử dụng

Nếu mục tiêu là tải mô hình, thử prompt, trò chuyện hoặc viết mã trên máy cá nhân, Ollama hợp lý nhờ cách cài đặt và sử dụng gọn. Khi các yêu cầu chủ yếu đến nối tiếp, TTFT và tốc độ giải mã từng phiên quan trọng hơn thông lượng tổng dưới tải lớn. Lợi thế nhiều client của vLLM trong phép đo không tự chuyển thành trải nghiệm tốt hơn cho một người.

Nếu ứng dụng nội bộ, nhóm người dùng hoặc nhiều tác vụ tự động gửi yêu cầu chồng lên nhau, vLLM đáng được thử trước với mô hình còn khoảng trống VRAM. Phép đối chiếu cần giữ cùng nội dung prompt, chiều dài đầu ra, cách gửi tải và quy tắc bộ nhớ đệm; đồng thời ghi TTFT, tốc độ giải mã, thông lượng đầu ra, thời gian xếp hàng và lỗi. Khi mô hình đã chiếm sát VRAM, thu gọn mô hình hoặc ngữ cảnh có thể hữu ích hơn việc đổi engine, vì engine mới cũng cần bộ nhớ vận hành.

Trường hợp mô hình vượt khả năng chứa của GPU đặt ra câu hỏi khác: phần nào chạy ở CPU và chi phí truyền dữ liệu là bao nhiêu. llama.cpp có thể là đối chứng hữu ích với mô hình hỗn hợp chuyên gia. Với lựa chọn giữa Ollama và vLLM, tải chồng lấp và ngân sách bộ nhớ của chính máy sẽ vận hành mới quyết định liệu công cấu hình thêm có đổi lấy được thông lượng cần thiết hay không.

Đọc thêm: