Skip to content

Audio groups (whisper, kokoro) have a single backend and no possible fallback #86

Description

@sre-helmcode

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).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions