Ngày 21/8, nhóm hạ tầng Ling của Ant, cùng Alibaba và nhóm SGLang đã công bố trên blog LMSYS một thành phần có tên Weight Cache Daemon: một tiến trình thường trực trong bộ nhớ GPU, giữ lại trọng số đã lượng tử hóa và đã cắt lát, để một engine suy luận mới khởi động có thể ánh xạ zero-copy sang qua CUDA IPC. Theo số liệu nhóm công bố, thời gian tải trọng số FP8 của Ling-2.6-1T giảm từ khoảng 495 giây xuống 0,63 giây, tổng thời gian khởi động giảm từ 8,8 phút xuống 0,528 phút.
Tám trong tám phút rưỡi dành để đọc đĩa
Nhóm đã tách một lần khởi động hoàn chỉnh ra để đo từng phần. Ling-2.6-1T FP8 chạy trên 8 GPU H20-3e, trọng số đặt trên SSD NVMe 3,5T; từ lúc khởi động đến khi có thể nhận request mất khoảng 527 giây. Trong đó tải trọng số chiếm 495 giây, tức 93,9%; khởi tạo tokenizer mất 13 giây, khởi tạo phân tán torch 5 giây, ghi CUDA graph 7,7 giây, các phần còn lại cộng lại chưa tới 6 giây.
Mỗi card phải đọc từ đĩa khoảng 120 GB safetensors, giải tuần tự hóa, cắt lát theo song song tensor, rồi lượng tử hóa FP8 và sắp xếp lại trọng số, tổng cộng 161 mảnh. Pipeline này chạy lại từ đầu mỗi lần khởi động, nhưng kết quả của nó lại xác định: cùng một mô hình, cùng một cấu hình, các tensor cuối cùng nằm trong bộ nhớ luôn giống nhau — và thường vẫn còn nguyên ngay sau khi tiến trình trước đó vừa thoát.
Với môi trường sản xuất, vài phút này đồng nghĩa với việc độ trễ đuôi P99 tăng vọt trong lúc khởi động lại, các request đang xử lý dở đều thất bại hoặc xếp hàng vô thời hạn, còn rolling update và khôi phục sự cố đều bị chu kỳ này chặn lại.
Trọng số ở lại trong bộ nhớ GPU
Mỗi GPU chạy một tiến trình daemon, ứng với một TP rank. Nó tải trọng số một lần theo đúng pipeline đầy đủ từ đĩa, sau đó xuất toàn bộ tham số và buffer trong model.state_dict() thành các handle CUDA IPC, chuyển giao qua Unix socket cho các tiến trình engine kết nối tới. Phía engine trước tiên dựng cấu trúc mô hình trên meta device mà không cấp phát bộ nhớ nào, rồi cho con trỏ data của từng tham số trỏ tới tensor đã ánh xạ. Hai tiến trình dùng chung một vùng bộ nhớ vật lý, không hề có bước sao chép nào. Các tham số hậu xử lý sinh ra trong quá trình lượng tử hóa FP8 như weight_scale cũng được cache theo, giúp bỏ qua bước lượng tử hóa lại.
Có hai lớp an toàn được dựng lên. Một là dấu vân tay cấu hình: đường dẫn mô hình, cách cắt TP/PP/DP, phương pháp lượng tử hóa cùng hash cấu hình, dtype đều phải khớp, đồng thời ghi thêm năng lực tính toán GPU và phiên bản torch làm dấu môi trường. Lý do là kiến trúc hay phiên bản torch khác nhau sẽ đi theo nhánh hậu xử lý khác nhau: trọng số vẫn ánh xạ sạch sẽ nhưng tính ra kết quả rác. Đưa môi trường vào dấu vân tay biến lỗi ẩn này thành một sự không khớp rõ ràng, rồi hệ thống quay về tải từ đĩa.
Lớp thứ hai là danh sách trắng phương pháp lượng tử hóa. Hiện chỉ mới xác thực trường hợp không lượng tử hóa và block-wise FP8; per-tensor FP8, Marlin, AWQ/GPTQ sẽ báo lỗi ngay. Nguyên nhân là IPC chỉ xuất dữ liệu tensor thô, trong khi các phương pháp này để lại một phần hiệu ứng trong metadata phía Python, hoặc sắp xếp lại và chuyển vị trọng số — ánh xạ sang sẽ ra giá trị sai. Nhóm chọn để nó báo lỗi thẳng thừng thay vì âm thầm đưa ra kết quả sai.
Nếu daemon sập, engine đang chạy không bị ảnh hưởng: bộ đếm tham chiếu CUDA vẫn còn, bộ nhớ chỉ được giải phóng khi cả hai bên đều thoát. Khi daemon khởi động lại, nó đọc đĩa và xuất handle lại từ đầu, engine mới lúc đó mới kết nối được.
Tiện thể giải luôn bài toán hot standby
Thành phần này có ba chế độ: daemon (engine tự kéo daemon lên, lần khởi động đầu vẫn chậm), client (kết nối tới daemon đang chạy sẵn, khởi động lại chưa tới 1 giây) và off (mặc định, đi qua đĩa; Ling-2.6-1T mất 405 đến 411 giây).
Thiết thực hơn cả việc tăng tốc khởi động là vài mô hình triển khai. Nhiều instance engine trên cùng một card ánh xạ chung một bộ trọng số, đĩa chỉ đọc một lần, lượng tử hóa chỉ làm một lần. Dịch vụ online ưu tiên cao và xử lý batch offline ưu tiên thấp dùng chung một card, khi bên sau bị chiếm chỗ thì bật lại trong chưa tới 1 giây. Trong chuyển đổi chính-phụ, engine dự phòng ánh xạ zero-copy vào cùng bộ trọng số và luôn ở trạng thái nóng, khi instance chính gặp sự cố sẽ tiếp quản trong vòng 1 giây.
Điểm cuối cùng này là khoản chi phí rõ ràng. Ước tính thô: một instance Ling-2.6-1T chiếm 8 card H20-3e, hot standby kiểu truyền thống nghĩa là phải để thêm 8 card khác chạy không tải bên cạnh. Chuyển sang máy dự phòng dùng chung trọng số thì tiết kiệm được đúng nhóm card thường trực đó. Rolling update cũng tương tự: tính theo mỗi chu kỳ khoảng 8,8 phút, mỗi instance mỗi vòng khởi động lại đốt khoảng 1,2 giờ-GPU chạy không tải, với cụm có hàng trăm instance thì một vòng nâng cấp đã tốn tới ba chữ số giờ-GPU.
Vẫn chưa xong
Weight Cache Daemon là giai đoạn đầu của Fast Engine Recovery Framework. Lộ trình đặt mục tiêu khởi động nguội dưới 10 giây, chuyển đổi hot standby dưới 1 giây. Kế tiếp nhóm dự định làm serialize CUDA graph, cache kernel và tối ưu khởi tạo phân tán. Theo phần bóc tách ở trên, các mục này cộng lại khoảng 26 giây, đúng là phần lớn nhất còn lại sau trọng số.
Nhóm cũng công bố số liệu cho hạng mục Qwen3-235B FP8: khoảng 235 GB trọng số, tải từ đĩa mất 306 đến 327 giây, ánh xạ IPC chưa tới 1 giây, tức khoảng 500 lần. Với Ling-2.6-1T thì con số này khoảng 780 lần.
Bài blog tiện thể nhắc tới Kimi K3 2,8 nghìn tỷ tham số vừa ra mắt. Số tham số càng tăng thì thời gian tải từ đĩa tăng gần như tuyến tính, trong khi ánh xạ IPC gần như là hằng số, khoảng cách này chỉ càng ngày càng doãng ra. Với các nhóm đang chạy mô hình quy mô nghìn tỷ tham số, cái giá của một lần khởi động lại đang chuyển từ "chờ vài phút" thành "gần như không phải chờ", và điều này không chỉ ảnh hưởng tới các con số về khả dụng, mà còn tới việc có dám thường xuyên đổi cấu hình hay dám nhét hai dịch vụ chung một card hay không.
Nguồn tham khảo: blog kỹ thuật LMSYS Org, CocoLoop, tài liệu dự án SGLang; phần bóc tách thời gian khởi động cũng như số liệu so sánh tải trọng số với ánh xạ IPC đều lấy từ bảng benchmark một node do nhóm công bố.