AI cần biển báo, không chỉ thêm mã lực

Ba release gần đây cho thấy vấn đề của AI production không phải thiếu model, mà thiếu cách chia làn: ai được dùng, dùng gì, và trả tiền cho ai.

Dạo này mình thấy nhiều team AI chạy y như mới lên đường cao tốc: cứ thấy xe nào khỏe hơn là muốn đổi ngay. Nhưng đến lúc hóa đơn về, ai cũng nhìn nhau như vừa đi lạc qua một con đường không có biển báo. Và cái đau không nằm ở chỗ model chậm hay nhanh, mà ở chỗ không ai biết ai đang lái, đang đi đâu, và đang đốt bao nhiêu xăng.

Ba release gần đây làm mình nghĩ lại rất nhiều về chuyện này. Điều đáng chú ý không phải là một model mới “xịn hơn”, hay một plugin marketplace trông tiện hơn, mà là toàn bộ stack đang dịch từ model-first sang control-plane-first: phải quản được người dùng, ngân sách, routing, và tool access trước khi bàn tới benchmark.

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

Thứ đang diễn ra: AI đang lớn lên, nhưng hóa đơn cũng vậy

Cloudflare đưa spend controls vào AI Gateway và mở closed beta cho budget + routing dựa trên identity qua Cloudflare Access và identity provider sẵn có. Còn xAI thì đẩy Grok Build theo hướng plugin marketplace: đóng gói skills, slash commands, agents, hooks, MCP servers, LSPs vào một chỗ để cài, cập nhật, phân phối. Fireworks lại cho thấy Qwen 3.7 Plus được đặt trong ngữ cảnh agent loops dài hơi, với cơ chế giữ reasoning qua nhiều lượt.

Ba mảnh này trông khác nhau, nhưng mình đọc ra cùng một tín hiệu: AI không còn là một hộp chat nối API nữa. Nó đang biến thành hệ thống có người dùng, công cụ, ngữ cảnh, quyền truy cập, và chi phí chạy theo từng đường đi riêng.

Nói đơn giản thì: trước đây bạn chỉ cần chọn “xe nào mạnh”. Giờ bạn phải biết xe nào được phép chạy, chạy tuyến nào, và ai trả tiền đổ xăng.

Vì sao niềm tin “cứ mở rộng model là xong” nghe hợp lý

Niềm tin này không ngu đâu, nó chỉ thiếu một nửa bức tranh.

Khi team mới bắt đầu, một shared API key cho cả phòng là cách nhanh nhất để mọi người thử AI. Cắm vào là chạy, ai cũng vui. Vấn đề là khi usage tăng, shared key tạo ra ba điểm mù rất khó chịu:

1. Không biết ai tiêu: invoice đến thì finance thấy một cục tiền, còn engineering không chỉ ra được ai đã gọi gì.
2. Không biết tiêu vì việc gì: code review summary, log parsing, email triage, hay một job CI nào đó tự nhiên chạy quá tay — tất cả nằm chung một dòng.
3. Không biết chọn route nào: nếu không có chính sách, người dùng sẽ chọn model mạnh nhất cho mọi việc, vì đó là lựa chọn an toàn nhất trong đầu họ.

Phản xạ này nghe có lý: mạnh hơn thì chắc tốt hơn. Nhưng thực tế, một task như tóm tắt log không cần cùng một mức “cỗ máy” với một bài toán refactor kiến trúc. Nếu không có routing, bạn đang bắt mọi xe chạy cùng một làn, rồi ngạc nhiên vì làn đó lúc nào cũng tắc.

Ba chốt mình sẽ lắp trước khi cho AI ra đường

Mình nghĩ builder nên nhìn AI stack bằng một khung rất thực dụng: Identity → Budget → Routing.

1) Identity: biết ai đang cầm vô lăng

Nếu team bạn vẫn dùng chung một API key cho mọi thứ, bạn đang tự bỏ tiền vào một điểm mù. Hãy gắn usage với người dùng, team, project, hoặc service account.

Ví dụ cụ thể: nếu một engineer chạy thử agent để dọn issue, còn CI cũng gọi agent để review PR, hai nguồn đó phải tách được. Không cần làm phức tạp ngay từ đầu; chỉ cần đến lúc finance hỏi thì bạn không phải đoán.

2) Budget: đặt giới hạn theo ngữ cảnh, không chỉ theo tháng

Budget không chỉ là “đến cuối tháng đừng vượt quá X”. Cái hữu ích hơn là budget theo tenant, team, job type, hoặc môi trường.

Nếu bạn chạy thử nội bộ, budget có thể rộng hơn. Nếu là flow production hướng tới khách hàng, budget phải chặt hơn và có chặn tự động khi vượt ngưỡng. Đây là chỗ Cloudflare AI Gateway khá đáng chú ý: spend control không chỉ để nhìn hóa đơn, mà để đạp phanh đúng lúc.

3) Routing: đừng để mọi yêu cầu đi cùng một cửa

Routing nghĩa là cùng một app nhưng có nhiều lối đi: task đơn giản đi model nhẹ hơn, task nhạy cảm hoặc khó hơn mới lên model mạnh. Qwen 3.7 Plus cho agent loops dài cho thấy một xu hướng rõ: có workload cần reasoning được giữ qua nhiều lượt, nhưng không phải việc nào cũng đáng trả giá cho kiểu xử lý đó.

Nếu bạn là team sản phẩm, routing tốt sẽ giúp bạn không phung phí model lớn cho việc nhỏ. Nếu bạn là team platform, routing tốt giúp bạn viết policy rõ ràng: việc nào bắt buộc có tool access, việc nào chỉ được đọc, việc nào không được đụng dữ liệu thật.

Điều đáng giữ từ các release này

Mình không nghĩ bài học lớn nhất là “hãy dùng Cloudflare”, hay “hãy cài plugin marketplace”, hay “hãy chạy Qwen theo kiểu agent”. Bài học đáng giữ là:

• Spend control là feature của production, không phải của finance riêng lẻ.
• Plugin marketplace là dấu hiệu rằng agent cần lớp phân phối công cụ, không phải mỗi team tự nối tay từng tích một.
• Agent model với reasoning kéo dài cho thấy inference stack giờ phải quan tâm tới nhịp làm việc dài, không chỉ lượt trả lời ngắn.

Phần mình thích ở xAI plugin marketplace là nó làm rõ một điểm: agent không còn sống một mình. Nó cần skills, hooks, tools, và cả cơ chế cài đặt/cập nhật có kiểm soát. Phần mình thích ở Cloudflare là nó nhắc thẳng rằng identity và budget phải đi cùng nhau, chứ không thể để API key mù danh tính rồi cuối tháng ngồi giải toán.

Điều nên bỏ qua

Có ba thứ mình sẽ bớt mê ngay:

• Đừng mặc định model mới nhất là default tốt nhất. Nhiều task chỉ cần model vừa đủ, với routing đúng.
• Đừng nghĩ marketplace là xong bài toán tích hợp. Marketplace chỉ giải quyết discovery và packaging; quyền, trust, sandbox, và audit mới là chỗ đau thật.
• Đừng nhầm reasoning dài với hệ thống đúng. Một agent nhớ lâu hơn không có nghĩa là nó sẽ tiêu tiền khôn hơn.

Nếu là mình, mình sẽ bắt đầu bằng một buổi chiều rất thực tế: liệt kê top 5 luồng AI đang chạy trong team, gắn mỗi luồng với owner, budget, model mặc định, và policy routing. Sau đó mới hỏi tiếp: chỗ nào cần tool access, chỗ nào cần plugin, chỗ nào nên hạ model xuống cho rẻ hơn.

Bởi vì khi AI đã đi vào production, câu hỏi không còn là “model nào mạnh hơn” nữa. Câu hỏi thật là hệ thống của bạn có đủ biển báo để không tự lao vào hố chi phí hay không.

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