868b56642c9ecf1321aa46e476896976aac195bd
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 vh
|
868b56642c |
docs(memory): svos-dev fixed the roster check; disabled_toolsets deleted from config
svos-dev landed c9d2a96 - build_miranda_roster now returns an empty disabled list unconditionally and the startup line no longer names the key. The 28-name list is removed from ~/.hermes/config.yaml rather than left commented, since a paste-ready array behind a hash is what a future session uncomments; a short warning stands in its place. Their mechanism is better than mine and replaces it in the record. _get_platform_tools resolves platform_toolsets first and applies global suppression last, so subtracting 28 names from a one-element platform set is a no-op by resolution order - not merely 'adds no safety on top'. That holds for any future platform; the measurement only established the single case. And the endpoint already carried the answer. _handle_toolsets computes each row's enabled as membership in the per-platform set, so verified live: 29 rows with svos_miranda the only one reporting enabled=True. A check reading that field rather than counting rows was correct all along, against a config that never needed the key. |
||
|
vh
|
379fc27e7d |
feat(hermes): enable svos_miranda live; retire irv parakeet and voice-studio
Four operator rulings executed. svos_miranda is live in Hermes. Gateway restarted 02:10 (PID 3107822 -> 3901622, confirmed by observing the change). /v1/toolsets now reports 29 rows including svos_miranda, and an api_server session resolves to exactly the 8 plugin tools with the write-klass five absent. agent.disabled_toolsets stays off permanently: 'i dont want the tools disabled everywhere'. That key is a global end-of-pipeline subtraction rather than an api_server-scoped one - measured, a default session goes 46 tools to 20 - and it is unnecessary anyway, since platform_toolsets.api_server alone produces the exact 8-tool surface. The operator's own session was verified intact at 46 tools after the restart, which was the point of the ruling. The consequence is now SVOS's to absorb: it must stop verifying against the global roster before it restarts, because that roster is 29 by design and will not shrink. Two workable options went to svos-dev - verify the api_server surface instead, or relax the check to 'svos_miranda present and write-klass absent'. The second also survives any unrelated plugin landing on this host, which matters because 'stt' already appears in that endpoint's rows while resolving it logs 'Unknown toolset'. irv parakeet retired: it lost tts-dev's bench to the FV seat at both clip lengths and to whisper-large-v3 at 6.24s. Checked for consumers first - no gateway alias pointed at it, and every other reference on that host was a comment in a port-allocation register. Retirement banner on its README names the replacement. voice-studio stopped: it existed for the dots mint loop and Breeze obsoleted dots on 2026-09-06, so it was retired rather than repaired. |
||
|
vh
|
1f98a1be32 |
docs(memory): voice-studio is retired not broken; agent.disabled_toolsets is global
Two corrections and one finding from the same night. voice-studio: operator ruled the stack out of service. It existed for the dots mint/audition loop and dots was decommissioned 2026-09-06 when Breeze took the fleet seat, so its reason to exist went with it - which is also why nine days of breakage alerted nobody. No v11 rebuild. The gate one-liner was applied minutes before the retraction landed and was left in place rather than reverted, since the value it replaced was a dead address and reverting is another recreate of a stack that is going away. Container not stopped: it was already running, and 'down for now' arrived as a relayed paraphrase rather than an instruction. The two host-level facts survive the stack. Containers on irv-ml1 cannot resolve nh3.internal at all, so on that host the DNS name is the WRONG fix for a dead-IP bug - it swaps a dead address for an unresolvable one. Confirm resolution from inside the container before recommending a name. And a stale link can have more than one drift behind it: voice-studio had three stacked, two of them invisible from the host compose file. Hermes: svos_miranda is installed and enabled in config but the gateway was NOT restarted, so it is not live. agent.disabled_toolsets as specified by svos-dev is not scoped to api_server - it is a strict end-of-pipeline subtraction applied to every session on every platform. Measured: a default session goes 46 tools to 20, losing memory, file, terminal, web, browser and more. It is also unnecessary: platform_toolsets.api_server alone resolves an api_server session to exactly the 8 svos_miranda tools. The line buys only SVOS's startup check, which reads a global endpoint to verify a per-platform property. Left commented out with the measurement inline so an incidental restart cannot gut the assistant. |
||
|
vh
|
b9b14b5baf |
feat(parakeet): stand up Parakeet STT on fv-ml1 GPU 3 + LiteLLM ext-stt/whisper-1
Retargets the existing sherpa-onnx stack from irv-ml1 to fv-ml1's utility card and puts it behind the gateway. GPU 3 was the only card with room: 0/1/2 carry the vLLM seats at 84-95.5 GB of 96. Changes: - compose: pin GPU via `device_ids: ["3"]` (the dead on-host stub used `count: all`, which would have handed a 0.6B ASR seat all four cards); join traefik-net; port 8300; homepage href to the live FV address. - .env.example: default to the v3 int8 model (25 European languages, 464 MiB) rather than English-only v2; models to /tank/parakeet/models. - app.py: warm the recognizer at startup before uvicorn accepts traffic. The warmup is not an optimisation. ONNX Runtime's CUDA EP compiles and autotunes lazily on the FIRST DECODE, and on sm_120 that measured 45.7s cold (reproduced at 45.1s on a second container) against ~0.50s warm. A 45s first request is indistinguishable from a hang and LiteLLM's default timeout abandons it long before it returns. Decoding 1s of silence at load moves the cost inside the healthcheck's 300s start_period; first real request after restart is now 0.65s. Verification, because "provider=cuda" in the log is only an echo of the env var: ORT falls back to CPU silently and still returns correct text, so the service being up and the transcript being right establishes nothing. The discriminator is a process on GPU 3 (922 MiB), confirmed. Controls both directions — a known TTS sentence transcribes near-exactly (positive), 3s of digital silence returns empty (null). Warm throughput 0.50s median on an 8.52s clip, n=5, spread 0.47-0.65s, single-stream, one clip: a smoke measurement with its harness stated, not a benchmark. Gateway aliases `ext-stt` (engine-neutral, mirrors ext-tts) and `whisper-1` (OpenAI-compatible drop-in) registered via POST /model/new, i.e. LiteLLM's Postgres store where the ext-tts family already lives — no gateway restart, and config.yaml is consequently not a complete picture of what the gateway serves. Both verified end to end. The aliases use a raw IP deliberately: ana-docker resolves no .internal names at all (resolv.conf points at 1.1.1.1), and LiteLLM only reaches irv-ml1 through a hand-pinned extra_hosts entry. A second hosts entry would mean recreating the container and bouncing the gateway for every consumer. Also records the svos_miranda plugin validation pass and its structural findings, and notes that the irv-ml1 parakeet is still running — there are two now, and retiring the old one is the operator's call. |