Trong bài viết này
Từ được đánh dấu có giải thích. Di chuột hoặc chạm để xem, hay mở từ điển AI.
Một mô hình nhỏ đề xuất bốn token. Mô hình lớn kiểm tra cả đoạn, chấp nhận ba token đầu rồi sửa token thứ tư. Nếu kiểm tra một đoạn rẻ hơn chạy mô hình lớn bốn lần tuần tự, hệ thống có thể sinh nhanh hơn. Điều kiện quan trọng nằm trong cách kiểm tra và xử lý token bị từ chối.
Bạn nên hiểu sinh tự hồi quy, phân bố token và lấy mẫu xác suất. Bài này xét cách speculative decoding có hiệu chỉnh phân bố; các số thời gian và xác suất đều là ví dụ giả định.
Hai mô hình làm hai công việc
Draft model tạo một chuỗi đề xuất bằng các bước rẻ hơn. Target model tính xác suất tại các vị trí của chuỗi đề xuất trong một lượt xử lý có thể tận dụng song song. Hệ thống kiểm tra từ đầu đến cuối, dừng chuỗi chấp nhận ở lần từ chối đầu tiên.
Mô hình lớn không phải chỉ chấm toàn câu “nghe ổn”. Nó phải cung cấp phân bố có điều kiện tại từng vị trí. Những token sau điểm bị sửa đã được đề xuất dưới tiền tố cũ, nên không thể tùy tiện giữ chúng như thể tiền tố không đổi.
Fast Inference from Transformers via Speculative Decoding trình bày thuật toán tăng tốc lấy mẫu mà giữ phân bố của mô hình đích dưới các điều kiện của thuật toán. Kết quả tăng tốc trong paper thuộc mô hình và hệ thống được thử, không phải hệ số có sẵn cho mọi cặp draft/target.
Chấp nhận bằng tỉ lệ, không chỉ bằng argmax
Gọi q là phân bố draft và p là phân bố target tại cùng tiền tố. Một token x được lấy từ q có xác suất chấp nhận min(1, p(x)/q(x)). Nếu q(x) = 0,4 và p(x) = 0,3, token đề xuất được chấp nhận với xác suất 0,75.
Khi bị từ chối, thuật toán lấy mẫu từ phân bố hiệu chỉnh tỉ lệ với max(0, p − q), đã chuẩn hóa. Bước này bù phần mà draft đã đề xuất quá ít. Chỉ bỏ token sai rồi lấy mẫu p một cách tùy tiện không phải cùng thuật toán và có thể làm lệch phân bố.
Xét hai token A, B với q = [0,4; 0,6], p = [0,3; 0,7]. A được đề xuất với xác suất 0,4 và chấp nhận 0,75, tạo xác suất cuối 0,3. B luôn được chấp nhận khi đề xuất; phần A bị từ chối chuyển sang B. Tổng của B là 0,6 + 0,1 = 0,7, khớp p.
Cùng phân bố không có nghĩa cùng chuỗi mỗi lần
Hai chương trình lấy mẫu đúng cùng phân bố vẫn có thể tạo chuỗi khác nhau do cách dùng số ngẫu nhiên. Cam kết về phân bố không nên được diễn đạt thành luôn trùng từng ký tự với lần chạy thường. Giải mã tham lam có cách kiểm tra khác với lấy mẫu ngẫu nhiên.
Mô hình tự hồi quy tính xác suất token tiếp theo từ ngữ cảnh hiện có, chọn một token rồi nối vào chuỗi. Chuỗi mới trở thành ngữ cảnh cho lượt tiếp theo.
↔ Vuốt ngang để xem toàn bộ sơ đồ.
01 / Đọc ngữ cảnh
Mô hình xử lý các token của yêu cầu và phần trả lời đã có.
02 / Tính xác suất
Từ ngữ cảnh đó, mô hình tính phân bố xác suất cho những token có thể xuất hiện tiếp theo.
03 / Chọn token
Cách giải mã quyết định token được chọn; không phải lúc nào cũng lấy token có xác suất cao nhất.
04 / Nối và lặp
Token được nối vào chuỗi để tạo ngữ cảnh mới. Quá trình lặp đến điều kiện dừng.
Các ô dùng từ nguyên vẹn để dễ quan sát; đây không phải kết quả của một tokenizer cụ thể. Token thực tế có thể chỉ là một phần của từ.
Sơ đồ cho thấy vòng sinh token tự hồi quy. Nó không có nhánh draft, xác suất chấp nhận hay phân bố hiệu chỉnh. Hãy đặt bước đề xuất và xác minh vào trong vòng ấy, giữ nguyên điều kiện tiền tố ở mỗi vị trí.
Các biến đổi như temperature, top-k hoặc top-p phải được xử lý nhất quán với phân bố mục tiêu của thuật toán. Tokenizer và miền token của hai mô hình cũng cần cơ chế tương thích; không thể mặc định hai ID có cùng ý nghĩa chỉ vì đều là số nguyên.
Khi thời gian tiết kiệm bị chi phí ăn hết
Lấy ví dụ giả định: bốn bước target tuần tự mất 40 mili giây. Draft tốn 6 mili giây và lượt xác minh tốn 14 mili giây. Nếu mỗi vòng thực sự đưa ra trung bình bốn token hữu ích, thời gian theo ví dụ giảm từ 40 xuống 20 mili giây.
Nhưng nếu chỉ một token thường được chấp nhận, phần đề xuất còn lại bị bỏ và chi phí kiểm tra khó được bù. Draft quá lớn, dữ liệu truyền giữa thiết bị hoặc tải batch đã bão hòa cũng có thể khiến phương pháp không nhanh hơn.
Đo số token hữu ích mỗi lượt, tỉ lệ chấp nhận, độ trễ đến token đầu và thông lượng dưới tải thật. Tỉ lệ chấp nhận cao là tín hiệu tốt nhưng chưa đủ: draft chậm vẫn có thể làm toàn bộ hệ thống chậm.
Bài tập: chứng minh lại một phân bố hai token
Đổi q thành [0,8; 0,2], giữ p = [0,3; 0,7]. Tính xác suất chấp nhận A và phân bố hiệu chỉnh khi A bị từ chối. Bạn phải nhận 0,375 và toàn bộ phần hiệu chỉnh nằm ở B.
Sau đó cộng xác suất các đường đi để thu lại [0,3; 0,7]. Tiêu chí hoàn thành là giải thích được vì sao “chỉ giữ token top-1 của target” không thay thế phép lấy mẫu này. Đọc KV cache để hiểu trạng thái cần được quản lý khi tiền tố được chấp nhận hoặc sửa.