Which Kaldi deployment boundary fits zero-downtime model migration for a small ASR service?

Goal: replace the acoustic model and decoding configuration of a small Kaldi ASR service without interrupting incoming transcription requests. The service uses Kaldi offline decoding or online2 streaming decoding with endpointing, and the exact Kaldi revision is pinned.

Kaldi does not define a built-in zero-downtime migration protocol, so the deployment boundary is unresolved. One option hot-swaps model artifacts inside a single process, which limits duplicated model memory but couples old and new versions in the same address space. The alternative runs separate old and new decoder pools and moves traffic between them, which isolates versions and simplifies rollback but can roughly double model memory. Thread-safety and graph compatibility are revision-sensitive, and a migration unit should include the feature configuration, acoustic model, decoding graph, and decoding or endpointing options rather than model files alone.

Should the service hot-swap artifacts in one process or use separate decoder pools with traffic shifting? Which artifacts must be versioned together to prevent silent accuracy regression? How should readiness and draining be decided when Kaldi itself provides no migration protocol?