Giảm độ trễ và chi phí LLM: bốn đòn bẩy và thứ tự nên dùng

Thử hình dung bạn đang ở tuần thứ ba tại khách hàng. Trợ lý tra cứu chính sách nội bộ bạn dựng đã trả lời đúng, nhóm nghiệp vụ hài lòng. Rồi trưởng phòng vận hành nhắn hai dòng: nhân viên than phải chờ lâu, và hoá đơn API tháng này vượt xa dự tính.

Phản xạ của nhiều kỹ sư là đổi ngay sang model nhỏ hơn. Cách đó có thể đúng, nhưng thường sai thứ tự. Có bốn đòn bẩy để giảm độ trễ và chi phí, cái nào cũng có giá phải trả riêng, và FDE giỏi là người biết kéo cái nào trước.

Đây là kỹ năng khách hàng thấy rõ nhất sau giai đoạn demo. Một hệ thống chạy đúng nhưng chậm và đắt sẽ khó qua được vòng duyệt ngân sách, dù chất lượng tốt đến đâu.

Vì sao phải chạy đúng trước rồi mới chạy nhanh?

Tài liệu hướng dẫn của Anthropic nói thẳng: nên thiết kế một prompt chạy tốt khi chưa bị ràng buộc gì về model hay prompt, rồi sau đó mới áp dụng các chiến lược giảm độ trễ. Lý do là tối ưu quá sớm có thể che mất mức chất lượng tối đa mà bài toán đạt được.

Vì thế, trước khi tối ưu, bạn cần một bộ eval nhỏ, chẳng hạn vài chục câu hỏi thật của khách kèm đáp án mong muốn. Không có nó, bạn không biết một thay đổi làm hệ thống nhanh hơn có đang âm thầm làm nó sai đi hay không.

Bốn đòn bẩy, mỗi cái kéo một thứ khác nhau

Đòn bẩy thứ nhất là bớt token, vì theo Anthropic, model càng ít token phải xử lý và sinh ra thì phản hồi càng nhanh. OpenAI đưa ra một quy tắc kinh nghiệm đáng nhớ: cắt 50% token đầu ra có thể cắt khoảng 50% độ trễ. Cách làm là yêu cầu câu trả lời ngắn hơn, có cấu trúc, và đặt max_tokens làm chốt chặn.

Đòn bẩy thứ hai là prompt caching. Khi phần đầu prompt lặp lại giữa các lời gọi, nhà cung cấp lưu lại phần đã xử lý, giúp giảm cả thời gian lẫn chi phí. Ở Anthropic, token đọc từ cache có giá bằng 0,1 lần giá input cơ bản; OpenAI cho biết giá input token đã cache giảm tới 95%.

Đòn bẩy thứ ba là chọn model phù hợp. Anthropic gọi đây là một trong những cách trực tiếp nhất để giảm độ trễ, còn OpenAI ghi nhận model nhỏ thường vừa chạy nhanh hơn vừa rẻ hơn. Đổi lại, đây là đòn bẩy dễ làm tụt chất lượng nhất nếu đổi mà không kiểm chứng.

Đòn bẩy thứ tư là Batch API của OpenAI: giảm 50% chi phí, đổi lại mỗi batch hoàn thành trong vòng 24 giờ, thường nhanh hơn. Nó chỉ hợp với việc không cần phản hồi ngay, và có rate limit tách biệt khỏi rate limit theo model.

Streaming không nằm trong bốn đòn bẩy trên, vì nó không rút ngắn tổng thời gian cũng không giảm chi phí. Nó là đòn bẩy về cảm nhận: người dùng thấy chữ hiện ra theo thời gian thực, nên ứng dụng có cảm giác nhanh hơn hẳn.

Tính tay một ví dụ: trợ lý tra cứu chính sách

Quay lại trợ lý ở đầu bài. Giả sử mỗi request gồm 10.000 token cố định (hướng dẫn hệ thống cộng tài liệu chính sách) và 200 token câu hỏi. Trong giờ cao điểm có 20 câu hỏi rơi vào cùng một khung 5 phút.

Không có cache, bạn trả 20 × 10.200 = 204.000 đơn vị giá input. Có cache trên Anthropic, lần đầu ghi cache 10.000 token với giá 1,25 lần, tức 12.500 đơn vị.

Mười chín lần sau đọc cache với giá 0,1 lần, tức 19 × 1.000 = 19.000 đơn vị. Cộng thêm 4.000 đơn vị cho phần câu hỏi, tổng là 35.500 đơn vị, chưa bằng một phần năm con số ban đầu.

Điều kiện để có con số đó là prompt phải được sắp đúng. OpenAI yêu cầu toàn bộ prefix phải khớp thì mới dùng lại được cache, và khuyên đặt hướng dẫn ổn định cùng tài liệu tham khảo dùng chung lên đầu. Bố cục nên trông như sau:

[1] Hướng dẫn hệ thống   (cố định)
[2] Tài liệu chính sách  (cố định)
---- hết phần cache ----
[3] Câu hỏi người dùng   (thay đổi)

Tiếp theo là đầu ra. Nếu câu trả lời trung bình dài 400 token mà người dùng chỉ cần kết luận cộng điều khoản trích dẫn, việc yêu cầu định dạng gọn còn khoảng 200 token có thể giảm gần một nửa thời gian sinh, theo quy tắc kinh nghiệm của OpenAI.

Còn việc tóm tắt toàn bộ câu hỏi trong ngày cho nhóm nghiệp vụ thì không ai phải ngồi chờ. Việc kiểu này rất hợp để chuyển sang Batch API: tiết kiệm một nửa chi phí mà không ảnh hưởng tới rate limit của trợ lý đang chạy.

Thứ tự nên dùng

Nguyên tắc sắp xếp: đòn bẩy nào ít rủi ro cho chất lượng thì làm trước, đòn bẩy nào cần eval để chứng minh thì làm sau. Bảng dưới có sáu bước vì ngoài bốn đòn bẩy còn có bước dựng mốc ở đầu, và streaming được chen vào giữa như một đòn bẩy cảm nhận gần như không rủi ro.

Bước	Việc cần làm	Giảm gì	Điều kiện
1	Làm prompt chạy đúng, dựng eval	Chưa giảm gì, chỉ lấy mốc	Có câu hỏi thật của khách
2	Cắt token đầu ra, đặt max_tokens	Độ trễ và chi phí	Câu trả lời ngắn vẫn đủ ý
3	Cache phần prompt cố định	Chi phí input và thời gian xử lý	Prefix ổn định, lưu lượng đều
4	Bật streaming (đòn bẩy cảm nhận)	Độ trễ cảm nhận, không giảm chi phí	Có người dùng đang chờ
5	Đổi sang model nhỏ hơn	Độ trễ và chi phí	Eval không tụt
6	Đẩy việc không gấp sang batch	Chi phí	Chấp nhận chờ tới 24 giờ

Những lỗi khiến tối ưu phản tác dụng

Lỗi phổ biến nhất là phá cache mà không biết. Chỉ cần chèn ngày giờ hiện tại hay tên người dùng vào dòng đầu prompt là prefix không còn khớp, và mọi request đều phải xử lý lại từ đầu.

Lỗi thứ hai là bật cache cho lưu lượng thưa. TTL mặc định của Anthropic là 5 phút; nếu các request cách nhau lâu hơn, mọi lời gọi đều trả giá ghi 1,25 lần mà không được đọc lần nào, đắt hơn cả không cache. TTL 1 giờ ghi gấp 2 lần, chỉ đáng dùng khi chắc chắn đọc lại nhiều.

Lỗi thứ ba là coi streaming như cách giảm tổng thời gian, rồi dùng nó cho một pipeline backend chờ toàn bộ kết quả. Ở đó không có ai nhìn chữ hiện ra, nên streaming không mang lại gì.

Lỗi thứ tư là đổi model chỉ dựa trên vài lần thử bằng tay. Một model nhỏ có thể trả lời tốt mười câu bạn nghĩ ra nhưng sai ở đúng loại câu hỏi khách hỏi nhiều nhất. Cũng đừng đẩy tác vụ có người dùng chờ sang batch chỉ vì nó rẻ một nửa.

OpenAI còn nhắc một nguyên tắc dễ quên: đừng mặc định dùng LLM. Nếu một bước chỉ là trích mã số hợp đồng theo mẫu cố định, một biểu thức chính quy vừa nhanh hơn vừa không tốn đồng nào.

Khách hàng hiếm khi nhớ bạn dùng model nào; họ nhớ hệ thống trả lời nhanh hơn, hoá đơn giảm mà chất lượng không tụt. Vì thế, khi đưa việc này vào CV, hãy ghi đúng kết quả đã đo kèm cách kiểm chứng, kiểu “giảm chi phí input bằng cách sắp lại prompt cho trúng cache, kiểm chứng bằng eval”.