Krieger (GPU host)

The home GPU machine — Windows, on the tailnet as krieger (100.90.162.24). Normally asleep; woken on demand rather than left running 24/7.

Hardware: ASUS B860M MAX GAMING AX board, RTX 5060 with 8 GB VRAM, 240 mm AIO, Fractal North case. The 8 GB is the binding constraint — Ollama, ComfyUI and the transcription service all compete for it, which is why they’re arbitrated rather than run side by side. (UniFi fingerprints the machine as a Z490-E; that’s wrong, ignore it.)

What it runs

• Ollama — local LLM inference. Models currently proxied through LiteLLM include Qwen 2.5 7B, a Foundation-Sec 8B fine-tune, Moondream, and Qwen 3.5 9B.
• ComfyUI — image generation.
• Presumably a transcription service too, given the transcribe-wake-proxy described below — worth confirming/documenting what specifically runs there.

How it gets woken

Lana never talks to Krieger directly. Each service has its own small “wake-proxy” container on Lana (ollama-wake-proxy, comfyui-wake-proxy, transcribe-wake-proxy, all part of the litellm stack in docker-infra) that:

1. Receives the request meant for Krieger.
2. Sends a Wake-on-LAN packet via Home Assistant if Krieger looks asleep.
3. Waits for the target service (Ollama, ComfyUI, etc.) to come up.
4. Forwards the original request over Tailscale.

This is why LiteLLM’s ollama_chat/* models can have a longer first-request latency — that’s Krieger waking up, not a slow model.

There’s also a separate, more direct Wake-on-LAN call from Home Assistant that predates the wake-proxies and may power an in-app “wake now” button rather than the transparent per-request wake above. Worth checking litellm/ollama-wake-proxy and litellm/providers/ollama-provider.js in docker-infra/flowviz before assuming which code path is actually live.

When a wake “works” but nothing responds

Krieger’s Realtek 2.5GbE NIC has a failure mode where the link comes up and transmit works, but it receives zero frames — so it ends up on an APIPA address and is unreachable, while Home Assistant reports the Wake-on-LAN packet as sent. Wake-on-LAN keeping the NIC on standby power is itself the trigger, so the wake-proxies make it more likely, not less. Restart-NetAdapter sometimes clears it; otherwise it needs a cold power cycle with the AC removed. Symptoms, diagnosis and the adapter settings involved are written up in the personal knowledge repo (home/krieger.md), served to Claude by knowledge-mcp.

What wakes it, and how often

Besides interactive use, the nightly update-agent run asks the local Qwen model for a second opinion on each pending image update, which wakes Krieger. That only happens on nights when something actually has a new version, and it exists to measure whether the local model’s verdicts match Claude’s well enough to take over the routine cases. If the nightly wakes prove more trouble than the comparison is worth, drop UA_MODEL_LOCAL from the workflow and the run stays entirely on Lana.

Gaps to fill in

This page is a starting point, not exhaustive — worth adding:

• Exactly what the transcription service is and how it’s invoked
• How sleep/wake is triggered on the Windows side (Home Assistant integration, WoL config)