Móng AI quan trọng hơn model mới

Móng AI quan trọng hơn model mới

Release mới đáng chú ý không phải vì thêm model, mà vì nó nhắc builder nhìn AI stack theo lớp: compute, inference, storage, provenance và tiền.

“Intelligence should be abundant, not expensive” nghe như câu treo trên slide gọi vốn, nhưng nếu bạn đang build hệ thống AI thật, phần đáng nhìn không nằm ở câu khẩu hiệu. Nó nằm ở câu hỏi kém hào nhoáng hơn: khi model ngày càng dễ đổi, lớp nào mới quyết định hệ thống của bạn chạy được lâu?

Một team Việt Nam rất dễ rơi vào cảnh này: sáng thứ Hai CTO hỏi “model nào đang hot?”, chiều thứ Hai cả nhóm đổi provider, tối thứ Ba latency nhảy múa, sáng thứ Tư log lỗi đầy như bê tông chưa khô. Model mới có thể tốt hơn, rẻ hơn, nhanh hơn. Nhưng nếu stack phía dưới chưa có móng, bạn chỉ đang thay màu sơn cho căn nhà còn nghiêng.

Luận điểm của mình: đừng đọc các release AI như danh sách món mới; hãy đọc như bản vẽ kết cấu. Together AI gọi vốn Series C 800 triệu USD, nói về open-source AI, B200 on-demand, serverless inference, dedicated inference, custom containers, model library, benchmark coding agent TPS. Cloudflare nói về Monetization Gateway cho API, dataset, MCP tools qua x402. LlamaIndex thêm granular bounding boxes cho LlamaParse. EverOS kéo memory agent về Markdown-first. Azure Files nhắc lại chuyện shared storage cho Linux workloads. Nhìn rời rạc thì là tin công cụ. Ghép theo lớp thì là một tín hiệu khác: AI production đang chuyển từ “chọn model” sang “quản trị tài nguyên, bằng chứng và dòng tiền ở từng request”.

Sơ đồ minh họa cho bài Móng AI quan trọng hơn model mới

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

Tín hiệu chính: inference đang thành hạ tầng, không còn là demo

Together AI công bố họ đạt 31% more TPS so với engine OSS nhanh kế tiếp cho production coding agent workloads — đây là số theo công bố của họ, nên mình không xem như chân lý phổ quát. Nhưng con số đó vẫn chỉ ra một hướng quan trọng: workload agent không chỉ cần model thông minh, mà cần throughput — số token hoặc request xử lý được trong một đơn vị thời gian — ổn định khi nhiều tác vụ chạy song song.

Với coding agent, tốc độ không chỉ là “trả lời nhanh”. Nó ảnh hưởng đến cách bạn thiết kế queue, retry, timeout, cost cap và trải nghiệm dev. Một agent sửa code mà mỗi bước tool call chờ quá lâu thì giống công trình có giàn giáo nhưng thợ cứ phải đứng chờ vật liệu.

Nói thẳng ra thì: model là phần nhìn thấy, inference runtime mới là phần chịu lực.

Nếu bạn đang dùng API serverless, bạn mua sự tiện. Nếu bạn chuyển sang dedicated inference hoặc custom hardware, bạn mua quyền kiểm soát. Nếu bạn tự host bằng vLLM/Ollama hoặc một engine khác, bạn mua khả năng tối ưu sâu nhưng cũng ôm vận hành. Không có lựa chọn “đúng nhất”; chỉ có lựa chọn khớp với tải, ngân sách và mức chịu đau của team.

Mổ stack theo 5 lớp builder nên soi

Thay vì hỏi “model nào mới?”, mình sẽ bóc hệ thống theo 5 lớp. Đây là framework dùng được khi đọc release, chọn vendor hoặc thiết kế lại AI stack.

| Lớp | Câu hỏi cần hỏi | Dấu hiệu đáng giữ |
|---|---|---|
| Compute | GPU/CPU lấy ở đâu, có co giãn không? | Có on-demand, reserved hoặc dedicated rõ ràng |
| Inference | Model chạy nhanh và ổn định thế nào? | Có benchmark đúng workload, đo TPS/latency/error |
| Storage | Dữ liệu, weights, cache, file dùng chung ra sao? | Shared storage và quyền truy cập không thành nút nghẽn |
| Provenance | Kết quả lấy từ đâu, có chứng cứ không? | Có attribution, bounding boxes, log truy vết |
| Monetization & access | Ai được gọi, trả tiền kiểu gì? | Policy theo request/tool/API, không chỉ theo user seat |

Together đang đánh mạnh vào hai lớp đầu: compute và inference. Azure Files nằm ở lớp storage: Linux workloads, AI/data-intensive pipelines và cloud-native app thường cần shared storage thay vì mỗi container giữ một bản riêng. LlamaParse granular bounding boxes đẩy lớp provenance lên rõ hơn: không chỉ extract đúng, mà còn chỉ được vị trí trên trang nơi giá trị xuất hiện. Cloudflare Monetization Gateway chạm lớp monetization & access: nếu agent gọi API, dataset hoặc MCP tool, đơn vị tính tiền có thể là request, token, MB hoặc outcome. EverOS thì nằm ở lớp memory/storage cho agent: Markdown-first, hybrid BM25 + vector retrieval, giữ memory có thể đọc, sửa, version.

Điểm mới không phải từng tool riêng lẻ. Điểm mới là AI stack đang có khung kèo vận hành riêng, và builder phải biết lớp nào đang yếu trước khi ném thêm model vào.

Điều đáng giữ: benchmark đúng tải, không đúng sân khấu

Benchmark “coding agent workload” đáng quan tâm hơn benchmark hỏi đáp chung, vì nó gần với production hơn: agent phải đọc file, gọi tool, tạo patch, kiểm tra lỗi, rồi lặp lại. Nhưng bạn vẫn cần kiểm tra lại trên workload của mình.

Ví dụ cụ thể: giả sử team bạn có 6 developer, mỗi người dùng coding agent để sửa bug trong monorepo. Một request không chỉ là một prompt; nó có thể kéo theo 8-15 bước: đọc file, grep, gọi test, sửa code, chạy lại, tóm tắt diff. Nếu nhà cung cấp nói TPS cao, bạn cần hỏi:

context window là vùng ngữ cảnh model còn giữ được trong một lượt xử lý; với agent đọc codebase, context quá hẹp sẽ khiến nó quên chi tiết giữa chừng. tool calling là khả năng model gọi API/công cụ thay vì chỉ viết chữ; với coding agent, đây là đường dây điện âm tường, hỏng là cả nhà tối.

Một release khoe model library rộng rất hữu ích nếu bạn có routing tốt. Nhưng nếu hệ thống không đo được workload thật, model library dễ biến thành kệ trưng bày: nhiều lựa chọn, ít quyết định.

Lớp dễ bị xem nhẹ: bằng chứng và bộ nhớ

Hai nguồn liên quan đáng nối vào câu chuyện này là LlamaParse và EverOS.

Granular bounding boxes trong LlamaParse nghe nhỏ, nhưng với document AI production lại lớn. bounding box là tọa độ vùng trên trang nơi dữ liệu được trích xuất. Nếu pipeline lấy số tiền từ hóa đơn, báo cáo tài chính hoặc hồ sơ bảo hiểm, câu hỏi không chỉ là “số này đúng không?” mà là “nó nằm ở đâu để người kiểm duyệt đối chiếu?”.

Còn EverOS chọn Markdown-first memory: memory agent được lưu thành file Markdown, index bằng SQLite và LanceDB, tìm bằng hybrid BM25 + vector retrieval. BM25 là tìm kiếm theo từ khóa kiểu search truyền thống; vector retrieval là tìm theo độ gần nghĩa. Kết hợp hai thứ giúp agent vừa bắt đúng thuật ngữ, vừa không bỏ lỡ câu tương đương về nghĩa.

Mình không nói bạn phải dùng đúng EverOS hay LlamaParse. Ý đáng giữ là: production AI cần chứng cứ có thể kiểm tra và memory có thể chỉnh sửa. Nếu memory chỉ là vector mờ mịt, khi agent nhớ sai bạn sẽ khó biết sai từ đâu. Nếu extraction không có attribution, khi người dùng hỏi “dựa vào đâu?”, hệ thống chỉ biết cười trừ.

Điều nên bỏ qua: chạy theo “open-source” như nhãn dán

Open-source AI là hướng đáng mừng, nhất là khi chi phí inference và quyền kiểm soát dữ liệu là chuyện sống còn. Nhưng “open-source” không tự động đồng nghĩa với rẻ, an toàn hoặc dễ vận hành.

Bạn vẫn phải tính:

Cloudflare Monetization Gateway cũng là tín hiệu nên nhìn tỉnh táo. Khi agent trở thành người dùng chính của web, tính tiền theo request/API/tool có lý. Nhưng builder cần chuẩn bị policy rõ: tool nào được gọi tự động, tool nào cần approval, tool nào có budget cap. Nếu không, agent của bạn có thể tiêu tiền rất đều đặn theo cách không ai vui.

Một buổi chiều để tự soi lại stack

Không cần đại tu ngay. Bạn có thể làm một bài audit gọn trong một buổi.

Bước 1: Vẽ 5 lớp hiện tại

Ghi ra hệ thống của bạn đang dùng gì cho compute, inference, storage, provenance, monetization/access. Chỗ nào ghi “chưa rõ” là chỗ cần ưu tiên.

Bước 2: Chọn một workflow thật

Đừng dùng prompt demo. Lấy một workflow có người dùng thật: coding agent sửa bug, chatbot tra tài liệu nội bộ, pipeline đọc invoice, agent gọi MCP tool.

Bước 3: Đo 6 chỉ số tối thiểu

Bước 4: Đặt câu hỏi thay model bằng gì

Nếu đổi model ngày mai, lớp nào vỡ? Prompt? Tool schema? Eval? Cache? Billing? Đây là bài test rất thật. Một hệ thống có móng tốt sẽ đổi model như thay vật liệu hoàn thiện, không phải đập lại cả nền.

Bước 5: Chốt một quyết định nhỏ

Ví dụ: thêm log attribution cho document extraction; tách budget theo tool call; benchmark lại coding agent với concurrency thật; đưa memory quan trọng về format có thể review bằng Git.

Sau bài này, bạn nên nghĩ khác điều gì?

Đừng hỏi “release này có model nào mới?” trước. Hỏi: release này củng cố lớp nào trong AI stack của mình?

Together AI đáng chú ý vì nó kéo câu chuyện open-source AI về compute và inference production. Nhưng các mảnh ghép quanh nó — storage cho Linux workloads, payment gateway cho agent, bounding boxes cho document AI, memory runtime có thể inspect — mới làm rõ bức tranh: AI app không còn là một model cộng prompt. Nó là một hệ thống nhiều lớp, mỗi lớp có failure mode riêng.

Takeaway gọn: builder giỏi không chạy theo mái nhà bóng bẩy; họ kiểm tra móng trước khi nâng thêm tầng. Và nếu móng còn rung, đừng trách cái cửa sổ trả lời chậm.

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

Nguồn tham khảo