Voxtral Mini 4B в браузере: как запихнуть супер-ASR в WebGPU и Rust

Зачем вообще это нужно?

Представь: у тебя есть ноутбук без интернета, но нужно транскрибировать часовую встречу. Облачные сервисы отпадают - дорого, медленно, да еще и приватность под вопросом. Локальные решения вроде Whisper тянут - они для пакетной обработки, а не для реального времени. Вот тут и появляется Voxtral Mini 4B Realtime - модель размером всего 4 миллиарда параметров, но с задержкой меньше 500 мс.

Проблема в том, что даже такая "мини" модель весит несколько гигабайт. Запустить ее в браузере - задача нетривиальная. До 2025 года это было почти невозможно, но теперь есть Rust с фреймворком burn и WebGPU бэкендом.

Что получится в итоге?

Браузерное приложение, которое:

• Загружает квантованную GGUF версию Voxtral Mini 4B (q4_k_m)
• Работает на любом GPU с поддержкой WebGPU (Chrome 124+, Firefox 125+)
• Транскрибирует речь в реальном времени с задержкой ~300-400 мс
• Не отправляет данные никуда - все локально
• Занимает в памяти браузера около 2.5 ГБ

Если ты уже пробовал запускать Voxtral локально на Python, то знаешь - это требует установки кучи зависимостей. Браузерная версия избавляет от этой головной боли.

Подготовка: что нужно собрать

1 Конвертируем модель в GGUF

Оригинальная модель от Mistral в формате Safetensors. Нам нужна квантованная версия q4_k_m - оптимальный баланс между качеством и размером. Квантование до 4 бит уменьшает модель в 4 раза.

Используем llama.cpp с поддержкой архитектуры Mistral:

# Клонируем актуальную версию llama.cpp (на 09.02.2026 это v0.9.1)
git clone --branch v0.9.1 https://github.com/ggerganov/llama.cpp
cd llama.cpp
make -j4

# Конвертируем Safetensors в GGUF
python convert.py \
  --outfile voxtral-mini-4b-realtime.q4_k_m.gguf \
  --outtype q4_k_m \
  /path/to/voxtral-mini-4b-realtime/

2 Настраиваем Rust проект с burn

Burn - это ML фреймворк на Rust с кроссплатформенными бэкендами. Нас интересует именно burn-wgpu - бэкенд для WebGPU.

Создаем новый проект:

cargo new voxtral-browser --lib
cd voxtral-browser

Cargo.toml должен выглядеть так:

[package]
name = "voxtral-browser"
version = "0.1.0"
edition = "2021"

[dependencies]
burn = { version = "0.15.3", features = ["wgpu"] }
burn-wgpu = "0.15.3"
burn-ndarray = "0.15.3"

[lib]
crate-type = ["cdylib"]

[profile.release]
lto = true
opt-level = "z"
codegen-units = 1

Почему именно burn, а не Candle? Candle отлична для десктопных приложений, но burn специально заточен под WebGPU с автоматическим шардингом моделей. Это критично для браузера.

Код: загружаем и запускаем модель

3 Структура модели для burn

Voxtral Mini 4B использует архитектуру Mistral с модификациями для ASR. Нам нужно описать ее структуру для burn:

use burn::{
    module,
    nn,
    tensor::{backend::Backend, Tensor},
};

#[derive(module::Module, Debug)]
struct VoxtralConfig {
    vocab_size: usize,
    hidden_size: usize,
    intermediate_size: usize,
    num_hidden_layers: usize,
    num_attention_heads: usize,
    num_key_value_heads: usize,
    max_position_embeddings: usize,
    sliding_window: usize,
}

#[derive(module::Module, Debug)]
struct VoxtralModel {
    config: VoxtralConfig,
    embed_tokens: nn::Embedding,
    layers: Vec>,
    norm: nn::LayerNorm,
    lm_head: nn::Linear,
}

Здесь есть нюанс: оригинальный Voxtral использует sliding window attention для реального времени. В GGUF это сохраняется как отдельный параметр sliding_window. Не забудь его включить в конфиг.

4 Загрузка GGUF весов

Burn не умеет напрямую грузить GGUF. Нужен адаптер:

use std::collections::HashMap;

fn load_gguf_to_burn>(
    path: P,
    device: &B::Device,
) -> HashMap> {
    let mut file = std::fs::File::open(path).unwrap();
    let mut reader = GgufReader::new(&mut file).unwrap();
    
    let mut tensors = HashMap::new();
    
    for tensor_info in reader.tensor_infos() {
        let name = tensor_info.name.clone();
        let tensor_data = reader.read_tensor_data(&tensor_info).unwrap();
        
        // Конвертируем данные GGUF в формат burn
        let shape: Vec = tensor_info.shape().iter().map(|&d| d as usize).collect();
        let tensor = Tensor::from_data(
            tensor_data.as_slice(),
            shape,
            device,
        );
        
        tensors.insert(name, tensor);
    }
    
    tensors
}

5 Шардинг модели для WebGPU

Вот где burn показывает свою силу. Модель в 2.5 ГБ не влезет в память одного GPU шейдера. Burn автоматически разбивает ее на части:

use burn_wgpu::{AutoGraphicsApi, WgpuBackend, WgpuDevice};
use burn::backend::wgpu::AutoGraphicsApi;

// Создаем бэкенд с автоматическим шардингом
let device = WgpuDevice::default();
let backend = WgpuBackend::::new(device);

// Загружаем модель
let weights = load_gguf_to_burn("voxtral-mini-4b-realtime.q4_k_m.gguf", &backend.device());
let model = VoxtralModel::new(&backend, config);
model.load_weights(weights);

// Burn автоматически разобьет модель на шейдеры
// Каждый шейдер получит свою часть весов

Без шардинга WebGPU просто упадет с ошибкой "buffer too large". Burn решает эту проблему прозрачно - ты даже не заметишь, как модель разбивается на части.

Интеграция с браузером

6 Собираем WASM

Rust код нужно скомпилировать в WebAssembly:

# Устанавливаем целевой WASM
rustup target add wasm32-unknown-unknown

# Собираем с оптимизациями
cargo build --release --target wasm32-unknown-unknown

# Оптимизируем размер
wasm-opt -Oz -o voxtral.wasm target/wasm32-unknown-unknown/release/voxtral_browser.wasm

Размер итогового WASM: около 8-10 МБ. Плюс 2.5 ГБ весов модели, которые загружаются лениво по мере необходимости.

7 JavaScript обертка

Создаем простой HTML/JS интерфейс:

    


    Начать запись
    

    
    

Оптимизации и подводные камни

Самая большая проблема - это аудио препроцессинг. Voxtral ожидает мел-спектрограммы, а не сырые PCM данные. Нужно реализовать преобразование в браузере, что добавляет еще 50-80 мс задержки.

Альтернативы: зачем так сложно?

Можно пойти более простым путем:

1. WebAssembly + ONNX Runtime: Проще в настройке, но медленнее. ONNX Runtime для Web не оптимизирован под большие модели.

2. TensorFlow.js: Еще проще, но поддержка трансформеров ограничена. Не подходит для 4B параметров.

3. Серверный бэкенд: Как в Open WebUI. Но тогда теряется главное преимущество - локальность.

4. Другие ASR модели: Whisper-tiny.js работает в браузере, но качество хуже, а задержка больше. Для реального времени не годится.

Rust + burn + WebGPU - это единственный стек на 09.02.2026, который позволяет запускать модели размером 4B+ в браузере с приемлемой производительностью.

Кому это подойдет?

Это решение не для всех. Вот кому стоит попробовать:

• Разработчикам приватных приложений: Врачи, юристы, психологи - все, кто не может отправлять аудио в облако.
• Создателям оффлайн-инструментов: Полевые исследователи, журналисты в зонах без интернета.
• Энтузиастам edge AI: Кто хочет выжать максимум из браузерных технологий.
• Стартапам с ограниченным бюджетом: Не платить за облачную ASR (от $0.006 за минуту).

А вот кому не подойдет:

• Тем, у кого слабый GPU (интегрированная графика старше 2022 года)
• Кто хочет "просто работающее решение" без настройки
• Проектам, где задержка в 300 мс критична (например, синхронный перевод)

Что будет дальше?

К 2027 году этот стек станет стандартом для запуска ML в браузере. Уже сейчас вижу тенденции:

1. WebGPU 2.0 добавит поддержку tensor cores, что ускорит вычисления в 5-10 раз.

2. Квантование до 2 бит уменьшит модели еще в 2 раза без потери качества.

3. Автоматическая оптимизация графов в burn сделает настройку ненужной.

4. Поддержка sparsity позволит запускать модели до 10B параметров.

Пока же приходится собирать все вручную. Но результат того стоит: полная независимость от облаков, приватность и скорость, которую не даст ни один SaaS.

Если хочешь посмотреть на готовую реализацию - есть демо на Hugging Face Spaces. Там же можно скачать квантованные веса модели.

А если ищешь что-то попроще для начала - попробуй настроить AI-тренера речи на слабом железе. Там меньше параметров, но и порог входа ниже.