Blog / AI / Deep Article
Tìm hiểu cách mô hình AI nhỏ dự đoán token và mô hình lớn xác minh để giảm độ trễ, vì sao không làm thay đổi phân phối và khi nào kỹ thuật này không hiệu quả.
Bạn hỏi một chatbot về một đoạn mã. Chữ đầu tiên xuất hiện khá nhanh, nhưng sau đó câu trả lời dài hàng trăm dòng cứ chảy ra từng chút một. Đã có GPU xử lý hàng nghìn phép tính song song, tại sao AI vẫn phải viết chậm thế nhỉ?
Vấn đề là phần lớn mô hình ngôn ngữ tự hồi quy sinh văn bản bằng cách dự đoán token tiếp theo từ những token đã có. Token không nhất thiết là một từ trọn vẹn; nó có thể là một phần của từ hoặc dấu câu. Token sau cần biết token trước, nên việc sinh một câu dài thường kéo theo nhiều lượt tính toán nối tiếp. GPU mạnh đến đâu cũng không thể bỏ qua quan hệ phụ thuộc ấy chỉ bằng cách tăng số lõi.
Có một cách giải quyết khá khéo: speculative decoding, tức giải mã dự đoán rồi xác minh. Một thành phần nhẹ hơn viết nháp vài token; mô hình lớn kiểm tra cả nhóm trong một lượt. Đây mới là ý tưởng đáng tìm hiểu: tăng tốc mà không nhất thiết phải thay mô hình chính.
Trong mô hình AI, người viết nháp thường là một mô hình nhỏ; người kiểm tra là mô hình đích có năng lực cao hơn. Mô hình nhỏ đề xuất chuỗi token, mô hình lớn tính toán để xác minh các vị trí đó. Phần nháp được chấp nhận mới đi vào đầu ra. Nếu một token bị từ chối, thuật toán xử lý bước lấy mẫu tiếp theo và không mặc nhiên giữ phần nháp phía sau. Chỉ nhìn thấy hai mô hình chạy cùng nhau rồi gọi đó là tăng tốc thì chưa đủ đâu nhé.
Nghiên cứu của Yaniv Leviathan, Matan Kalman và Yossi Matias, được giới thiệu tại ICML 2023, trình bày thuật toán speculative decoding chính xác. Theo trang công bố của Google Research, nhóm tác giả đo được mức tăng tốc 2–3 lần trên thiết lập T5-XXL so với cách triển khai T5X tiêu chuẩn. Con số ấy là kết quả của phép thử cụ thể, chứ không phải lời hứa rằng mọi chatbot hôm nay đều nhanh gấp ba.
Câu hỏi là: mô hình lớn vẫn phải xem toàn bộ bản nháp, vậy chi phí biến mất ở đâu? Thực tế, một lượt chạy mô hình lớn không chỉ tốn phép tính. Nó còn phải truy cập trọng số trong bộ nhớ, điều phối phần cứng và chờ các bước xử lý. Trong một số cấu hình, kiểm tra nhiều vị trí trong cùng lượt tận dụng khả năng song song tốt hơn việc sinh từng token riêng rẽ.
Giả sử mô hình nhỏ đoán năm token. Nếu cả năm phù hợp, hệ thống có thể tiến xa hơn sau một lần xác minh. Nhưng nếu token đầu tiên sai, phần lớn công viết nháp bị bỏ phí. Thực tế là lợi ích phụ thuộc tỷ lệ chấp nhận, tốc độ mô hình nhỏ, bộ nhớ và cách tổ chức GPU. Không phải cứ thêm một mô hình phụ là tự động nhanh hơn, chứ.
Đây là phần dễ bị hiểu nhầm nhất. Nếu thay mô hình lớn bằng mô hình nhỏ, chất lượng hoặc phân phối câu trả lời có thể thay đổi. Nhưng speculative decoding chính xác không trao quyền quyết định cuối cùng cho mô hình nháp. Nó sử dụng quy tắc xác minh và lấy mẫu để bảo toàn phân phối xác suất đầu ra của mô hình đích, trong những điều kiện thuật toán được đáp ứng.
Nói nôm na, mô hình nhỏ được quyền đề xuất, không được quyền chốt. Bài học là tốc độ có thể đến từ cách tổ chức tính toán, chứ không nhất thiết từ việc đánh đổi chất lượng mô hình. Tuy nhiên, bảo toàn phân phối không đồng nghĩa mọi lần chạy đều tạo đúng một chuỗi chữ. Với lấy mẫu ngẫu nhiên, hai lần sinh độc lập vốn có thể khác nhau. Không phải là hệ thống đã biến văn bản thành kết quả cố định đâu nhé.
Một giới hạn nữa: kỹ thuật này không sửa được câu trả lời bịa, thiên lệch hay thiếu nguồn. Nếu mô hình đích có thể trả lời sai, hệ thống vẫn có thể sinh câu trả lời sai nhanh hơn. Đây là vấn đề cần phân biệt khi đánh giá sản phẩm AI, nhất là ứng dụng liên quan tài liệu pháp lý, y tế hoặc tài chính.
Tài liệu Hugging Face Transformers mô tả nhiều dạng assisted decoding. Bản quen thuộc dùng một mô hình nhỏ để đề xuất token. Nhưng còn có prompt lookup decoding: tìm các cụm token lặp lại ngay trong lời nhắc, rồi dùng chúng làm ứng viên. Khi tóm tắt văn bản dài, đầu ra thường lặp từ tài liệu nguồn; cách này có thể hữu ích mà không cần chạy thêm mô hình nháp.
Câu hỏi là nên dùng cách nào cho từng hệ thống? Với lập trình viên làm công cụ tóm tắt hợp đồng, prompt lookup có thể đáng thử vì văn bản đầu ra bám sát đầu vào. Với ứng dụng viết sáng tạo, dự đoán nháp có thể khó trúng hơn. Đó là giả thuyết kỹ thuật cần benchmark (đo hiệu năng) trên dữ liệu thật, không phải kết luận chung cho mọi mô hình.
Hãy xét hai tình huống ở Việt Nam. Một nhóm làm trợ lý chăm sóc khách hàng muốn phản hồi trên điện thoại gần như tức thì. Một nhóm khác dùng AI để tóm tắt hàng nghìn báo cáo mỗi đêm. Nhóm đầu quan tâm thời gian người dùng chờ token tiếp theo; nhóm sau quan tâm tổng số token xử lý mỗi giây và chi phí hạ tầng. Cùng một kỹ thuật có thể tạo ra lợi ích khác nhau.
Vấn đề là các biểu đồ tăng tốc công bố thường đo trên mô hình, phần cứng và tập dữ liệu cụ thể. Muốn biết có đáng dùng trong doanh nghiệp Việt Nam hay không, phải đo chính các loại yêu cầu sẽ phục vụ: câu hỏi tiếng Việt, độ dài tài liệu, số người dùng đồng thời và độ trễ mạng. Một con số đẹp trong bài báo không thể biến một phép đo đơn lẻ thành bằng chứng triển khai thực tế, chứ.
Với đội lập trình viên ở Việt Nam, tôi sẽ ưu tiên ba phép đo: thời gian đến token đầu tiên, thời gian giữa các token tiếp theo và tổng số yêu cầu hoàn thành trong một phút. Sau đó so sánh cùng một mô hình đích, cùng phần cứng và tải tương đương, trước và sau khi bật cơ chế dự đoán. Đấy mới là cách biết phần tăng tốc có thật hay chỉ là cảm giác từ một màn hình trình diễn.
Tài liệu Hugging Face cũng nêu giới hạn triển khai: mô hình trợ giúp thường cần nhỏ hơn đáng kể và dùng cùng tokenizer để hiệu quả; đường speculative decoding được mô tả không hỗ trợ đầu vào xử lý theo lô. Nếu hạ tầng của doanh nghiệp đã tối ưu rất tốt cho xử lý nhiều yêu cầu cùng lúc, thêm cơ chế dự đoán chưa chắc có lợi. Đừng biến một tính năng thành lời cam kết tiết kiệm chi phí nhé.
Chúng ta cũng chưa có cơ sở để suy ra cùng mức tăng tốc cho mọi ngôn ngữ. Câu tiếng Việt có cách phân tách token và mẫu lặp riêng; mức chấp nhận nháp còn tùy mô hình, dữ liệu và câu hỏi. Bài học cho người làm AI tại Việt Nam là đừng lấy kết quả tiếng Anh hoặc một bài benchmark làm đáp án cho toàn bộ nhu cầu địa phương.
Tóm lại, speculative decoding biến quá trình sinh token nối tiếp thành một quy trình có người viết nháp và người xác minh theo nhóm. Nghe như mẹo tổ chức công việc thôi, nhưng phần khó nằm ở phép xác minh xác suất để mô hình nhỏ không làm lệch kết quả. Câu hỏi cuối cùng là: ứng dụng của bạn đang chậm vì bước giải mã, hay vì nguyên nhân khác? Trả lời được câu đó trước, rồi hãy quyết định có nên dùng kỹ thuật này hay không.