Offload và phân tầng KV Cache cho phục vụ LLM ngữ cảnh dài

Phục vụ ngữ cảnh dài cuối cùng biến bộ nhớ GPU thành một bài toán lập lịch. Một yêu cầu có thể hoàn tất lượt đầu tiên nhưng để lại trạng thái KV vốn tốn kém để tính lại và hiện chưa cần thiết trên GPU. KV cache offload là kỹ thuật di chuyển các khối bộ nhớ đệm có thể tái sử dụng từ tầng GPU nhanh sang một tầng lớn hơn, chậm hơn—thường là RAM máy chủ trước—sau đó chỉ đưa chúng trở lại khi một yêu cầu sau có thể tái sử dụng chúng.

Mục tiêu không phải là làm cho bộ lưu trữ chậm trông giống HBM. Mục tiêu là dành năng lực KV GPU đắt đỏ cho tập làm việc đang hoạt động, đồng thời vẫn giữ các tiền tố có giá trị cao ở nơi khác. Điều đó khiến KV cache offload hữu ích nhất khi lưu lượng của bạn có ngữ cảnh dài và khả năng tái sử dụng đáng kể: prompt hệ thống lặp lại, khung RAG, phiên nhiều lượt hoặc các tiền tố tài liệu lặp lại.

Hướng dẫn này trình bày cách quyết định liệu phân tầng có phù hợp hay không, cách các cơ chế kiểm soát vLLM hiện tại phối hợp với nhau, TensorRT-LLM cung cấp gì cho offload bộ nhớ máy chủ, và cách kiểm thử thay đổi này mà không đánh đổi lỗi hết bộ nhớ GPU lấy một sự cố độ trễ đuôi.

Câu trả lời nhanh

Hãy dùng KV cache offload như một phần mở rộng có kiểm soát của việc tái sử dụng tiền tố—không phải như một giải pháp bộ nhớ mặc định.

Ràng buộc quan trọng là tính cục bộ. Khi một khối đã offload được tái sử dụng, nó phải quay lại bộ nhớ GPU trước khi attention sử dụng nó. Đường truyền đó là một phần trong ngân sách độ trễ của yêu cầu.

Một tầng KV cache thực sự lưu trữ gì

Trong quá trình sinh tự hồi quy, các lớp attention tạo ra tensor key và value cho các token đã xử lý. Giữ lại các tensor đó giúp máy chủ tránh phải tính lại tiền tố đã thấy ở một bước giải mã sau hoặc khi tái sử dụng tiền tố tương thích. Trong TensorRT-LLM, KV cache được biểu diễn dưới dạng các pool khối chứa trạng thái cho một số lượng token cố định; tài liệu của nó cũng mô tả việc tái sử dụng giữa các yêu cầu, lưu giữ theo mức độ ưu tiên và offload bộ nhớ máy chủ. Hệ thống KV Cache TensorRT-LLM

Một ngăn xếp phục vụ thực tế thường có ba mức nhiệt độ lưu trữ khả dĩ:

Hướng dẫn offload của vLLM nêu rõ thứ tự này: thiết kế đa tầng của nó sử dụng CPU làm tầng chính, và việc truyền dữ liệu giữa GPU với tầng phụ được dàn qua tầng CPU đó. Nói cách khác, một lần trúng tầng lạnh không phải là một lượt đọc trực tiếp từ GPU. Hướng dẫn sử dụng KV Offloading của vLLM

              promote on a usable cache hit
Request ──> GPU HBM  <──────────────────── CPU DRAM
              │                                ▲
              │ evict completed, reusable      │ stage
              ▼                                │
          active GPU cache  ─────────────> secondary storage
                 hot                     warm / cold

Sơ đồ vllm kv cache offload này được cố ý đơn giản hóa: chỉ tầng GPU mới nên luôn nằm trên đường dẫn tính toán trọng yếu. Các tầng CPU và lưu trữ nên phục vụ một chính sách tái sử dụng có thể đo lường.

KV cache offload không phải là model-weight offload

Sự phân biệt này ngăn ngừa một cấu hình sai phổ biến đáng ngạc nhiên:

• KV cache offload di chuyển trạng thái attention do các yêu cầu tạo ra. Nó chủ yếu thay đổi bộ nhớ khả dụng cho ngữ cảnh đang hoạt động và đường dẫn tái sử dụng.
• Model-weight offload di chuyển các tham số mô hình. Trong vLLM, cơ chế --cpu-offload-gb được ghi lại trong mục offload trọng số mô hình và có thể tăng công việc truyền CPU–GPU cho mỗi lượt forward của mô hình. Các đối số serve của vLLM

Đừng cho rằng một thiết lập giúp mô hình tải được cũng tạo thêm dung lượng KV có thể sử dụng. Trước tiên, hãy tách riêng ngân sách trọng số mô hình, không gian làm việc thời gian chạy và ngân sách KV-cache; sau đó quyết định liệu các khối KV không hoạt động có đáng được giữ lại ngoài bộ nhớ GPU hay không.

vLLM KV cache offload: bắt đầu với đường dẫn CPU gốc

Đối với CLI vLLM hiện tại, cờ offload KV cache của vllm liên quan là --kv-offloading-size. Tài liệu tham chiếu CLI chính thức cho biết đây là kích thước bộ đệm offload KV tính bằng GiB; khi tensor parallelism lớn hơn một, kích thước là tổng trên các rank tensor-parallel. Offloading bị tắt khi không đặt giá trị này. Cờ đi kèm --kv-offloading-backend hỗ trợ backend CPU native và LMCache. Đối số vLLM serve

Hãy dùng một thử nghiệm thí điểm có giới hạn thay vì định cỡ tầng host theo toàn bộ RAM khả dụng:

vllm serve <your-model> \
  --gpu-memory-utilization 0.85 \
  --kv-offloading-size 16 \
  --kv-offloading-backend native

Ví dụ này là một khuôn mẫu thử nghiệm, không phải thiết lập dùng cho mọi trường hợp. Giá trị phù hợp phụ thuộc vào bố cục cache của mô hình, độ dài ngữ cảnh, cấu hình tensor-parallel, phần RAM host dự phòng, hỗn hợp yêu cầu và mục tiêu độ trễ. Hãy cố định phiên bản image vLLM và chạy vllm serve --help trong image đó trước khi đưa các cờ vào môi trường production; cấu hình phục vụ thay đổi nhanh chóng.

Đường đi native phù hợp cho lần thử offload CPU KV cache của vllm đầu tiên vì nó giữ câu hỏi về phân tầng ở phạm vi hẹp: liệu một tầng CPU ấm có thể giữ đủ các block hữu ích để cải thiện việc tiếp nhận hoặc tránh cache GPU bị churn mà không làm xấu đi p95 và p99?

Chọn cơ chế tiếp nhận cache trước dung lượng cache

Nhiều block được giữ lại hơn không nhất thiết đồng nghĩa với nhiều block hữu ích hơn. Trước khi tăng bộ đệm offload, hãy trả lời bốn câu hỏi:

1. Những prefix nào được chia sẻ giữa các yêu cầu?
2. Các prefix đó được tái sử dụng sau bao lâu kể từ khi được tạo?
3. Một block hữu ích lớn đến đâu so với ngân sách truyền dữ liệu của host?
4. Những block nào nên bị loại bỏ hoàn toàn vì khả năng tái sử dụng quá thấp?

Nếu workload không thể trả lời hai câu hỏi đầu tiên từ trace, hãy bắt đầu bằng việc đo lường tái sử dụng prefix trên GPU. Một tầng CPU có thể bảo toàn trạng thái cache ấm; nó không thể tạo ra khả năng tái sử dụng cho các prompt hoàn toàn độc nhất.

Chỉ xây dựng đường đi phân tầng vLLM sau thử nghiệm thí điểm CPU

OffloadingConnector của vLLM là đường đi dành cho tầng chính CPU cùng các tầng phụ tùy chọn. Hướng dẫn chính thức mô tả CPUOffloadingSpec cho một tầng CPU duy nhất và TieringOffloadingSpec cho tầng chính CPU với một hoặc nhiều tầng phụ. Tài liệu này cũng nêu LRU và ARC là các tùy chọn chính sách eviction tích hợp sẵn. Hướng dẫn sử dụng KV Offloading của vLLM

Sau đây là cấu hình bám sát ví dụ đa tầng trong tài liệu. Chỉ thay thế mô hình, đường dẫn, kích thước block, số byte và số lượng luồng sau khi kiểm thử chúng trên host của riêng bạn:

vllm serve <your-model> \
  --kv-transfer-config '{
    "kv_connector": "OffloadingConnector",
    "kv_role": "kv_both",
    "kv_connector_extra_config": {
      "spec_name": "TieringOffloadingSpec",
      "cpu_bytes_to_use": 10737418240,
      "block_size": 16,
      "eviction_policy": "lru",
      "secondary_tiers": [
        {
          "type": "fs",
          "root_dir": "/mnt/kv_cache",
          "n_read_threads": 32,
          "n_write_threads": 16
        }
      ]
    }
  }'

Ba chi tiết vận hành quan trọng hơn việc sao chép đoạn mã:

1. cpu_bytes_to_use là phần dung lượng dành riêng cho tầng CPU tổng cộng trên các worker, không phải một gợi ý mơ hồ cho hệ điều hành. Hãy lập ngân sách cho tiến trình, hệ điều hành, page cache của storage và mọi dịch vụ colocated.
2. Kích thước block hoặc chunk được cấu hình xác định đơn vị I/O. Chunk quá nhỏ có thể làm tăng overhead metadata và lập lịch; chunk quá lớn có thể đưa lên các byte mà một yêu cầu không cần. Hãy kiểm thử cả hai với độ dài prefix thực tế.
3. Một tầng phụ nằm phía sau CPU. Nếu tầng CPU quá nhỏ hoặc bão hòa, việc bổ sung dung lượng filesystem có thể giữ lại nhiều dữ liệu hơn mà không cải thiện độ trễ của lần hit sau đó.

Vì vậy, mục tiêu của offload KV cache của vllm không phải là “giữ lại mọi thứ.” Mà là “giữ lại các block có đường tái sử dụng hợp lý và kịp thời.”

Offload KV cache TensorRT-LLM sang bộ nhớ host

TensorRT-LLM thể hiện cùng ý tưởng cơ bản này thông qua cấu hình KV-cache. Tài liệu của nó cho biết host_cache_size cấp phát bộ nhớ host cho offloading, mặc định là 0, và cho phép một block vẫn có thể tái sử dụng cho đến khi sau đó bị eviction khỏi bộ nhớ host. Khi tái sử dụng, block được sao chép trở lại bộ nhớ GPU. Hệ thống KV Cache TensorRT-LLM

Đối với việc triển khai offload KV cache TensorRT-LLM sang bộ nhớ host, hãy chú ý đến chính sách lưu giữ cũng như dung lượng:

Tại thời điểm viết bài, TensorRT-LLM ghi nhận giá trị mặc định secondary_offload_min_priority là 35. Hãy coi đó là giá trị mặc định theo phiên bản, không phải khuyến nghị chính sách: ngưỡng nên phản ánh giá trị tái sử dụng quan sát được và chi phí truyền tải của dịch vụ bạn.

Phương pháp triển khai bảo vệ độ trễ

Đừng bật một tầng lạnh trong lúc xảy ra sự cố về dung lượng rồi tuyên bố thành công khi lỗi OOM dừng lại. Thay vào đó, hãy thực hiện theo một trình tự có kiểm soát:

1. Thu thập đường cơ sở chỉ dùng GPU. Ghi lại phân phối độ dài ngữ cảnh, mức độ đồng thời, thời gian đến token đầu tiên, độ trễ giữa các token, p50/p95/p99 đầu cuối, tỷ lệ tái sử dụng tiền tố và hành vi đẩy KV khỏi GPU.
2. Dành trước dung lượng bộ nhớ máy chủ thực tế. Bao gồm overhead thời gian chạy và hệ điều hành; đừng chỉ định kích thước cache CPU chỉ dựa trên ảnh chụp bộ nhớ trống.
3. Bật một tầng CPU nhỏ. Giữ ổn định mô hình, chính sách batch, hình dạng lưu lượng và cảnh báo SLO trong khi chỉ thay đổi một chiều của cache.
4. So sánh chất lượng hit, không chỉ số lượng hit. Phân biệt hit GPU, chuyển lên từ CPU, chuyển lên từ tầng lạnh và các miss kích hoạt tính toán lại.
5. Kiểm tra độ trễ đuôi khi có tranh chấp tài nguyên. Chạy các yêu cầu dài/ngắn hỗn hợp và tăng dần mức độ đồng thời. Kết quả chỉ xét trung bình sẽ che giấu các hàng đợi truyền tải.
6. Chỉ thêm tầng thứ cấp nếu giá trị lưu giữ biện minh cho điều đó. Kiểm thử mất cache, áp lực lưu trữ, hành vi khởi động lại và các đợt chuyển lên đột biến trước khi triển khai rộng rãi.
7. Đặt quy tắc rollback. Ví dụ: vô hiệu hóa tầng mới nhất khi p99 của thời gian đến token đầu tiên hoặc độ trễ giữa các token vượt ngân sách đã thống nhất trong một khoảng thời gian kéo dài.

Hướng dẫn vLLM ghi nhận các chỉ số cấu hình và offload, bao gồm thông tin cấu hình và tín hiệu sử dụng cache CPU. Hãy dùng chúng cùng với trace ứng dụng; một chỉ số cache không có độ trễ ở cấp yêu cầu khiến việc phân biệt một lần chuyển lên có giá trị với tình trạng truyền tải thrash trở nên khó khăn. Hướng dẫn sử dụng KV Offloading của vLLM

Các chế độ lỗi cần loại trừ trong thiết kế

Khi offload KV cache là tối ưu hóa không phù hợp

Tạm thời không dùng offload KV cache khi:

• Bộ nhớ GPU không phải là yếu tố giới hạn.
• Hầu như tất cả prompt là duy nhất, nên các tiền tố được giữ lại không quay lại.
• SLO chính của bạn là độ trễ đuôi rất thấp và không thể chứng minh đường truyền tải nằm trong giới hạn đó.
• DRAM máy chủ hoặc lưu trữ đã là tài nguyên production đang bị tranh chấp.
• Chưa đánh giá prefix caching, batching, giới hạn ngữ cảnh, lựa chọn mô hình hoặc lượng tử hóa cache.

Trong các trường hợp đó, bước đầu tiên gọn gàng hơn có thể là rà soát ngân sách bộ nhớ GPU, áp dụng chính sách ngữ cảnh khác hoặc thay đổi kiến trúc phục vụ. Để tìm hiểu các lựa chọn về topology và song song hóa, xem Suy luận đa GPU với vLLM, vLLM so với SGLang và TensorRT-LLM so với vLLM.

Câu hỏi thường gặp

Offload KV cache có giảm mức sử dụng bộ nhớ GPU không?

Nó có thể giảm áp lực từ các block KV không hoạt động nhưng có thể tái sử dụng bằng cách chuyển chúng ra khỏi tầng GPU. Nó không loại bỏ nhu cầu về cache nằm trên GPU cho tác vụ attention đang hoạt động, và một block đã được offload được tái sử dụng phải được chuyển trở lại trước khi dùng.

Cờ offload KV cache của vLLM là gì?

Trong tài liệu CLI vLLM hiện tại, --kv-offloading-size bật bộ đệm offload KV khi được thiết lập, còn --kv-offloading-backend chọn backend. Hãy xác minh chính xác các cờ trong bản phát hành vLLM bạn đã ghim. Đối số vLLM serve

Tầng hệ thống tệp có phải là cache GPU trực tiếp không?

Không. vLLM ghi nhận CPU là tầng chính cho triển khai đa tầng của nó; việc truyền giữa GPU và tầng thứ cấp được thực hiện theo từng chặng qua bộ nhớ CPU. Đó là lý do các kiểm thử tầng thứ cấp phải bao gồm toàn bộ đường chuyển lên.

Offload KV cache có tốt hơn việc mua GPU lớn hơn không?

Chúng giải quyết các ràng buộc khác nhau. GPU lớn hơn có thể tăng tập làm việc nóng mà không có overhead chuyển lên. Offload có thể giữ lại trạng thái ấm hoặc lạnh hữu ích với dung lượng GPU hiện có. Hãy so sánh cả hai với mức tái sử dụng đã đo của workload, SLO độ trễ, gánh nặng vận hành và tổng chi phí phục vụ.

Kết luận: xem offload KV cache là một chính sách bộ nhớ đệm, không phải một mẹo tăng dung lượng

Thiết kế offload KV cache mạnh nhất giữ trạng thái đang hoạt động trên GPU, dành riêng bộ nhớ CPU cho việc tái sử dụng nóng có bằng chứng hỗ trợ, và chỉ thêm tầng lạnh khi việc lưu giữ vẫn có giá trị sau khi đã đo lường chi phí truyền dữ liệu và xử lý lỗi. Hãy bắt đầu với một thử nghiệm CPU có giới hạn, theo dõi việc thăng cấp và độ trễ theo từng tầng, rồi chỉ áp dụng chính sách cải thiện SLO trong môi trường production—không chỉ đơn thuần tăng lượng cache được giữ lại.

Nếu chi phí vận hành của một stack phục vụ tự lưu trữ lớn hơn mức độ kiểm soát mà khối lượng công việc của bạn cần, hãy so sánh một triển khai đám mây GPU với model API hoặc khám phá Flatkey Compute trước khi cam kết mở rộng đội máy chủ.

Nguồn

• vLLM: Hướng dẫn sử dụng KV Offloading
• vLLM: Tham số Serve
• NVIDIA TensorRT-LLM: Hệ thống KV Cache