Báo cáo kỹ thuật của NVIDIA về Nemotron 3 Ultra xuất hiện trên feed của tôi tuần này, và rất dễ để lướt qua nó như “thêm một bản open-weight model nữa”. Đó sẽ là một sai lầm. Phần đáng chú ý không nằm ở bảng benchmark — mà nằm ở quyết định kiến trúc phía sau nó, vì đây là câu trả lời trực tiếp cho một vấn đề mà bất kỳ team nào đang chạy coding agent hoặc research agent chạy dài đều từng gặp: transformer trở nên đắt đỏ và chậm chính xác vào lúc context window dài ra — tức là đúng lúc workload dạng agent cần nó nhất.
Vấn đề mà kiến trúc này giải quyết
Attention chuẩn của transformer có độ phức tạp bậc hai (quadratic) theo độ dài chuỗi. Mỗi token bạn thêm vào context sẽ nhân chi phí attend tới mọi token khác lên. Với một lượt chat, việc này không sao. Nhưng với một agent đã chạy qua bốn mươi lần gọi tool, đã đọc vào lượng file tương đương cả một codebase, và đang giữ toàn bộ lịch sử hội thoại cộng với scratchpad suy luận, bạn phải trả chi phí bậc hai đó ở mỗi lượt forward pass — trong khi phần lớn context đó chỉ là “khung xương” cũ mà model hầu như không cần attend lại kỹ.
Các state-space model như Mamba giải quyết vấn đề mở rộng quy mô — chúng xử lý chuỗi với thời gian gần như tuyến tính — nhưng về mặt lịch sử phải đánh đổi một phần khả năng suy luận cặp-đôi chính xác mà dense attention làm tốt. Đó chính là điểm đánh đổi mà kiến trúc của Nemotron 3 Ultra được xây dựng để giải quyết: không chọn một trong hai, mà xen kẽ cả hai.
Cấu trúc lai được sắp xếp ra sao
Nemotron 3 Ultra có 550 tỷ tham số, nhưng chỉ 55 tỷ tham số được kích hoạt mỗi lượt forward pass — tỷ lệ sparsity 10x nhờ mixture-of-experts. Ba thành phần chính:
- Các lớp Mamba-2 đảm nhận phần lớn việc mô hình hóa chuỗi tầm xa. Đây là “cỗ máy” giúp mang context đi xa với chi phí rẻ trong cửa sổ 1 triệu token.
- Các lớp attention của transformer được xen kẽ theo chu kỳ để làm phần suy luận dense, cặp-đôi — những phần của tác vụ mà bạn thực sự cần token A attend trực tiếp tới token B cách đó hàng nghìn vị trí, chứ không chỉ dựa vào một trạng thái nén tóm tắt.
- Bộ định tuyến LatentMoE chọn expert nào được kích hoạt dựa trên biểu diễn latent thay vì embedding token thô — theo báo cáo của NVIDIA, cách này tránh được hiện tượng “routing collapse” thường gặp ở các cài đặt MoE ngây thơ (khi một vài expert hút hết lưu lượng còn số còn lại gần như không được huấn luyện).
Kết quả, theo số liệu NVIDIA công bố: throughput 300+ token/giây, tăng tốc tới 5 lần với lượng tử hóa NVFP4 trên phần cứng Blackwell, và chi phí token trên mỗi tác vụ thấp hơn khoảng 30% so với các mô hình dense tương đương về năng lực — trong khi hỗ trợ context gốc 262K (BF16) mở rộng tới 1 triệu token dưới NVFP4.
Vì sao điều này quan trọng với cách bạn triển khai agent, không chỉ với việc chọn model
Hệ quả thực tế của việc “mở rộng gần tuyến tính với context dài” là đường cong chi phí của một phiên agent chạy dài không còn giống như đâm vào tường nữa. Đây là cách ước lượng thô nếu bạn đang lập kế hoạch năng lực cho một nền tảng agent nội bộ:
# Ước lượng thô chi phí mỗi phiên: transformer dense vs hybrid Mamba-MoE
# Mô hình đơn giản hóa: chi phí dense attention scale ~O(n^2) theo context hiệu dụng,
# hybrid scale gần với ~O(n) cho phần do Mamba chi phối.
def dense_transformer_cost(context_tokens, cost_per_1k_quadratic=0.004):
# số hạng bậc hai chiếm ưu thế khi context vượt vài nghìn token
return (context_tokens / 1000) ** 2 * cost_per_1k_quadratic
def hybrid_moe_cost(context_tokens, active_params_ratio=0.10, cost_per_1k_linear=0.0009):
# active_params_ratio phản ánh tỷ lệ sparsity MoE 55B/550B
return (context_tokens / 1000) * cost_per_1k_linear * (1 + active_params_ratio)
for ctx in [8_000, 64_000, 262_000, 1_000_000]:
dense = dense_transformer_cost(ctx)
hybrid = hybrid_moe_cost(ctx)
print(f"{ctx:>9,} tokens -> dense: ${dense:8.2f} hybrid: ${hybrid:8.2f} ratio: {dense/hybrid:5.1f}x")Chạy đoạn code này và khoảng cách không có vẻ ấn tượng ở mức 8K token — chính ở khoảng 262K đến 1M token, sự khác biệt mới cộng dồn rõ rệt. Đó chính là khoảng mà một coding agent chạy dài, một pipeline ingest tài liệu, hay một vòng lặp research nhiều giờ đồng hồ đang sống trong đó. Nếu team bạn từng phải giới hạn độ dài phiên agent hoặc tóm tắt context một cách quyết liệt để kiểm soát chi phí, đây là cú đặt cược kiến trúc nói rằng bạn có thể không cần làm vậy nữa — ít nhất là không cần quyết liệt đến thế.
Điểm cần lưu ý: đây không phải model thông minh nhất
Điểm số NVIDIA tự công bố trên Artificial Analysis Intelligence Index là 48 — khá tốt với một open-weight model, nhưng Kimi K2.6 đạt 54 điểm và dẫn đầu ở GPQA Diamond cùng các benchmark suy luận khác. Nemotron 3 Ultra không chào hàng là “model thông minh nhất”. Nó chào hàng là “throughput trên mỗi đơn vị năng lực cao nhất ở context dài”, cộng thêm điểm 78.7 trên AA-Omniscience (benchmark chống ảo giác của họ) — một con số đáng chú ý với một model kích cỡ này, và điều đó quan trọng hơn điểm IQ thô đối với các workload dạng agent, nơi một lệnh gọi tool sai nhưng tự tin còn tệ hơn một lệnh gọi đúng nhưng chậm.
Tôi sẽ dùng nó ở đâu
Nếu workload agent của bạn bị giới hạn — các lượt chat ngắn, review một file code đơn lẻ, hỏi đáp nhanh — kiến trúc này mang lại rất ít giá trị; bạn chưa ở trong vùng mà chi phí bậc hai gây đau. Nơi nó thực sự đáng giá:
- Coding agent chạy dài, tích lũy diff lớn, context nhiều file, và lịch sử gọi tool suốt một phiên
- Pipeline RAG tổng hợp nhiều tài liệu, nơi nếu không có nó bạn buộc phải chunk hoặc re-rank quyết liệt để vừa với context nhỏ hơn
- Bất kỳ workload nào mà hiện tại bạn đang trả một “thuế context” bằng cách tóm tắt hoặc cắt bớt lịch sử chỉ để kiểm soát chi phí inference của transformer, chứ không phải vì thông tin đó không hữu ích
Góc nhìn trung thực cho một Tech Lead đang đánh giá công nghệ này: đừng thay sang Nemotron 3 Ultra chỉ vì nó mới hơn. Hãy thay nếu bạn có thể chỉ ra một điểm cụ thể trong pipeline của mình nơi độ dài context — chứ không phải độ thông minh của model — mới là nút thắt cổ chai gây ra chi phí hoặc độ trễ. Đó là một trường hợp sử dụng hẹp hơn so với những gì bài đưa tin ra mắt ngụ ý, nhưng nó là thật, và nó sẽ ngày càng phổ biến khi các phiên agent mặc định chạy dài hơn.
Nguồn: