SpeechKV: сжимать KV-cache, а не speech embeddings

SpeechKV разбирает практический узкий участок Speech LLM: речь обычно приходит в модель как длинная последовательность acoustic frames, и autoregressive decoding вынужден снова и снова держать большой speech KV-cache. Обычное решение - рано сжать speech embeddings в adapter, но тогда часть фонетической и временной информации теряется до того, как LLM успевает ее использовать. Главный ход статьи - не трогать residual stream и full-resolution queries, а сжимать только keys/values внутри LLM после нескольких слоев, когда локальная акустическая информация уже частично агрегирована.

Метод. Авторы строят Speech LLM на Qwen3-1.7B: speech encoder выдает frames с шагом 80 ms, MLP adapter проецирует их в пространство LLM, а SpeechKV на выбранном слое l0 применяет learned pooling к KV-cache каждые R frames. В отличие от Concat-MLP или Window Q-Former на входе adapter, LLM сначала видит несжатую речь и сам формирует промежуточное представление; затем в decoding хранится уже укороченный speech cache. Обучение идет на 71,242.5 часов ASR data, при этом trainable около 480M параметров из 2.2B: speech encoder, adapter и LoRA, остальные веса LLM заморожены.

Результаты. При R=4 SpeechKV улучшает средний entity error rate на in-house ER benchmark с 14.41 у MLP baseline до 13.46, средний WER на in-house ASR с 5.78 до 5.71 и OpenASR WER с 6.12 до 5.98. При R=8 качество немного проседает относительно R=4, но остается близким к baseline: 14.91 ER, 5.95 in-house WER и 6.05 OpenASR WER. На A100 80 GB с vLLM R=4 дает 1.49x ускорение decoding step для 30-секундной речи, 1.88x для 5 минут и 2.02x для 10 минут; KV memory сокращается примерно в 2.8x.

Ограничения. Работа проверена в основном на ASR/recognition-style задачах, а не на полном наборе speech reasoning и spoken dialogue сценариев. Компрессия изучается на одном LLM backbone и одном speech encoder, поэтому оптимальный слой l0=5 может быть архитектурно специфичным. Обучение само по себе дорогое: 10,000 steps, около суток на 8 H100, и метод пока не решает latency encoder-а или streaming constraints.

Фишка из статьи. Самая полезная часть - не только средний WER, а trade-off между местом сжатия, качеством и длиной аудио. R=4 оказывается рабочей точкой: качество не хуже baseline, а выигрыш растет с длиной записи.

Как это читать: R=8 почти не ускоряет 10-минутный decoding сильнее R=4, потому что после достаточного сокращения speech cache bottleneck переезжает в feed-forward layers и text KV-cache. Поэтому интересный инженерный вывод - не максимальная компрессия, а умеренное сжатие внутри LLM после ранней акустической агрегации.