Hải đồ cho agent chạy thật

Hải đồ cho agent chạy thật

Nemotron 3 Ultra đáng chú ý, nhưng quyết định của builder không nằm ở model mới nhất. Nó nằm ở cách bóc hệ thống agent theo lớp vận hành.

Bạn có dám chọn model cho agent mà không nhìn leaderboard trước không?

Câu hỏi nghe hơi ngược đời, nhất là trong tuần có một model open mới được đưa lên Amazon SageMaker JumpStart từ ngày đầu: NVIDIA Nemotron 3 Ultra. Một cú click để deploy, 550 tỷ tham số tổng, 55 tỷ tham số active, tối ưu NVFP4, quảng bá nhanh hơn 5 lần và giảm tới 30% chi phí cho agentic workloads. Nếu chỉ đọc phần headline, tay bạn rất dễ trượt xuống nút triển khai như đang thấy hải đăng giữa đêm.

Nhưng với team đang build hệ thống AI thật, câu hỏi không phải là: “Model này có mạnh không?” Câu hỏi đúng hơn là: hệ thống của mình đang nghẽn ở lớp nào?

Sau bài này, mình muốn bạn đổi một thói quen: đừng chọn model agent như chọn động cơ lớn nhất. Hãy bóc nó như một hải trình có nhiều đoạn nước: reasoning, tool access, inference startup, governance, document pipeline, và cost-per-task.

Sơ đồ minh họa cho bài Hải đồ cho agent chạy thật

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

Tín hiệu chính: model đang được bán như một phần của hệ thống

Nemotron 3 Ultra không chỉ được giới thiệu như một large language model. Nó được đặt thẳng vào ngữ cảnh agent chạy dài: lập kế hoạch, gọi tool, chia việc cho sub-agent, tự kiểm tra kết quả, rồi tiếp tục qua nhiều lượt.

Ở đây có vài thuật ngữ cần neo lại cho gọn:

Điểm đáng bàn là AWS và NVIDIA đang đóng gói thông điệp theo hướng production: không chỉ benchmark thông minh, mà là thời gian hoàn thành task, độ ổn định qua nhiều bước, và chi phí trên mỗi task. Đây là ngôn ngữ gần với builder hơn.

Nhưng gần hơn không có nghĩa là đủ.

Lớp 1: reasoning dài không cứu được workflow rối

Nemotron 3 Ultra nhắm tới agent cần reasoning nhiều bước: coding agent, deep research, enterprise workflow có nhánh quyết định và recovery khi lỗi. Với MoE, model có tổng quy mô lớn nhưng chỉ dùng 55B active parameters trong mỗi forward pass, giúp throughput dễ chịu hơn so với một dense model cùng cỡ chất lượng.

Nói thẳng ra thì: model này hấp dẫn nếu bài toán của bạn thật sự cần duy trì mạch suy luận qua nhiều bước, chứ không chỉ trả lời một câu hỏi hay viết một đoạn code ngắn.

Ví dụ cụ thể: giả sử team bạn đang có agent đọc issue, tìm file liên quan, sửa code, chạy test, đọc log lỗi, rồi sửa tiếp. Nếu mỗi lần model quên mục tiêu ban đầu sau vài vòng, context dài và reasoning ổn định có thể giúp. Nhưng nếu agent đang gọi sai API, thiếu permission, hoặc không biết khi nào dừng, đổi sang model mới chỉ làm nó sai nhanh hơn.

Framework mình hay dùng ở lớp này:

| Câu hỏi | Nếu câu trả lời là “có” | Quyết định hợp lý |
|---|---|---|
| Task có hơn 10 bước phụ không? | Có nhiều plan, tool call, retry | Test model agent-oriented |
| Lỗi chính là quên trạng thái? | Mất mục tiêu, lặp việc | Ưu tiên context + memory design |
| Lỗi chính là tool/API? | Sai credential, sai schema | Sửa orchestration trước |
| Chi phí đội lên theo vòng lặp? | Agent tự sửa quá nhiều lần | Đo cost-per-task, không đo token đơn lẻ |

Đây là mỏ neo đầu tiên: model mạnh chỉ đáng tiền khi lỗi chính nằm ở reasoning, không phải ở workflow hygiene.

Lớp 2: tool access mới là chỗ production hay va đá

Nguồn liên quan về Bedrock AgentCore Identity nghe có vẻ rất “hạ tầng”, nhưng lại chạm đúng nỗi đau production: agent cần gọi CRM, Slack, GitHub, database, hoặc API nội bộ. Muốn gọi được thì cần credential. Muốn credential an toàn thì không được hardcode trong code hay nhét vào prompt.

AWS cho phép AgentCore Identity tham chiếu secret có sẵn trong AWS Secrets Manager. Secrets Manager là dịch vụ quản lý bí mật như API key, client secret, token; điểm quan trọng là team giữ được encryption, rotation, tags, replication, policy theo chuẩn sẵn có.

Đây là lớp nhiều demo bỏ qua. Demo agent thường chạy bằng token trong .env. Production agent thì khác: ai được gọi tool nào, secret xoay vòng ra sao, audit log nằm đâu, nếu token bị revoke thì agent fail kiểu gì?

Nếu team Việt Nam của bạn có 3-7 dev, đừng chờ đến lúc có “AI platform team” mới xử lý. Một buổi chiều là đủ để làm bản đồ quyền tối thiểu:

  1. Liệt kê 5 tool agent gọi nhiều nhất.
  2. Với mỗi tool, ghi rõ credential nằm ở đâu.
  3. Tách quyền đọc, ghi, xóa thành scope riêng.
  4. Định nghĩa lỗi khi secret hết hạn: retry, báo người, hay dừng task.
  5. Log tool call theo task ID, không log secret.

Nếu chưa làm được 5 bước này, model mới không phải nút thắt cổ chai. Nó chỉ là cánh buồm đẹp trên con tàu chưa kiểm tra khoang nước.

Lớp 3: inference nhanh còn phụ thuộc cold start

Một nguồn khác nhắc đến Dynamo Snapshot, hệ thống startup nhanh cho inference trên Kubernetes dựa trên CRIU và checkpoint/restore. Cold start là độ trễ từ lúc workload được scale lên đến lúc nó thật sự phục vụ request: kéo image, load weight vào GPU, warm up CUDA kernel, compile hoặc capture CUDA graph, đăng ký service discovery.

Với agent workload, cold start không chỉ làm user chờ. Nó phá SLA khi traffic tăng bất ngờ, vì GPU đã được cấp nhưng chưa tạo token nào. Checkpoint/restore là cách lưu trạng thái process đang chạy rồi khôi phục lại nhanh hơn, thay vì khởi động từ đầu.

Liên hệ với Nemotron 3 Ultra: dù model có throughput tốt, hệ thống vẫn có thể chậm nếu replica mới mất nhiều phút để sẵn sàng. Builder cần đo ba thứ cùng lúc:

Đây là lý do mình không thích câu “model X nhanh hơn” nếu không kèm ngữ cảnh deploy. Nhanh ở token/second khác với nhanh ở task completion. Nhanh khi pod đã warm khác với nhanh lúc traffic bất ngờ đổ vào.

Lớp 4: benchmark là tín hiệu, không phải bản đồ đi biển

Theo The Decoder, Nemotron 3 Ultra được Artificial Analysis xếp là model open của Mỹ mạnh nhất hiện tại trong bảng intelligence ranking, điểm 48; cao hơn Gemma 4 31B, Nemotron 3 Super và gpt-oss-120b, nhưng vẫn dưới một số model open từ Trung Quốc như Kimi K2.6 điểm 54. Nguồn cũng nhắc tốc độ hơn 300 tokens/second trên DeepInfra theo Artificial Analysis.

Các con số này đáng để nhìn. Nhưng nếu bạn là tech lead, đừng biến nó thành quyết định tự động.

Benchmark thường trả lời: model nào giỏi trên tập bài đo này? Production hỏi thêm: model nào ổn với repo của mình, tài liệu của mình, tool của mình, permission của mình, và ngân sách của mình?

Một cách test gọn trong một buổi chiều:

Chọn 20 task thật đã từng làm:
- 5 task coding có test fail
- 5 task research cần nhiều nguồn
- 5 task gọi API nội bộ
- 5 task đọc tài liệu dài

Đo:
- completion rate
- số tool call lỗi
- thời gian đến kết quả dùng được
- chi phí mỗi task
- số lần cần người can thiệp

Nếu Nemotron 3 Ultra thắng ở nhóm task nhiều bước nhưng thua ở task ngắn, đó không phải vấn đề. Đó là tín hiệu để route workload: task dài dùng model reasoning mạnh, task đơn giản dùng model rẻ hơn.

Lớp 5: document intelligence đừng bị quên ở tầng dưới

Nguồn từ LlamaIndex về Parse-Flow kéo mình về một lớp ít hào nhoáng hơn: document intelligence. Document intelligence là lớp biến tài liệu lộn xộn như PDF, invoice, contract, report thành dữ liệu downstream system dùng được.

Agent có context dài vẫn có thể trả lời tệ nếu đầu vào bị parse sai bảng, mất layout, lẫn header/footer, hoặc chunk tài liệu vô nghĩa. Với enterprise workflow, nhiều lỗi không nằm ở model mà nằm ở pipeline tài liệu trước đó.

Nếu bạn đang build agent cho hợp đồng, invoice, hồ sơ kỹ thuật, hãy thêm một cột vào ma trận chọn model: input quality risk. Tài liệu càng nhiều layout phức tạp, bạn càng cần kiểm tra parser, schema extraction, index quality trước khi đổ tiền vào model reasoning.

Đổi cách nghĩ ở đây rất quan trọng: agent không “thông minh” hơn dữ liệu nó được đưa vào theo cách hỗn loạn. Nó chỉ tự tin hơn khi đi lạc.

Điều đáng giữ, điều nên bỏ qua

Điều đáng giữ từ đợt release này không phải là cảm giác phải chạy theo model mới. Điều đáng giữ là một khung nhìn hệ thống:

Điều nên bỏ qua là cuộc đua “model nào thông minh nhất tuần này” nếu bạn chưa biết hệ thống mình đang rò ở đâu.

Nếu là mình, mình sẽ không deploy Nemotron 3 Ultra chỉ vì nó mới có trên SageMaker JumpStart. Mình sẽ chọn một hải trình nhỏ: 20 task thật, 2 model đối chứng, cùng một agent harness, cùng tool permission, cùng tài liệu đầu vào. Sau đó mới quyết định route workload, không quyết định bằng tiếng ồn.

Takeaway gọn: model mới chỉ đáng giá khi nó sửa đúng lớp đang đau trong hệ thống của bạn. Còn nếu chưa biết đau ở đâu, ra khơi bằng leaderboard thì dễ say sóng lắm.

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

Nguồn tham khảo