Hardware e desempenho da Naomi: perfis, gargalos e escolhas seguras

Um modelo pequeno em texto pode funcionar bem em uma máquina que não sustenta visão multimodal, transcrição pesada e avatar 3D ao mesmo tempo. Da mesma forma, uma GPU rápida pode estar com pouca VRAM livre porque Ollama, OBS, um jogo e o navegador já ocupam recursos. O desempenho útil depende da carga combinada, não apenas do nome do processador.

Os perfis centralizam decisões sobre modelo, concorrência e recursos opcionais. Isso evita que cada módulo invente sua própria regra e que o botão da interface mostre um estado diferente do core. Um perfil conservador é preferível a iniciar rapidamente e falhar com falta de memória no primeiro turno real.

Auto é o padrão porque observa CPU, RAM disponível, GPU selecionada, VRAM livre e o runtime efetivo. Ele não confia apenas em uma API que diga que CUDA existe: prepara dependências, executa um preflight e mantém fallback em CPU quando a aceleração falha ou está sem espaço seguro.

1. 01InventárioDescobre recursos do computador e identifica o dispositivo que realmente será usado.
2. 02DisponibilidadeConsidera memória livre no momento, não apenas a capacidade nominal impressa na caixa.
3. 03ValidaçãoTesta o backend necessário antes de confiar em aceleração, especialmente no caminho de transcrição.
4. 04LimitesEscolhe modelo e concorrência compatíveis e reduz funções opcionais quando elas aumentariam o risco de travamento.
5. 05FallbackSe GPU ou serviço falhar, mantém um caminho em CPU funcional em vez de insistir em um backend quebrado.

• Auto: mede a máquina e escolhe uma base segura. É a melhor primeira tentativa e deve se adaptar quando a aceleração não é comprovada.
• Batata: reduz consumo, concorrência e recursos opcionais para computadores com pouca margem de CPU ou memória.
• Médio: equilibra latência e qualidade em máquinas intermediárias, sem presumir que toda função pesada cabe ao mesmo tempo.
• Ultra: amplia recursos para hardware forte já validado; o nome não substitui um teste de CUDA, driver, áudio e carga combinada.

Perfil é um ponto de partida, não uma pontuação de prestígio. Se Ultra provoca trocas constantes de modelo, paginação de memória ou ruído no áudio, Médio pode entregar uma experiência melhor. Se Auto cai para CPU, isso pode ser uma decisão correta diante de VRAM ocupada, e não um defeito na detecção.

• VRAM: modelos locais, visão multimodal, jogo, OBS e renderização 3D podem disputar o mesmo espaço.
• RAM: contexto, modelos em CPU, navegador e ferramentas de criação aumentam pressão e podem causar paginação.
• CPU: VAD, OCR, transcrição, captura, streaming e automações podem somar picos mesmo quando o LLM usa GPU.
• Áudio: driver, taxa de amostragem, Bluetooth, USB e cabo virtual afetam estabilidade independentemente da velocidade do modelo.
• Disco: primeiro carregamento de modelo, cache e atualização ficam lentos em unidade cheia ou com pouca taxa de leitura.
• Rede: login, Azure, pesquisa, Live e geração de mídia dependem de latência e disponibilidade externas.

O sintoma nem sempre revela a origem. Uma resposta lenta pode ser fila de inferência, troca de modelo, TTS remoto ou rede. Áudio cortado pode vir de reconexão do dispositivo enquanto a inferência está normal. Diagnóstico útil separa captura, transcrição, geração, síntese e reprodução em tempos distintos.

Não existe um número mínimo universal porque a Naomi reúne recursos opcionais. Um computador para texto e voz local não enfrenta a mesma carga de uma live com jogo, OBS, avatar, transcrição, visão e resposta em cabo virtual. Defina primeiro o cenário e meça o conjunto inteiro.

1. Comece com Auto, uma conversa de texto e o modelo planejado.
2. Adicione voz e teste várias interrupções, silêncio e reconexão do microfone.
3. Ative uma integração por vez: Discord, avatar, OBS ou visão.
4. Execute o jogo ou aplicativo real junto do setup, não um benchmark isolado.
5. Observe latência, fila, uso de RAM/VRAM, descartes de frame e estabilidade do áudio por uma sessão prolongada.
6. Reduza modelo, concorrência ou visão antes de culpar todos os módulos ao mesmo tempo.

A otimização mais eficaz costuma vir de reduzir trabalho simultâneo. Mantenha o modelo de reação da Live leve, evite alternar runners grandes a cada evento, diminua a frequência de captura visual e limite respostas concorrentes. Carregar um modelo maior não melhora uma experiência que passa metade do tempo trocando memória entre GPU e sistema.

O Modo Jogo ajuda ao pausar recursos de copiloto e automações que poderiam disputar cursor ou tela, preservando conversa e integrações permitidas. Ele reduz interferência, mas não libera recursos infinitos. OBS, jogo, TTS e modelo ainda precisam de margem suficiente para coexistir.

• Prefira estabilidade térmica e de memória a um pico curto de benchmark.
• Mantenha fallback CPU testado antes de depender de CUDA em uma apresentação.
• Use diagnósticos sanitizados e nunca compartilhe arquivos com tokens ou caminhos privados desnecessários.
• Revalide depois de mudar driver, modelo, microfone, escala do Windows ou aplicativo de streaming.