Có một cái bẫy mà hầu hết developer đều mắc phải khi mới bắt đầu dùng AI API: mặc định chọn model mạnh nhất có sẵn. Cảm giác đó như một lựa chọn có trách nhiệm. Bạn đang build thứ gì đó thực sự, tại sao lại mạo hiểm với option rẻ hơn?

Nhưng sau khi ship hàng chục tính năng production với AI, pattern trở nên rõ ràng: model đắt tiền không phải lúc nào cũng phù hợp — và thường thì không phải.

Giả Định Đang Làm Tốn Tiền Bạn

Niềm tin ngầm là capability tăng tuyến tính theo giá. Trả nhiều hơn, nhận output thông minh hơn. Nhưng thực tế LLM không hoạt động như vậy.

Các tier model được tối ưu cho những đánh đổi khác nhau:

  • Model nhỏ/nhanh (Claude Haiku, GPT-4o Mini, Gemini Flash): Latency thấp, chi phí thấp, đủ tốt cho các task có cấu trúc
  • Model tầm trung (Claude Sonnet, GPT-4o): Cân bằng reasoning, code mạnh hơn, phù hợp với hầu hết developer workflow
  • Model flagship (Claude Opus, o1, Gemini Ultra): Reasoning sâu, phân tích phức tạp, chuỗi multi-step dài

Sai lầm là dùng flagship model cho những task mà model nhỏ xử lý tốt như nhau — và trả thêm 10–50 lần tiền mỗi token mà không thu được gì thêm.

So Sánh Chi Phí Thực Tế

Giả sử bạn đang build một code review bot xử lý 500 PR descriptions mỗi ngày, mỗi cái khoảng 800 token input và 400 token output.

Khối lượng ngày: 500 requests × 1,200 tokens = 600,000 tokens/ngày

Với một PR description summarizer? Haiku làm được việc. Chất lượng output người dùng không phân biệt được sự khác biệt. Bạn vừa tiết kiệm được $670/tháng.

Những Chỗ Developer Hay Mắc Sai Lầm

1. Dùng flagship model để classification

"Lỗi này có thể phục hồi hay fatal?" — Binary classification không cần một model có thể viết luận văn. Model nhỏ được prompt tốt xử lý điều này với độ chính xác >95% với 1/20 chi phí.

2. Dùng flagship model để extraction

Kéo dữ liệu có cấu trúc từ văn bản (tên, ngày, số tiền) là task pattern-matching. Model nhỏ với JSON mode nhanh hơn, rẻ hơn, và chính xác như nhau.

3. Dùng flagship model cho mọi bước trong agent chain

Nếu agent pipeline của bạn có 6 bước, không phải tất cả đều cần cùng một model. Các bước thu thập dữ liệu, format output, hoặc chạy validation có thể dùng model rẻ hơn. Chỉ bước nặng về reasoning (quyết định làm gì tiếp theo) mới có thể cần mid-tier hoặc flagship.

Bước 1: Thu thập context     → Haiku  ($)
Bước 2: Phân loại intent     → Haiku  ($)
Bước 3: Lập kế hoạch hành động → Sonnet ($$)
Bước 4: Thực hiện hành động  → Haiku  ($)
Bước 5: Validate kết quả     → Haiku  ($)
Bước 6: Viết response cuối   → Sonnet ($$)

Cách tiếp cận "cascade" này có thể giảm chi phí 60–70% trong khi duy trì chất lượng output ở những chỗ thực sự quan trọng.

4. Không đo lường sự khác biệt chất lượng

Hầu hết developer giả định flagship model tốt hơn mà không thực sự đo. Hãy chạy eval: tạo output từ cả hai model trên task cụ thể của bạn, chấm điểm, và xem liệu sự khác biệt có xứng đáng với giá cả không. Thường thì không.

Khi Nào Model Đắt Mới Thực Sự Xứng Đáng

Để rõ ràng: có những task mà flagship model thực sự đáng giá.

Complex multi-hop reasoning — debug một vấn đề phức tạp trải rộng 5 file, 3 service, và một race condition. Model nhỏ sẽ cho bạn câu trả lời nghe có vẻ hợp lý nhưng sai.

Phân tích long-context — đọc toàn bộ codebase, một tài liệu pháp lý, hoặc một dataset lớn và đưa ra đánh giá mạch lạc. Model nhỏ mất đi sự nhất quán khi context tăng.

Agentic planning với stakes cao — nếu một agent có thể deploy code hoặc sửa database, bạn muốn judgement tốt nhất có thể cho bước planning.

Giải quyết vấn đề mới lạ — yêu cầu model reasoning về thứ gì đó mà nó chưa thấy pattern rõ ràng. Flagship model tốt hơn hẳn về khả năng generalization.

Nguyên tắc chung: nếu một junior developer với đúng instructions có thể làm tốt task đó, một model nhỏ cũng có thể. Nếu cần senior engineer, hãy chọn model lớn hơn.

Framework Thực Tế

Trước khi chọn model, hãy trả lời ba câu hỏi:

  1. Task có tính xác định hay sáng tạo? Xác định (formatting, extraction, classification) → model nhỏ. Nặng về sáng tạo hoặc reasoning → mid hoặc flagship.

  2. Latency có quan trọng không? Tính năng user-facing mà tốc độ phản hồi ảnh hưởng UX → ưu tiên model nhỏ. Background job → dùng model tốt nhất cho chất lượng.

  3. Output sai trông như thế nào? Nếu output xấu được bắt downstream (validation, test, human review) → dùng model rẻ hơn. Nếu output xấu gây hậu quả không thể đảo ngược (gửi email, chạy migration) → dùng model tốt nhất bạn có.

Đừng Mặc Định Chọn Flagship

Những AI engineer giỏi nhất không phải là người dùng model mạnh nhất — mà là người biết dùng model nào cho task nào. Mặc định flagship giống như dùng senior engineer để viết CRUD boilerplate. Vẫn chạy được, nhưng tốn kém và lãng phí.

Hãy xây dựng policy chọn model cho project của bạn. Match tier với độ phức tạp của task. Chạy eval để xác nhận giả định. Bạn sẽ ship nhanh hơn, tốn ít hơn, và — một cách counterintuitive — đưa ra quyết định tốt hơn về chỗ nào flagship model thực sự quan trọng.