- Implementação baseada em Rust capaz de executar reconhecimento de fala em streaming tanto em ambiente nativo quanto no navegador, usando o framework Burn ML
- O modelo é baseado no Voxtral Mini 4B Realtime da Mistral e realiza inferência totalmente no lado do cliente em uma aba do navegador via WASM + WebGPU
- O modelo quantizado Q4 GGUF (2,5 GB) pode ser executado no navegador, enquanto o modelo F32 baseado em SafeTensors (9 GB) funciona em ambiente nativo
- Para contornar restrições do navegador (alocação de 2 GB, espaço de endereçamento de 4 GB, limitações de leitura da GPU etc.), foram aplicadas técnicas como sharding, carregamento em 2 etapas e processamento assíncrono de tensores
- Disponível sob licença Apache-2.0, com demo em tempo real no HuggingFace Spaces
Visão geral do Voxtral Mini 4B Realtime (Rust)
- Implementação completa do modelo Voxtral Mini 4B Realtime da Mistral em Rust e no framework Burn ML
- Permite executar reconhecimento de fala em streaming em ambientes locais e no navegador
- A versão para navegador usa WASM (WebAssembly) e WebGPU para funcionar no lado do cliente
- O modelo quantizado Q4 GGUF (cerca de 2,5 GB) roda no navegador, enquanto o modelo F32 SafeTensors (cerca de 9 GB) é usado em ambiente nativo
- Há uma demo em tempo real disponível no HuggingFace Spaces
Arquitetura
- O áudio de entrada (mono 16 kHz) é convertido em espectrograma Mel e depois transformado em texto ao passar pelo encoder (32 camadas) e pelo decoder (26 camadas)
- Principais etapas de processamento
- Espectrograma Mel → encoder (32 camadas, 1280 dimensões) → downsample Conv 4x → adapter (3072 dimensões) → decoder (GQA 32Q/8KV)
- São fornecidos dois caminhos de inferência
- F32 (nativo): baseado em SafeTensors, usando operações de tensor do Burn
- Q4 GGUF (nativo + navegador): quantização GGUF Q4_0, usando shaders WGSL customizados
Soluções técnicas para execução no navegador
- Para executar um modelo 4B no navegador, foram resolvidas 5 restrições
- Limite de alocação de 2 GB → leitura de múltiplos buffers com
ShardedCursor
- Limite de espaço de endereçamento de 4 GB → carregamento em 2 etapas (faz o parsing, libera o reader e depois finaliza)
- Tabela de embeddings de 1,5 GiB → embeddings Q4 na GPU + busca de linhas na CPU
- Leitura síncrona da GPU proibida → uso de
into_data_async().await
- Limite de 256 workgroups → restrição do tamanho do kernel via patch no cubecl-wgpu
Correção de padding do Q4
- O mistral-common padrão faz padding do áudio com 32 tokens de silêncio, mas isso cobre apenas metade dos 38 prefixos do decoder
- Por causa disso, o modelo quantizado Q4_0 gera erros em entradas onde a fala começa imediatamente
- Para resolver, o padding foi expandido para 76 tokens (= 38 tokens do decoder), preenchendo todo o prefixo com silêncio
Build e testes
- Opções de build
- Padrão:
cargo build --release (wgpu + native-tokenizer)
- Para navegador:
wasm-pack build --target web --features wasm
- Testes
- Suporte a testes unitários e de integração com GPU
- Os testes E2E no navegador são executados com Playwright + ambiente real com GPU
- Na CI, esses testes são ignorados por não haver GPU
Preparação do modelo e sharding
Licença e recursos
1 comentários
Comentários do Hacker News
Se houver interesse, o @antirez publicou uma implementação em C do Voxtral Mini 4B
Dá para ver em antirez/voxtral.c
Eu criei meu fork e estou adicionando uma implementação em CUDA e algumas melhorias
Funciona bem, mas ainda não alcança a velocidade do endpoint de API da Mistral AI
Parece que eu deveria ler e aprender materiais relacionados antes de sair programando, então seria ótimo ter algum guia de referência
Não sei bem quais são as diferenças, mas a reação da comunidade parece ser melhor para esse projeto
Testando a demo, só aparece resultado depois de apertar o botão Mic, gravar e então clicar em “Stop and transcribe”
Fiquei pensando se daria para transformar isso em um modo realmente em tempo real, em que as legendas apareçam 1–2 segundos depois de a pessoa falar
A demo hospedada pela Hugging Face implementa isso com um modelo de 8,5GB baseado em GPU
Mas dá para implementar algo parecido com uma UI baseada em ring buffer
Eu uso o Whisper assim no Flutter e também rodo inferência GGUF do llama.cpp em Dart
Mesmo no M4 Max não é tempo real, e o Whisper fica quase em tempo real via ONNX em dispositivos de 2022 para cá
Em hardware de consumo, acho que velocidade de inferência importa mais do que melhorias de precisão (WER)
Esse tipo de modelo aberto on-premises é exatamente a direção de que precisamos
Tanto usuários quanto empresas preferem esse formato. Parece que a Mistral entendeu bem isso
A era dos modelos abertos deve ficar ainda mais interessante agora
Trabalho muito legal. Seria ótimo integrar com o handy.computer, e também fiquei curioso se há planos de suporte a streaming
A primeira versão provavelmente não terá suporte a streaming
Graças a isso conheci uma ótima ferramenta, e agora sinto que suporte ao Voxtral é realmente necessário
Não entendo muito de modelos, mas testei o Nvidia Parakeet e funcionou muito bem
Fico na dúvida se um modelo de 9GB como esse precisa ficar o tempo todo carregado na memória da GPU para uso em tempo real, ou se dá para recarregar a cada vez
Frases curtas são convertidas quase instantaneamente, e frases longas em 1–3 segundos
Uma pequena perda de precisão não faz diferença para uso em conversas com IA
Estou usando o Parakeet V3 no app open source Handy (link), e a implementação em C era bem mais lenta
Em STT, a velocidade é o ponto central da UX
A latência aparece quando você chama um modelo novo ou troca um contexto grande
Na maior parte do tempo o modelo já está carregado, então tokens per second é a principal variável
Em arquiteturas complexas com vários agentes, a troca de contexto deixa tudo mais lento
O prompt caching do ik_llama ajuda a acelerar esse tipo de cenário
Resumindo: a menos que você troque de modelo ou de contexto com frequência, a latência de carregamento dos pesos não é um grande problema
Tenho dúvidas se é eficiente um navegador baixar um modelo de 2,5GB em uma aba e logo depois apagar tudo
Mesmo que internet rápida e armazenamento barato sejam mais comuns, isso ainda parece desperdício
Computação no cliente é legal, mas para um modelo desse tamanho, parece mais certo rodar no servidor
Mas isso pode mudar se surgir um padrão de Web API para LLMs
Se o navegador puder se comunicar com o modelo preferido do usuário e abstrair inferência local/remota, os sites poderiam compartilhar modelos entre si
Se em 2026 um modelo local de 2,5GB ainda for um problema, então o que poderia ser considerado aceitável?
A evolução foi impossível → centralizado → local, e se o preço disso for 2,5GB, parece totalmente administrável
É legal ver isso rodando no navegador, mas eu não quero viver em um mundo onde sites baixam 2,5GB em segundo plano
O Nano fica armazenado localmente e compartilhado entre sites, então só precisa ser baixado uma vez
Pelo visto, não é o caso da Mistral
Há estatísticas sobre isso neste post do blog
mas acho o ambiente sandbox do navegador mais seguro do que instalar um pacote ou baixar um executável
Daqui a pouco esse tipo de coisa também vai parecer normal :-)
No meu ambiente (Firefox, Asahi Linux, M1 Pro), isso falha
Falei “hello” e, cerca de um minuto depois, começaram a aparecer palavras estranhas repetidas
Pergunta simples: queria entender em que nível modelos abertos como os da Mistral estão em comparação com OpenAI ou Anthropic
Já dá para usar recursos de LLM com privacidade em uma máquina pessoal,
ou eles ainda estão muito atrás dos modelos comerciais?
Projeto interessante, e também foi legal ver o uso do framework burn
Mas ao executar na versão mais recente do Chromium, o sistema travou e o SO foi encerrado à força
Logo depois do download do modelo, a conexão VPN também caiu, e não sei por quê, já que não havia limite de banda