NInfer - Server Control

Here's the situation this node solves. You want a 27B language model to write your prompt, and then you want to run a diffusion sampler on the same card. NInfer holds something like 18 GiB while it's resident and has no unload API - no eject, no /unload, nothing. Killing the process is the only way to get the memory back.

The Client node's idle timer handles this on a delay: quiet for idle_seconds, and the reaper stops the server for you. Server Control is for when you want it to happen now, at a specific point in the graph, without guessing at a timer.

The two ports

Everything about this node is designed around a wire that used to go wrong. The first version shipped Status and Healthy as connectable text/boolean outputs, people wired them into a Chat node's Model field, and the request failed with an openai.NotFoundError because the server received a status report where it expected a model id. The author closed the trap at the source rather than documenting around it: Server Control no longer emits text or boolean ports at all. The status report is preview text inside the node body, and the only output is a dedicated NINFER_CONTROL signal that physically cannot feed a data input.

So:

• Run After (trigger, an * wildcard input) does nothing with the data. Its whole job is ordering - this node runs after whatever is wired into it finishes. The canonical use: wire Chat.Response into it with the action set to stop, and NInfer is torn down as soon as the reply exists. Yes, that wire doubles back from the chat into a node the chat also depends on; the graph reads oddly and works fine.
• Done (done, type NINFER_CONTROL) is the mirror image - downstream nodes wait for it. Wire it into the first GPU-hungry node in the image half of your workflow and that node runs after the VRAM has been freed.

Inputs

• Action - ensure running, stop, keep alive, or status. ensure running starts the server if it isn't answering; keep alive parks the idle limit out of reach; status changes nothing and just reports.
• Model File - the .ninfer artifact used by ensure running and keep alive. Read from NINFER_MODELS_DIR at load time.
• Force Kill - off means graceful shutdown, on means kill the process outright. Reach for it when a server hangs and the polite Ctrl-C equivalent doesn't take.
• Language - zh or en, default zh. Purely cosmetic: ComfyUI doesn't expose the interface language to the backend, so this widget exists only to choose the language of the status text. ComfyUI's own node labels follow your interface setting separately.
• Run After - optional, ordering only.

The preview report is genuinely useful when something is stuck: whether the server is healthy, its PID, how many generations are in flight, the idle counter against its limit, and whether ComfyUI itself is busy.

The arrangement most people want

Client ──Client──▶ Chat ──Response──▶ Preview Any
                     │
                     └──Response──▶ Server Control  (action: stop)
                                        │
                                       Done ──▶ your sampler group

The honest caveat: with stop in the graph, your next run pays the cold start again - the README measures roughly 9 s to start and under a second to stop. For a single image the author's own advice is to leave NInfer running; the stop/start cycle earns its keep when you're batching, or when the LLM step is only part of a longer graph that needs the card afterwards.

Where people get burned

Two processes on one card means out-of-memory errors stay your problem. Stop happens on the graceful path via GenerateConsoleCtrlEvent, which is Windows-specific - this is a Windows-first pack, and if you're on Linux you'll be driving a server you started yourself. Make sure no other ComfyUI node is still holding GPU memory, and note that the pack will not stop a server that's mid-generation: the in-flight counter protects you there, so a stop placed carelessly early in a graph simply won't fire while a request is open.

One more thing worth saying: the pack's lifecycle code touches ComfyUI internals (PromptServer, the prompt queue) to know whether a job is queued. That's fine and it's how the idle logic stays correct mid-workflow, but it does mean a ComfyUI release that renames those attributes can quietly break the "don't kill the server mid-graph" behaviour. If NInfer starts dying mid-workflow after an update, that's the first suspect.