What
whisper and kokoro are served by exactly one deployment each, both on nan-eu009 (10.10.0.9:8090 and :8880). Losing that node is a hard failure for every audio request in both tenants, not a degradation.
Unlike every chat group, this cannot be closed with a fallbacks entry:
qwen3.6 is a chat group. A rung there would answer a transcription request with prose the caller cannot distinguish from a real transcript — a plausible 200 that is worse than the 502.
- A self-referencing entry (
whisper: ["whisper"]) does nothing. run_async_fallback skips any target equal to the original group and re-raises. Enterprise carried one for weeks believing otherwise; removed in helmcode/nan-devops#385.
So the exemption in tests/router-settings/served_groups.py is honest, and closing it is hardware: a second audio backend.
Volume, with each figure's scope stated
Three numbers about whisper already exist in this workspace and they are not the same population. Naming them separately because this issue is what a hardware decision would rest on:
| Figure |
What it counts |
Source |
| 330 whisper/day (peak full day), 21–330 range |
requests that were accepted and logged |
community LiteLLM_SpendLogs, 2026-09-14→16 (full retention window), read 2026-09-16 |
| 3,755 kokoro/day (peak full day), 890–3,755 range |
same |
same |
| ~1,221 HTTP 415/day |
requests rejected before reaching the backend ("Failed to decode audio" — members uploading formats it will not accept) |
tests/host-firewall/test_alert_rules.py, measured on the ingress metric |
| 0.023 req/s (~1,987/day) |
everything hitting the endpoint, accepted or not |
same |
They reconcile: the 415s never reach SpendLogs, so accepted (~330) + rejected (~1,221) is the right order of magnitude for ~1,987 total. Do not quote one of these as "whisper traffic" without saying which.
Tenant split: community carries essentially all of it. Enterprise LiteLLM_SpendLogs over 8 days of retention holds 1 kokoro request and 0 whisper.
eu009 is also the node with the historical speaches FD leak (mitigated 2026-07-27 with a LimitNOFILE drop-in plus whisper-watchdog.service). The single point of failure is structural, not that bug.
Not in scope
whisper's 57 logged No fallback model group found lines on 2026-09-15 are those same HTTP 415s — client errors no rung of any modality would have rescued. They are not evidence for this issue.
Also worth folding in
whisper-stt-probe-stale (grafana values) is labelled service: litellm-community and probes the community path only; enterprise has no round-trip probe for whisper. Low priority given the tenant split above, but it belongs in the same piece of work.
Done when
A second backend serves whisper and kokoro, both groups are keyed in router_settings.fallbacks to that peer in both tenants, and their entries are removed from EXEMPT in tests/router-settings/served_groups.py (the linter then requires them to be covered).
Context: helmcode/nan-devops#338 (the coverage linter and why these two are exempt), helmcode/nan-devops#385 (removing the inert entry).
What
whisperandkokoroare served by exactly one deployment each, both on nan-eu009 (10.10.0.9:8090and:8880). Losing that node is a hard failure for every audio request in both tenants, not a degradation.Unlike every chat group, this cannot be closed with a
fallbacksentry:qwen3.6is a chat group. A rung there would answer a transcription request with prose the caller cannot distinguish from a real transcript — a plausible 200 that is worse than the 502.whisper: ["whisper"]) does nothing.run_async_fallbackskips any target equal to the original group and re-raises. Enterprise carried one for weeks believing otherwise; removed in helmcode/nan-devops#385.So the exemption in
tests/router-settings/served_groups.pyis honest, and closing it is hardware: a second audio backend.Volume, with each figure's scope stated
Three numbers about whisper already exist in this workspace and they are not the same population. Naming them separately because this issue is what a hardware decision would rest on:
LiteLLM_SpendLogs, 2026-09-14→16 (full retention window), read 2026-09-16tests/host-firewall/test_alert_rules.py, measured on the ingress metricThey reconcile: the 415s never reach SpendLogs, so accepted (~330) + rejected (~1,221) is the right order of magnitude for ~1,987 total. Do not quote one of these as "whisper traffic" without saying which.
Tenant split: community carries essentially all of it. Enterprise
LiteLLM_SpendLogsover 8 days of retention holds 1 kokoro request and 0 whisper.eu009 is also the node with the historical speaches FD leak (mitigated 2026-07-27 with a
LimitNOFILEdrop-in pluswhisper-watchdog.service). The single point of failure is structural, not that bug.Not in scope
whisper's 57 logged
No fallback model group foundlines on 2026-09-15 are those same HTTP 415s — client errors no rung of any modality would have rescued. They are not evidence for this issue.Also worth folding in
whisper-stt-probe-stale(grafana values) is labelledservice: litellm-communityand probes the community path only; enterprise has no round-trip probe for whisper. Low priority given the tenant split above, but it belongs in the same piece of work.Done when
A second backend serves
whisperandkokoro, both groups are keyed inrouter_settings.fallbacksto that peer in both tenants, and their entries are removed fromEXEMPTintests/router-settings/served_groups.py(the linter then requires them to be covered).Context: helmcode/nan-devops#338 (the coverage linter and why these two are exempt), helmcode/nan-devops#385 (removing the inert entry).