Nemotron ASR Server Check

Every pack that depends on an outside process should ship one of these, and almost none do. Nemotron ASR Server Check does one thing: it asks your NeMo-Speech.cpp server whether it's alive, and tells you which models are loaded. One input, one STRING output, fifteen seconds of your life.

Why it earns a spot in your workflow

Because the alternative is discovering the server is down after a four-minute render gets to the last node. This pack is a client - it never starts the ASR server, and it can't. So the server is a piece of your environment that can silently be missing, and every other node in the pack fails at the point of use with an error that could mean a dozen things.

This node moves that failure to the front. Queue it alone, before you trust anything else.

It's also the fastest way to answer "what is this model actually called?" The model field on the Transcribe nodes wants an id like .nemotron-3.5-asr-streaming-0.6b.q8_0.gguf, and unlike the file path, you can't guess it - the leading dot is part of the name, and getting it wrong gets you a server-side error rather than a helpful one. This node prints the ids the server is actually serving. Copy, paste, done.

What it actually does

Two HTTP GETs against the base URL you give it, in order:

GET /health      -> {"status": "ok", "version": "0.1.0", ...}
GET /v1/models   -> {"data": [{"id": ..., "capability": "transcription", ...}, ...]}

Then it formats one string and shows it on the node:

Server OK: ok (version 0.1.0); models: .nemotron-3.5-asr-streaming-0.6b.q8_0.gguf

That's the whole node. Note the asymmetry in how it fails, because it's deliberate and useful: if /health doesn't answer, the node raises - you get the same "Cannot reach Nemotron ASR server" error every other node in the pack gives you, which is your confirmation that the problem is the server, not the graph. If /health answers but /v1/models returns nothing useful, the model list just comes back empty. Server up, no model loaded: that's a real and common state, and now you can see it.

server_url defaults to http://127.0.0.1:8080. Trailing slashes are handled, so don't fuss.

Install

Part of comfyui_nemotron_asr - five nodes, one install. ComfyUI Manager, search comfyui_nemotron_asr, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/Rakeshcool/comfyui_nemotron_asr

No extra Python packages: this node uses stdlib urllib only. The ASR server is a separate program you start yourself, and the pack says so plainly in its docs - the nodes hold no connection between runs, so you can start and stop the server freely between queue runs.

You can skip the node entirely and check from a terminal, which is what the README suggests for a first install:

curl -s http://127.0.0.1:8080/health
curl -s http://127.0.0.1:8080/v1/models

Both are worth doing once. If curl can't reach it, no node in the pack will either.

Two practical notes

It's an output node, so you can queue the graph with just this in it. Do that. It's a cleaner signal than reading the console.

server_status is a STRING, so if you want to be fancy you can pipe it into a text node and have the workflow tell you what went wrong. Most people just read the preview on the graph and move on.

The general debugging rule applies here as everywhere: change one thing and look at the output. If this node says the server is fine and models are loaded, and Transcribe still fails, you've eliminated half the suspects in one queue.