# NVIDIA Nemotron3.5 Lightning and NeMo Switchyard: routing library and specialist model

NeMo Switchyard and NemotronLightning solve different layers of a specialist system, so a routing library cannot choose the correct model from one attractive benchmark score.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-08-11
Original announcement: https://blogs.nvidia.com/blog/nemotron-lightning-switchyard-rtx-dgx/
Canonical URL: https://retrivium.ai/retrospectives/retro-nemotron35-lightning-router-library/

NeMo Switchyard and NemotronLightning solve different layers of a specialist system, so a routing library cannot choose the correct model from one attractive benchmark score.

## Selection is different from execution

A router decides where a task should go; the selected model then attempts it. Good execution on one task class does not establish that the router recognizes that class reliably. Likewise, a routing rule cannot make an unsuitable specialist satisfy an unsupported output contract.

## Separate artifacts in one announcement

The [NVIDIA announcement](https://blogs.nvidia.com/blog/nemotron-lightning-switchyard-rtx-dgx/) introduces the model and routing library as distinct artifacts. The earlier [Nemotron3 paper](https://arxiv.org/abs/2512.20856) and [Ultra paper](https://arxiv.org/abs/2606.15007) provide dated family context. They do not collapse selection policy and model behaviour into one undifferentiated capability that can be evaluated with a single isolated model score.

The release creates a composition opportunity. Acceptance evidence should nevertheless identify both the route chosen and the result produced. Otherwise an error assigned to the specialist may actually begin with selection, while a routing success may be credited for work completed only after an unnecessary detour.

## A mixed-workflow example

Imagine a queue containing concise field extraction and open-ended planning. A compact executor may fit one role while another needs a different contract. The routing rule should identify the relevant task properties instead of sending everything to whichever model has the most impressive headline.

| Observation | Diagnostic layer |
| --- | --- |
| Appropriate specialist, wrong output | Inspect execution and task acceptance. |
| Inappropriate specialist selected | Inspect routing features and policy. |
| Correct output after repeated fallback | Inspect the full route, not only its final model. |

## A routing acceptance set

Include ambiguous tasks and cases outside the intended specialist scope. A rule evaluated only on clear examples can look reliable until the application presents mixed requirements. A fallback needs an explicit reason rather than silently becoming the normal path while the initial selection is still counted as successful.

Preserve the route, relevant task evidence and outcome together. This lets an operator distinguish model capability from allocation quality. Without that record, aggregate success can hide a router that chooses poorly but is repeatedly rescued by later stages. The chain works, but the source of its success is misunderstood.

## The retrospective lesson

The announcement matters because specialist execution and routing can be examined as connected artifacts. Their relationship creates new design choices, not a universal ranking that automatically determines deployment policy.

The conclusion is to test routing and execution separately before the chain. A model score can inform selection, but only task-specific routing evidence shows whether the system sends appropriate work to that model under the intended workload.

Further analysis: [Reproducible inference stacks: preserving a GPU pilot’s result](/journal/software-stack-reproducibility/); [GPU hosting for multimodal models: count more than text](/journal/multimodal-gpu-hosting/).