Khi một ứng dụng LLM bắt đầu có nhiều người dùng, chi phí và độ trễ thường tăng nhanh hơn dự kiến. Nguyên nhân không chỉ nằm ở giá mỗi token, mà còn ở việc gửi lại cùng một yêu cầu, chọn mô hình quá lớn cho tác vụ đơn giản và xử lý từng request riêng lẻ. Một pipeline suy luận được thiết kế tốt có thể giảm lãng phí mà không cần thay đổi ngay mô hình chính. 1. Đo lường trước khi tối ưu Trước tiên, hãy ghi nhận các chỉ số theo từng loại request: - Số token đầu vào và đầu ra. - Thời gian chờ từ lúc nhận yêu cầu đến khi có token đầu tiên. - Tổng thời gian hoàn tất. - Tỷ lệ lỗi, timeout và số lần retry. - Chi phí ước tính trên mỗi tác vụ thành công. - Tỷ lệ câu trả lời đạt yêu cầu qua bộ kiểm thử nội bộ. Nên phân loại request theo mục đích, chẳng hạn tóm tắt, trích xuất thông tin, trả lời câu hỏi và viết nội dung. Một mô hình lớn có thể cần thiết cho nhiệm vụ suy luận phức tạp, nhưng không nhất thiết phù hợp với mọi nhóm tác vụ. 2. Caching: không tính tiền cho cùng một công việc hai lần Exact cache lưu kết quả dựa trên chuỗi đầu vào đã chuẩn hóa. Cách này phù hợp với các yêu cầu lặp lại gần như giống hệt, ví dụ tra cứu chính sách cố định hoặc sinh nội dung từ cùng một mẫu. Khóa cache nên bao gồm phiên bản prompt, tên mô hình, tham số suy luận và phiên bản dữ liệu liên quan. Nếu thiếu các thành phần này, hệ thống có thể trả về kết quả cũ sau khi prompt hoặc mô hình đã thay đổi. Semantic cache tìm những yêu cầu có ý nghĩa tương tự thay vì chỉ so sánh chuỗi ký tự. Tuy nhiên, không nên bật cơ chế này một cách mù quáng. Hai câu hỏi gần nghĩa vẫn có thể khác về thời hạn, quyền truy cập hoặc đối tượng áp dụng. Với dữ liệu nhạy cảm, cần phân tách cache theo người dùng, tổ chức hoặc phạm vi quyền hạn. Các câu trả lời phụ thuộc vào dữ liệu thời gian thực cũng nên có thời gian sống ngắn hoặc bị loại khỏi semantic cache. 3. Batching: tận dụng tài nguyên khi có nhiều request Batching gộp nhiều yêu cầu tương thích vào một lần xử lý. Đây là lựa chọn hữu ích cho các tác vụ ngoại tuyến như phân loại hàng nghìn đoạn văn, tạo embedding hoặc chấm điểm dữ liệu. Đổi lại, batching có thể làm tăng thời gian chờ của request đầu tiên nếu hệ thống cố đợi đủ một lô. Với API tương tác, có thể dùng micro-batching: gom request trong một khoảng thời gian rất ngắn, sau đó xử lý khi đạt số lượng tối đa hoặc hết thời gian chờ. Hai tham số cần theo dõi là kích thước lô và thời gian chờ gom. Không nên tối ưu thông lượng bằng cách khiến trải nghiệm hội thoại trở nên chậm rõ rệt. 4. Định tuyến theo độ khó Một bộ định tuyến đơn giản có thể gửi câu hỏi ngắn, yêu cầu định dạng rõ ràng hoặc tác vụ trích xuất sang mô hình nhỏ hơn; các yêu cầu cần nhiều bước suy luận, xử lý văn bản dài hoặc đòi hỏi chất lượng cao mới chuyển sang mô hình lớn. Quy tắc định tuyến có thể bắt đầu bằng các tín hiệu dễ giải thích như độ dài đầu vào, loại tác vụ, ngôn ngữ và mức độ nhạy cảm. Sau đó, nhóm phát triển có thể huấn luyện một bộ phân loại nhẹ để dự đoán mô hình nào đủ khả năng xử lý. Mọi thay đổi về router cần được kiểm tra trên cùng một bộ dữ liệu đánh giá, vì việc giảm chi phí nhưng làm tăng câu trả lời sai sẽ không phải là tối ưu thực sự. 5. Giảm token nhưng không cắt thông tin quan trọng Hãy loại bỏ hướng dẫn trùng lặp, giới hạn lịch sử hội thoại theo chính sách rõ ràng và yêu cầu đầu ra có cấu trúc khi bài toán chỉ cần vài trường dữ liệu. Với tài liệu dài, có thể tóm tắt các lượt trao đổi cũ rồi giữ lại những chi tiết cần thiết cho phiên hiện tại. Tuy vậy, việc nén ngữ cảnh phải được đánh giá bằng các câu hỏi cần tham chiếu đến thông tin xa trong hội thoại; nếu không, hệ thống có thể tiết kiệm token nhưng bỏ mất dữ kiện quan trọng. 6. Một kiến trúc triển khai thực tế Luồng xử lý có thể gồm các bước: chuẩn hóa request, kiểm tra quyền truy cập, tra exact cache, quyết định có dùng semantic cache hay không, định tuyến sang mô hình phù hợp, gọi mô hình với timeout, ghi log chi phí và chất lượng, rồi lưu kết quả nếu đáp ứng điều kiện cache. Log không nên chứa nguyên văn dữ liệu nhạy cảm nếu không cần thiết. Nên lưu mã định danh đã băm, kích thước token, phiên bản prompt và kết quả kiểm tra thay vì toàn bộ nội dung. Danh sách kiểm tra trước khi áp dụng: - Có bộ dữ liệu đại diện cho từng loại tác vụ. - Có ngưỡng chất lượng tối thiểu cho mỗi tuyến mô hình. - Có cơ chế vô hiệu hóa cache khi dữ liệu hoặc prompt thay đổi. - Có giới hạn token, timeout và ngân sách theo người dùng hoặc ứng dụng. - Có dashboard theo dõi chi phí, độ trễ và tỷ lệ lỗi. - Có thử nghiệm tải để kiểm tra hành vi khi lưu lượng tăng. Tối ưu suy luận không nên bắt đầu bằng việc chọn mô hình rẻ nhất. Cách bền vững hơn là đo lường, loại bỏ các lần gọi lặp lại, xử lý theo lô khi phù hợp và chỉ dùng mô hình lớn cho phần việc thật sự cần nó. Khi mỗi quyết định đều gắn với chỉ số chất lượng, nhóm phát triển có thể giảm chi phí mà vẫn giữ được trải nghiệm và độ tin cậy của sản phẩm.