{"slug": "why-day-0-for-nemotron-3-5-lightning-wasn-t-a-scramble", "title": "Why Day 0 for Nemotron 3.5 Lightning wasn't a scramble", "summary": "NVIDIA released Nemotron-3.5-Lightning, a 30B mixture-of-experts model with 3B active parameters, on the same day Modelplane, an open-source fleet-level control plane for inference, achieved zero-day support by running it on a live endpoint without any platform upgrade. Modelplane's design decouples from the engine, allowing new models to be adopted as soon as the engine supports them, as demonstrated by a ready-to-run recipe on a single Nebius H100.", "body_md": "NVIDIA released [Nemotron-3.5-Lightning](https://developer.nvidia.com/blog/nvidia-nemotron-3-5-lightning-delivers-fast-accurate-specialized-task-execution-for-long-running-agents) this morning. We had it running on Modelplane, our open-source fleet-level control plane for inference, this afternoon. We validated it against a live endpoint on a real GPU, with a [ready-to-run recipe](https://docs.modelplane.ai/examples/nemotron-3.5-lightning/) published the same day.\n\nWe wrote no Modelplane code to get there. We didn't cut a release. Modelplane has zero day support for new models as an inherent property of its design.\n\n## The model[#](#the-model)\n\nNemotron-3.5-Lightning is a 30B mixture-of-experts with 3B active parameters, built for the execution layer of long-running agents: the tool calls, result validation, and subagent handoffs a reasoning model triggers but doesn't do itself. It's a hybrid Mamba-Transformer, shipped in NVFP4, with open weights on Hugging Face. NVIDIA reports large output-speed gains over similarly sized models on agentic tasks; the numbers are in [their announcement](https://developer.nvidia.com/blog/nvidia-nemotron-3-5-lightning-delivers-fast-accurate-specialized-task-execution-for-long-running-agents).\n\n## Deploying it with Modelplane[#](#deploying-it-with-modelplane)\n\nStage the weights to the clusters where you want to deploy the model:\n\nThen deploy it. The deployment uses a stock vLLM container with the flags from NVIDIA's cookbook:\n\nThe NVFP4 checkpoint (~20 GiB) fits on a single H100 with room for the KV and Mamba caches, so it runs on one GPU in one pod.\n\nWe ran this recipe on vLLM, end to end on a single Nebius H100; serving and tool calls both worked. NVIDIA also publishes SGLang and TensorRT-LLM recipes for the same model. On Modelplane those are the same `ModelDeployment`\n\nwith a different engine image and flags.\n\n## Day zero model support, no platform upgrade[#](#day-zero-model-support-no-platform-upgrade)\n\nRunning a new model almost always takes engine work. Sometimes the engine can't load the architecture until new code lands; sometimes it loads but support keeps improving for weeks. Nemotron-3.5-Lightning is a hybrid Mamba-Transformer served in NVFP4, so serving it well is real work in the engine: the architecture, the NVFP4 kernels, a state-space-model cache, a reasoning parser for its thinking format. That work happens in the engine, on the engine's schedule.\n\nBut what sits between a new engine build and you running it? Most systems that orchestrate engines on Kubernetes are coupled to the engine: they wrap it, pin its version, or ship it inside their own runtime image. When the engine moves to support a new model, a coupled layer often has to move with it. So the real sequence becomes upgrade the orchestration layer, then adopt the new engine, then run the model. Upgrading the layer that runs your whole fleet is a far bigger, riskier change than pulling a new engine image.\n\nModelplane is never in that chain. It doesn't wrap the engine or rewrite your flags; it runs the image, command, and args you give it, exactly as written. The engine is a container you point at, with no Modelplane version pinned to it. New engine, new model, nothing to upgrade in between. The design guarantees it.\n\nWhat Modelplane does instead is the fleet: provisioning clusters and node pools, scheduling each replica onto hardware that fits, caching weights once per cluster, scaling replicas, and routing through one OpenAI-compatible endpoint. None of that is model-specific, so a new model arrives on the engine's release cadence, whichever engine you run.\n\nYou can watch it happen. Support for this model is still improving in SGLang: a fix to its NVFP4 mixture-of-experts path is [merged upstream](https://github.com/sgl-project/sglang/pull/33543) but not yet in a tagged release. When it ships, adopting it is a one-line change, the engine image in a `ModelDeployment`\n\n, and nothing in Modelplane moves.\n\n## Try it[#](#try-it)\n\nThe full recipe is in the docs: [Nemotron-3.5-Lightning on Modelplane](https://docs.modelplane.ai/examples/nemotron-3.5-lightning/).\nModelplane is Apache 2.0, still early, and evolving fast at [github.com/modelplaneai/modelplane](https://github.com/modelplaneai/modelplane).\n\nIf you run inference across more than one cluster, we'd like your issues.", "url": "https://wpnews.pro/news/why-day-0-for-nemotron-3-5-lightning-wasn-t-a-scramble", "canonical_source": "https://modelplane.ai/blog/nemotron-3-5-lightning-day-zero", "published_at": "2026-08-11 00:00:00+00:00", "updated_at": "2026-08-11 23:50:51.120083+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-infrastructure", "ai-tools"], "entities": ["NVIDIA", "Nemotron-3.5-Lightning", "Modelplane", "Hugging Face", "vLLM", "Nebius", "SGLang", "TensorRT-LLM"], "alternates": {"html": "https://wpnews.pro/news/why-day-0-for-nemotron-3-5-lightning-wasn-t-a-scramble", "markdown": "https://wpnews.pro/news/why-day-0-for-nemotron-3-5-lightning-wasn-t-a-scramble.md", "text": "https://wpnews.pro/news/why-day-0-for-nemotron-3-5-lightning-wasn-t-a-scramble.txt", "jsonld": "https://wpnews.pro/news/why-day-0-for-nemotron-3-5-lightning-wasn-t-a-scramble.jsonld"}}