Batch liên tục cho phép máy chủ vLLM tiếp nhận một yêu cầu mới trong khi các yêu cầu khác vẫn đang sinh token. Batch cố định chờ tất cả thành viên hoàn tất trước khi có thể tạo batch tiếp theo; batch liên tục xem xét lại tập đang hoạt động ở mỗi bước lập lịch. Sự khác biệt đó quan trọng khi prompt và đầu ra có độ dài khác nhau. Các yêu cầu ngắn có thể tham gia công việc trên GPU mà không cần chờ phản hồi dài nhất trong một nhóm trước đó.
Đối với một nhóm suy luận, câu hỏi hữu ích không phải là liệu batch liên tục có được bật trong danh sách tính năng hay không. Mà là liệu hỗn hợp yêu cầu thực tế của bạn có tăng số phản hồi hoàn tất mỗi giây mà không đẩy thời gian đến token đầu tiên, thời gian hàng đợi hoặc tỷ lệ lỗi vượt quá mục tiêu dịch vụ hay không. Hướng dẫn này giải thích cơ chế, các giới hạn quan trọng và một benchmark mà bạn có thể chạy trước khi chọn năng lực GPU.
Cách batch liên tục của vLLM hoạt động
Trong kiến trúc V1 hiện tại của vLLM, bộ lập lịch lấp đầy ngân sách token ở mỗi bước bằng các yêu cầu đang chạy và đang chờ. Một yêu cầu theo dõi số token đã được tính toán; bộ lập lịch phân bổ công việc để thu hẹp khoảng cách đó. Cùng một vòng lặp xử lý prefill theo khối, lưu đệm tiền tố và giải mã suy đoán. Đây là mô hình tư duy chính xác hơn so với một sơ đồ về một batch tĩnh chạy đến khi hoàn tất. Xem tổng quan kiến trúc vLLM để biết mô tả về bộ lập lịch.
Hãy hình dung ba yêu cầu đến: một phản hồi chat ngắn, một prompt tài liệu dài và một chat ngắn khác. Với batch cố định, chat ngắn thứ hai có thể phải chờ ranh giới batch của yêu cầu dài. Với batch liên tục, nó có thể được xem xét ở một bước lập lịch sau đó trong khi các yêu cầu đầu tiên vẫn hoạt động. Việc tiếp nhận vẫn bị giới hạn bởi ngân sách token, giới hạn chuỗi và dung lượng KV-cache khả dụng. Batch liên tục không đảm bảo không có hàng đợi hoặc kết quả nhanh hơn cho mọi yêu cầu.
PagedAttention xử lý một phần khác của vấn đề: lưu trữ và quản lý bộ nhớ đệm KV attention theo các khối. Nó giúp engine sử dụng bộ nhớ linh hoạt hơn, trong khi bộ lập lịch quyết định yêu cầu nào nhận được tài nguyên tính toán. Giữ riêng các vai trò này giúp bạn chẩn đoán liệu thông lượng thấp là do lập lịch, áp lực KV-cache, prompt dài hay nút thắt ở thượng nguồn. thiết kế PagedAttention của vLLM mô tả cơ chế bộ nhớ.
Các tham số kiểm soát định hình một batch
| Tham số kiểm soát | Giới hạn của tham số | Điều cần theo dõi khi thay đổi |
|---|---|---|
max_num_batched_tokens |
Token được xử lý trong một lần lặp của bộ lập lịch | Thông lượng, thời gian đến token đầu tiên, độ trễ giữa các token và tiến trình của prompt dài |
max_num_seqs |
Chuỗi được xử lý trong một lần lặp | Yêu cầu đang chạy, dung lượng bộ nhớ dự phòng và độ trễ đuôi |
| Prefill theo khối | Chia một prefill dài qua nhiều bước lập lịch | Độ trễ của prompt dài và sự ảnh hưởng đến các yêu cầu giải mã |
| Giới hạn hàng đợi hoặc tiếp nhận | Yêu cầu được phép chờ hoặc chạy | Thời gian hàng đợi, tỷ lệ từ chối và liệu tình trạng quá tải có lan đến bên gọi hay không |
| Dung lượng KV-cache | Ngữ cảnh hoạt động có thể chứa trên GPU | Preemption, tính toán lại và lỗi hết bộ nhớ |
Các thiết lập này tương tác với nhau. Tăng ngân sách token có thể cải thiện thông lượng cho một khối lượng công việc và làm xấu đi độ trễ tương tác cho khối lượng khác. Tăng số lượng chuỗi được tiếp nhận có thể tăng mức đồng thời nhưng cũng tiêu thụ nhiều KV cache hơn. Phiên bản, kiến trúc mô hình, độ dài ngữ cảnh và phần cứng đều ảnh hưởng đến kết quả. Đọc tài liệu tham chiếu cấu hình bộ lập lịch để biết hành vi của bản phát hành vLLM đã cài đặt, sau đó thay đổi từng tham số một.
Khi KV cache không thể chứa công việc mới, vLLM có thể preempt một yêu cầu đang chạy và sau đó tính toán lại tiến trình của yêu cầu đó. Số lượt preemption tăng là một cảnh báo rằng việc chỉ thêm nhiều yêu cầu đến hơn vào batch không phải là miễn phí. Tổng quan kiến trúc giải thích các quy tắc lập lịch và preemption.
Một benchmark phù hợp với lưu lượng production
Đừng so sánh các thiết lập batch liên tục bằng một prompt ngắn duy nhất được gửi nhanh nhất có thể từ client. Hãy xây dựng ba nhóm yêu cầu từ log riêng của bạn hoặc một trace an toàn về quyền riêng tư:
- Chat tương tác ngắn với prompt và phản hồi ngắn.
- Yêu cầu ngữ cảnh dài với prefill lớn và độ dài đầu ra vừa phải.
- Yêu cầu agent hoặc RAG với các tiền tố lặp lại, độ dài đầu ra đa dạng, hủy yêu cầu và các đợt tăng vọt.
Giữ cố định bản sửa đổi mô hình, tokenizer, loại GPU, phiên bản vLLM và
trace yêu cầu giữa các lần chạy. Quét tốc độ yêu cầu được cung cấp từ dưới
tải dự kiến cho đến điểm mà thời gian hàng đợi hoặc lỗi trở nên không thể chấp nhận. Hướng dẫn chính thức về vllm bench serve
tài liệu hóa các tham số kiểm soát tốc độ yêu cầu và tập dữ liệu. Ghi lại
chính xác lệnh, cấu hình và phiên bản trace để có thể lặp lại so sánh.
Với mỗi lần chạy, ghi lại số yêu cầu hoàn tất mỗi giây, số token đầu ra mỗi giây, p50 và p95 thời gian đến token đầu tiên, p95 độ trễ giữa các token, p95 độ trễ đầu cuối, thời gian hàng đợi, lỗi và mốc cao nhất của bộ nhớ GPU. tài liệu tham chiếu các chỉ số production của vLLM bao gồm các gauge cho yêu cầu đang chạy và đang chờ cùng histogram cho thời gian hàng đợi, thời gian đến token đầu tiên và preemption. Một bảng điểm hữu ích là:
| Lần chạy | Yêu cầu gửi đến/giây | Yêu cầu hoàn thành/giây | Token đầu tiên p95 | Hàng đợi p95 | Đầu cuối p95 | Tỷ lệ lỗi | Số lần thu hồi |
|---|---|---|---|---|---|---|---|
| Cơ sở | đã đo | đã đo | đã đo | đã đo | đã đo | đã đo | đã đo |
| Thay đổi ngân sách token | đã đo | đã đo | đã đo | đã đo | đã đo | đã đo | đã đo |
| Thay đổi giới hạn chuỗi | đã đo | đã đo | đã đo | đã đo | đã đo | đã đo | đã đo |
Điền các số đo vào bảng này; không có mức tăng phần trăm phổ quát nào để sao chép từ mô hình hoặc nhà cung cấp khác. Hãy chọn cấu hình đáp ứng các mục tiêu về độ trễ và độ tin cậy với chi phí thấp nhất cho mỗi phản hồi được chấp nhận, thay vì cấu hình chỉ có thông lượng token cao nhất khi xét riêng lẻ.
Chẩn đoán kết quả không như mong đợi
Nếu batch liên tục có vẻ không hiệu quả, hãy tìm ràng buộc trước khi thay đổi thêm một cờ khác.
Các yêu cầu đang chờ tăng lên trong khi bộ nhớ GPU vẫn còn dư. Kiểm tra giới hạn tiếp nhận, giới hạn chuỗi nhỏ, quá trình token hóa trên CPU và mức đồng thời phía máy khách. Bộ lập lịch không thể lấp đầy GPU bằng những yêu cầu chưa bao giờ đến được GPU.
Thời gian đến token đầu tiên tăng lên với các prompt dài. Trong điểm chuẩn, hãy tách lưu lượng nặng prefill khỏi lưu lượng nặng decode. Xem xét prefill theo khối và các thiết lập ngân sách token, đồng thời so sánh phân bố prompt dài thay vì chỉ giá trị trung bình.
Thông lượng cải thiện nhưng độ trễ p95 xấu đi. Máy chủ có thể đang chấp nhận nhiều công việc đồng thời hơn mức mà mục tiêu dịch vụ tương tác của bạn cho phép. Hạn chế tiếp nhận, sử dụng thời gian chờ hàng đợi hoặc một nhóm phục vụ riêng, rồi kiểm tra lại ở cùng tải yêu cầu gửi đến.
Số lần thu hồi hoặc sự kiện hết bộ nhớ tăng lên. Các ngữ cảnh hoạt động có thể không vừa với KV cache của GPU. Giảm mức đồng thời hoặc giới hạn ngữ cảnh, chọn GPU có đủ bộ nhớ, hoặc xem lại lựa chọn mô hình và độ chính xác. Tránh coi một yêu cầu bị thu hồi là một sự kiện lập lịch miễn phí.
Mức sử dụng GPU thấp ngay cả khi các yêu cầu đang chờ. Hãy kiểm tra CPU, mạng, lưu trữ, tải mô hình và nhịp gửi yêu cầu từ máy khách trước khi quy kết nút thắt cho batch liên tục. Hướng dẫn triển khai vLLM của chúng tôi đề cập đến runbook phục vụ tổng quát hơn; bài viết này tập trung vào hành vi của bộ lập lịch và việc đo lường.
Lựa chọn GPU ảnh hưởng đến quyết định ở đâu
Batch liên tục có thể cải thiện cách bạn sử dụng GPU, nhưng không thể khiến một mô hình vừa với lượng bộ nhớ vốn không có. Hãy ước tính trọng số, KV cache theo mức đồng thời và độ dài ngữ cảnh dự kiến, chi phí chạy thời gian thực và biên an toàn. Sau đó, thực hiện điểm chuẩn trên cấu hình GPU mà bạn dự định thuê. Một GPU 80 GB và GPU có bộ nhớ lớn hơn có thể tạo ra hành vi tiếp nhận và thu hồi khác nhau cho cùng một mô hình và dấu vết yêu cầu.
GPU Compute của Flatkey liệt kê các tùy chọn thuê, bao gồm H100 SXM, H200, B200, B300, A100 80GB và RTX 5090. Cấu hình, khu vực, tình trạng sẵn có và giá phải được xác nhận cho gói thuê đã chọn. Hãy mang theo dấu vết điểm chuẩn, độ trễ mục tiêu, phiên bản mô hình và ước tính bộ nhớ khi so sánh các lựa chọn. Điều đó giúp cuộc thảo luận về năng lực tập trung vào công việc đã hoàn thành thay vì thông số GPU nổi bật.
Danh sách kiểm tra quyết định thực tế
Trước khi chốt một cấu hình batch liên tục vLLM, hãy trả lời các câu hỏi sau:
- Kịch bản lưu lượng cao nhất có đáp ứng các mục tiêu độ trễ token đầu tiên p95 và độ trễ đầu cuối không?
- Điều gì xảy ra khi có một đợt tăng vọt vượt mức yêu cầu thông thường: hàng đợi bị giới hạn, bị từ chối hay độ trễ tăng đột biến?
- Số lần thu hồi và áp lực KV cache có ổn định ở độ dài ngữ cảnh dự kiến không?
- Kết quả có thể lặp lại trên đúng phiên bản mô hình và cấu hình GPU mà bạn dự định chạy không?
- Chi phí cho mỗi phản hồi được chấp nhận có tốt hơn phương án thay thế sau khi tính cả số lần thử lại và dung lượng nhàn rỗi không?
Câu hỏi thường gặp
Batch liên tục vLLM có nghĩa là mọi yêu cầu đều chạy ngay lập tức không?
Không. Một yêu cầu mới đến có thể được xem xét tại một bước lập lịch, nhưng vẫn có thể phải chờ ngân sách token, một vị trí chuỗi hoặc dung lượng KV cache. Hãy theo dõi đồng thời các chỉ số đang chạy và đang chờ cùng với biểu đồ phân bố thời gian hàng đợi trước khi cam kết một mục tiêu độ trễ tương tác.
Batch liên tục vLLM có giống với prefill theo khối không?
Không. Batch liên tục mô tả cách các yêu cầu tham gia và rời khỏi công việc đã được lập lịch theo thời gian. Prefill theo khối chia công việc prefill của một prompt dài để nó có thể chia sẻ ngân sách token qua các bước. Chúng hoạt động cùng nhau trong bộ lập lịch hiện tại, nhưng điều chỉnh một núm tinh chỉnh không thể thay thế việc đo lường núm còn lại.
Tôi có nên tối đa hóa kích thước batch không?
Không nhất thiết. Batch lớn hơn có thể cải thiện thông lượng nhưng làm tăng thời gian hàng đợi, thời gian đến token đầu tiên hoặc áp lực thu hồi. Hãy chạy cùng một dấu vết ở cùng tải yêu cầu gửi đến và so sánh toàn bộ mục tiêu dịch vụ, bao gồm lỗi và chi phí cho mỗi phản hồi được chấp nhận.
Batch liên tục vLLM là một phương pháp lập lịch, không phải kết quả điểm chuẩn. Thiết lập tốt nhất là thiết lập có thông lượng, độ trễ, hành vi bộ nhớ và chế độ lỗi mà bạn có thể giải thích bằng các số đo của chính mình.
