SGLang ra mắt Weight Cache Daemon: Khởi động lại engine AI chỉ trong chưa đầy 1 giây

TL;DR

Ngày nay, các mô hình State-of-the-Art (SOTA) đang ngày càng lớn hơn và việc tải lại dịch vụ mô hình sau khi gặp sự cố là rất tốn kém. Do đó, chúng tôi giới thiệu Weight Cache Daemon, một tiến trình GPU thường trú giúp lưu giữ các trọng số mô hình đã được lượng tử hóa trong bộ nhớ GPU và cung cấp chúng cho các instance SGLang engine mới thông qua cơ chế ánh xạ zero-copy CUDA IPC. Điều này giúp giảm thời gian tải trọng số từ vài phút xuống còn vài giây.

Weight Cache Daemon là giai đoạn đầu tiên trong Fast Engine Recovery Framework của chúng tôi, hướng tới mục tiêu khởi động nguội (cold restart) dưới 10 giây và chuyển đổi dự phòng nóng (warm standby) dưới 1 giây cho việc phục vụ LLM trong môi trường sản xuất.

Các kết quả chính:

Bối cảnh

Khi các mô hình LLM ngày càng lớn hơn — như Qwen3-235B, Ling-2.6-1T và Kimi K3 2.8T mới ra mắt — thời gian khởi động nguội của các engine phục vụ đã trở thành điểm nghẽn quan trọng đối với hiệu suất sản xuất. Một instance Ling-2.6-1T FP8 trên 8×H20-3e GPU mất khoảng 8,52 phút chỉ để sẵn sàng phục vụ, với trọng số nằm trên ổ cứng 3.5T NVME SSD. Trong môi trường sản xuất, điều này có nghĩa là:

Thời gian đã đi đâu? Chúng tôi đã phân tích quá trình khởi động hoàn chỉnh của SGLang engine cho Ling-2.6-1T FP8:

Điểm nghẽn rất rõ ràng: việc tải trọng số từ ổ cứng chiếm 93,2% thời gian khởi động. Đối với mô hình Ling-2.6-1T FP8, mỗi TP rank đọc khoảng 120GB tệp safetensors từ ổ cứng, giải mã, áp dụng TP sharding và thực hiện các biến đổi sau lượng tử hóa (lượng tử hóa FP8, đóng gói lại trọng số). Công việc này được lặp lại y hệt trong mỗi lần khởi động lại, mặc dù các tensor GPU thu được là tất định và thường đã có sẵn trong bộ nhớ GPU.

Chúng ta có thể tránh việc tải lại từ ổ cứng mỗi lần không? Câu trả lời là có — bằng cách giữ trọng số trong bộ nhớ GPU xuyên suốt các lần khởi động lại engine.

Thiết kế

Ý tưởng cốt lõi: Bộ nhớ đệm trọng số thường trú thông qua CUDA IPC

Weight Cache Daemon là một tiến trình GPU thường trú lưu giữ các trọng số đã được lượng tử hóa và phân mảnh TP (TP-sharded) trong bộ nhớ GPU. Khi khởi động lại engine, tiến trình engine mới sẽ ánh xạ trọng số từ daemon thông qua CUDA IPC zero-copy — không cần I/O ổ cứng, không cần giải mã, không cần lượng tử hóa.

Mỗi GPU chạy một tiến trình daemon cho TP rank của nó. Daemon thực hiện:

Engine kết nối với daemon, xác thực tính tương thích của cấu hình và ánh xạ trực tiếp trọng số vào không gian địa chỉ của nó — engine và daemon chia sẻ cùng một bộ nhớ GPU vật lý thông qua CUDA IPC.

Tải dữ liệu Zero-Copy thông qua Meta Device

Chìa khóa để tải dữ liệu dưới một giây chính là zero-copy: con trỏ param.data của engine được trỏ trực tiếp đến tensor GPU đã được ánh xạ IPC. Không có dữ liệu nào được sao chép.

Để đạt được điều này, engine khởi tạo mô hình trên meta device (không cấp phát bộ nhớ GPU/CPU), sau đó thay thế con trỏ dữ liệu của mỗi tham số bằng tensor đã ánh xạ IPC.

Các tham số sau lượng tử hóa (ví dụ: weight_scale từ lượng tử hóa FP8) được tạo bởi process_weights_after_loading cũng được daemon lưu vào bộ nhớ đệm và ánh xạ trực tiếp — không cần lượng tử hóa lại.

Xác thực cấu hình: An toàn là trên hết

Bất kỳ sự không khớp nào giữa cấu hình của engine và cấu hình đã lưu trong bộ nhớ đệm của daemon đều kích hoạt quá trình tải lại hoàn toàn từ ổ cứng, đảm bảo tính chính xác:

Hai trường cuối cùng tạo thành một dấu ấn môi trường (environment stamp): một daemon và một client chạy các nhánh xử lý hậu kỳ khác nhau (khả năng tính toán hoặc phiên bản torch/kernel khác nhau) có thể tạo ra các trọng số ánh xạ sạch qua IPC nhưng lại trả về dữ liệu rác — việc đóng dấu môi trường vào CacheConfig sẽ biến điều đó thành một sự không khớp rõ ràng.

Điều này rất quan trọng đối với sự an toàn trong sản xuất: nếu người vận hành thay đổi cấu hình mô hình hoặc lượng tử hóa, engine sẽ phát hiện sự không khớp và quay lại tải từ ổ cứng thay vì ánh xạ các trọng số không tương thích.

Ngoài việc xác thực cấu hình, các phương pháp lượng tử hóa được kiểm soát bởi danh sách cho phép (allowlist) IPC. CUDA IPC zero-copy chỉ xuất dữ liệu tensor thô, vì vậy nó chỉ chính xác khi toàn bộ hiệu ứng của process_weights_after_loading được ghi lại bởi dữ liệu đó. Các phương pháp đóng dấu siêu dữ liệu phía Python hoặc đóng gói lại/chuyển vị trọng số (per-tensor FP8, Marlin, AWQ/GPTQ) có thể âm thầm phục vụ các giá trị số sai — chúng sẽ gây ra lỗi nghiêm trọng thay vì thực hiện. Hiện đã xác minh: unquantized và block-wise FP8 (đã thiết lập weight_block_size); các phương pháp khác sẽ được thêm vào sau khi xác minh toàn diện.

Ba chế độ: daemon, client và off

Ở chế độ daemon, engine tạo ra các tiến trình daemon trong quá trình khởi động và đợi chúng tải trọng số từ ổ cứng. Lần khởi động đầu tiên vẫn chậm (daemon phải tải từ ổ cứng), nhưng các lần khởi động lại sau đó sẽ diễn ra tức thì.

Ở chế độ client, engine kết nối với các daemon đang chạy sẵn. Đây là lộ trình khởi động nhanh — daemon đã được khởi động trước đó và đã giữ trọng số trong bộ nhớ GPU.

An toàn và Độ bền vững

Weight Cache Daemon được thiết kế để không gây xâm lấn và an toàn:

Vượt xa việc khởi động lại: Các kịch bản sản xuất

Weight Cache Daemon mở ra các mô hình sản xuất vốn không khả thi với cách tải dựa trên ổ cứng truyền thống:

Chia sẻ trọng số giữa nhiều Instance

Một daemon duy nhất trên mỗi GPU giữ trọng số trong bộ nhớ; nhiều instance engine (ví dụ: các dịch vụ độc lập) ánh xạ tới cùng các handle IPC thông qua zero-copy. Trọng số được tải từ ổ cứng và lượng tử hóa chính xác một lần cho mỗi GPU, bất kể có bao nhiêu instance sử dụng chúng.

Phục vụ đồng thời với mức ưu tiên

Chạy một dịch vụ trực tuyến ưu tiên cao và một tác vụ batch ưu tiên thấp trên cùng một GPU, được hỗ trợ bởi cùng một weight cache daemon. Instance ưu tiên thấp có thể bị thu hồi và khởi động lại trong thời gian dưới một giây mà không cần tải lại trọng số từ ổ cứng — cho phép chia sẻ thời gian GPU linh hoạt mà không bị phạt thời gian khởi động như thông thường.

Chuyển đổi dự phòng Active-Standby

Triển khai một engine dự phòng (standby) cùng với engine chính (primary), cả hai đều được hỗ trợ bởi cùng một weight cache daemon. Engine dự phòng ánh xạ trọng số thông qua zero-copy và luôn ở trạng thái "nóng". Khi engine chính gặp sự cố, engine dự phòng tiếp quản trong dưới 1 giây — không cần tải trọng số, không cần I/O ổ cứng.

Điều này đạt được khả năng chuyển đổi dự phòng với thời gian chết gần bằng không mà không cần dành riêng một bộ GPU đầy đủ cho bản sao nhàn rỗi, tránh lãng phí tài nguyên GPU đắt đỏ của các triển khai hot-standby truyền thống.

Hiệu suất

Tải trọng số: Ổ cứng so với IPC Zero-Copy