AI rẻ hơn, quyết định khó hơn

AI rẻ hơn, quyết định khó hơn

Model rẻ đang thắng chú ý, nhưng câu hỏi thật không phải “có nên đổi ngay không”. Câu hỏi là workload nào đáng đổi, dữ liệu nào không được đem ra thử.

Có một cảnh mình gặp hoài ở team đang dùng AI: cuối tháng mở bill ra, cả phòng im như vừa nghe tiếng nứt dưới nền nhà. Tuần trước còn vui vì chatbot nội bộ trả lời nhanh, agent viết SQL ngon lành, tool low-code dựng dashboard trong vài giờ. Tuần này thì finance hỏi: “Mấy token này ai ăn hết vậy?”

Rồi lập tức có người thả một link: model mới rẻ hơn nhiều, cộng đồng đang bàn rần rần, vài công ty Mỹ cũng đã trả tiền dùng trực tiếp. Câu chuyện Deepseek đứng đầu nhóm software vendor tăng trưởng nhanh trên dữ liệu giao dịch của Ramp tháng 6/2026 là một tín hiệu như vậy. Nhưng nếu bạn chỉ đọc nó như “model Trung Quốc rẻ đang thắng”, bạn sẽ bỏ lỡ phần đáng tiền hơn.

Luận điểm của mình: thời của “chọn model tốt nhất mặc định” đang nứt ra. Nhưng quyết định đúng không phải là chạy theo model rẻ nhất. Quyết định đúng là tách workload thành từng lớp rủi ro, rồi chọn nơi đặt từng lớp đó.

Sơ đồ minh họa cho bài AI rẻ hơn, quyết định khó hơn

Sơ đồ tóm tắt ý chính của bài viết.

Tín hiệu mới: chi phí đang trở thành chấn tâm

Deepseek tăng nhanh trên Ramp không phải vì mọi người tự host open-source model trong hầm máy chủ nào đó. Điểm đáng chú ý là theo phân tích được trích dẫn, các công ty đang trả tiền trực tiếp và gửi dữ liệu qua nền tảng của Deepseek. Đây là khác biệt lớn.

Nếu bạn tải model về, tự chạy trên hạ tầng của mình, câu hỏi chính là vận hành: GPU, latency, monitoring, đội ngũ. Nếu bạn gọi API trực tiếp của một nhà cung cấp nước ngoài, câu hỏi chuyển sang: dữ liệu đi đâu, hợp đồng ra sao, audit thế nào, ai chịu trách nhiệm khi có sự cố.

Ở đây có một thuật ngữ cần neo nhanh: inference là lúc model xử lý yêu cầu thật, ví dụ bạn gửi prompt “tóm tắt hợp đồng này” và model trả kết quả. Chi phí inference mới là thứ làm hóa đơn phình ra khi sản phẩm có người dùng thật, không phải lúc demo cho sếp xem.

Các tín hiệu khác cũng cùng hướng: inference platform như Fireworks AI, fal, DeepInfra tăng vì công ty muốn chạy model mở với chi phí thấp hơn; một số team đang thử phối hợp model đắt và model rẻ; các công cụ low-code/no-code thì nhồi AI vào workflow để người không code cũng tạo app, agent, automation.

Nhìn bề mặt thì đây là cuộc đua model. Nhìn sâu hơn, đây là cuộc dịch chuyển từ “AI như tính năng” sang “AI như chi phí vận hành phải tối ưu”.

Mổ lớp đá thứ nhất: rẻ không đồng nghĩa an toàn để dùng rộng

Điều nhiều team hiểu sai: thấy giá thấp là muốn thay model mặc định trong toàn bộ hệ thống.

Không nhanh vậy đâu.

Price-to-performance là tỷ lệ giữa chất lượng nhận được và số tiền bỏ ra. Nó quan trọng, nhưng không đủ. Một model rẻ hơn rất nhiều mà kém hơn một chút có thể là lựa chọn tuyệt vời cho phân loại ticket, viết nháp email, chuẩn hóa tên sản phẩm. Nhưng cùng model đó có thể là lựa chọn tệ nếu bạn đưa vào luồng phân tích hồ sơ pháp lý, dữ liệu khách hàng nhạy cảm, hoặc logic cạnh tranh cốt lõi.

Hình dung thế này: team bạn có ba loại việc AI đang làm:

  1. Việc nền: tóm tắt nội dung công khai, tạo mô tả sản phẩm, gợi ý tiêu đề.
  2. Việc nghiệp vụ: phân loại lead, đọc ticket khách hàng, hỗ trợ sales soạn phản hồi.
  3. Việc nhạy cảm: phân tích hợp đồng, dữ liệu tài chính, chiến lược giá, thông tin người dùng.

Nếu đổi cả ba sang một API rẻ hơn chỉ vì trend, bạn đang để dung nham chi phí nguội nhanh nhưng lại mở thêm đứt gãy bảo mật. Tiết kiệm bill là thật; rủi ro dữ liệu cũng thật.

Ở đây có thêm một thuật ngữ: data residency là yêu cầu dữ liệu được lưu hoặc xử lý ở khu vực pháp lý nhất định. Với team làm fintech, health, enterprise SaaS, hoặc phục vụ khách hàng quốc tế, đây không phải mục tick cho đẹp. Nó quyết định bạn được phép gửi gì qua đâu.

Bảng quyết định: workload nào nên đổi, workload nào nên đứng yên

Thay vì hỏi “có nên dùng Deepseek/Qwen/model rẻ hơn không?”, mình sẽ hỏi thế này: workload này có đáng chuyển khỏi model hiện tại không?

| Loại workload | Có thể thử model rẻ? | Điều kiện trước khi thử | Khi nào dừng |
|---|---:|---|---|
| Tạo nháp nội dung nội bộ | Có | Không chứa dữ liệu khách hàng; có người duyệt | Output sai làm mất thời gian sửa nhiều hơn tiền tiết kiệm |
| Phân loại/tóm tắt ticket | Có, nhưng giới hạn | Mask thông tin nhạy cảm; log đầy đủ; có bộ test mẫu | Tỷ lệ phân loại sai ảnh hưởng SLA |
| RAG trên tài liệu công khai | Có | Có eval câu hỏi chuẩn; kiểm tra hallucination | Trả lời thiếu nguồn hoặc trộn tài liệu |
| Phân tích hợp đồng/tài chính | Chỉ thử sandbox | Dữ liệu giả lập hoặc đã ẩn danh; legal duyệt | Không chứng minh được đường đi dữ liệu |
| Agent có quyền gọi tool | Rất thận trọng | Tool permission chặt; human approval | Agent tự ý ghi/sửa/xóa ngoài phạm vi |

Routing là cách điều hướng yêu cầu sang model phù hợp. Ví dụ câu hỏi dễ đi qua model rẻ; câu hỏi khó hoặc rủi ro cao chuyển sang model mạnh hơn. Đây là hướng đáng chú ý hơn việc “đổi nhà cung cấp một phát cho xong”.

Ví dụ cụ thể: giả sử team bạn có chatbot hỗ trợ nội bộ. Câu hỏi “quy trình xin nghỉ phép” có thể đi qua model rẻ đọc policy đã public trong công ty. Nhưng câu “so sánh lương nhóm sales quý này” phải bị chặn hoặc chuyển sang hệ thống có quyền hạn, logging và phê duyệt rõ ràng. Cùng là chatbot, nhưng hai câu hỏi nằm trên hai tầng địa chất khác nhau.

Điều đáng giữ: kiến trúc lai, không phải lòng trung thành với một model

Một điểm mình thấy đáng học từ các case gần đây là cách team nghiêm túc bắt đầu tách việc. TechCrunch có nhắc thử nghiệm của Harvey với Fireworks AI: họ kết hợp model mạnh cho tác vụ nặng và model rẻ hơn cho phần còn lại để giảm chi phí inference mà vẫn giữ chất lượng theo bài test của họ. Mình không lấy đó làm công thức áp dụng nguyên xi, nhưng hướng nghĩ thì rất đáng giữ.

Cùng lúc, Microsoft Build 2026 nhấn mạnh nhiều thứ quanh Foundry, control plane và observability. Observability nghĩa là khả năng nhìn được hệ thống đang chạy ra sao: request nào đi qua model nào, latency bao nhiêu, lỗi ở đâu, chi phí tăng lúc nào. Với AI production, không có observability thì bạn chỉ biết bill tăng sau khi núi đã phun tro.

Ở mảng video, Avataar dùng distillation — hiểu ngắn là nén năng lực model lớn thành bản gọn hơn cho use case cụ thể — để tạo Varya phục vụ bối cảnh Ấn Độ. Theo nguồn, họ nói model chạy 4 bước thay vì 50 bước của Wan 2.2, tạo clip 5 giây 720p trong 45 giây trên NVIDIA H200 so với 1.230 giây, và dự kiến giá thấp hơn đáng kể so với một số dịch vụ video AI phổ biến. Điểm mình muốn giữ lại không phải là “hãy dùng model này”, mà là: local context + tối ưu đúng workload có thể quan trọng hơn chạy theo model tổng quát mạnh nhất.

Với team Việt Nam, bài học này rất thực tế. Nếu bạn làm e-commerce, education, legal ops, customer support tiếng Việt, có khi model đắt nhất không phải model hiểu workflow của bạn nhất. Nhưng model rẻ nhất cũng không tự nhiên hiểu nghiệp vụ. Bạn cần bộ eval của riêng mình.

Điều nên bỏ qua: bảng xếp hạng và danh sách tool dài như trầm tích

Danh sách 21 low-code/no-code AI tools có ích nếu bạn đang scan thị trường. Nhưng dùng danh sách để ra quyết định thì dễ lạc. Tool nào cũng nói tạo app nhanh, agent thông minh, automation mượt. Vấn đề là tool không quyết định chi phí inference thay bạn, càng không quyết định rủi ro dữ liệu thay bạn.

Trước khi thêm một tool AI vào stack, hỏi 5 câu này:

Nếu vendor không trả lời rõ, đừng để nó chạm dữ liệu nhạy cảm. Bạn có thể dùng nó cho prototype, landing page, internal mockup. Nhưng từ prototype đến production là hai lớp đất khác nhau, đạp nhầm là sụt.

Nếu là mình, mình sẽ quyết thế này

Mình sẽ không “cấm cửa” model rẻ. Cũng không thay toàn bộ stack chỉ vì một tháng trend đẹp.

Mình sẽ chia quyết định thành ba vòng:

Vòng 1: Cho phép thử
Các tác vụ ít rủi ro, dữ liệu công khai hoặc đã ẩn danh, output có người duyệt. Mục tiêu là đo chi phí, latency, chất lượng trên workload thật.

Vòng 2: Cho phép chạy có điều kiện
Các tác vụ nghiệp vụ có ảnh hưởng tới khách hàng. Cần eval cố định, logging, rollback, routing sang model mạnh khi confidence thấp. Eval ở đây là bộ câu hỏi/bài test lặp lại để biết model có thật sự đủ dùng không.

Vòng 3: Chưa chuyển
Dữ liệu nhạy cảm, agent có quyền thao tác hệ thống, quyết định pháp lý/tài chính. Muốn chuyển thì phải có legal, security, procurement và owner nghiệp vụ cùng ký.

Sau bài này, điều mình muốn bạn nghĩ khác là: model rẻ không phải lựa chọn cấp thấp; nó là lựa chọn cần biên giới rõ. Cái mới và ồn ào nhất có thể đáng thử, nhưng chỉ khi bạn biết nó được phép đứng ở tầng nào trong hệ thống.

AI đang rẻ hơn thật. Nhưng ra quyết định thì không rẻ đi — nó chỉ chuyển từ bảng giá sang bản đồ rủi ro. Và bản đồ mà vẽ ẩu thì đi vài bước là gặp miệng núi lửa, khỏi cần benchmark.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo