OpenRouter phân tích cách NVIDIA Nemotron 3.5 Lightning tối ưu hóa tác vụ cho AI Agent

Một tác nhân (agent) có thể thực hiện một yêu cầu khó để lập kế hoạch cho một tác vụ và hàng chục yêu cầu khác để thực thi nó. Những yêu cầu sau đó sẽ đọc tệp, chọn công cụ, xác thực kết quả và quyết định việc cần làm tiếp theo. NVIDIA đã xây dựng Nemotron 3.5 Lightning cho phần khối lượng công việc lớn đó trong quy trình làm việc.

Nemotron 3.5 Lightning là mô hình mixture-of-experts (hỗn hợp chuyên gia) với 30 tỷ tham số, kích hoạt khoảng 3 tỷ tham số cho mỗi token. Nó hỗ trợ gọi công cụ, các tác vụ lập trình, tuân thủ hướng dẫn và các bước tác nhân có phạm vi rõ ràng khác.

Tên gọi này dễ gây nhầm lẫn với Nemotron 3 Ultra, nhưng hai mô hình này được xây dựng cho các phần khác nhau trong quy trình làm việc của tác nhân. Việc lựa chọn giữa chúng ảnh hưởng đến chi phí, độ trễ và độ tin cậy của toàn bộ quá trình chạy.

Tổng quan về Nemotron 3.5 Lightning

Các giới hạn và tính năng của endpoint trong bảng này được lấy từ các trang mô hình của chúng tôi vào ngày 11 tháng 9 năm 2026. Hãy kiểm tra trang mô hình tiêu chuẩn hoặc trang mô hình miễn phí trước khi thiết kế dựa trên một giới hạn cụ thể.

30B MoE với 3B tham số hoạt động có nghĩa là gì?

Nemotron 3.5 Lightning là một mô hình mixture-of-experts thưa (sparse). Nó chứa tổng cộng 30 tỷ tham số, nhưng không sử dụng mọi chuyên gia cho mỗi token. Một bộ định tuyến (router) sẽ chọn một tập hợp con nhỏ hơn các chuyên gia khi mô hình xử lý từng token, giúp đưa số lượng tham số hoạt động lên khoảng 3 tỷ. Bạn cũng sẽ thấy điều này được viết là 30B-A3B, nghĩa là 30 tỷ tham số tổng cộng và khoảng 3 tỷ tham số hoạt động.

Thiết kế này mang lại cho mô hình tổng dung lượng lớn hơn so với một mô hình dày (dense) 3B mà không cần chạy toàn bộ 30 tỷ tham số cho mỗi token. Đó là cách Lightning kết hợp một checkpoint tương đối lớn với thông lượng cần thiết cho các yêu cầu tác nhân thường xuyên.

Số lượng tham số hoạt động không phải là thông số kỹ thuật đầy đủ về tính toán hoặc bộ nhớ. Toàn bộ mô hình vẫn phải được lưu trữ và các lớp chia sẻ cũng chạy trong quá trình suy luận (inference). Các yêu cầu phần cứng phụ thuộc vào độ chính xác, độ dài ngữ cảnh, công cụ suy luận, chiến lược batching và cấu hình bộ nhớ đệm (cache).

Lightning cũng sử dụng kiến trúc lai thay vì một ngăn xếp Transformer thuần túy. Thẻ mô hình của NVIDIA mô tả các lớp Mamba-2 và MoE xen kẽ với các lớp attention được chọn lọc. Nó cũng hỗ trợ lập luận có thể cấu hình và đi kèm với khả năng dự đoán đa token cùng hai bộ soạn thảo giải mã suy đoán (speculative-decoding drafters) là DSpark và DFlash để tạo văn bản nhanh hơn, cùng với một checkpoint NVFP4 được tinh chỉnh cho suy luận.

Nemotron 3.5 Lightning được thiết kế để làm gì?

Các tác nhân chạy dài thực hiện rất nhiều yêu cầu mô hình. Một số yêu cầu đòi hỏi sự lập kế hoạch khó khăn. Phần lớn công việc mang tính hẹp hơn, chẳng hạn như chọn công cụ, tạo đối số, kiểm tra kết quả, chỉnh sửa tệp hoặc quyết định việc cần làm tiếp theo.

NVIDIA định vị Lightning cho lớp thực thi đó. Mô hình này là một ứng viên khi khối lượng công việc của bạn có các đặc điểm sau:

Ví dụ, một tác nhân lập trình có thể sử dụng một mô hình lập luận lớn hơn để kiểm tra kho lưu trữ và quyết định kế hoạch triển khai. Sau đó, Lightning có thể xử lý các bước riêng lẻ như định vị một ký hiệu, chỉnh sửa một tệp, chạy một công cụ và diễn giải kết quả.

So sánh Nemotron 3.5 Lightning với Nemotron 3 Ultra

NVIDIA đã chưng cất (distilled) Lightning từ Nemotron 3 Ultra, nhưng hai mô hình này không thể thay thế cho nhau. Lightning là mô hình nhỏ hơn dành cho việc thực thi tác nhân khối lượng lớn. Ultra là mô hình lớn hơn dành cho việc lập luận phức tạp và điều phối.

NVIDIA báo cáo rằng Lightning đạt thông lượng gấp bốn lần so với các mô hình mở có kích thước tương đương. Trong thử nghiệm PinchBench của NVIDIA, nó đã hoàn thành 10.000 tác vụ tác nhân nhanh hơn tới 30% với độ chính xác tương đương. Đây là kết quả do nhà cung cấp báo cáo, vì vậy hãy tự kiểm tra thông lượng và khả năng hoàn thành tác vụ trên khối lượng công việc của riêng bạn.

Sự khác biệt nằm ở độ khó và hậu quả của yêu cầu. Ultra phù hợp hơn khi một bước đòi hỏi lập luận sâu sắc về một vấn đề mơ hồ, tạo ra kế hoạch cho một quy trình làm việc dài hoặc đưa ra quyết định khó đảo ngược. Lightning phù hợp hơn khi tác vụ có phạm vi rõ ràng và được lặp lại đủ thường xuyên để độ trễ và chi phí trở nên quan trọng.

Bạn không cần phải gán một mô hình cho toàn bộ tác nhân. Hãy định tuyến các yêu cầu phức tạp đến Ultra và các yêu cầu thực thi thường xuyên đến Lightning. Sau đó, hãy đo lường xem sự kết hợp này có cải thiện chi phí trên mỗi tác vụ hoàn thành mà không làm giảm độ tin cậy hay không.

Định tuyến giữa hai mô hình trên OpenRouter

Nếu bạn muốn giao việc chọn mô hình cho chúng tôi, hãy sử dụng Auto Router. Gửi openrouter/auto làm ID mô hình, và Auto Router sẽ phân loại prompt trước khi chọn mô hình dựa trên loại tác vụ, khả năng của mô hình, hỗ trợ công cụ và chi phí. Cài đặt cost_tier chọn một dải chi phí, từ thấp đến tối đa. Nó không nâng cấp cuộc hội thoại từ mô hình rẻ hơn sang mô hình đắt hơn. Nếu bạn muốn Auto Router chỉ chọn giữa Lightning và Ultra, hãy giới hạn các lựa chọn của nó bằng allowed_models.

Định tuyến giữa hai mô hình bên ngoài OpenRouter

NeMo Switchyard của NVIDIA triển khai mô hình định tuyến này như một lớp điều phối mã nguồn mở. Bộ định tuyến leo thang (escalation router) của nó bắt đầu mỗi cuộc hội thoại với một mô hình chi phí thấp hơn, và một LLM đóng vai trò giám khảo sẽ chuyển phiên làm việc sang một mô hình có khả năng hơn khi phát hiện sự khó khăn kéo dài. Trong đánh giá của LangChain về 145 tác vụ tác nhân đa bước, việc định tuyến giữa Lightning và Claude Opus 4.8 đã giảm chi phí 74% so với đường cơ sở chỉ dùng mô hình tiên phong (frontier-only), trong khi gửi khoảng 7% yêu cầu đến mô hình tiên phong. Độ chính xác thấp hơn khoảng sáu điểm. Kết quả này cho thấy sự đánh đổi trong định tuyến trên điểm chuẩn đó. Đây không phải là điểm chuẩn của sự kết hợp giữa Lightning và Ultra. Hãy kiểm tra bất kỳ thiết lập định tuyến nào trên các tác vụ của riêng bạn trước khi dựa vào khoản tiết kiệm đó.

Cửa sổ ngữ cảnh dài bao nhiêu?

Nemotron 3.5 Lightning hỗ trợ lên đến 1 triệu token ở cấp độ mô hình. Ngữ cảnh khả dụng cho ứng dụng của bạn phụ thuộc vào endpoint phục vụ nó.

Vào ngày 11 tháng 9 năm 2026, mọi nhà cung cấp đằng sau ID mô hình tiêu chuẩn đều cung cấp cửa sổ ngữ cảnh 262.144 token. Các giới hạn hoàn thành khác nhau tùy theo nhà cung cấp, từ 32.768 đến 235.929 token. Mô hình:free cung cấp toàn bộ cửa sổ ngữ cảnh 1 triệu token và giới hạn hoàn thành ở mức 65.536 token.

Nếu một yêu cầu cần hơn 262.144 token, hiện tại chỉ có endpoint miễn phí mới cung cấp toàn bộ ngữ cảnh 1 triệu token của mô hình trên OpenRouter. Thông báo của NVIDIA trên endpoint đó nêu rõ rằng việc sử dụng được ghi lại vì mục đích bảo mật và để cải thiện các sản phẩm và dịch vụ của NVIDIA, đồng thời yêu cầu bạn không tải lên thông tin bí mật hoặc dữ liệu cá nhân. Đối với các khối lượng công việc nhạy cảm hoặc cần ngữ cảnh dài trong sản xuất, hãy chọn một endpoint hoặc mô hình khác.

Sự khác biệt này rất quan trọng khi bạn chuyển đổi giữa hai ID mô hình. Một yêu cầu thành công trên endpoint miễn phí có thể vượt quá giới hạn ngữ cảnh của endpoint tiêu chuẩn. Endpoint miễn phí cũng liệt kê tính năng gọi công cụ nhưng không liệt kê response_format hoặc structured outputs.

Hãy kiểm tra trang mô hình thay vì coi ngữ cảnh tối đa của kiến trúc là lời hứa từ mọi nhà cung cấp. Chúng tôi hiển thị các giới hạn hiện tại và các tham số được hỗ trợ cho từng endpoint trên trang mô hình.

Trọng số mở và triển khai cục bộ

NVIDIA xuất bản checkpoint tham chiếu BF16 theo giấy phép OpenMDW-1.1. Thẻ mô hình mô tả bản phát hành BF16 như một điểm khởi đầu cho việc hậu đào tạo, thích ứng miền, nghiên cứu và tạo ra các biến thể tối ưu hóa. NVIDIA cũng xuất bản dữ liệu đào tạo và công thức để tùy chỉnh và đánh giá, và thẻ mô hình cho biết bản phát hành đã sẵn sàng cho mục đích thương mại.

Để suy luận trực tiếp, NVIDIA khuyến nghị bản phát hành NVFP4 của họ. Nó cũng cung cấp một checkpoint GGUF cho các hệ thống cục bộ được hỗ trợ. Hướng dẫn BF16 liệt kê H100 80GB hoặc A100 80GB cho việc triển khai trên một GPU. Các bản phát hành tối ưu hóa nhắm mục tiêu vào phần cứng như RTX 5090, RTX PRO 6000 và DGX Spark.

Chạy mô hình cục bộ không có nghĩa là mọi máy đều có thể phục vụ toàn bộ cửa sổ ngữ cảnh 1 triệu token. Trong hướng dẫn Ollama hiện tại của NVIDIA, ngữ cảnh mặc định tỷ lệ thuận với VRAM khả dụng. Nó là 4K dưới 24GB, 32K từ 24GB đến dưới 48GB và 256K với 48GB trở lên. Ví dụ llama.cpp sử dụng khoảng 40K. Bạn có thể nâng các giới hạn đó lên, và việc làm như vậy có thể yêu cầu nhiều bộ nhớ hơn hoặc giảm tải CPU.

Các trọng số được công khai và "open-weight" là mô tả rõ ràng nhất. Hãy đọc giấy phép OpenMDW-1.1 trước khi bạn phân phối lại một mô hình đã sửa đổi hoặc đưa ra các quyết định triển khai dựa trên các điều khoản của nó.

Cách gọi Nemotron 3.5 Lightning trên OpenRouter

Nếu bạn không muốn cung cấp GPU hoặc quản lý công cụ suy luận, hãy gọi Lightning thông qua OpenRouter. ID mô hình tiêu chuẩn giữ nguyên API trong khi chúng tôi định tuyến các yêu cầu qua các nhà cung cấp khả dụng cho mô hình đó.

Cài đặt OpenRouter TypeScript SDK.

Thiết lập OPENROUTER_API_KEY trong môi trường của bạn, sau đó gửi yêu cầu với ID mô hình Lightning. Mô hình tiêu chuẩn liệt kê structured outputs, vì vậy bạn có thể yêu cầu một lược đồ JSON và phản hồi sẽ tuân thủ theo đó.

Khi chúng tôi chạy yêu cầu này vào ngày 11 tháng 9 năm 2026, mô hình đã trả về {"category": "Bug (Payment Checkout)", "priority": "medium"}. Các kết quả đầu ra được lấy mẫu thay đổi giữa các lần chạy, và lược đồ, không phải các giá trị, là thứ mà yêu cầu đảm bảo.