NVIDIA launches Nemotron 3.5 Lightning and NeMo Switchyard for multi-model agents

NVIDIA has expanded its open-model lineup with Nemotron 3.5 Lightning and released NeMo Switchyard, a routing library meant to help agent systems choose among several models instead of sending every request to the same one. The August 11 release pairs a relatively compact model for high-volume specialized work with software that can direct each step of an agent workflow according to requirements such as accuracy, latency and cost. Together, the products show how the industry is moving from competition between individual models toward systems in which models play different roles.

Nemotron 3.5 Lightning is a 30-billion-parameter mixture-of-experts model. In that architecture, only part of the network is activated for a given request, allowing the model to offer more total capacity without using every parameter for every token. NVIDIA positions Lightning as a worker inside a larger agent system rather than the model that must plan and solve every part of a job. The company names code review, tool use, security-alert monitoring and billing questions among the specialized tasks it is intended to handle, while a larger frontier model can coordinate the broader workflow.

The company says Lightning can deliver up to four times faster output and complete agentic tasks 30 percent faster than other models in its class. Those figures come from NVIDIA and the evaluations described in its announcement, so buyers will still need to test the model on their own workloads. The release was developed with contributions from the Nemotron Coalition, and NVIDIA is publishing an agentic reinforcement-learning dataset used for coding-agent post-training. Organizations can also adapt the model with NVIDIA NeMo using their own domain data, tools and work patterns.

Deployment flexibility is a central part of the pitch. NVIDIA says the model can run locally on RTX PCs, DGX Spark, DGX Station and Jetson systems, as well as across workstations, data centers, edge devices and cloud services. Local or on-premises operation can matter when a task has high request volume, requires quick responses or involves information an organization does not want to send to a third-party model endpoint. Lightning is available through Hugging Face, ModelScope, OpenRouter and NVIDIA services, including an NVIDIA NIM microservice.

NeMo Switchyard addresses a different source of cost. A capable frontier model may be useful for a difficult reasoning step but unnecessarily expensive for a routine classification or lookup. The open-source library lets developers create a router that sends prompts to different open, proprietary or NVIDIA models without rewriting the surrounding application. Its routing logic can be modified to reflect a team’s preferred balance of quality, response time and expense. NVIDIA says its internal benchmarks retained frontier-level accuracy while reducing task-completion cost to nearly one-third of using Opus 4.8 alone.

Partner results in the announcement illustrate both the promise and the limits of routing claims. LangChain reported 74 percent lower cost across 145 multi-turn Deep Agents tasks when only 7 percent of calls went to a frontier model, but it also recorded a 6 percent accuracy trade-off. Ramp said it matched frontier-model performance while cutting cost by 58 percent and runtime by 33 percent on its software-engineering benchmark. Cognition reported a 28 percent reduction in mean cost for a staged router used with Devin Desktop in NVIDIA’s internal environment. These are vendor and partner measurements, not a universal guarantee.

The release makes model selection an explicit engineering decision inside agent products. A router can reduce waste, but it also introduces another component that must be evaluated: a poorly chosen route can save money while degrading the answer or sending sensitive work to the wrong environment. The practical test for Nemotron 3.5 Lightning and Switchyard will be whether teams can measure routing decisions, detect quality regressions and override the system when a task requires a specific model. If that operational layer holds up, multi-model agents may become less dependent on one expensive default and more closely resemble other distributed software systems, with specialized services chosen for the work they perform best.