🎯Core Definition
Speech-audio LLMs let a large language model “hear” audio directly (audio in, sometimes audio out); the core question is how audio is fused into the LLM, with two dominant designs:
📌Overview
1. Encoder + projector (Qwen-Audio route): audio passes through a large encoder (a Whisper-style mel encoder, ~150M params) into continuous features, which a Q-Former or convolutional downsampler compresses into few tokens (e.g. ~1 token per 2 seconds) concatenated with text tokens into the LLM. Qwen-Audio uses task tags (transcribe/audioqa…) to disambiguate modality and task; Qwen2-Audio adds multi-task architecture and positional alignment between audio and text tokens. Pros: reuses existing LLMs, cheap to train; cons: a representational gap between continuous features and discrete text tokens.
📌Overview
2. Native unified discrete tokens (any-to-any, GPT-4o route): audio is also tokenized by a codec (RVQ) and modeled jointly with text tokens in the same Transformer backbone — shared embeddings + full/cross attention, enabling token-level streaming in and out with dramatically lower end-to-end latency (Chameleon does the same for images). Cons: audio tokens are dense (25-50/s vs 2-5/s for text) requiring compression/downsampling, and discretization loses some acoustic detail.
📌Overview
Training recipe (common to both): stage 1 freeze the LLM and align only the audio encoder → stage 2 full fine-tuning → stage 3 speech instruction/dialogue SFT (plus preference alignment if needed), avoiding catastrophic forgetting while keeping text capability.
💡Use Cases
real-time voice assistants (GPT-4o voice, Gemini Live), audio understanding/Q&A, music understanding, speech translation, voice cloning; interviews compare Qwen-Audio vs GPT-4o fusion.
⚡Key Problems Solved
cascaded STT→LLM→TTS propagates errors, adds latency, and cannot perceive timbre/emotion/music; native audio tokens put audio in the same discrete symbol space as text, enabling a closed hear-think-speak loop with low-latency streaming.
