Tối ưu chi phí AI — hướng dẫn đầy đủ để giảm 70–90% hóa đơn LLM

Năm kỹ thuật này cộng dồn hiệu quả. Mỗi kỹ thuật cắt giảm một phần khác nhau của hóa đơn — kết hợp ba kỹ thuật có thể thực tế đưa bạn đến mức giảm 70% mà không làm giảm chất lượng; cả năm kỹ thuật đưa bạn tiến gần 85–90%. Hướng dẫn này bao quát đầy đủ các lựa chọn, kèm khoản tiết kiệm được đo lường và mã có thể chạy cho từng kỹ thuật. Mỗi kỹ thuật liên kết đến một bài phân tích chuyên sâu ở cuối.

Năm kỹ thuật, xếp hạng theo ROI

1. Bộ nhớ đệm prompt — kỹ thuật có ROI cao nhất

Nếu system prompt của bạn dài hơn 1.000 token và bạn gọi cùng một prompt hơn hai lần trong khoảng thời gian 5 phút, bộ nhớ đệm prompt là khoản tiết kiệm gần như miễn phí. Anthropic tính phí input được lưu trong bộ nhớ đệm ở mức 10% mức phí input (2,5% ở Claude Fable 5.1; 5% ở Claude Opus 5.5); OpenAI tự động thực hiện điều tương đương tại 10%. Chỉ cần thêm một trường:

# Prompt caching: 1 extra field = 10% rate on cached input
resp = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=600,
    system=[{
        "type": "text",
        "text": LONG_SYSTEM_PROMPT,
        "cache_control": {"type": "ephemeral"},   # cache this part
    }],
    messages=[{"role": "user", "content": question}],
)

Mức tiết kiệm thực tế: giảm 60–90% dòng chi phí đầu vào nếu system prompt của bạn lớn và ổn định. Hãy xem bảng điều khiển /app/usage — nếu cache_read_input_tokens bằng 0, bạn có 30 phút công việc phía trước nhưng khoản đầu tư này sẽ hoàn vốn mãi mãi. Phân tích chuyên sâu.

2. Phân tầng model — dùng model rẻ nhất nhưng vẫn đủ tốt

Claude Haiku 4.5 có giá khoảng 10% Claude Opus 4.7. Với việc phân loại, định dạng, quyết định định tuyến và tóm tắt đơn giản — Haiku là quá đủ. Chỉ dành Opus cho các lệnh gọi suy luận thực sự khó.

# Pick the cheapest model that's still good enough for the task.
# Escalate by difficulty: cheap (Haiku 4.5 / GPT-5.6 Terra) -> Sonnet 5 -> Opus 4.7
def pick_model(difficulty: int) -> str:
    if difficulty <= 2: return "claude-haiku-4-5"     # ~10x cheaper than Opus
    if difficulty <= 4: return "gpt-5-6-terra"        # a second family, cheap output
    if difficulty <= 7: return "claude-sonnet-5"
    return "claude-opus-4-7"

Cách xây dựng quyết định phân tầng: trước tiên dùng một bộ phân loại nhỏ (chính Haiku có thể thực hiện việc này với 100 token đầu vào), sau đó định tuyến. Đo chất lượng đầu ra bằng các bài đánh giá giữ lại. Đừng để trực giác quyết định — hãy benchmark.

• Tầng 0 (Haiku 4.5): phân loại, trích xuất, dịch, tóm tắt đầu vào <2K — chi phí mỗi lệnh gọi tính bằng cent
• Tầng 1 (GPT-5.6 Terra): tóm tắt dài hơn, hoàn thiện mã, sử dụng công cụ đơn giản — cũng tính bằng cent nhưng xử lý ngữ cảnh dài tốt hơn
• Tầng 2 (Sonnet 5): suy luận thực sự, agent nhiều bước, tác vụ thị giác — model chủ lực trong môi trường production
• Tầng 3 (Opus 4.7): chỉ dùng khi bạn đã xác nhận Sonnet không xử lý đúng

3. Giới hạn đầu ra — giới hạn những gì model tạo ra, không chỉ những gì model đọc

Token đầu ra thường đắt hơn token đầu vào 4–5 lần. Giá trị mặc định max_tokens=4096 tùy tiện khuyến khích model dài dòng. Hãy giới hạn mạnh và dùng chuỗi dừng để dừng tại đúng điểm đánh dấu:

# Two-layer caps: per-call max_tokens + per-key wallet cap
client.chat.completions.create(
    model="claude-sonnet-5",
    messages=[...],
    max_tokens=800,             # cap each call
    stop=["</answer>"],         # cut at terminator
)
# /app/keys → set "Spending limit" per key:
#   Production: $50/day · Experiment: $5/day · CI: $1/day

Kết hợp max_tokens cho từng lệnh gọi với giới hạn chi tiêu ví theo từng khóa tại /app/keys — vòng lặp không kiểm soát hoặc lỗi không thể vượt quá hạn mức hằng ngày của bạn. Hai lớp, cả hai đều quan trọng.

4. Xử lý song song — dành cho khối lượng công việc dạng theo lô

Nếu bạn xử lý 1.000 mục độc lập (phân loại phản hồi, chấm điểm khách hàng tiềm năng, tạo mô tả), các lệnh gọi tuần tự sẽ mất một giờ. Xử lý bất đồng bộ với AsyncOpenAI và giới hạn đồng thời giúp bạn hoàn tất trong chưa đầy một phút — đồng thời timeout chặt hơn cho phép bạn thất bại nhanh với các upstream chậm. Xử lý song song không cắt giảm chi phí mỗi token, nhưng cho phép các mẫu kiến trúc (xử lý idempotent, ngân sách thử lại chặt hơn) có tác dụng đó.

5. Vệ sinh cơ chế thử lại — đừng trả tiền cho các lần thử lại không kiểm soát

Mã ngây thơ thử lại sau mọi lỗi, kể cả lỗi 400. Đó là trả tiền cho thất bại (các yêu cầu 4xx tại Kunavo không bị tính phí, nhưng bạn vẫn tiêu tốn ngân sách giới hạn tốc độ và thời gian trôi qua). Chính sách đúng: chỉ thử lại 408/429/5xx, thời gian chờ lũy thừa cộng jitter, tối đa 5 lần thử và tổng thời gian chờ 30 giây. Với mọi trường hợp khác, hãy thất bại nhanh và hiển thị lỗi.

Khoản tiết kiệm thể hiện như thế nào trong thực tế

Khoản tiết kiệm thực tế được đo lường trên một SaaS sử dụng Kunavo với mức chi $5.000/tháng:

• Thêm bộ nhớ đệm prompt: tiết kiệm $2.000 (−40%)
• Phân tầng Haiku cho việc phân loại: tiết kiệm $800 (−16%)
• max_tokens chặt chẽ hơn: tiết kiệm $400 (−8%)
• Tổng cộng: tiết kiệm $3.200/tháng, chi $1.800 (tổng mức giảm −64%)

Các khoản này cộng dồn — mỗi kỹ thuật tiếp theo tác động lên mức cơ sở đã giảm. Nếu chưa áp dụng bộ nhớ đệm trước, các kỹ thuật khác sẽ tiết kiệm ít hơn. Thứ tự rất quan trọng: bắt đầu với #1, sau đó #2, rồi #3.

Những cách không hiệu quả như quảng cáo

• "Embedding cho mọi thứ" — embedding giúp tiết kiệm khi tìm kiếm văn bản, không phải khi tạo nội dung. Chúng rẻ nhưng không làm giảm chi phí lệnh gọi LLM
• "Fine-tune cục bộ để giảm chi phí" — chỉ hợp lý nếu bạn xử lý hơn 10M token/ngày cho một tác vụ chuyên biệt. Với hầu hết đội ngũ, bộ nhớ đệm prompt + phân tầng Haiku hiệu quả hơn sự phức tạp vận hành của việc tự lưu trữ
• "Aggregator rẻ hơn" — Kunavo đã định giá hầu hết model thấp hơn mức phí chính thức của nhà cung cấp. Các aggregator rẻ hơn thường thắng bằng cách âm thầm đổi model bạn yêu cầu sang một model rẻ hơn

Tiếp theo nên xem gì

Hãy áp dụng bộ nhớ đệm trước — đây là khoản ROI cao nhất trên mỗi giờ đầu tư. Sau đó theo dõi bảng điều khiển /app/usage theo model và tầng. Rồi phân tầng. Theo dõi chi phí hàng tháng trên mỗi người dùng đang hoạt động như chỉ số định hướng chính — nếu chỉ số này đi ngang hoặc giảm trong khi mức độ tương tác tăng, bạn đang làm đúng.

Câu hỏi thường gặp