Các phương pháp thực chiến tích hợp để vận hành AI mà không lãng phí chi phí

• Để vận hành LLM và nền tảng AI một cách ổn định trong môi trường production, cần một cách thiết kế lấy cấu trúc làm trung tâm có thể thích ứng với thay đổi
• Để chuẩn bị cho thay đổi của mô hình và API, hãy tách mọi lời gọi AI thành các service riêng và áp dụng mẫu migration dựa trên chạy kép
• Tận dụng Flex service tier của OpenAI có thể giúp giảm 50% chi phí với cùng mô hình và chất lượng dữ liệu
• Đặt dữ liệu lặp lại ở phần đầu prompt để tối đa hóa hiệu quả sử dụng cache token, chỉ phải trả 10% chi phí
• Để ngăn chi phí phát sinh quá mức, cần triển khai Rate Limiting và Circuit Breaker như thành phần bắt buộc ở backend

---

Chiến lược tích hợp AI để sẵn sàng trước thay đổi

• Mô hình AI và API liên tục thay đổi, và cách đang hoạt động hiện tại có thể thất bại bất cứ lúc nào
• Thay vì chạy theo từng công cụ hay mô hình riêng lẻ, cốt lõi là thiết kế hệ thống có thể thích nghi với thay đổi
• Mục tiêu của việc ứng dụng AI không phải là chạy theo công nghệ mới nhất, mà là vận hành ổn định và kiểm soát chi phí

Mẫu migration (The Migration Pattern)

• Trích xuất mọi lời gọi AI API thành service để xử lý nội bộ việc kết nối, cấu hình prompt và các prompt cụ thể
• Các service này được vận hành ở trạng thái luôn có thể migration (permanent migratability) để luôn có thể dùng phiên bản và mô hình mới nhất hoặc phiên bản đã dùng trước đó
• Kinh nghiệm gặp vấn đề khi migration từ GPT 4.1 sang GPT-5
  • Prompt được tối ưu hoàn hảo cho GPT 4.1 lại giảm độ tin cậy trên GPT-5, chẳng hạn bị thiếu JSON key
  • GPT-5 có xu hướng dùng structured JSON schemas thay vì định dạng JSON đơn giản
  • Cần giải thích cách định nghĩa key và các giá trị có thể có, rồi điền vào trong prompt
• Cách triển khai chiến lược migration
  • Trong một khoảng thời gian nhất định hoặc trong môi trường test/staging, chạy đồng thời prompt cũ với mô hình cũ và prompt mới với mô hình mới
  • Cũng có thể dùng cấu trúc dữ liệu và lời gọi API hoàn toàn khác nhau (OpenAI khuyến nghị chuyển từ chat-style API sang response-style API)
  • Ghi log kết quả của cả hai phía; nếu có khác biệt quan trọng, hệ thống sẽ thông báo và hiển thị diff
  • Server chạy kép gây ra chi phí gấp đôi, nhưng giúp hiểu được sự khác biệt giữa mô hình cũ và mới, cũng như khác biệt của prompt ảnh hưởng ra sao tới chất lượng, khả năng dự đoán và độ tin cậy
• Đặc biệt hữu ích cho phân tích nền, xử lý dữ liệu và phân tích ngữ nghĩa, thay vì chỉ cho hội thoại thuần túy
• Nếu kết quả mới không đạt kỳ vọng, có thể rollback về phiên bản legacy bất cứ lúc nào
• Hệ thống API rồi cũng sẽ có lúc deprecated, nên chuẩn bị cho migration là bắt buộc
• Kiểm tra diff của dữ liệu JSON giúp tái cấu trúc prompt hiệu quả hơn
  • Có thể dùng Claude Code hoặc OpenAI Codex để điều chỉnh prompt cho đến khi kết quả hai bên trở nên tương tự
• Mẫu này áp dụng cho mọi service giao tiếp với các mô hình ML bên ngoài
• Nếu service mới đột ngột suy giảm hiệu năng, có thể chuyển công tắc để quay về phiên bản cũ và tiếp tục lấy dữ liệu đáng tin cậy như trước

Bí mật của service tier (The Service Tier Secret)

• Các dịch vụ đám mây cung cấp service tier, áp dụng mức giá khác nhau tùy theo mức độ quan trọng của lời gọi API
• Với OpenAI
  • default tier: mức giá hiển thị trên website
  • batched requests: rẻ hơn đáng kể, nhưng không biết khi nào batch được lấp đầy và xử lý, nên không phù hợp cho tác vụ bán đồng bộ
  • Flex tier: giá bằng một nửa default tier
    • Có thể chậm hơn 50% và đôi lúc không khả dụng, nhưng vẫn cung cấp cùng mô hình và chất lượng dữ liệu
• Trường hợp sử dụng Flex tier
  • Áp dụng cho các tác vụ backend như trích xuất khách mời, phân tích nội dung phát biểu, tóm tắt, v.v.
  • Dùng tính năng auto-retries của OpenAI SDK nên không cần logic riêng
  • Triển khai fallback khi gặp lỗi 429: thử vài lần bằng Flex, nếu thất bại thì chuyển sang standard tier để thử lại
• Kết quả khi triển khai ở quy mô lớn
  • Đạt mức giảm chi phí 50% ngay lập tức (Flex tier khả dụng trong phần lớn thời gian)
  • Khi input token nhiều và output token ít (ví dụ transcript podcast lớn → dữ liệu tóm tắt JSON nhỏ), cache token cũng có giá bằng một nửa
  • Có thể tăng gấp đôi khối lượng công việc trích xuất và suy luận, qua đó cải thiện chất lượng nền tảng và tăng tỷ lệ chuyển đổi
• Những điểm cần kiểm tra theo từng nền tảng
  • Giá Batch bằng với chi phí xử lý Flex
  • Giá Flex có trên các model GPT-5, 5.1, o3, o4
  • Codex, Pro, GPT-4o, công cụ audio thời gian thực, v.v. có thể không dễ dùng được giá Flex
• Nếu có price tier mà không sử dụng thì đó là sự cẩu thả về tài chính (financial negligence)
• Nếu vẫn cần kết quả nhanh ngay cả khi hệ thống tắc nghẽn, có thể chọn Priority tier (giá gấp đôi, kết quả nhanh hơn)
  • Priority cũng có thể không tồn tại với một số model nhất định
• Do model và cách sử dụng rất đa dạng, cần linh hoạt trong triển khai và tối ưu hóa

Đưa phần lặp lại lên trước để tối ưu cache (Front-Loading for Cache Efficiency)

• Khi có nhiều dữ liệu cần phân tích, hãy đặt phần lặp lại ở phía trước
• Đặt system prompt ở đầu, và nếu cùng một dữ liệu được phân tích nhiều lần thì hãy bắt đầu prompt bằng chính dữ liệu đó
• Thứ tự prompt
  1. System prompt (mô tả vai trò)
  2. Chỉ thị hệ thống luôn giống nhau ("trích xuất dữ liệu theo định dạng này")
  3. Dữ liệu có thể trùng lặp giữa nhiều prompt
  4. Chỉ thị riêng cho từng prompt
• Dữ liệu được đặt ở đầu sẽ được xử lý như cache token, nên chỉ phải trả 10% chi phí so với token thông thường
• Ví dụ áp dụng thực tế
  • Đưa toàn bộ transcript vào trước, rồi ở cuối transcript mới thêm chỉ thị cho tác vụ cụ thể (tìm khách mời cụ thể, tìm nhà tài trợ, xử lý câu hỏi khách hàng, v.v.)
• Cách kiểm tra tối ưu cho nhiều prompt
  • Đưa các prompt vào Claude Code hoặc cuộc trò chuyện ChatGPT như dữ liệu, rồi yêu cầu phân tích tối ưu hóa
  • Không nên chấp nhận nguyên xi kết quả từ AI mà chỉ dùng như tài liệu tham khảo (AI chỉ là công cụ dự đoán token; việc nó nói cách nào hữu ích hơn không có nghĩa là thực sự như vậy)
  • Phân tích nhiều prompt cùng lúc có thể mang lại insight có ý nghĩa

Rate Limiting và Circuit Breakers

• Khi dùng nền tảng bên ngoài có chi phí dựa trên token, Rate Limiting là bắt buộc
• Đối tượng cần áp dụng Rate Limit
  • Các hành động hướng tới khách hàng có thể kích hoạt tương tác AI
  • Các tương tác AI mà backend server có thể gửi đi
• Cần ngăn tình huống race condition khiến cùng một process liên tục khởi động lại và lặp lại cùng một lời gọi (ngay cả khi dùng cache token vẫn phát sinh chi phí)
• Phát hiện dấu hiệu bất thường
  • Cần có khả năng nhận cảnh báo và dừng lại khi mức sử dụng AI token trong một khoảng thời gian tăng gấp 10 lần bình thường
• Triển khai Circuit Breaker
  • Circuit breaker tổng cho toàn bộ chức năng AI của ứng dụng hoặc cho từng phần cụ thể
  • Feature toggle có thể bật/tắt từ lệnh Laravel hoặc giao diện quản trị
  • Các tính năng self-onboarding như nút "tạo cấu hình đẹp mắt" cũng cần có thể bật/tắt
  • Nếu ai đó tự động hóa khiến chi phí tăng hàng trăm USD mỗi giờ, có thể chặn ngay bằng toggle
• Feature toggle phải được triển khai ở backend, không phải frontend (điều khiển tại nơi chi phí thực sự phát sinh)
• Ứng dụng quét AI
  • Có thể dùng công cụ agentic coding để quét code, xác định điểm có thể bị lạm dụng lời gọi AI và vị trí cần thêm feature toggle
• Mọi việc sử dụng AI đều phải đi qua hệ thống backend
  • Không được để client-side dùng token để gọi trực tiếp nền tảng AI (vốn dĩ đã là cách làm không tốt)
  • Phải đi qua backend thì mới có thể bật/tắt tính năng và nhận cảnh báo khi mức sử dụng tăng cao
• Các lớp bảo vệ đã được triển khai
  • Rate limits cho mọi tính năng
  • Rate limits cho người dùng frontend
  • Rate limits cho backend
  • Feature toggles
  • Cảnh báo lạm dụng tính năng (theo tài khoản, loại thuê bao, IP)
• Trong tương lai có thể những thứ này sẽ được tích hợp sẵn trong công cụ và framework, nhưng hiện tại vẫn cần tự triển khai

Bài học cốt lõi: xây dựng hệ thống sẵn sàng cho thay đổi

• Môi trường AI luôn thay đổi (mô hình, API, giá cả), nên không thể theo kịp mọi thứ
• Cốt lõi của vận hành AI không phải là model mới nhất, mà là thiết kế hệ thống có thể thích ứng khi thay đổi xảy ra
• Các thành phần bắt buộc:
  • Mẫu migration
  • Tối ưu service tier
  • Prompt caching
  • Rate limiting
  • Circuit breakers
• Đây không phải là các tùy chọn nice-to-have, mà là nền tảng để ngăn thua lỗ khi vận hành AI trong production
• Ngay từ lúc đưa AI vào production, chi phí và độ ổn định không còn là vấn đề kỹ thuật mà là vấn đề cấu trúc

"Build for Change" — Hãy xây nền tảng cho sự thay đổi