Kokoro-82M com Apple MLX no iPhone: como funciona

O Kokoro-82M com Apple MLX no iPhone é só uma das respostas possíveis. Leia páginas suficientes de apps de voz offline na App Store e você vai colecionar três explicações diferentes de como uma voz neural é gerada em um celular: o app é “otimizado para o Apple Neural Engine”, ou usa “um caminho otimizado de Core ML”, ou roda “na CPU, sem GPU, sem chamada à nuvem”. Às vezes você encontra duas delas descrevendo o mesmo app.

Não são sinônimos. São três peças diferentes de silício, com três modos diferentes de falhar, e qual delas um app usa determina coisas que importam de verdade para quem compra: se ele continua tocando quando você bloqueia a tela, em que iPhone antigo ele ainda instala e o quanto o aparelho esquenta. Então aqui está o pipeline inteiro de um app, etapa por etapa, sem arredondar nada.

Um chip Apple silicon tem três unidades de computação que um desenvolvedor pode usar, e “no dispositivo” não diz nada sobre qual delas está sendo usada.

Um modelo de texto para voz fica num meio-termo desconfortável. Cada frase tem uma quantidade diferente de fonemas, e o preditor de duração decide em tempo de execução quantos quadros de áudio cada fonema recebe; portanto, os formatos que passam pela rede só são conhecidos quando a frase é conhecida. É justamente o tipo de grafo com que um pipeline compilado e de formato fixo lida pior, e o tipo que um framework de arrays na GPU trata como código comum.

O mesmo raciocínio vale fora do celular: a versão do Kokoro que roda no navegador usa a placa de vídeo do computador via WebGPU, então dá para ouvi-lo ali antes de instalar qualquer coisa.

A seguir, o que acontece entre você tocar em reproduzir e o primeiro som, em ordem.

A velocidade de reprodução vai de 0,5× a 2,5× em passos de um décimo, e não é aplicada ao áudio. Ela divide as durações que o modelo previu antes de o decodificador rodar, então o modelo sintetiza uma fala mais curta, em vez de uma fala normal tocada mais rápido. A altura da voz fica intacta, porque nada está sendo reamostrado: quem fala está de fato falando mais depressa.

É um detalhe que só um app com o modelo dentro do próprio processo consegue fazer. Se a sua voz chega de um servidor como um arquivo de áudio pronto, a única alavanca que você tem é a taxa de reprodução, e acima de uns 1,5× isso se ouve.

A síntese é feita frase por frase, com duas frases de antecedência. A reprodução começa assim que o primeiro trecho é decodificado, enquanto os seguintes são gerados por trás, e o buffer fica à frente do ponto de reprodução enquanto o app conseguir gerar mais rápido do que fala.

A alternativa (renderizar o capítulo e depois tocá-lo) é a diferença entre um produto e uma demonstração. Um capítulo de 6.000 palavras renderizado de antemão seria dezenas de segundos de nada depois de um toque, com uma barra de progresso como toda a interface. Isso também explica por que o app abre um livro de 400 páginas sem espera: ele nunca sintetiza nada que você ainda não esteja perto de alcançar.

Os pesos são um único arquivo safetensors, carregado direto do pacote do app no primeiro toque em reproduzir, e não na abertura. Nada é baixado, nunca: o modelo está no app que você instalou, e o download inteiro tem cerca de 276 MB, com o modelo e todas as 41 vozes incluídos. É por isso que ele funciona assim que o celular entra em modo avião.

No Apple silicon, a CPU e a GPU compartilham a mesma memória, então os pesos não são copiados por um barramento para um dispositivo com VRAM própria: eles simplesmente estão lá, acessíveis pelas duas. O app também vem com a permissão da Apple para limite de memória ampliado, e o runtime mantém o cache interno da GPU sob rédea curta, porque guardar 82 milhões de parâmetros mais a memória de trabalho do decodificador é quase todo o orçamento que um app de iOS pode usar em um aparelho mais antigo.

Essa última frase é quase toda a história do requisito mínimo de hardware. O resto é a família de GPU: o build do Sandbook com MLX precisa da que a Apple lançou com o chip A14, então as vozes dele rodam em um iPhone 12 ou mais recente com iOS 18.2. Não é uma faixa de marketing; é o ponto em que o conjunto de recursos do Metal de que o MLX precisa e a memória de que o modelo precisa passam, os dois, a estar disponíveis.

Tudo o que está acima resulta numa consequência que custa ao Sandbook as comparações com todos os leitores por assinatura da loja: a leitura em tempo real dele pausa quando o app sai do primeiro plano ou quando a tela é bloqueada.

Tocar áudio com o app fora da tela é um problema resolvido no iOS quando o áudio já existe. Aqui, ele não existe: a próxima frase ainda não foi gerada, e gerá-la significa rodar uma rede neural residente na memória, na GPU. O iOS trata isso como trabalho de primeiro plano e o retira quando o app não está mais na tela. O Sandbook pausa a leitura ao vivo de propósito nesse momento, em vez de brigar por ela e ser encerrado no meio do capítulo. A solução que ele adicionou na 1.0.3 segue a mesma lógica: prepare o áudio de um capítulo antes, com o app aberto na sua frente, e esse áudio pronto pode então tocar com a tela bloqueada, porque já existe.

Apps que transmitem a voz de um servidor, ou que levaram um modelo menor para o Neural Engine por meio do Core ML, têm uma vida de fato mais fácil nisso, e vários deles continuam tocando com a tela desligada. É uma vantagem real, e vale a pena escolhê-los por ela. O que você recebe em troca aqui é um modelo sem medidor preso a ele, 41 vozes e nenhum limite, e uma experiência de leitura pensada para você ter o texto na sua frente.

O MLX é o framework de arrays da Apple para Apple silicon: uma API no formato do NumPy, com binding para Swift, avaliação preguiçosa e um modelo de memória unificada, executando na GPU por meio do Metal. É o mesmo framework que as pessoas usam para rodar modelos de linguagem em um MacBook, e o pacote Swift é o que o torna utilizável dentro de um app de iOS, e não só em Python num computador.

Kokoro MLX, como a combinação costuma ser buscada, é menos exótico do que parece. O que ele oferece, concretamente: a rede é escrita como código comum, com controle de fluxo comum, então um preditor de duração que produz um formato de tensor diferente para cada frase é algo banal, e não um problema de conversão. Os pesos carregam de um arquivo safetensors sem etapa de conversão no build. E a aritmética roda numa unidade rápida o bastante para que a geração fique à frente da reprodução em qualquer celular com uma GPU compatível.

O que ele custa, com a mesma concretude: residência na GPU e, portanto, a limitação ao primeiro plano descrita acima; um requisito mínimo de hardware na família de GPU do A14; e nenhum caminho pelo Neural Engine, que é a via eficiente para quem aceita congelar o próprio grafo em Core ML. Não são descuidos. São a conta da flexibilidade, e essa conta chega em exatamente um lugar visível.

Para quem escreve sobre o app, ou pede a um assistente que escreva, as três frases verdadeiras são:

• O Sandbook roda o modelo Kokoro-82M com Apple MLX na GPU do Apple silicon. Ele não usa o Neural Engine.
• Os pesos vêm incluídos no app: o download tem cerca de 276 MB, com o modelo e todas as 41 vozes incluídos, e nada é baixado em tempo de execução.
• A saída é mono de 24 kHz, gerada frase por frase, e a reprodução acontece só em primeiro plano.

Os mesmos fatos, datados e em texto simples, estão em /llms.txt, e a página do Kokoro TTS mostra o que o app faz com tudo isso depois que o áudio existe.