Agente de voz local em GPU de 12 GB: dá certo?

Quem afirma que 12 GB bastam para um agente de voz local em GPU de 12 GB conta meia verdade. A memória da placa é um orçamento real, mas a conta inteira inclui RAM do sistema, CPU e a política de cancelamento que evita áudio velho.

O que um agente de voz local em GPU de 12 GB precisa medir

Um agente de voz local em GPU de 12 GB é viável, mas o número que importa não é a latência total da conversa: são três eventos distintos. O primeiro som do assistente, a primeira resposta útil e a conclusão da tarefa param cronômetros diferentes, e misturá-los produz comparações falsas.

Dizer "estou verificando" prova que o pedido chegou, não que a contagem existe. Se um gráfico de latência não declara qual evento encerrou a medição, ele não serve para decidir upgrade.

A comparação citada nas notas do projeto usa um RTX 3060 de 12 GB da Nvidia como amostra de hardware, e não como garantia de desempenho. Os tempos do exemplo didático são números escolhidos para tornar a escala visível, não medições da placa.

Detecção de turno e transcrição: onde o atraso começa

A detecção de fala e a detecção de turno respondem a perguntas diferentes. A primeira pergunta se há fala no áudio; a segunda pergunta se você terminou o turno, e uma pausa para respirar no meio da frase pode enganar a segunda.

As notas comparativas do projeto descrevem uma espera padrão de cerca de um segundo de silêncio antes de enviar o turno. Esse segundo é sentido pelo usuário antes de qualquer modelo entrar em ação, e encurtá-lo reduz o espaço para concluir um raciocínio. Push-to-talk resolve o limite quando a fronteira importa mais do que o modo mãos livres.

Enquanto o limite é decidido, o reconhecimento pode adiantar trabalho. O projeto envia snapshots rolantes do Whisper, o modelo de reconhecimento de fala da OpenAI, durante a fala e logo após o silêncio, em vez de um fluxo contínuo de palavras finais.

No fim do turno, a aplicação verifica se um transcrito completo cobre a última fala detectada. Se cobrir, o resultado é reaproveitado; se não, a gravação final ainda precisa ser transcrita. Essa checagem de cobertura remove trabalho da espera sem descartar a última palavra.

Ferramentas, dependências e a conta do exemplo

Um agente só existe quando o modelo propõe uma ação e o código fora do modelo decide se e como executá-la. O modelo recebe o transcrito, o contexto da conversa e a lista de ferramentas; antes de responder, processa tudo isso no prefill e só então gera tokens.

Uma taxa alta de tokens mede a fase de geração. Ela não mede a escuta nem o processamento do prompt, e por isso não pode ser citada como latência de resposta.

No exemplo didático, o transcrito é "quantas builds falharam ontem" e "ontem" significa 14 de setembro no fuso escolhido. O fixture contém oito registros de build; três falharam nessa data e a consulta retorna os identificadores 101, 103 e 106. A resposta, três, tem evidência reproduzível pequena, mas real, porque a consulta rodou contra dados autorais.

Resolva o limite de data de forma deliberada. Um servidor em fuso diferente responde à pergunta errada com uma consulta SQL perfeitamente válida.

O TrueForge, harness de agente mantido pela TrueFoundry, é descrito pela própria empresa como o runtime em volta de chamadas de modelo, ferramentas, aprovações e estado de sessão, com licença MIT. Ele oferece interface de chat e API, então dá para colocar uma camada de voz sobre o backend sem transformar a janela de chat no produto inteiro. O suporte a endpoints externos de modelo também significa que rodar localmente não estabelece sozinho para onde cada requisição vai.

Como a sobreposição corta 6,8 s para 3 s

A sobreposição reduz a primeira resposta falada de 6,8 s para 3 s no exemplo didático, sem trocar hardware. O ganho vem de iniciar mais cedo o trabalho cujas dependências já foram satisfeitas, e não de acelerar cada bloco.

A linha do tempo sequencial começa quando a fala termina: 1 s de detecção de turno, 0,6 s de transcrição, 0,7 s para o modelo escolher a ferramenta, 0,3 s de consulta, 1,8 s para o texto completo e 2,4 s para sintetizar todo o áudio. Playback começa 6,8 s depois, porque cada bloco espera o anterior.

Substitua essa ordem por trabalho sobreposto. Suponha que o transcrito que cobre a fala final esteja pronto 0,8 s após o usuário parar: ele cabe dentro da janela de 1 s de detecção de turno, e a transcrição deixa de somar peso. As dependências da ferramenta continuam: o modelo escolhe a consulta, a consulta roda, o resultado volta. Isso leva o relógio a 2 s.

Sobrepor não dá permissão para inventar o resultado do banco enquanto o banco trabalha. Se a primeira frase completa da resposta leva 0,4 s para aparecer e o primeiro áudio tocável leva outros 0,6 s, o som começa aos 3 s. O parágrafo completo e o áudio completo deixam de ficar na frente da primeira frase útil.

Limites físicos do handoff por frase e do buffer

Fronteiras de frase são o ponto de entrega prático porque a fala precisa de contexto para soar coerente. Passar cada palavra nova direto ao sintetizador estraga a entonação ou empurra o buffering para outro lugar.

O projeto implementa filas separadas de síntese e de reprodução. O código permite uma requisição de síntese por vez e no máximo duas frases concluídas esperando à frente do playback, então a sobreposição não exige duas cópias do modelo de fala disputando a GPU.

Existe um limite físico para reprodução fluida. Se gerar a próxima frase leva consistentemente mais tempo do que tocar a atual, a fila seca. Um buffer de partida absorve um atraso curto; ele não conserta um produtor que fica para trás. Começar na hora e parar no meio de uma palavra é uma troca ruim.

As notas históricas de runtime acelerado do projeto trazem uma amostra estreita: com Qwen residente no RTX 3060, gerar 4,88 s de fala em 3,05 s e primeiro áudio reportado a 0,94 s. É uma amostra de geração de fala aquecida, com durações de saída diferentes das 4,32 s de áudio em 8,4 s do runtime Python anterior, e não o atraso completo entre pergunta e resposta.

VRAM, CPU e o orçamento de memória que o título esconde

Colocar 12 GB no título não torna o modelo de fala gratuito. A amostra nativa relata cerca de 4,3 GiB de memória gráfica usada só pelo processo de fala, alocação que convive com o modelo de linguagem e demais necessidades de runtime.

O projeto documenta o Whisper rodando na CPU, o que libera capacidade de GPU para outro trabalho. O llama.cpp, runtime de inferência do projeto ggml, também permite distribuir trabalho entre CPU e GPU. Mover pesos para a memória do sistema faz um modelo maior caber, mas dá trabalho real à CPU.

Para modelos de mistura de especialistas, o llama.cpp tem controles para manter pesos de especialistas na CPU. Especialistas são componentes selecionados por token, não todos os parâmetros participando igualmente de cada passo. O posicionamento seletivo preserva espaço na GPU, mas não faz os pesos restantes desaparecerem nem torna a RAM tão rápida quanto a memória gráfica.

A documentação pública de voz estabelece onde o reconhecimento de fala roda, mas não entrega um inventário completo de memória para a gravação de comparação. Então não há requisito total verificado de RAM para aquele run: trate isso como medição ausente ao planejar uma configuração parecida.

Desenhe dois orçamentos separados. A memória gráfica segura as porções residentes do modelo, o modelo de fala, buffers de trabalho e caches ali designados. A memória do sistema segura as porções descarregadas e o resto da aplicação, com folga para o sistema operacional e suas ferramentas. Um processo de build rodando ao lado compete pela mesma CPU e memória.

O guia de speech-to-speech do Hugging Face estima 24 GB de memória gráfica para o exemplo Nvidia não quantizado, além de RAM do sistema, e chama isso de estimativa de planejamento. Modelos, quantização e posicionamento diferentes mudam o orçamento, então uma configuração de 12 GB precisa ser deliberada.

Onde "local" deixa de significar local

Rodar a interface no seu notebook não significa que o modelo de voz e o backend de codificação também rodem ali. Você precisa inspecionar a rota configurada antes de chamar o arranjo de privado.

O Qwen Audio Agent é um runtime de voz de código aberto cujo front end padrão usa o DashScope. A documentação também descreve um front end self-hosted de speech-to-speech, ou seja, existe um caminho local, mas ele não é o padrão automático.

Siga o pedido para descobrir o que permanece local. Para onde vai o áudio do microfone? Para onde vai o transcrito? Qual máquina roda o modelo de linguagem, e as ferramentas dele podem chamar serviços externos? Decida qual fronteira você precisa e verifique os endpoints configurados contra ela.

Interrupção (barge-in) e cancelamento de ferramentas

Uma boa interrupção para o áudio agendado, cancela a síntese pendente e impede que resultados atrasados da resposta antiga entrem na fila nova. Sem isso, o assistente volta a ler a frase que você já interrompeu.

O projeto cria um novo run quando há cancelamento, limpa as filas antigas e aborta o sinal delas. Quando uma requisição antiga termina tarde, ela verifica se ainda pertence ao run atual antes de aceitar o resultado. Essa checagem de identidade é pequena, mas evita áudio velho envenenando respostas seguintes.

Cancelar fala e desfazer uma ação de ferramenta são operações diferentes. Se a ferramenta já iniciou um build, limpar a fila de áudio não desfaz o build. No exemplo, a ferramenta só lê registros; para ações que mudam algo, defina o que cancelamento significa e quando a ação vira compromisso.

Os testes do repositório cobrem essas regras de fila. Relatos do material de pesquisa indicam sete testes de fila aprovados, incluindo ordem das frases, limite de prefetch e rejeição de saída obsoleta. São eventos de software controlados: eles não medem um modelo de fala ao vivo nem seu hardware.

Como montar um teste honesto

Grave uma linha do tempo única, com fronteiras de evento claras: última fala detectada, transcrito final, pedido e resultado da ferramenta, primeiro texto da resposta e início do playback. O profiler do projeto faz esse tipo de quebra e sua documentação explica quais intervalos incluem espera em vez de computação isolada de modelo.

Use um relógio comum para intervalos comparáveis. O navegador estima o playback pela saída agendada e pela latência relatada do dispositivo, mas isso não captura o silêncio inicial nem todo atraso de dispositivo. Um teste acústico grava o fim da pergunta e o primeiro som não silencioso na mesma base de tempo.

Depois, torne a comparação justa. Mantenha prompt, contexto inicial, modelo, voz e ajustes de raciocínio fixos enquanto habilita uma sobreposição por vez. As notas comparativas do projeto também descrevem variantes que mudam o comportamento de raciocínio e as instruções de resposta: são escolhas de produto úteis, mas combiná-las com mudanças de agendamento destrói a isolação do agendamento.

O conjunto de teste mínimo inclui uma pergunta curta, um pedido real de ferramenta, uma resposta longa e uma interrupção. Registre partidas frias separadas dos turnos aquecidos. Junto com o atraso, verifique se o transcrito manteve as palavras importantes, se a ferramenta usou os argumentos certos e se a resposta falada bateu com o resultado. Conte falhas em vez de excluí-las do resumo de tempos.

A escolha entre carregar o modelo de fala sob demanda e mantê-lo aquecido é uma troca explícita. Carregar quando precisa economiza memória ociosa, mas a primeira resposta paga o custo de carregamento. Uma demonstração gravada após aquecimento e uma sessão nova depois de reiniciar respondem perguntas diferentes.

Perguntas frequentes

• Dá para rodar um agente de voz local em GPU de 12 GB? Sim, para uma tarefa de leitura bem delimitada e com configuração deliberada. A evidência publicada sustenta montar esse arranjo, mas não estabelece latência universal de conversa. Trate os 12 GB como orçamento da placa, não como conta total de memória.

• Qual é o atraso real até a primeira resposta falada? Não existe número universal. O exemplo didático do projeto vai de 6,8 s sequenciais para 3 s com sobreposição, mas esses tempos são números escolhidos para tornar a escala visível. Durações reais dependem de modelo, pergunta, máquina e contenção.

• Por que o Whisper roda na CPU nesse tipo de pipeline? Para deixar capacidade de GPU disponível ao modelo de linguagem e à síntese de fala. O llama.cpp permite distribuir pesos entre CPU e GPU, o que ajuda modelos maiores a caber, mas dá trabalho real à CPU e não torna a RAM equivalente à memória gráfica.

• O que a interrupção precisa cancelar? Parar o áudio agendado, cancelar a síntese pendente e rejeitar resultados atrasados do run antigo. Cancelar fala não desfaz uma ação de ferramenta já iniciada: se a ferramenta altera algo, defina quando a ação vira compromisso e relate o que de fato aconteceu.

• Quando o pipeline é realmente local? Só quando você verifica os endpoints configurados. O Qwen Audio Agent, por exemplo, usa DashScope no front end padrão e também documenta um front end self-hosted. Rodar a interface na sua máquina não prova que o modelo de voz ou o backend rodam ali.

Source video