Yandex: Alice processa comandos de casa inteligente no próprio alto-falante — em média 6x mais rápido que a nuvem

• Станция Миди и голосовое управление Zigbee-устройствами без интернета. История разработки — Habr (блог Яндекса), 2023-11
• Итоги Яндекса за 2025: 5,3 млн активных устройств YaOS/YaOS X, 2,9 млрд запросов к Алисе — Habr, 2025
• Яндекс.Станция — линейка устройств, включая Станцию Мини 3 Про с локальной обработкой команд — TAdviser, n/a
• Яндекс Станция Миди — официальная страница продукта (Zigbee-хаб, локальные команды) — Яндекс, n/a

Contexto

Alice é o assistente de voz da Yandex que vive em alto-falantes inteligentes e TVs nas plataformas YaOS e YaOS X. A escala do ecossistema até o final de 2025: 5.3 milhões de dispositivos ativos, 2.9 bilhões de solicitações processadas no ano, e 14 novos gadgets inteligentes na linha (dados da Yandex publicados no Habr). É um dos maiores ecossistemas de voz fora do mundo de língua inglesa.

Em novembro de 2023, a Yandex lançou o Station Midi — o primeiro alto-falante em que a Alice aprendeu a entender e executar comandos de casa inteligente localmente, no próprio dispositivo, sem uma ida e volta para a nuvem. O Midi também funciona como um hub Zigbee em si: sensores, lâmpadas e plugues se conectam ao alto-falante diretamente, contornando os serviços em nuvem.

O que torna o caso notável do ponto de vista da engenharia: a Yandex é uma empresa rara que documentou publicamente sua arquitetura local — o time a descreveu em um post técnico no Habr em novembro de 2023, com tamanhos de modelos concretos, pegadas de memória e histórico de otimizações. Para comparação: Amazon e Google também moveram o processamento de comandos de voz para dispositivos, mas nunca forneceram documentação de engenharia pública tão detalhada de suas soluções.

Essa abertura torna o caso verificável e instrutivo: você pode rastrear como uma pilha de processamento de reconhecimento de fala e compreensão do lado do servidor ocupando dezenas de gigabytes é espremida em um alto-falante com um gigabyte de RAM.

Problema

A arquitetura clássica do assistente de voz roteia cada comando através da nuvem: a gravação de voz vai para um servidor, é reconhecida e interpretada lá, e a resposta retorna ao dispositivo. Para uma casa inteligente, isso significa dois problemas. Primeiro, a latência entre dizer 'desligue a luz' e a luz realmente desligar: mesmo com boa internet, o comando faz uma viagem completa pela rede, embora o alto-falante e a lâmpada estejam no mesmo cômodo. Segundo, uma casa inteligente completamente não funcional durante quedas de internet: uma chave de luz que morre com o Wi-Fi prejudica a confiança na própria ideia de uma casa inteligente.

Mover o processamento para o dispositivo encontrou uma aritmética de recursos difícil. A pilha de servidor do Alice foi projetada para um data center: o serviço NLU de nuvem 'Begemot' sozinho requer pelo menos 30 gigabytes de RAM e cerca de 30 gigabytes de disco. Um alto-falante inteligente típico (Station Mini) tem 256 megabytes de RAM e 256 megabytes de flash — uma diferença de mais de cem vezes. O reconhecimento de fala local também tem de trabalhar em modo streaming — começar a analisar a frase antes da pessoa terminar, caso contrário não há ganho de velocidade.

Assim, a tarefa foi enquadrada não como 'colocar um modelo em um alto-falante', mas como um programa de engenharia completo: reconstruir três subsistemas — reconhecimento de fala (ASR), compreensão de linguagem (NLU) e o backend de casa inteligente — em versões que caibam dentro de megabytes de um ou dois dígitos, sem perda de qualidade na classe-alvo de comandos.

Solução

A fundação foi estabelecida no tempo do design de hardware. O Station Midi é construído em um SoC Amlogic A113X2 com um processador neural integrado (NPU), 1 gigabyte de RAM e 8 gigabytes de flash — versus 256 megabytes de cada um no Mini. O NPU e a margem de memória foram uma aposta deliberada em modelos locais, feita antes desses modelos estarem prontos.

O reconhecimento de fala (ASR) foi construído em um encoder transformer com uma mudança de CTC para RNN-T — uma arquitetura que permite reconhecimento em streaming, em tempo real: o alto-falante analisa a frase enquanto está sendo falada. O modelo, aproximadamente 10 milhões de parâmetros, foi treinado no mesmo conjunto de dados do reconhecedor de nuvem, com exemplos de comandos de casa inteligente adicionados. Para comparação: modelos ASR de nuvem são ordens de magnitude maiores.

A compreensão de linguagem foi resolvida adaptando o serviço 'Begemot' do lado do servidor — assim nasceu 'Begemotik'. De um serviço que requer pelo menos 30 gigabytes de RAM, tudo desnecessário para o domínio de casa inteligente foi cortado: componentes ML pesados, reconhecimento de geografia e data. O resultado — 90 megabytes de RAM e 73 megabytes de flash: duas a três ordens de magnitude de compressão, mantendo a qualidade nos comandos-alvo.

O terceiro componente é o backend de casa inteligente local em Go: a lógica de execução de comando que consumia 500+ megabytes na nuvem foi espremida para ~200 megabytes de RAM e 90 megabytes de flash — em parte abandonando síntese de fala e mantendo armazenamento local de configuração de casa inteligente com sincronização.

O elo de ligação é o hub Zigbee integrado: dispositivos de casa inteligente se conectam ao alto-falante diretamente, portanto, todo o caminho 'voz → reconhecimento → interpretação → comando de dispositivo' fica dentro do apartamento. A internet não é necessária para esses cenários. A arquitetura é híbrida, porém: qualquer coisa além de rotinas de comandos de casa inteligente — música, busca, conversa com Alice — ainda vai para a nuvem, onde os modelos de tamanho completo são executados.

Notavelmente, o time publicou não apenas o resultado, mas o histórico de desenvolvimento com falhas e bifurcações intermediárias (por exemplo, por que o CTC foi abandonado em favor de RNN-T) — um nível raro de transparência de engenharia para um produto de consumo.

Resultado

De acordo com o time da Yandex, o processamento local de comandos de casa inteligente é em média 6x mais rápido que o caminho em nuvem — o ganho vem da eliminação da viagem de rede redonda mais processamento em streaming no dispositivo; a empresa não publicou milissegundos exatos, e a velocidade de reconhecimento varia com a complexidade da frase. Luzes e outros dispositivos Zigbee continuam funcionando quando a internet cai — a resiliência offline se tornou não um efeito colateral, mas o segundo resultado de manchete do projeto.

A abordagem pegou em toda a linha: dispositivos mais novos, incluindo Station Mini 3 Pro, também receberam processamento de comando de voz local (TAdviser) — o Midi não foi um experimento, mas um teste de arquitetura para toda a plataforma. O ecossistema continuou crescendo enquanto isso: 5.3 milhões de dispositivos YaOS/YaOS X ativos e 2.9 bilhões de solicitações de Alice em 2025.

A escala de compressão que o time documentou em números é reveladora em si: NLU — de pelo menos 30 gigabytes de RAM para 90 megabytes; o backend de casa inteligente — de 500+ para ~200 megabytes; ASR — para um modelo ~10 milhões de parâmetros, ordens de magnitude menores que homólogos em nuvem. Esses números são um ponto de referência público raro para quem avalia a viabilidade de IA no dispositivo em hardware barato.

Na nossa opinião, a principal lição transferível do caso é a decomposição correta do híbrido: a Yandex não tentou arrastar 'todo o Alice' para o alto-falante; isolou o domínio estreito onde a localidade gera o máximo valor (comandos de casa inteligente rotineiros — alta frequência, curtos, com vocabulário limitado) e deixou tudo o mais para a nuvem. Esse enquadramento — 'local para o que é frequente e simples; nuvem para o que é raro e complexo' — se aplica muito além da casa inteligente: de menus de voz de bancos a assistentes automotivos.

A segunda observação: IA no dispositivo começa com hardware. O NPU no SoC e o gigabyte de memória foram projetados no Midi antecipadamente — em um chip fraco essa arquitetura não teria acontecido. Times planejando modelos locais em dispositivos devem orçar margem de computação uma geração antes dos modelos estarem prontos — caso contrário, quando o software amadurecer, o hardware em dispositivos já vendidos não conseguirá lidar.

Lições aprendidas

1. Latência é uma métrica de produto de casa inteligente: os usuários sentem o ganho 'em média 6x' a cada clique de um interruptor.
2. IA no dispositivo é acima de tudo uma disciplina de compressão: um ASR ~10M-parâmetro e uma NLU espremida de 30 GB para 90 MB são suficientes para comandos rotineiros — nenhum modelo gigante necessário.
3. Comprima cortando o domínio, não apenas por quantização: 'Begemotik' ficou centenas de vezes menor que 'Begemot' porque tudo que a casa inteligente não precisa foi cortado (geografia, datas, componentes ML pesados).
4. Decomponha o híbrido por frequência e complexidade: local para comandos frequentes simples, nuvem para consultas raras complexas; não tente arrastar todo o assistente para o dispositivo.
5. Resiliência offline é um valor por si só: uma casa inteligente que morre com o Wi-Fi prejudica a confiança em toda a categoria.
6. Hardware especializado (um NPU no SoC, margem de memória) deve ser planejado no tempo de design do dispositivo — uma geração antes dos modelos estarem prontos; você não pode retrofit modelos no dispositivo em um chip fraco.
7. Um artigo de engenharia público (Habr) com tamanhos de modelos concretos e um histórico de falhas é uma prática rara e correta: torna os resultados reivindicados verificáveis.

Perguntas frequentes