Speculative decoding trong LM Studio: 23 lên 29 token/giây

Bạn tải model 8B về máy, gõ một câu hỏi, rồi ngồi nhìn chữ bò ra từng dòng. Câu trả lời đúng, nhưng chậm tới mức bạn quay lại gọi API cloud cho xong việc. Speculative decoding là công tắc có sẵn trong LM Studio và llama.cpp: cấu hình mất chưa tới mười phút, và theo cơ chế của nó, chất lượng đầu ra không đổi.

Speculative decoding làm gì

Model ngôn ngữ sinh từng token một. Token thứ hai phải đợi token thứ nhất, token thứ ba đợi token thứ hai. Bản tổng hợp kỹ thuật này chỉ ra điểm mấu chốt: kiểu sinh đó nghẽn ở băng thông bộ nhớ, không nghẽn ở sức tính toán — GPU còn rỗi nhưng phải chờ dữ liệu chạy qua bộ nhớ. Ngược lại, khi xử lý prompt, model tính xác suất cho mọi vị trí cùng lúc được.

Speculative decoding khai thác đúng khoảng chênh đó. Một model draft nhỏ đoán trước k token; model chính nạp cả k token vào một forward pass để kiểm, vì lúc đó nó đã có sẵn chuỗi token trong tay. Kiểm từ trái sang phải, giữ lại đoạn đúng liền mạch, rồi model chính tự sinh token kế tiếp.

Chất lượng giữ nguyên nhờ một ràng buộc trong thuật toán: model chính chỉ nhận token trùng với thứ chính nó sẽ sinh ra, và sau token draft cuối cùng được chấp nhận, nó luôn sinh thêm một token nữa.

Bật trong LM Studio: hai bước

Quy trình dưới đây theo mô tả của tác giả bài XDA, bổ sung từ tài liệu chính thức LM Studio. Anh ghi nhận hai bước này mất chưa tới mười phút, tính từ lúc đã tải xong cả hai model.

1. Tải về hai model cùng họ. Tác giả dùng Llama 3.1 8B làm model chính và Llama 3.2 1B làm model draft.
2. Trỏ model chính tới model draft. Vào My Models, chọn Edit Model Default Config ở model chính, rồi đi theo Load → Advanced → Speculative Decoding, đổi từ Off sang Draft Model và chọn Llama 3.2 1B Instruct (Q8_0).

Ba tham số còn lại, tác giả để nguyên: Max draft tokens = 3, Min draft tokens = 0, Draft probability = 0. Bấm Load Model và tick Remember settings.

Một chi tiết bài XDA không nhắc tới nhưng tài liệu LM Studio có: phải bật chế độ Power User trở lên thì tùy chọn này mới hiện trong thanh bên của màn hình chat. Nếu bạn dò mãi không thấy menu, đây gần như luôn là lý do.

Chọn cặp model: cùng tokenizer, khác cỡ

Ràng buộc cứng: model draft phải dùng cùng vocabulary với model chính, nên trên thực tế nó phải là cùng một dòng model ở kích thước nhỏ hơn. Tài liệu LM Studio liệt kê ba cặp dùng được:

Model chính	Model draft
Llama 3.1 8B Instruct	Llama 3.2 1B Instruct
Qwen 2.5 14B Instruct	Qwen 2.5 0.5B Instruct
DeepSeek R1 Distill Qwen 32B	DeepSeek R1 Distill Qwen 1.5B

Điều kiện thứ hai: model draft phải nhỏ hơn model chính rõ rệt. Chọn draft quá lớn là hỏng toàn bộ mục đích, vì bước draft phải nhanh và nhẹ thì phần tiết kiệm mới còn lại.

Con số thực đo: 23,35 lên 29,46 token/giây

Tác giả bài XDA dùng cùng một prompt, cùng mọi cấu hình, bật rồi tắt speculative decoding, chạy mỗi kiểu ba lần sau khi đã warm up model. Kết quả anh ghi lại: 23,35 token/giây khi tắt, 29,46 token/giây với Llama 3.2 1B làm draft — tăng khoảng 26%.

Anh nói thẳng rằng sáu token mỗi giây nghe không nhiều, nhưng cộng dồn qua câu trả lời dài và hội thoại nhiều lượt thì thấy rõ. Hai điểm cần giữ khi đọc con số này: nó đo trên máy cá nhân của tác giả, không phải phần cứng lab, và nó gắn với đúng cặp Llama 3.1 8B + Llama 3.2 1B đó. Đây là bản ghi thí nghiệm, không phải mức tăng được bảo đảm.

Khi nào không nên bật

Speculative decoding đánh đổi bộ nhớ lấy tốc độ. Model draft và cache của nó ăn thêm RAM và sức tính toán. Nếu model chính đã dùng gần hết phần cứng của bạn, bật thêm sẽ làm chậm đi chứ không nhanh lên. Đây là cái bẫy dễ gặp nhất trên máy đã chạy sát trần bộ nhớ.

Ràng buộc thứ hai quan trọng với ai serve model cho nhiều người: đây là kỹ thuật giảm độ trễ, không phải tăng throughput. Lợi ích đến từ giai đoạn công việc nghẽn bộ nhớ; khi batch lớn dần tới mức nghẽn sức tính toán, lợi thế đó biến mất, và trên server vốn đã đầy tải nó có thể làm mọi thứ chậm hơn.

Không đủ RAM cho model thứ hai?

Tài liệu llama.cpp còn vài kiểu draft không cần nạp thêm model nào. Kiểu thống kê n-gram lưu thống kê của các chuỗi token ngắn rồi dự đoán dựa trên những token đã xuất hiện trong ngữ cảnh trước đó, và về bộ nhớ thì gần như miễn phí. Còn có kiểu dùng hash mà tài liệu mô tả là rất nhẹ: khoảng 16 MB bộ nhớ cố định, dùng chung pool hash cho mọi slot của server nên các request khác nhau hưởng lợi lẫn nhau.

Kiểu n-gram hợp nhất với công việc có mẫu lặp lại nhiều: sửa code trên đoạn văn bản cũ, model phải nhắc lại chuỗi suy luận trong câu trả lời cuối, và tác vụ tóm tắt. Máy chật thì thử kiểu này trước.

EAGLE-3 và con số 6,5 lần

EAGLE (Extrapolation Algorithm for Greater Language-model Efficiency) làm việc ở mức feature thay vì mức token: thay vì đoán token, nó đoán hidden state rồi dùng LM head đã đóng băng của model chính để chuyển state đó thành token. Bản thứ ba đổi hai thứ — quay lại dự đoán token trực tiếp, và hợp nhất feature từ nhiều tầng thay vì chỉ tầng trên cùng.

Paper EAGLE-3 công bố mức tăng tốc tới 6,5 lần, hơn EAGLE-2 khoảng 1,4 lần, và trong framework SGLang đạt throughput cao hơn 1,38 lần ở batch size 64. Một bài phân tích vận hành khác ghi nhận EAGLE-3 đẩy tỷ lệ chấp nhận α lên khoảng 0,6-0,8 cho hội thoại thông thường. Đây là số của nhóm nghiên cứu trên tác vụ họ chọn — chính tài liệu cũng lưu rằng nó không bảo đảm cho mọi workload.

Cái giá là ràng buộc ghép cặp chặt hơn: draft model EAGLE-3 phải được train riêng cho đúng model đích, ví dụ Qwen3-4B_eagle3 đi với Qwen/Qwen3-4B. Tài liệu còn ghi DSpark hiện chỉ hỗ trợ draft có backbone Qwen3.

Việc cần làm tiếp

Thứ tự rẻ tiền nhất: thử kiểu n-gram trước vì nó không tốn thêm bộ nhớ; nếu chưa đủ thì thêm model draft thường; nếu bạn đang chạy Qwen hoặc Llama phổ biến thì tìm draft model EAGLE-3 đã có người train sẵn. Và ở mỗi bước, đo bằng đúng prompt cũ với hai trạng thái bật/tắt. Trần tốc độ thật nằm ở tỷ lệ chấp nhận trên workload của bạn, không nằm ở workload của người viết benchmark.