Một bộ lập lịch ưu tiên ba lớp giúp giảm độ trễ của mô hình ngôn ngữ trên thiết bị từ hơn một giây xuống còn dưới 0,2 giây, giúp các ứng dụng chat luôn phản hồi nhanh ngay cả khi điện thoại đang bận xử lý các tác vụ chạy ngầm. Được xây dựng cho chip Tensor G3 chạy mô hình 3 tỷ tham số, nó cắt giảm độ trễ từ 1.420 ms xuống còn 161 ms mà không làm gián đoạn các tác vụ chạy ngầm.
Tại sao các LLM trên thiết bị gặp khó khăn
Chạy một mô hình ngôn ngữ lớn trên bộ vi xử lý di động là một sự thắt chặt về tài nguyên. Trên Tensor G3, mô hình 3B đã chiếm khoảng 85% đơn vị xử lý thần kinh (NPU). Khi một tác vụ ưu tiên thấp—chẳng hạn như trình lập chỉ mục ngoại tuyến—chạy cùng lúc với việc người dùng mở cửa sổ chat, thời gian phản hồi cảm nhận được sẽ tăng từ khoảng 140 ms lên 1.400 ms, một sự chậm trễ gấp 10 lần mà người dùng có thể nhận thấy ngay lập tức.
Vấn đề không chỉ là tốc độ. Các thiết bị di động phải cân bằng giữa độ mượt của giao diện người dùng (UI), thời lượng pin và nhiều ứng dụng cùng yêu cầu tính toán. Một hàng đợi đơn giản xử lý các tác vụ theo thứ tự sẽ buộc luồng UI phải chờ đợi các công việc chạy ngầm, biến một trợ lý hội thoại thành một trải nghiệm chậm chạp.
Cách bộ lập lịch ba lớp hoạt động
Bộ lập lịch mới chèn ba thành phần phối hợp vào quy trình suy luận (inference pipeline):
- Priority Queue (Hàng đợi ưu tiên) – một min-heap sắp xếp các tác vụ đến theo mức độ quan trọng cố định.
- Preemption Controller (Bộ điều khiển chiếm quyền) – khi một yêu cầu có ưu tiên cao hơn đến, nó sẽ tạm dừng các tác vụ ưu tiên thấp hơn thay vì hủy bỏ chúng.
- Token Budget Governor (Bộ quản lý ngân sách token) – giới hạn số lượng token mà một tác vụ có thể tạo ra dựa trên trạng thái vòng đời của ứng dụng.
Cùng nhau, chúng cho phép một yêu cầu chat ở tiền cảnh (foreground) nhảy lên đầu hàng, trong khi các tác vụ chạy ngầm tạm dừng ở trạng thái chờ (parked state), sẵn sàng tiếp tục khi tài nguyên được giải phóng.
Các cấp độ ưu tiên và việc chiếm quyền
Bốn cấp độ xác định những gì có thể bị gián đoạn:
| Cấp độ | Mô tả |
|---|---|
| Chat tiền cảnh | Tương tác UI quan trọng |
| Gợi ý trực tiếp | Các gợi ý kiểu tự động hoàn tất |
| Tóm tắt chạy ngầm | Tóm tắt nội dung định kỳ |
| Lập chỉ mục ngoại tuyến | Xử lý dữ liệu hàng loạt |
Bộ lập lịch không bao giờ hủy bỏ một tác vụ ưu tiên thấp. Thay vào đó, nó chụp nhanh (snapshot) bộ nhớ đệm key-value (KV cache) của mô hình—một cấu trúc lưu giữ các kết quả attention trung gian—và tạm dừng tác vụ đó. Khi yêu cầu ưu tiên cao hoàn tất, bộ điều khiển sẽ khôi phục bản snapshot và để tác vụ chạy ngầm tiếp tục từ nơi nó đã dừng lại. Cách tiếp cận "tạm dừng và tiếp tục" này giúp tránh việc tính toán lại tốn kém vốn sẽ xảy ra nếu tác vụ được khởi động lại từ đầu.
Việc loại bỏ một phần KV-cache (partial KV-cache eviction) giúp cắt giảm thêm lãng phí. Prompt hệ thống tĩnh sẽ được giữ lại trong bộ nhớ đệm, trong khi chỉ các lượt hội thoại động bị loại bỏ. Kết quả là giảm 40%–60% chi phí nạp lại (re-prefilling) mô hình sau khi tạm dừng.
Quản lý ngân sách token mà không cần bộ hẹn giờ
Nhiều triển khai dựa vào bộ hẹn giờ (timers) để đoán khi nào một tác vụ nên nhường thời gian CPU hoặc NPU. Bộ hẹn giờ rất thiếu linh hoạt; chúng có thể khiến UI bị "đói" tài nguyên hoặc làm lãng phí hiệu suất chip. Bộ lập lịch thay thế bộ hẹn giờ bằng ProcessLifecycleOwner của Android, thứ phát ra các sự kiện vòng đời giúp chỉ ra một cách đáng tin cậy khi nào ứng dụng đang ở tiền cảnh hoặc chạy ngầm.
- ON_RESUME – ứng dụng lấy lại toàn bộ ngân sách tính toán, cho phép các tác vụ tiền cảnh đang chờ được chạy không bị cản trở.
- ON_STOP – ứng dụng giới hạn các tác vụ chạy ngầm xuống còn khoảng 25% ngân sách token thông thường, nhằm dành sẵn tài nguyên cho bất kỳ yêu cầu UI đột xuất nào.
Bằng cách gắn việc phân bổ tài nguyên với các sự kiện vòng đời, hệ thống phản ứng với hành vi thực tế của người dùng thay vì các lát cắt thời gian tùy ý.
Hiệu quả đạt được và sự đánh đổi
Với hàng đợi "đến trước phục vụ trước" (first-come-first-served) đơn giản, một tác vụ chạy ngầm sẽ đẩy độ trễ chat tiền cảnh lên khoảng 1.420 ms. Khi bộ lập lịch ưu tiên hoạt động, cùng một yêu cầu chat đó hoàn tất trong khoảng 161 ms, một sự cải thiện gấp 10 lần giúp khôi phục trải nghiệm người dùng mượt mà.
Việc tiếp tục một tác vụ đã tạm dừng làm tăng khoảng 22% tổng thời gian thực thi của nó. Vì công việc chạy ngầm không mang tính tới hạn, sự đánh đổi này vẫn có thể chấp nhận được, đặc biệt là khi giao diện UI vẫn hoạt động nhanh nhạy.