Không tổn hao chất lượng, nhưng không hề miễn phí: Khi nào Speculative Decoding phát huy tác dụng

Speculative Decoding là một chủ đề nóng trong quá trình suy luận (inference) của LLM.

Các công ty như DSpark tuyên bố tốc độ tăng lên từ 60% đến 85%. Google cũng công bố các nghiên cứu về phương pháp này.

Khái niệm này rất đơn giản: Một mô hình nháp (draft model) nhỏ sẽ viết các token. Một mô hình mục tiêu (target model) lớn sẽ xác minh chúng trong một lượt duy nhất. Điều này giúp quá trình tạo (generation) nhanh hơn.

Nhưng với tư cách là một kỹ sư, bạn phải đặt ra hai câu hỏi:

  • Nó có làm tăng hiện tượng ảo giác (hallucinations) không?
  • Mô hình bổ sung có gây lãng phí tài nguyên tính toán (compute) không?

Hãy cùng xem xét các sự thật.

Thứ nhất, chất lượng không bị tổn hao. Mô hình mục tiêu xác minh mọi token. Nếu mô hình nháp mắc lỗi ở token thứ 3, mô hình mục tiêu sẽ bác bỏ và tạo lại từ điểm đó. Kết quả đầu ra về mặt toán học là đồng nhất với việc chỉ sử dụng mô hình mục tiêu. Nó không làm trầm trọng thêm hiện tượng ảo giác.

Thứ hai, chi phí là có thật. Một mô hình nhỏ tốn ít chi phí vận hành hơn nhiều so với một mô hình lớn. Một mô hình 7B có thể chỉ tốn 1/10 chi phí của một mô hình 70B.

Speculative Decoding là một canh bạc.

  • Nếu thành công hoàn toàn (full hit), bạn tiết kiệm được lượng lớn tài nguyên tính toán.
  • Nếu thất bại hoàn toàn (full miss), bạn sẽ lỗ. Bạn phải chạy cả mô hình nháp cộng với các bước bổ sung của mô hình mục tiêu. Điều này còn chậm hơn cả suy luận tiêu chuẩn.

Để chiến thắng, bạn phải tuân theo quy tắc này: Số lượng token được chấp nhận trung bình phải lớn hơn 1 cộng với chi phí vận hành (overhead) của mô hình nháp.

Nếu mô hình nháp của bạn kém ở một tác vụ cụ thể, tỷ lệ chấp nhận (acceptance rate) sẽ giảm xuống. Nếu nó giảm quá thấp, Speculative Decoding sẽ khiến hệ thống của bạn chạy chậm hơn.

Cách quyết định xem bạn có nên sử dụng nó hay không:

  1. Đo lường tỷ lệ chấp nhận của bạn. Đừng tin vào các điểm chuẩn (benchmarks) chung chung. Hãy sử dụng dữ liệu và tác vụ của riêng bạn.
  2. Kiểm tra loại tác vụ. Sử dụng nó cho các tác vụ có thể dự đoán được như hoàn thiện mã nguồn (code completion). Tránh sử dụng cho các tác vụ không thể dự đoán như viết lách sáng tạo.
  3. Theo dõi độ trễ p99. Một lần thất bại hoàn toàn sẽ gây ra sự tăng vọt về độ trễ.

Sự tối ưu hóa tốt nhất không phải là cái luôn luôn chiến thắng. Đó là cái mà bạn biết khi nào nên tắt đi.

Hãy sử dụng nó khi tỷ lệ thành công cao. Hãy ngừng sử dụng khi tỷ lệ thành công sụt giảm.

Nguồn: https://dev.to/zxpmail/lossless-but-not-free-the-lossless-but-not-free-when-speculative-decoding-actually-pays-off-1c2g

Cộng đồng học tập tùy chọn: https://t.me/GyaanSetuAi