The announcement

Google released Gemma 4 today — four model sizes (E2B, E4B, 26B MoE, 31B Dense), all under Apache 2.0. That last part is the headline for us. Previous Gemma releases carried a custom license with usage restrictions. Apache 2.0 means no strings: embed it, ship it commercially, modify it, don’t ask permission.

The model family is built from the same research as Gemini 3. The 31B Dense currently sits at #3 on the Arena AI text leaderboard among open models, and the 26B MoE at #6 — outperforming models 20x their size. The smaller E2B and E4B variants are designed for edge/mobile deployment, running on phones and Raspberry Pis.

Why audio developers should care

All four models handle text and vision natively. The E2B and E4B models add native audio input — speech recognition and understanding baked into the architecture, not bolted on. Audio is processed at 16kHz with 6.25 tokens per second, up to 30-second clips recommended.

Now, let’s be honest about what “audio input” means here. This is speech-focused: transcription, translation, spoken instruction understanding. It’s not a timbre analysis model. You can’t feed it a synth pad and ask what the filter cutoff is. But the fact that a 2B-parameter open model can natively ingest audio alongside text and images — and reason about all three — is a meaningful shift for the audio tooling space.

For context: a year ago, the state of the art for open multimodal models was text-and-image only. Audio understanding required separate specialized pipelines (Whisper for ASR, CLAP for embeddings, custom models for everything else). Gemma 4 doesn’t replace those tools, but it compresses the stack for a whole class of audio-adjacent applications.

The local inference story

This is where it gets interesting for indie developers. The 31B model runs quantized on a single consumer GPU. The 26B MoE activates only 3.8B parameters during inference — meaning you get near-frontier reasoning at a fraction of the compute. Ollama, llama.cpp, vLLM, and LM Studio all have day-one support.

If you’re building audio tools and you’ve been relying on API calls to frontier models for any reasoning/planning/orchestration layer, you can now move that local. No latency, no API costs, no data leaving your machine. For a music producer’s workflow — where real-time feel matters and audio data is sensitive (unreleased material, client sessions) — local inference isn’t a nice-to-have, it’s the correct architecture.

The 26B MoE is particularly compelling for interactive use cases. With only 3.8B active parameters per forward pass, you get fast token generation while retaining the reasoning quality of a much larger model. On an RTX 4090, this should be comfortably interactive.

Function calling and agentic workflows

All Gemma 4 models support native function calling with structured JSON output and system instructions. This is the feature that turns a language model from a chatbot into an orchestrator.

The pattern: define tools (synth parameter adjustment, audio rendering, similarity scoring), give the model a system prompt that describes the workflow, and let it plan and execute multi-step operations. The model decides which tool to call, with what arguments, and how to interpret the results.

For audio applications, this unlocks a specific architecture: the LLM as a conversational controller for a DSP backend. User says “make it darker” → model reasons about what “darker” means in synthesis terms → calls a filter cutoff adjustment function → triggers a re-render → evaluates the result. All running locally, all within a single conversation context.

What this doesn’t solve

Gemma 4 is not an audio embedding model. It doesn’t do timbre similarity, spectral analysis, or synthesis parameter estimation. Those problems still need specialized models (CLAP, OpenL3, AudioMAE) and domain-specific training data. The audio input capability is essentially ASR with some reasoning — powerful for voice-controlled workflows, but not a substitute for the audio ML pipeline.

It’s also not a real-time audio processor. The model operates on discrete audio clips, not streaming buffers. For anything that needs sub-10ms latency (live effects, real-time pitch correction), you’re still in DSP-native territory.

The open model inflection point

What’s changed isn’t any single capability — it’s the combination. A year ago, if you wanted multimodal reasoning + function calling + audio input + local inference + a permissive license, you were assembling five different tools and hoping the glue held. Gemma 4 is one model that does all of it, runs on hardware you already own, and ships under a license that lets you build whatever you want.

For indie audio tool developers operating without cloud budgets or ML teams, this is the kind of shift that changes what’s feasible. Not everything becomes easy — the hard ML problems are still hard. But the orchestration layer, the conversational interface, the reasoning that ties specialized components together — that just became a local, free, unrestricted resource.

We’re paying close attention to how this fits into our own tooling roadmap. More on that shortly.

Gemma 4 is available now on Hugging Face, Kaggle, and Ollama. The model card has the full benchmark suite.