build(asr): add qualified vLLM 0.23 image

[volschin]

Zusammenfassung

• ersetzt das EOL-ASR-Image-Rezept durch ein reproduzierbares, Digest- und Source-gepinntes ARM64-Image mit vLLM 0.23.0, Torch 2.11.0+cu130 und FlashInfer 0.6.12
• bindet exakt das produktiv verwendete UrocyonF Qwen3-ASR-1.7B-Modell ein und hält dessen API-Vertrag fail-closed fest
• sperrt Audio-Abhängigkeiten per Hash-Lock und prüft den effektiven Runtime-Inhalt auf unerwünschte bzw. doppelte Kernpakete
• aktualisiert Compose, Deployment-Dokumentation und Regressionstests

Verifikation

• pytest -q: 373 passed
• ruff check agent/ tests/
• ruff format --check agent/ tests/
• docker compose config --quiet
• Shell-Syntaxprüfung des Build-Skripts

Live-A/B auf der GX10

• Kandidat: sha256:0fadf01c8957a91ad83aca03395e7cd61fb66c1b20f5049e268ddd5424560930
• 19.13 GB statt 33.29 GB Produktionsimage: ca. 42,5 % kleiner
• Qualität: je 70/70 erfolgreiche Fälle; WER, CER, Macro-WER, Entity-/Zahlen-/Zeit-/Datumswerte identisch
• Non-Speech: 5 Wörter Produktion, 5 Wörter Kandidat
• Last: je 12/12 erfolgreiche Requests; p50-Verhältnis 1,018 und p90-Verhältnis 1,044 innerhalb der Gates
• echte CUDA-Aktivität für beide Images nachgewiesen, jeweils bis 96 % SM
• Gesamtergebnis: alle Gates erfüllt, Kandidat eligible=true

Das Produktionssystem blieb während Build und Tests unverändert und gesund. Dieser PR führt keinen Rollout durch; dafür ist weiterhin eine separate Freigabe erforderlich.

Hinweis: Der qualifizierte Kandidat enthält den getesteten Source-Build von FlashInfer 0.6.12. Das inzwischen veröffentlichte vorcompilierte 0.6.18-Wheel wurde bewusst nicht nachträglich substituiert, weil dies einen neuen Kandidaten erzeugen würde.

Summary by Sourcery

Qualify and document a new digest-pinned Spark-vLLM midpoint ASR image using the production Urocyon Qwen3-ASR-1.7B model, while keeping deployment contracts stable and deferring rollout.

New Features:

• Introduce a reproducible Spark-vLLM midpoint ASR base image with pinned CUDA, PyTorch 2.11, vLLM 0.23.0, FlashInfer 0.6.12, Transformers 5.12.1, and audio decoder stack.
• Add a dedicated build script for the midpoint base image that can either rebuild from pinned source or reuse a verified local base by ID.
• Provide a local build workflow and README instructions for constructing and testing the midpoint ASR candidate without changing production.

Bug Fixes:

• Align repository and Compose configuration with the actual production UrocyonF/Qwen3-ASR-1.7B snapshot and transcription contract, including acceptance of additive response fields.

Enhancements:

• Refine deployment tests to enforce exact ASR model snapshot usage, audio dependency hash-locking, and prevention of core runtime reinstallation or compiler/CUDA toolkit additions in ASR images.
• Strengthen Dockerfile health checks and Compose wiring so ASR is always built from the repository-owned derivative image with stable service identity, networks, GPU reservation, and offline cache usage.
• Add runtime assertions in the ASR Dockerfile to verify adapter provenance, package versions, and audio decoder installations against expected hashes.
• Capture and formalize historical execution plans and design documents for Spark-vLLM ASR image work, midpoint reactivation, ModelRunnerV1 diagnostics, and same-model correction, marking them as non-executable records.

Documentation:

• Document the Spark-vLLM ASR image design, midpoint reactivation, ModelRunnerV1 diagnostic, and same-model correction, including goals, constraints, and historical outcomes.
• Update DGX deployment documentation to describe the new ASR build process, the UrocyonF 1.7B snapshot usage, and the current rollout hold for the qualified candidate.

Tests:

• Expand DGX deployment tests to cover ASR audio lock integrity, forbidden Python package and compiler additions, midpoint build reproducibility, runtime version checks, and Compose service contract invariants.
• Add STT client tests to ensure transcription responses with additive fields (such as usage metadata) are accepted as long as a string text field is present.

[sourcery-ai]

Reviewer's Guide

This PR replaces the previous external ASR image setup with a reproducible, digest- and source-pinned Spark-vLLM 0.23.0 ARM64 base plus a minimal ASR derivative, tightens deployment/runtime guards to keep the ASR stack immutable except for locked audio decoders, and adds historical design/plan docs for the qualification runs, all while preserving the production Qwen3-ASR-1.7B contract and updating tests and docs accordingly.

Sequence diagram for updated ASR container healthcheck and model verification

sequenceDiagram
  participant Docker as DockerEngine
  participant ASR as qwen3_asr_container
  participant HC as HealthcheckPython
  participant API as vllm_http_server

  Docker->>ASR: run healthcheck CMD
  ASR->>HC: start python3 -c ...
  HC->>API: GET /v1/models
  API-->>HC: 200 JSON { data: [ { id: qwen3-asr } ] }
  HC->>Docker: exit 0 if any(model.id == qwen3-asr)
  Note over HC,ASR: healthcheck fails closed unless qwen3_asr model is loaded

Loading

File-Level Changes

Change	Details	Files
Introduce a Spark-vLLM midpoint base build script and patch that reproducibly reconstruct the validated vLLM 0.23.0/Torch 2.11/FlashInfer 0.6.12 stack and assert its runtime inventory.	Add dgx/asr/build-midpoint-base.sh to build or reuse a pinned Spark base image with strict argument parsing and inventory checks. Add dgx/asr/eugr-midpoint.patch to adjust upstream eugr/spark-vllm-docker Dockerfile and build script for the midpoint configuration. Implement Python-based assertions in the build script to verify versions, adapter SHA-256, build metadata, and CUDA ARM64 manifest provenance.	dgx/asr/build-midpoint-base.sh dgx/asr/eugr-midpoint.patch tests/test_dgx_deployment.py
Convert the ASR Dockerfile to inherit the repository-built Spark-vLLM midpoint base and install only hash-locked audio decoder packages, with inline runtime integrity checks.	Change dgx/asr/Dockerfile FROM to an ARG-driven Spark base tag and drop previous flash-attn and ad-hoc audio installs. Wire in dgx/asr/requirements-audio-arm64.lock and install it via python3 -m pip with --require-hashes and --no-deps. Add a post-install python3 -c assertion block that validates adapter SHA-256, Torch/vLLM/Transformers/FlashInfer/audio versions and CUDA version. Update the Dockerfile healthcheck to require the presence of model id 'qwen3-asr' in /v1/models.	dgx/asr/Dockerfile dgx/asr/requirements-audio-arm64.in dgx/asr/requirements-audio-arm64.lock tests/test_dgx_deployment.py
Replace the ASR service in Compose from a mutable external image to a local build of the repository Dockerfile and pin it to the exact production UrocyonF Qwen3-ASR-1.7B snapshot.	Update dgx/docker-compose.yml to build qwen3-asr from context '.' and asr/Dockerfile instead of using ghcr.io/aeon-7/qwen3-asr-server:latest. Change the ASR service command model path to the offline cached UrocyonF/Qwen3-ASR-1.7B-NVFP4 snapshot revision 61ad4d533c64e033a750b66c44aad6f18634997e. Add deployment tests that assert Compose keeps GPU reservations, networks, restart policy, labels, served-model-name, and healthcheck contract unchanged while remaining image-tag-free.	dgx/docker-compose.yml tests/test_dgx_deployment.py dgx/README.md
Add strict guards to the ASR build and runtime to reject alternate pip installation paths, compiler/CUDA-toolkit additions, or core-stack reinstallation; and to lock audio requirements to two exact distributions with full hash coverage.	Introduce helpers to parse logical Dockerfile RUN instructions, detect pip install commands, and enforce a single audio-only requirements path with --require-hashes and --no-deps. Add forbidden lists/regexes to block installation of torch/vllm/triton/flashinfer/flash-attn/cffi and compiler/CUDA toolkit packages in ASR images. Add tests ensuring the ASR Dockerfile does not add compilers/CUDA toolkits and installs only the locked audio requirements while allowing post-install metadata checks. Add tests validating requirements-audio-arm64.in/lock contain exactly soundfile==0.13.1 and av==17.0.1 with per-entry SHA-256 hashes.	tests/test_dgx_deployment.py dgx/asr/requirements-audio-arm64.in dgx/asr/requirements-audio-arm64.lock dgx/asr/Dockerfile
Enhance tests around ASR deployment, midpoint build behaviour, and STT client response handling to enforce contracts and ensure compatibility with additive response fields.	Add constants for ASR revision, midpoint commits/digests, cutoff timestamp, base image ID and adapter SHA-256 to tests/test_dgx_deployment.py. Add tests that assert midpoint build scripts pin specific commits, enforce CUDA ARM64 manifest inspection, single-distribution metadata checks, deterministic cache keys, and PyTorch cutoff exemptions. Add subprocess-based tests for build-midpoint-base.sh --help and unknown argument handling, and reuse-base path binding to the exact base image ID. Extend STT tests to accept responses with additional fields (e.g. 'usage') while still returning only 'text' to the caller.	tests/test_dgx_deployment.py tests/test_stt.py
Add detailed historical design and execution-plan documentation for the Spark-vLLM ASR image, midpoint reactivation, ModelRunnerV1 diagnostic, and same-model correction work.	Create design spec describing Spark-vLLM ASR image goals, baseline, architecture, acceptance gates, and rollout/rollback constraints. Add a long-form implementation plan documenting the initial Spark-vLLM ASR image work, including tasks, constraints, A/B methodology, and outcomes. Add midpoint reactivation design/plan documenting recovery of vLLM 0.23.0 base and non-speech gating results. Add ModelRunnerV1 diagnostic design/plan describing the single-variable experiment and its failure to improve non-speech hallucinations. Add same-model correction design/plan documenting the invalid earlier 0.6B comparison and the corrected 1.7B same-model A/B that found increased non-speech hallucinations.	docs/superpowers/specs/2026-08-09-spark-vllm-asr-image-design.md docs/superpowers/plans/2026-08-09-spark-vllm-asr-image.md docs/superpowers/plans/2026-08-09-spark-vllm-asr-midpoint-reactivation.md docs/superpowers/specs/2026-08-09-spark-vllm-asr-midpoint-reactivation-design.md docs/superpowers/plans/2026-08-09-spark-vllm-asr-modelrunner-v1.md docs/superpowers/specs/2026-08-09-spark-vllm-asr-modelrunner-v1-design.md docs/superpowers/plans/2026-08-09-spark-vllm-asr-same-model.md docs/superpowers/specs/2026-08-09-spark-vllm-asr-same-model-design.md
Apply minor cleanups and formatting adjustments unrelated to ASR image semantics.	Tighten JSON response construction in the embedding server to a single-line list comprehension. Ensure imports (e.g. os, subprocess) are ordered cleanly and unused patch scripts are removed from the ASR Dockerfile. Add documentation notes about rollout hold and how to build/reuse the midpoint candidate locally without deploying it.	dgx/embedding/server.py dgx/README.md dgx/asr/Dockerfile tests/test_dgx_deployment.py

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• The ASR Dockerfile’s long inline python3 -c assertion chain is quite dense; consider moving these version and adapter checks into a small checked-in Python module to improve readability and make future adjustments easier.
• The deployment contract tests in tests/test_dgx_deployment.py now contain a lot of helper logic (regexes, Dockerfile parsing, bash script inspection); you may want to factor some of this into a dedicated utility/module to keep the test file focused and easier to maintain.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The ASR Dockerfile’s long inline `python3 -c` assertion chain is quite dense; consider moving these version and adapter checks into a small checked-in Python module to improve readability and make future adjustments easier.
- The deployment contract tests in `tests/test_dgx_deployment.py` now contain a lot of helper logic (regexes, Dockerfile parsing, bash script inspection); you may want to factor some of this into a dedicated utility/module to keep the test file focused and easier to maintain.

## Individual Comments

### Comment 1
<location path="dgx/asr/build-midpoint-base.sh" line_range="110" />
<code_context>
+    "build_script_commit: b51af15a280d28c2ad9096b3ef581524eddbd0e7",
+    "vllm_commit: 0fc695fc6d1d82e9a5ac6835ac8e4e1c83703665",
+    "flashinfer_commit: d768c14e7cf5dd5df45a8a1de78ae815879f108a",
+    "base_image: ${CUDA_IMAGE}",
+)
+
</code_context>
<issue_to_address>
**issue (bug_risk):** The `base_image` metadata check uses an undefined `CUDA_IMAGE` shell variable, which will never match the actual build metadata.

In `assert_historical_inventory`, `expected_metadata` includes `"base_image: ${CUDA_IMAGE}"`, but `CUDA_IMAGE` is never defined. This means the check searches for the literal `${CUDA_IMAGE}` in `/workspace/build-metadata.yaml` and will always fail, even when the base image is correct. Please either define `CUDA_IMAGE` to match the intended CUDA base tag or replace the placeholder with the actual expected `base_image` value so the assertion is valid.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

issue (bug_risk): The base_image metadata check uses an undefined CUDA_IMAGE shell variable, which will never match the actual build metadata.

In assert_historical_inventory, expected_metadata includes "base_image: ${CUDA_IMAGE}", but CUDA_IMAGE is never defined. This means the check searches for the literal ${CUDA_IMAGE} in /workspace/build-metadata.yaml and will always fail, even when the base image is correct. Please either define CUDA_IMAGE to match the intended CUDA base tag or replace the placeholder with the actual expected base_image value so the assertion is valid.