Sync model card with upstream GitHub inference README

README.md

@@ -19,8 +19,11 @@ license: apache-2.0
 acoustic echo cancellation (AEC), noise suppression, and dereverberation of
 16 kHz speech, designed to run on commodity CPUs in real time.
 
-- 1.3 M parameters (~5 MB F32)
-- ~1.56 ms per 16 ms frame on Zen4 (4 threads) — **≈10× realtime**
+- Two sizes — choose by CPU budget:
+  - **v1.3 (current)** — 4.8 M parameters (~19 MB F32), ~3.3 ms per 16 ms
+    frame on Zen4 (4 threads), **≈4.7× realtime**.
+  - **v1.2** — 1.3 M parameters (~5 MB F32), ~1.6 ms per 16 ms frame on
+    Zen4 (4 threads), **≈9.7× realtime**.
 - Causal, streaming: 256-sample hop, 16 ms algorithmic latency
 - F32 reference inference in C++ via [GGML](https://github.com/ggml-org/ggml);
   PyTorch reference included for verification and research
@@ -31,9 +34,14 @@ This page is the Hugging Face model card — it hosts the published weights.
 Source code, build system, tests, and training pipeline live in the GitHub
 repository: <https://github.com/localai-org/LocalVQE>.
 
-The current release is **v1.2**. It doubles the supported delay
-window from 500 ms to 1 second at a ~20 % per-hop CPU cost. It also
-avoids oversuppression of voices that are near to the noise floor.
+The current release is **v1.3**. It widens the encoder/decoder
+(mic channels `[2,112,32,104,96,152]`, far `[2,64,32]`, bottleneck
+256) and trains from scratch under a noise-floor-aware loss recipe.
+On doubletalk it filters noise better than v1.2; on far-end-only
+echo it cancels harder but the residual rates rougher in AECMOS —
+some users will prefer v1.2's gentler trade-off on FE-ST scenes.
+v1.2 stays available as the small/fast option (~1/4 the per-hop
+cost). Both reuse v1.2's 1024 ms echo-search window.
 
 The technical report describing the architecture, streaming-state contract,
 and streaming-causal normalisation operator is included in this repo as
@@ -97,17 +105,22 @@ implementation, no streaming runtime. We re-implemented it from the
 paper as a GGML graph at
 [richiejp/deepvqe-ggml](https://github.com/richiejp/deepvqe-ggml)
 (the full-width ~7.5 M-parameter version) before starting LocalVQE.
-LocalVQE is the same idea pruned and rebuilt to ~1.3 M parameters
-(~5 MB F32), small enough to run on commodity CPUs in real time.
+LocalVQE is the same idea rebuilt for streaming CPU inference, and
+published in two sizes: a 1.3 M-parameter compact build (v1.2,
+~5 MB F32) for tight CPU budgets, and a 4.8 M-parameter wider build
+(v1.3, ~19 MB F32) that filters noise better on some clips at ~2×
+the per-hop cost. Both are small enough to run real time on
+commodity CPUs.
 
 ## Files in this repository
 
 | File | Size | Description |
 |---|---|---|
-| `localvqe-v1.2-1.3M.pt` | 11 MB | PyTorch checkpoint — DNS5 pre-training + ICASSP 2022/2023 AEC Challenge fine-tune. |
-| `localvqe-v1.2-1.3M-f32.gguf` | 5 MB | GGML F32 export — what the C++ inference engine loads. |
-| `localvqe-v1.1-1.3M.pt` | 11 MB | Previous release. |
-| `localvqe-v1.1-1.3M-f32.gguf` | 5 MB | Previous release (F32 GGUF). |
+| `localvqe-v1.3-4.8M.pt` | 55 MB | PyTorch checkpoint — DNS5 pre-training + ICASSP 2022/2023 AEC Challenge fine-tune, wider arch + noise-floor-aware loss. **Current release.** |
+| `localvqe-v1.3-4.8M-f32.gguf` | 19 MB | GGML F32 export of the current release — what the C++ inference engine loads. |
+| `localvqe-v1.2-1.3M.pt` | 11 MB | Compact alternative — same arch family as v1.3 (`arch_version=3`), ~1/4 the cost per hop. |
+| `localvqe-v1.2-1.3M-f32.gguf` | 5 MB | GGML F32 export of the compact variant. |
+| `localvqe-v1.1-1.3M-f32.gguf` | 5 MB | Older release (F32 GGUF). |
 | `localvqe-v1-1.3M-f32.gguf` | 5 MB | Original release. |
 
 Only F32 GGUF is published today. A `quantize` tool is included in the
@@ -120,6 +133,18 @@ Full 800-clip eval on the
 [ICASSP 2022 AEC Challenge blind test set](https://github.com/microsoft/AEC-Challenge)
 — real recordings, not synthetic mixes.
 
+**v1.3** (current, 4.8 M):
+
+| Scenario                          |   n | AECMOS echo ↑ | AECMOS deg ↑ | blind ERLE ↑ | DNSMOS OVRL ↑ |
+|-----------------------------------|----:|--------------:|-------------:|-------------:|--------------:|
+| doubletalk                        | 115 |          4.73 |     **2.62** |       8.5 dB |          2.89 |
+| doubletalk-with-movement          | 185 |          4.67 |     **2.43** |       8.3 dB |          2.85 |
+| farend-singletalk                 | 107 |          3.69 |         4.83 |  **50.9 dB** |          1.94 |
+| farend-singletalk-with-movement   | 193 |          3.88 |         4.98 |  **49.9 dB** |          1.96 |
+| nearend-singletalk                | 200 |          5.00 |         4.18 |       2.4 dB |          3.17 |
+
+**v1.2** (compact alternative, 1.3 M):
+
 | Scenario                          |   n | AECMOS echo ↑ | AECMOS deg ↑ | blind ERLE ↑ | DNSMOS OVRL ↑ |
 |-----------------------------------|----:|--------------:|-------------:|-------------:|--------------:|
 | doubletalk                        | 115 |          4.72 |         2.37 |       8.4 dB |          2.83 |
@@ -128,12 +153,27 @@ Full 800-clip eval on the
 | farend-singletalk-with-movement   | 193 |          4.12 |         4.96 |      40.6 dB |          1.75 |
 | nearend-singletalk                | 200 |          5.00 |         4.16 |       2.1 dB |          3.17 |
 
-v1.2 vs v1.1 deltas: AECMOS echo MOS +0.80 / +0.72 on FE-ST and
-FE-ST-with-movement (the primary release goal — these scenarios are
-where echo leaks through), near-end deg MOS +0.11, double-talk
-roughly unchanged. FE-ST-with-movement raw ERLE drops 4.4 dB; v1.2
-is less aggressive when the echo path is moving, trading raw
-cancellation for fewer near-end gating artefacts.
+v1.3 vs v1.2 deltas (same 800-clip set, same eval pipeline):
+
+- **Doubletalk deg MOS +0.25**, dt-with-movement deg MOS +0.13 — the
+  wider model + noise-floor-aware loss recipe noticeably reduces
+  perceived speech degradation when both talkers are active. This is
+  the primary v1.3 release goal.
+- **FE-ST-with-movement ERLE +9.3 dB**, FE-ST ERLE +5.2 dB — v1.3
+  cancels far-end echo substantially harder. **AECMOS echo MOS drops
+  −0.24 / −0.09** at the same time: the residual after cancellation
+  rates rougher on AECMOS's perceptual scale even though there's
+  numerically less of it. Some users will prefer v1.2's gentler
+  trade-off on far-end-only scenes.
+- **Nearend-singletalk identical** within noise (deg +0.02,
+  OVRL +0.00) — wider capacity doesn't help (or hurt) when there's
+  nothing to cancel.
+- DNSMOS OVRL is up 0.04–0.21 across all scenarios — the wider
+  model produces consistently cleaner-rated output by DNS metrics.
+
+For the original v1.2 vs v1.1 deltas (the previous release's
+headline numbers), see the [v1.2 release notes on
+GitHub](https://github.com/localai-org/LocalVQE).
 
 - **AECMOS** (Purin et al., ICASSP 2022) is Microsoft's non-intrusive AEC
   quality predictor. "Echo" rates how well echo was removed; "degradation"
@@ -189,22 +229,41 @@ glslc`/`shaderc`).
 Measured with `bench` on Zen4 desktop (Ryzen 9 7900). Each hop is a
 full `ggml_backend_graph_compute`.
 
-**v1.2** (current, 1024 ms echo-search window):
-
-| Backend                     | Threads | p50     | p99     | max     |
-|-----------------------------|--------:|--------:|--------:|--------:|
-| CPU                         |       1 | 4.15 ms | 4.53 ms | 6.23 ms |
-| CPU                         |       4 | 1.56 ms | 1.73 ms | 4.57 ms |
-| CPU                         |       8 | 1.89 ms | 2.15 ms | 6.91 ms |
-| CPU                         |      16 | 2.12 ms | 2.17 ms | 6.43 ms |
-| Vulkan — AMD iGPU (RADV)    |       — | 4.88 ms | 5.06 ms | 6.24 ms |
-| Vulkan — NVIDIA RTX 5070 Ti |       — | 1.79 ms | 3.42 ms | 5.42 ms |
-
-Beyond ≈4 threads the model is small enough that thread-launch and
-synchronisation overhead dominate; **four threads is the sweet spot
-on Zen4**.
-
-**v1.1** (previous, 512 ms echo-search window) for comparison:
+**v1.3** (current — 4.8 M, wider encoder/decoder, bn 256):
+
+| Backend                     | Threads | p50     | p99     | RT factor |
+|-----------------------------|--------:|--------:|--------:|----------:|
+| CPU                         |       1 | 9.73 ms | 14.48 ms |    1.58× |
+| CPU                         |       2 | 5.41 ms |  5.62 ms |    2.95× |
+| CPU                         |       4 | 3.21 ms |  3.42 ms |    4.97× |
+| CPU                         |       8 | 3.47 ms |  3.80 ms |    4.59× |
+| CPU                         |      16 | 3.79 ms |  4.06 ms |    4.19× |
+| Vulkan — AMD iGPU (RADV)    |       — | 8.71 ms |  9.15 ms |    1.83× |
+| Vulkan — NVIDIA RTX 5070 Ti |       — | 2.57 ms |  4.21 ms |    6.07× |
+
+The wider v1.3 model is ~2× the per-hop cost of v1.2 in matching
+configurations. The dGPU (RTX 5070 Ti) ends up the fastest option
+by ~1.25× vs 4-thread CPU. The 1-thread case is the worst, still
+real-time (RT 1.58×) but with little margin — running v1.3 on a
+low-core / power-constrained device should use v1.2 instead.
+
+**v1.2** (compact alternative — 1.3 M, 1024 ms echo-search window):
+
+| Backend                     | Threads | p50     | p99     | RT factor |
+|-----------------------------|--------:|--------:|--------:|----------:|
+| CPU                         |       1 | 4.28 ms | 4.85 ms |     3.72× |
+| CPU                         |       2 | 2.59 ms | 3.80 ms |     6.09× |
+| CPU                         |       4 | 1.65 ms | 2.91 ms |     8.90× |
+| CPU                         |       8 | 1.93 ms | 2.41 ms |     8.22× |
+| CPU                         |      16 | 2.09 ms | 2.22 ms |     7.69× |
+| Vulkan — AMD iGPU (RADV)    |       — | 6.10 ms | 6.53 ms |     2.61× |
+| Vulkan — NVIDIA RTX 5070 Ti |       — | 1.96 ms | 3.64 ms |     7.85× |
+
+Beyond ≈4 threads both models are small enough that thread-launch
+and synchronisation overhead dominate; **four threads is the sweet
+spot on Zen4** for both v1.2 and v1.3.
+
+**v1.1** (older, 512 ms echo-search window) for comparison:
 
 | Backend                     | Threads | p50     | p99     | max     |
 |-----------------------------|--------:|--------:|--------:|--------:|
@@ -222,9 +281,12 @@ range.
 
 ## Running Inference
 
-Download `localvqe-v1.2-1.3M-f32.gguf` from this repository (the file list above)
-either via `huggingface-cli`, the Hub web UI, or `hf_hub_download` from
-`huggingface_hub`. Then:
+Download a GGUF from the file list above — `localvqe-v1.3-4.8M-f32.gguf`
+for the current default, or `localvqe-v1.2-1.3M-f32.gguf` for the
+smaller / faster option — via `huggingface-cli`, the Hub web UI, or
+`hf_hub_download` from `huggingface_hub`. The CLI flags are the same
+either way; the examples below use v1.2 so the snippets are shorter
+to type. Swap the filename in to run v1.3.
 
 ### CLI
 
@@ -269,10 +331,15 @@ calibration have been worked through.
 
 ## PyTorch Reference
 
-`localvqe-v1.2-1.3M.pt` is the PyTorch checkpoint used to produce the GGUF export.
-It is provided for verification, ablation, and downstream research — not
-for end-user inference, which should go through the GGML build above. The
-model definition lives under `pytorch/` in the
+`localvqe-v1.3-4.8M.pt` (current) and `localvqe-v1.2-1.3M.pt`
+(compact alternative) are the PyTorch checkpoints used to produce
+the GGUF exports. They are provided for verification, ablation, and
+downstream research — not for end-user inference, which should go
+through the GGML build above. Both share `arch_version=3` (pre-norm
+CausalGroupNorm + SiLU + STFT-256) and differ only in width
+(`mic_channels`, `far_channels`, `bottleneck_hidden`), which the
+loader reads from the saved `model_config` field. The model
+definition lives under `pytorch/` in the
 [GitHub repo](https://github.com/localai-org/LocalVQE):
 
 ```bash