GLM-5.2 vs Nemotron 3.5 Lightning for Agent Routing

Independent research — not an official Z.ai publication.Identity and provider disclosure

Model Research & Evaluation Editor

Editorial responsibility: GLM52.ai Editorial TeamPublished and editorially reviewed August 12, 2026

How we research and review Report a correction

Disclosed editorial pen name · AI-generated portrait

Agent router sending work to a compact single-GPU Nemotron executor and a much larger multi-node GLM-5.2 model route

Sources and immutable model metadata were checked on August 12, 2026. NVIDIA and SGLang speed claims remain labelled as publisher evidence.

The useful GLM-5.2 vs Nemotron 3.5 Lightning question is not which model wins an invented composite score. It is which jobs can move to a smaller executor without breaking tool behavior, context, license, latency, or recovery requirements. Nemotron 3.5 Lightning is a 30B-total, 3B-active hybrid mixture-of-experts model aimed at high-volume agent work. GLM-5.2 is a much larger sparse text model with established hosted and distributed-serving paths.

That scale gap can support a routed system: Nemotron handles repeatable, bounded steps, while GLM remains an escalation or separate workload route. It can also support a full replacement if Nemotron passes the same frozen tasks. Neither outcome follows from parameter count. The deployed checkpoint, serving engine, parser, context cap, and acceptance rule form the system being compared.

GLM52.ai fetched eight immutable metadata files in a digest-pinned disposable container. It downloaded no model weights and called neither model. The sanitized evidence receipt exposes exact indexed bytes, shards, revisions, config context fields, derived ratios, and limitations.

In this comparison

Route the work before ranking the models
Four checkpoints create four deployment floors
A single-GPU label still needs a memory gate
One-million-token labels are not equivalent
Treat Nemotron speed as publisher evidence
Keep GLM as a measured route, not an assumed winner
Migrate the reasoning and tool protocol
Freeze an accepted-task contract
Separate licenses and failure boundaries
Run a bounded routing pilot
Frequently asked questions
Sources and method

Route the work before ranking the models

An agent is a graph of roles, not one prompt. Inventory each role before choosing a checkpoint. A planner may need broad context and expensive review. An executor may receive a small typed instruction thousands of times. A verifier may need independence from the model that produced the answer. Routing all three through one model hides which capability creates value.

Work unit	Nemotron-first test	GLM-first or retained route	Fail-closed boundary
Repetitive tool execution	Bounded schema, short state, high volume	Retain GLM until Nemotron matches accepted-call rate	Never execute malformed or unapproved arguments
Repository-wide planning	Test only after measuring retrieval and state handoff	Use the selected GLM route when its larger context has measured value	Do not truncate source files without recording omissions
Local or isolated processing	Test pinned NVFP4 on a supported device	Self-host GLM only with a verified distributed recipe	Never send a local-only request to a hosted fallback silently
Specialized post-training	Start from Nemotron BF16 reference if its terms and toolchain fit	Keep the pinned GLM checkpoint when existing tuning evidence matters	Do not compare a tuned candidate with an untuned baseline without labels
High-impact final approval	Use Nemotron only if the external rubric passes	Keep GLM or a non-model control as an independent check	The producing model cannot approve its own high-impact output

This table defines tests, not model capability. A smaller model can outperform a larger route on a narrow, well-specified task. A larger context window can help a planner while adding cost and latency to a small tool call. Route by the smallest system that meets the declared contract, then preserve an explicit escalation rule.

The page differs from our Muse Glimmer local-agent comparison. Muse owns the local multimodal and 24/32 GB fit question. Nemotron owns a text-agent executor question with separate BF16 and optimized-inference artifacts, reasoning controls, and a migration path from an existing model route.

Four checkpoints create four deployment floors

Names such as “30B,” “3B active,” or “753B sparse” do not provide a memory plan. The immutable safetensor indexes provide an auditable weight-payload floor for each named artifact.

Official checkpoint	Intended role in its model card	Indexed payload	Shards	Pinned config context	License label
Nemotron 3.5 Lightning BF16	Customization reference	65,842,365,568 bytes / 61.320 GiB	14	262,144	OpenMDW-1.1
Nemotron 3.5 Lightning NVFP4	Optimized inference	21,559,589,596 bytes / 20.079 GiB	52	1,048,576	OpenMDW-1.1
GLM-5.2 BF16	Full-precision checkpoint	1,506,659,919,872 bytes / 1,403.186 GiB	282	1,048,576	MIT
GLM-5.2 FP8	Official reduced precision	755,617,140,416 bytes / 703.723 GiB	141	1,048,576	MIT

The indexed GLM BF16 payload is 22.883× the Nemotron BF16 payload. GLM FP8 is 35.048× the Nemotron NVFP4 payload. Within each family, Nemotron BF16 is 3.054× its NVFP4 payload, while GLM BF16 is 1.994× its FP8 payload.

Those ratios explain why the products belong in different infrastructure plans. They do not predict accepted-task quality, throughput, power, or price. Indexed bytes omit KV cache, graph captures, allocator behavior, activations, kernels, the operating system, speculative-decoding components, and concurrency. Compression can also change behavior. Compare the exact served artifact, not a family name.

The model architecture explains why active parameters and storage differ. Nemotron routes six experts per token from 128 routed experts plus a shared expert. GLM routes eight from 256 plus a shared expert. Sparse activation reduces token computation; it does not remove inactive experts from the served checkpoint. Our GLM local hardware guide covers that capacity distinction in depth.

A single-GPU label still needs a memory gate

The NVFP4 index occupies 20.079 GiB. Subtracting that from a nominal 32 GiB pool leaves 11.921 GiB. That is weight-only arithmetic, not proof of a working 32 GiB deployment. The remaining capacity must cover the runtime, KV cache, temporary buffers, graph capture, communication, and any draft model. Context and concurrent sequences can consume the margin.

The official Nemotron NVFP4 card describes the artifact as optimized for inference and provides single-device routes including DGX Spark and H100. Reproduce one documented profile before substituting a different GPU. Record GPU model, memory, driver, engine image, model revision, context cap, concurrency, reasoning mode, drafter, and peak allocated memory.

The BF16 index is 61.320 GiB before runtime overhead. Its official model card positions it as the customization reference and includes large-memory accelerator guidance. A 64 GiB capacity is not a comfortable BF16 inference plan because the weights alone consume most of it.

GLM sits in another class. Its FP8 payload requires at least nine nominal 80 GiB devices by weights-only division. Nine devices still provide no runtime headroom, and that arithmetic is not a supported topology. Use a documented engine recipe, topology, and context cap rather than turning a quotient into a procurement list.

One-million-token labels are not equivalent

The pinned Nemotron NVFP4 and both pinned GLM configs declare 1,048,576 positions. The pinned Nemotron BF16 config declares 262,144. A family-level “up to 1M” statement therefore does not describe every published artifact in the same way. Pin the repository revision and inspect the served config before advertising a limit.

Even matching config fields do not create matching usable windows. Context consumes KV-cache capacity and prefill time. System instructions, tool definitions, retrieved documents, reasoning tokens, and output share the window. A serving recipe can cap the model below its config maximum. A hosted endpoint can expose another limit. Long-input accuracy can degrade before a request is rejected.

Define context as an application receipt:

usable input budget = served context cap
                    - system and policy tokens
                    - tool definitions
                    - reserved reasoning/output tokens
                    - safety margin

Test at the longest accepted input, not a one-token prompt with a large flag. Hash the source set and record any retrieval, chunking, compression, or truncation. If Nemotron processes a repository through staged 128K or 256K segments while GLM receives one larger prompt, include handoff errors and repeated-prefix cost. If both receive one million tokens, include prefill time, peak cache, and lost-evidence tests.

Treat Nemotron speed as publisher evidence

The SGLang launch article describes OpenAI-compatible serving, reasoning on/off controls, reasoning budgets, multi-token prediction, and DFlash/DSpark acceleration. SGLang and NVIDIA’s launch article report up to 4× throughput and 30% faster completion for selected profiles.

Those are publisher results. This audit did not obtain the benchmark fixtures, normalize a GLM route to the same hardware, or rerun the measurements. “Up to” identifies a best reported case, not a service-level objective. MTP can increase accepted draft tokens for one workload while providing less benefit when tool calls, short outputs, or distribution shifts reduce acceptance.

Use the claims to design a reproduction receipt. Pin the exact SGLang build, checkpoint, quantization, GPU, tensor parallel setting, reasoning mode, MTP/DFlash configuration, prompt-length distribution, decode lengths, batch policy, and warmup. Report prompt and decode speed separately. Then measure cost per accepted task; raw tokens per second rewards output that may be rejected.

Nemotron’s intended role is useful evidence. NVIDIA presents it as an always-on, high-volume specialized agent rather than a universal frontier replacement. That framing supports a bounded executor trial. It does not prove which of your planner, verifier, coding, or tool tasks it can own.

Keep GLM as a measured route, not an assumed winner

GLM-5.2 provides an MIT checkpoint, a published one-million-token model window, and established hosted or distributed routes. Teams with an existing GLM prompt template, reasoning control, tool parser, provider contract, or Chinese-language workload have integration evidence worth preserving. None of those facts prove a quality lead over Nemotron.

The two publishers do not supply one shared, frozen pairwise harness in the materials reviewed here. Same-named benchmark rows can differ in task revision, prompts, tools, sampling, grader, exclusions, and run count. Subtracting them would manufacture precision. This page makes no universal intelligence, coding, or agent-success ranking.

Retain GLM when it passes a role that Nemotron has not yet matched, when its context route removes measured segmentation failures, or when its selected provider satisfies an operational requirement. Retain Nemotron when the local route passes the same contract at lower cost or higher throughput. Remove either route when it fails the predeclared floor. Model loyalty is not an acceptance criterion.

For a shared-harness design, use the run record and external-grader fields in our GLM-5.2 benchmark evidence hub. For client and route compatibility, start with the agent setup matrix and replace assumptions with exact model-specific receipts.

Migrate the reasoning and tool protocol

An OpenAI-compatible HTTP path reduces client changes; it does not guarantee semantic parity. Models can use different chat templates, reasoning delimiters, tool parsers, argument serialization, stop conditions, and retry behavior. Copying a model identifier into an existing GLM client can return 200 while corrupting the agent contract.

Inventory these boundaries before routing production work:

Prompt template: pin system-message placement, role order, tool-definition format, and assistant prefill rules.
Reasoning control: map GLM reasoning settings to Nemotron’s on/off and budget controls explicitly. Never infer equivalence from similar labels.
Tool parser: test one valid call, malformed JSON, unknown tool, missing required field, extra field, and denied action.
Stop and continuation: verify end tokens, tool-result insertion, maximum output, cancellation, and resumed state.
Structured output: validate JSON outside the model and reject schema violations before execution.
Observability: record selected route, checkpoint, engine, parser, reasoning mode, retries, tool decisions, and final acceptance without logging secrets.

Our GLM chat-template audit shows why tokenized protocol details matter. Create the same kind of pinned render receipt for Nemotron. Do not translate hidden reasoning text between models or depend on its presence. The application should consume validated final content and typed tool calls.

Freeze an accepted-task contract

Choose tasks from the role being migrated, not a broad leaderboard. A specialist executor trial might include 20 normal tool calls, five malformed-input cases, five tool failures, five interrupted runs, and five sensitive-data cases. Preserve every first attempt and provider error. Do not discard failures before calculating rate or cost.

Write the adoption rule before looking at model names:

Route a task class to the candidate only when:
- first-pass accepted-task rate meets the declared floor;
- severe unauthorized or malformed actions equal zero;
- p95 elapsed time and peak memory fit the operating budget;
- cost per accepted result improves by the required margin;
- context, license, data, isolation, and recovery gates all pass.

Escalate only when the policy permits the destination and payload.
Never retry a sensitive local task through a hosted route silently.

The external grader should compare final state, not prose confidence. For a file-edit tool, verify the exact allowed diff and test output. For retrieval, verify citations against the frozen corpus. For an API action, mock the write during evaluation and inspect the typed request. A model cannot grade its own call as safe.

Track cost per accepted result rather than per token alone:

accepted-result cost =
  (GPU rental + model/API tokens + retries + tool charges + review time)
  / accepted results

A fast model that requires repair may cost more than a slower first-pass route. A local GPU that waits idle may cost more than a hosted call. Record queueing, load time, prompt ingestion, generation, tools, retries, and human review separately so the bottleneck remains visible.

Separate licenses and failure boundaries

Nemotron’s official cards declare OpenMDW-1.1. GLM-5.2 declares MIT. These labels are not interchangeable, and this article is not legal advice. Review the exact checkpoint, tokenizer, serving code, quantization, training inputs you add, redistributions, notices, and downstream service terms with counsel. Do not copy a license conclusion from a family overview to a different artifact.

Operational failure boundaries matter as much as license text. A local executor can preserve data locality, but package downloads, telemetry, hosted tools, crash reporting, remote MCP servers, and silent fallback can still transmit content. Verify the assembled agent with outbound networking denied. Allowlist endpoints by role, not convenience.

Define escalation by data class. Public, low-impact work may move from Nemotron to a hosted GLM route after an observable error. Restricted work may remain local and fail closed. High-impact actions may require an independent model or deterministic policy check. A context overflow, out-of-memory error, parser failure, or quota response must not broaden permissions.

Run a bounded routing pilot

Start with one Nemotron NVFP4 serving profile and one existing GLM route. Pin both. Use a single task class and external grader. Keep temperature, tool set, input corpus, maximum output, retry count, and acceptance rule fixed; document any unavoidable adapter difference.

Run in this order:

Validate the Nemotron server with one non-consequential prompt and one mocked tool call.
Run malformed and denied-action fixtures before normal production-like tasks.
Measure at batch one, then raise concurrency one step at a time while recording peak memory and p95 latency.
Run the same fixtures through the pinned GLM route and retain provider failures.
Compare first-pass acceptance, severe failures, elapsed time, peak capacity, and cost per accepted result.
Route only the task classes that meet the frozen rule; leave every other class unchanged.
Add a canary percentage, route-level metrics, and an immediate rollback to the previous policy—not an unvalidated model alias.

Promote the executor only after the canary produces enough accepted tasks to estimate failure. If the role is rare or high impact, collect more evidence rather than widening the route from a handful of successes. Keep the GLM fallback explicit and policy-gated. If Nemotron replaces GLM for the tested role, remove dead adapter code and retain the old receipt for rollback analysis.

Frequently asked questions

Can Nemotron 3.5 Lightning replace GLM-5.2?

It can replace GLM for a task class only after the exact Nemotron checkpoint, server, template, reasoning mode, and tool parser pass the same frozen acceptance rule. Public launch materials do not establish a universal replacement. A routed system may use Nemotron for bounded high-volume execution and retain GLM for a separately measured role.

Does Nemotron 3.5 Lightning fit on one GPU?

The official NVFP4 card supplies single-device paths, and its indexed weights occupy 20.079 GiB. Runtime, KV cache, graphs, buffers, concurrency, and any drafter need additional capacity. Reproduce a supported profile at the required context and record peak memory; the weight subtraction alone is not a fit guarantee.

Do both models support one million tokens?

The pinned Nemotron NVFP4 and GLM configs declare 1,048,576 positions, while the pinned Nemotron BF16 config declares 262,144. A config maximum is not proof of feasible memory, provider exposure, long-input accuracy, or useful latency. Verify the exact served artifact and application budget.

Is Nemotron faster than GLM-5.2?

NVIDIA and SGLang publish strong throughput and completion-time claims for selected Nemotron profiles. We did not run a shared GLM comparison on the same hardware and fixtures, so those claims cannot answer this pairwise question. Measure prompt speed, decode speed, elapsed task time, failures, and cost per accepted result in one controlled harness.

Which license is easier for commercial use?

GLM’s official card declares MIT; Nemotron’s declares OpenMDW-1.1. “Commercial use” depends on the exact artifact, distribution, modifications, bundled components, and service design. Review both governing texts and downstream dependencies with counsel rather than choosing from the short label.

Sources and method

The discovery lead was the AI HOT SGLang/Nemotron 3.5 Lightning item. AI HOT supplied discovery only. Claims were checked against the SGLang release, NVIDIA launch article, official Nemotron BF16 card, official Nemotron NVFP4 card, Z.ai’s GLM-5.2 release, and the official GLM-5.2 repository.

The metadata probe used a digest-pinned python:3.13.5-slim-bookworm container and immutable revisions. It fetched four config.json files and four model.safetensors.index.json files with an identifiable user agent. The host’s known Docker bridge DNS failure reproduced in a bounded preflight, so the trusted outbound-only probe used the documented host-network exception. It opened no listener or published port. The repository and root filesystem were read-only, all Linux capabilities were dropped, and exact task container names were absent afterward.

The archived evidence under docs/evidence/glm-5-2-vs-nemotron-3-5-2026-08-12/ records execution controls and full probe URLs. The public JSON receipt publishes revisions, statuses, bytes, context fields, ratios, and limitations. The probe read 20,658,716 metadata bytes. It downloaded no model weights, made no model calls, measured no VRAM or latency, and did not normalize publisher benchmark tables.