LLM Worker Release Notes

This is the canonical public history for Sogni LLM Worker releases. Each entry starts with a plain-English recap; technical details and verified Docker image information are available when needed.

LLM Worker versions and images are separate from Comfy Worker versions and images.

#TL;DR for worker hosts

Most updates are routine. They improve reliability, hardware monitoring, and the range of models a worker can serve. Staying current helps the worker remain eligible for the widest compatible workload, but an ordinary update notice does not mean something is wrong with the machine.
Most standard installations do not need to be reinstalled. Use Upgrade worker in the Dashboard, run worker-restart.bat on Windows, or run ./worker-restart.sh on Linux. Installer-managed workers use the latest image and check for a newer image during that start process.
Current managed installations can also update automatically. The background updater waits for the worker to be idle before replacing it.
Hosted or customized deployments can differ. A deployment pinned to a numbered image tag requires the operator to select the new version. Follow the provider's update flow or the Dashboard's instructions.
Avoid interrupting active work. Prefer the Dashboard's managed upgrade or wait until the worker is idle before manually restarting it.

Use dashboard.sogni.ai/fast-workers to see the version a worker is running and whether an update is available.

The current production release is 1.0.18. If your deployment is configured to load an exact Docker image version—such as sogni/sogni-llm-worker:v1.0.18 instead of sogni/sogni-llm-worker:latest—you must update the tag manually to use a new release. Our standard configuration uses the latest tag, so if you are not sure, you are probably already set.

#DGX Spark DeepSeek pair sidecar 1.0.19

Released: September 17, 2026 PT

Update guidance: New deployment type; nothing to update on existing LLM Workers.

In plain English: Two cabled NVIDIA DGX Sparks can now join the Supernet as one worker serving DeepSeek V4 Flash Vision Exp with its full 1M-token context. The image is the LLM Worker in its external-backend form, built for ARM64, with the pair installer and its acceptance tests inside it. Follow Run DeepSeek V4 Flash on a DGX Spark pair. This image has no latest tag: every pair runs an exact version, and a new pair version is announced here.

Technical details and verified image

What it is. The sidecar validates the pair's backend against the model contract issued by the Sogni API (served name, checkpoint, context, runtime version) and refuses to advertise capacity on any mismatch. It reports the pair as one GB10 LLM worker and never starts, stops or restarts the model server itself; the pair kit's background service owns that.

Fixed in this build. The container's health port variable now matches the one the worker reads, so the sidecar container reports healthy. The image records the source revision it was built from, runs as the operator's user, and can see the GPU for hardware reporting only.

Image:

Docker tag — sha256:d1936a098183b067ca6e750bf083c0ebc181a4824fe65071baf372aa989f33d5

#Version 1.0.18

Released: September 1, 2026 PT

Update guidance: Recommended for all Sogni LLM Workers. This is the first LLM Worker release with Dashboard settings and hardware protection, and it also carries the fixes prepared since 1.0.15.

In plain English: This release brings the LLM Worker up to the same standard of care the Comfy Worker already had. You can now manage a worker's settings from the Dashboard instead of editing files on the machine, and a thermal guard looks after the card by pausing new requests while the GPU is too hot — it never interrupts a reply already being written. Worker Health also gets a lot more useful: alongside the GPU chart you can now see the host's own CPU and memory, and check which processes are holding video memory when a model that should fit does not.

Technical details and verified images

Dashboard settings. Supported worker settings can now be viewed and changed from the Dashboard and persist on the worker, overriding what is configured on the machine. Available settings cover hardware protection (thermal guard thresholds, rests between requests), which models this worker serves and which it prioritizes, and whether it may keep downloading additional models. Changes apply immediately unless a setting says otherwise.

GPU thermal guard. The worker stops accepting new requests when the GPU core reaches approximately 189°F and resumes once it has cooled to approximately 174°F and served a short minimum hold. A reply already being generated is never interrupted — the card's own throttling protects it in the moment, and the guard keeps the next request from piling onto a hot card. Text generation is lighter on a card than image or video rendering, so a well-cooled GPU rarely reaches the threshold at all. The guard is on by default and can be adjusted or switched off from the Dashboard.

Worker Health. The rolling six-hour GPU chart now carries the host's CPU load, memory use, and CPU temperature on the same time axis, so a busy or throttled host is no longer indistinguishable from a mysteriously slow GPU. CPU temperature is not available on every platform and is shown for information only. The health check also lists the processes using GPU memory and identifies which belong to this worker, which answers the common case of a model that should fit reporting an out-of-memory failure because something outside the worker is holding video memory.

Image identity. The health check now names the CUDA track and the exact build the running container came from, so a worker's actual version can be confirmed without opening a shell on the machine.

Startup pacing after repeated failures. A worker that cannot stay up — most often because video memory is held by a process the container does not own — now paces its retries instead of restarting continuously, and recovers on its own as soon as the machine is healthy. The container reports itself as starting normally while it waits, and the pause never becomes a permanent stop.

Also included since 1.0.15.

Model refreshes no longer offer models the worker's hardware cannot run.
Startup downloads skip models the worker is not eligible to serve.
Replies that mix reasoning and visible output keep their full content.

Image:

Docker tag — sha256:eb129b01f4c4665dd060b49c3c3c58fdc006d05a4ff8b9eb55683d28c54909d1