Cách Cloudflare giảm 68% chi phí đánh giá AI nhờ lưu trữ prompt
Cloudflare đã giảm chi phí cho công cụ đánh giá mã nguồn bằng AI từ $2,46 xuống còn $0,77 mỗi lần đánh giá thông qua việc tối ưu hóa lưu trữ prompt, giảm số lượng gọi LLM và chuyển đổi mô hình.
Được dịch tự động từ bản gốc tiếng Anh.
Các kỹ sư của Cloudflare đã thành công trong việc giảm 68% chi phí trung bình cho các quy trình đánh giá mã nguồn bằng AI, từ $2,46 xuống chỉ còn $0,77 mỗi lần. Chiến dịch tối ưu hóa này, được thực hiện từ giữa tháng 9 đến đầu tháng 10 năm 2026, cũng giúp cắt giảm thời gian đánh giá trung vị từ hơn bốn phút xuống dưới hai phút mà không làm suy giảm chất lượng phát hiện lỗi.
Chuyện gì đã xảy ra
Vào đầu năm nay, chi phí cho công cụ đánh giá mã nguồn bằng AI của Cloudflare đã tăng vọt bất chấp kiến trúc hệ thống vẫn ổn định. Vào tháng 4, chi phí trung bình cho một lần đánh giá là $1,19, nhưng đến cuối tháng 8, con số này đã tăng gấp đôi lên khoảng $2,46. Nhóm kỹ sư xác định hai nguyên nhân chính dẫn đến sự gia tăng này: độ phức tạp ngày càng cao của các thay đổi mã nguồn do kỹ sư gửi lên, khiến nhiều công việc bị đẩy vào các cấp độ đánh giá toàn diện tốn kém, và quyết định chiến lược chuyển sang sử dụng các mô hình của Anthropic với hiệu suất tốt hơn nhưng giá thành cao hơn. Cụ thể, việc chuyển sang Claude Opus 4.7 để kiểm tra tiêu chuẩn nội bộ đã làm tăng chi phí của riêng thành phần đó từ $0,25 lên $0,88 mỗi lần đánh giá.
Vào giữa tháng 9, nhóm đã khởi động một sáng kiến tối ưu hóa mạnh mẽ. Họ phân tích các mẫu sử dụng token và phát hiện rằng mặc dù tỷ lệ trúng cache (cache hit rate) rất cao, nhưng khối lượng lớn token được xử lý mới là yếu tố đẩy hóa đơn lên cao. Đến đầu tháng 10, sau khi triển khai hàng loạt thay đổi ở cấp độ cấu trúc và mô hình, chi phí trung bình đã giảm xuống còn $0,77. Điều này tương ứng với mức giảm 68% so với những tuần đỉnh điểm về chi tiêu. Đồng thời, thời lượng đánh giá trung vị giảm từ 4 phút 9 giây xuống còn 1 phút 32 giây, cải thiện đáng kể trải nghiệm của nhà phát triển bên cạnh hiệu quả tài chính.
Cơ chế hoạt động
Đột phá kỹ thuật cốt lõi liên quan đến việc tái tư duy cách hệ thống tận dụng tính năng lưu trữ prompt (prompt caching) của Anthropic. Prompt caching cho phép các mô hình ngôn ngữ lớn lưu trữ các tiền tố đã tính toán của cuộc hội thoại, giúp tái sử dụng rẻ hơn cho các yêu cầu tiếp theo. Tuy nhiên, Cloudflare phát hiện rằng cách triển khai ban đầu của họ không chia sẻ dữ liệu cache giữa các repository khác nhau. Prompt hệ thống bao gồm các chi tiết đặc thù của repository như thư mục làm việc và ngày tháng trước điểm ngắt cache, nghĩa là mỗi phiên mới đều bắt đầu với trạng thái bỏ lỡ cache (cache miss). Bằng cách tách prompt hệ thống và đặt một marker cache sau các hướng dẫn tĩnh của agent, họ đảm bảo rằng tiền tố chung dài từ 11k đến 21k token có thể được tái sử dụng cho tất cả các tác vụ, biến các thao tác ghi thường xuyên thành các thao tác đọc rẻ tiền.
Những lợi ích về hiệu quả tiếp theo đến từ việc giảm số lượng lệnh gọi LLM trong mỗi phiên. Trước đây, các sub-reviewer (công cụ đánh giá phụ) sẽ cố gắng sử dụng các công cụ mà chúng không có quyền truy cập, dẫn đến các lệnh gọi lãng phí và vòng lặp khôi phục lỗi. Nhóm đã loại bỏ các công cụ không thể truy cập này và song song hóa việc đọc tệp, cho phép các reviewer nạp ngữ cảnh trong một lượt duy nhất thay vì nhiều bước tuần tự. Họ cũng triển khai logic để bỏ qua các reviewer không cần thiết trong quá trình đánh giá lại và hủy các tác vụ tiếp tục chạy ngầm sau khi đã được đánh dấu hoàn tất. Những thay đổi này tổng hợp lại giúp giảm số lượng lệnh gọi LLM trung bình và tổng số token cho mỗi lần đánh giá.
Chi tiết chính
- Chi phí đánh giá trung bình giảm từ $2,46 xuống $0,77, tương đương mức giảm 68%.
- Thời gian đánh giá trung vị cải thiện từ 4m 09s xuống 1m 32s.
- Tỷ lệ trúng cache cho tiền tố chung tăng đáng kể sau khi tái cấu trúc prompt hệ thống.
- Việc chuyển từ Sonnet 5 sang Sonnet 5.5 giúp giảm gần một nửa chi phí đối với một số loại reviewer nhờ mức sử dụng token thấp hơn.
- Các thay đổi về mã nguồn đóng góp $0,65 vào khoản tiết kiệm, trong khi điều chỉnh mô hình và mức độ nỗ lực (effort) đóng góp $1,06.
- Thời gian đánh giá ở bách phân vị thứ 99 (99th percentile) hiện nhanh hơn 75% các lần đánh giá hồi tháng 4.
Tại sao điều này quan trọng
Đối với các nhóm kỹ sư đang xây dựng ứng dụng dựa trên các mô hình ngôn ngữ lớn, nghiên cứu tình huống này nhấn mạnh rằng sự ổn định về kiến trúc không đảm bảo sự ổn định về chi phí. Khi các mô hình trở nên mạnh mẽ hơn, người dùng có xu hướng gửi các đầu vào phức tạp hơn, điều này vô tình làm tăng mức tiêu thụ token. Kinh nghiệm của Cloudflare cho thấy tỷ lệ trúng cache cao là chưa đủ nếu dữ liệu cache không được cấu trúc để tối đa hóa khả năng tái sử dụng. Các nhà phát triển phải chủ động quản lý cấu trúc prompt để đảm bảo nội dung tĩnh, dùng chung được tách biệt khỏi nội dung động, biến đổi nhằm tận dụng hiệu quả cơ chế cache.
Ngoài ra, sự thay đổi trong các yếu tố thúc đẩy chi phí từ hạ tầng sang lựa chọn mô hình và mức độ nỗ lực cho thấy cần phải có sự tinh chỉnh liên tục. Chỉ đơn thuần chọn một mô hình mạnh mẽ không phải là quyết định "cài đặt rồi quên đi". Các nhóm cần liên tục đánh giá xem các thiết lập nỗ lực cao hơn có mang lại giá trị tương xứng trong kết quả tìm thấy hay không. Cloudflare nhận thấy rằng đối với một số tác vụ, mức nỗ lực trung bình là đủ, trong khi với những tác vụ khác, mức nỗ lực cao đáng đồng tiền bát gạo so với chi phí tăng thêm. Cách tiếp cận chi tiết này trong cấu hình giúp ngăn chặn việc cung cấp dư thừa tài nguyên tính toán cho các tác vụ không đòi hỏi suy luận sâu.
Bạn có thể làm gì
- Kiểm toán cấu trúc prompt của bạn để đảm bảo các tiền tố tĩnh được tách biệt khỏi các biến động nhằm cải thiện hiệu quả sử dụng cache.
- Giám sát số lượng lệnh gọi LLM trong mỗi phiên và xác định các lượt lãng phí do lỗi công cụ hoặc tóm tắt không cần thiết.
- Thử nghiệm các phiên bản mô hình mới so với baseline hiện tại, vì những cải tiến về hiệu quả đôi khi có thể bù đắp cho giá token cao hơn.
- Triển khai xử lý song song cho việc truy xuất ngữ cảnh để giảm độ trễ tuần tự và số lượng lệnh gọi.
- Xem xét các thiết lập mức độ nỗ lực (effort settings) cho các cấp độ tác vụ khác nhau để đảm bảo bạn không tính toán quá mức cho các kiểm tra đơn giản.
- Đảm bảo các tác vụ bị hủy thực sự được chấm dứt ở cấp độ script để ngăn ngừa lãng phí tài nguyên chạy ngầm.



