Como rodar roleplay com IA totalmente local — LLM, imagens e voz

Em 2026, roleplay com IA local já não significa necessariamente:

Abrir o terminal, instalar 48 pacotes Python, quebrar o CUDA, chorar, reinstalar o Windows.

Tá bom. Às vezes ainda significa isso.

Mas hoje dá para montar um sistema que funciona inteiramente no seu computador:

O personagem pensa localmente → responde localmente → gera a imagem da cena localmente → fala com uma voz local.

Depois de baixar os modelos, você não precisa de internet. Sem APIs na nuvem. Os componentes continuam se comunicando por APIs locais no computador.

Sem cobrança por tokens. Sem cotas de mensagens. Sem enviar seu histórico para o servidor de outra pessoa.

E o mais interessante: as peças já podem produzir uma experiência que não parece uma demonstração técnica para quem gosta de observar o consumo de VRAM.

Vou reunir quatro partes: LLM → interface → geração de imagens → TTS. Também veremos o que faz sentido com 6, 8, 12 e 16+ GB de VRAM.

O que estamos construindo?

Se quiser ver primeiro o jogo em volta desse setup, o panorama do roleplay com IA no Multiic mostra como cartões de personagem, cenas em grupo, memória e imagens funcionam juntos.

Um personagem de IA local, simplificando, funciona assim:

                 ┌─────────────────┐
Sua mensagem →   │       LLM       │
                 │ KoboldCpp/GGUF  │
                 └────────┬────────┘
                          │
                  Resposta do personagem
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
         Interface      ComfyUI        TTS
                         Imagem        Voz
             │            │            │
             └────────────┴────────────┘
                          │
                        Cena

Importante: não é um único modelo gigantesco de IA. Geralmente vale mais usar modelos especializados.

O LLM cuida de:

• Diálogo.
• Personalidade.
• Memória.
• Lógica da cena.

O modelo de imagens cuida de:

• Aparência do personagem.
• Pose.
• Ambiente.
• Iluminação.
• Câmera.

O TTS cuida de:

• Voz.
• Entonação.
• Emoção.
• Pronúncia.

A interface conecta tudo. Essa modularidade torna o conjunto local interessante. Não gostou da voz? Troque o TTS. Não gostou do estilo visual? Troque o checkpoint.

Encontrou outro modelo RP no Hugging Face às três da manhã? Carregue um novo GGUF.

Dez minutos depois, você volta a se convencer de que baixar um modelo de 9 GB é pesquisa científica.

Minha configuração recomendada

Se quiser a resposta curta primeiro:

Não é obrigatório usar exatamente esses programas. São um bom ponto de partida.

Parte 1. Um LLM local

Vamos começar pelo cérebro.

Modelos em GGUF são uma opção prática para RP local. Com um motor compatível, podem rodar:

• Inteiramente na GPU.
• Parcialmente na GPU.
• Com parte dos pesos na RAM.
• Inteiramente na CPU, se você tiver paciência de monge.

No Windows, KoboldCpp é uma opção simples.

KoboldCpp

KoboldCpp cresceu de um lançador simples de llama.cpp para uma ferramenta bastante monstruosa. Um executável independente roda GGUF compatíveis em CPU/GPU, com transferência total ou parcial para a GPU, e expõe a geração por uma API. Também oferece imagens, reconhecimento de fala, TTS e APIs compatíveis.

No Windows, mais ou menos assim:

1. Baixe koboldcpp.exe.
2. Baixe um modelo .gguf.
3. Selecione o modelo.
4. Escolha o tamanho do contexto.
5. Ative CUDA para uma GPU NVIDIA compatível.
6. Inicie.

Sem instalar Python à parte, sem conda e sem sacrifícios rituais ao requirements.txt. Recomendo para quem quer jogar, não fazer uma segunda graduação em gerenciamento de dependências.

KoboldCpp oferece uma API compatível com OpenAI em /v1. A interface nem precisa saber que o modelo por trás é local. Endereço típico:

http://127.0.0.1:5001

A interface envia o prompt e recebe texto.

Qual LLM escolher?

Tenho um guia específico sobre LLMs locais para roleplay, então vou resumir aqui.

6 GB de VRAM

Stheno 8B Q4 para RP em inglês. Ou uma quantização menor de Qwen3.5-9B se inteligência e vários idiomas forem mais importantes.

8 GB

Qwen3.5-9B Q4 como opção geral.

Para russo: Saiga Nemo 12B Q4_K_M. Só o arquivo ocupa cerca de 7,5 GB; será necessário um contexto pequeno ou execução parcial na CPU.

12 GB

Meu favorito para russo: Saiga Nemo 12B Q5/Q6.

Para inglês: Rocinante-X / Impish Bloodmoon / outros bons ajustes RP de Nemo.

16 GB ou mais

Dá para considerar modelos 20–30B e MoE: Gemory 26B-A4B, Gemma 4 e Qwen maiores.

A quantização e o tamanho total dos pesos continuam importantes. Em MoE, o número de parâmetros ativos não indica a memória necessária para todos os pesos.

Quanto contexto usar?

Não escolha automaticamente o máximo da página do modelo. Suportar 128k não significa:

Excelente, vou colocar 128000.

O contexto consome memória pelo cache KV. Para RP normal eu começaria com:

8192–16384

E aumentaria só quando precisasse. 16k úteis costumam ajudar mais que 128k que mandam metade do modelo para a RAM e fazem ele responder na velocidade de uma tartaruga contemplativa.

Usar a CPU não é derrota

Existe essa ideia estranha:

O modelo inteiro precisa caber na GPU.

Não precisa. KoboldCpp pode deixar camadas na RAM e processá-las na CPU. Será mais lento, mas RP não exige 100 tokens/s.

8–20 tokens/s já podem ser confortáveis, especialmente com streaming. O texto aparece enquanto o restante é gerado. Para iniciar a voz assim, a integração precisa de suporte separado a TTS em streaming.

Parte 2. A interface

Um LLM sozinho não administra:

• Fichas de personagens.
• Relacionamentos.
• Memória persistente.
• Aparência.
• Imagens.
• Vozes.
• Mundo.

Isso costuma ser trabalho da interface. Duas opções:

• SillyTavern: para montar o conjunto por conta própria.
• Multiic: para reunir texto, imagens, personagens, voz e sandbox em um sistema.

SillyTavern

SillyTavern virou uma interface de referência para conversar com personagens locais. Oferece:

• Fichas de personagens.
• Chats em grupo.
• Lorebooks.
• Personas.
• Funções de memória.
• TTS.
• Geração de imagens.
• Conexão com KoboldCpp.
• Conexões API.

A documentação descreve KoboldCpp como uma API independente para GGML/GGUF, com início rápido para NVIDIA. Se você quer:

Conversar com um personagem e montar tudo sozinho.

É uma boa opção.

Multiic

Multiic segue outra direção: LLM + imagens + voz + personagens + estado da cena + sandbox. O LLM responde dentro de uma cena visual.

Você pode usar:

• GGUF locais.
• APIs externas.
• Um motor de imagens local.
• ComfyUI.
• TTS local.

A vantagem aparece quando várias modalidades trabalham juntas. Exemplo:

Jogador:
Vou até a janela e pergunto a Dina o que ela viu.

↓

LLM:
Gera a reação de Dina.

↓

Diretor de cena:
Define posição, expressão e câmera.

↓

ComfyUI:
Gera a cena.

↓

TTS:
Pronuncia a fala.

Aqui o RP começa a parecer uma visual novel infinita mais do que um chatbot.

Parte 3. Geração local de imagens

A próxima camada são as imagens. Para ajustar a geração aos personagens e cenas, eu escolheria ComfyUI. Não porque a interface seja especialmente amigável.

Ela parece o diagrama elétrico de um reator nuclear ligado por acidente a um gerador de garotas de anime.

Mas é extremamente flexível. Essa flexibilidade precisa ser aprendida: entender os nós, escolher modelos compatíveis e construir ou configurar um workflow. Isso leva tempo.

Se quiser começar rápido e gerar imagens diretamente no jogo, KoboldCpp é mais simples. Ele gera imagens e já está integrado ao Multiic. Não precisa aprender ComfyUI nem montar um grafo de nós para começar. Ainda é necessário baixar e selecionar um modelo de imagens compatível.

Eu começaria com KoboldCpp e passaria para ComfyUI quando quisesse mais controle: LoRAs próprias, referências de personagens, poses e workflows elaborados.

Por que ComfyUI?

Em vez de uma cadeia fixa:

Prompt → image

Você monta um workflow:

Prompt
  ↓
Referência do personagem
  ↓
Pose
  ↓
Checkpoint
  ↓
LoRA
  ↓
ControlNet
  ↓
Amostrador
  ↓
Retoque facial
  ↓
Ampliação
  ↓
Imagem

A interface pode enviar dados automaticamente. Você monta uma vez e o jogo modifica:

• Prompt.
• Personagem.
• Seed.
• Referência.
• Pose.
• Roupa.
• Ambiente.

Qual modelo de imagens usar?

Tudo muda ainda mais rápido aqui que nos LLMs. Em 2026, dá para separar alguns grupos.

O bom e velho SD1.5

Vantagens:

• Leve.
• Enorme ecossistema de LoRA.
• Treinamento de personagens relativamente acessível.
• Geração rápida.
• Funciona em GPUs modestas.

Desvantagens:

• Anatomia menos confiável.
• Menor compreensão de prompts complexos.
• Resolução e composição atrás de modelos modernos.

Com 4–6 GB de memória GPU, SD1.5 ainda pode valer a pena, principalmente com boas LoRAs já prontas.

SDXL

Também virou um clássico, mas continua útil para RP local. Vantagens:

• Muitos checkpoints.
• Muitas LoRAs.
• Requisitos relativamente moderados.
• Bom equilíbrio velocidade/qualidade.
• Opções para manter personagens reconhecíveis.

Com 8 GB é uma opção acessível, dependendo do workflow e dos outros modelos carregados.

FLUX

FLUX entende melhor prompts em linguagem comum. É mais fácil descrever:

Uma garota junto à janela olha para a câmera por cima do ombro. A mão esquerda toca o vidro, com a cidade ao anoitecer lá fora.

Do que tentar montar:

1girl, window, looking_back, hand_on_window,
night_city, masterpiece, best_quality...

Algumas variantes recentes são mais leves. O guia oficial do ComfyUI para FLUX.2 Klein 4B informa cerca de 8,4 GB de VRAM para a versão destilada na RTX 5090 testada, visando workflows interativos rápidos.

Para RP, rapidez importa mais que uma imagem perfeita em dois minutos.

Qwen Image e modelos orientados por instruções

Outra tendência: modelos entendem melhor frases normais, referências e edição. É mais prático para jogos que os prompts antigos de tags. O LLM pode escrever:

Fiona está sentada de lado em um sofá gasto, olhando irritada para o jogador. Luz quente da cozinha, plano médio, câmera na altura dos olhos.

E enviar ao modelo de imagens. O LLM vira também um pequeno diretor de cena. Assim eu faria a integração hoje.

Consistência do personagem

Aqui começa a dor real do RP com IA. Desenhar uma garota bonita é fácil. Desenhar a mesma garota vinte vezes é mais difícil. Opções:

LoRA de personagem

Um método estabelecido: treinar uma LoRA do personagem e adicioná-la ao workflow. Vantagens:

• Ajuda a manter a identidade.
• Arquivo pequeno.
• Uso rápido.

Desvantagem:

• É preciso treinar uma LoRA por personagem.

Adaptadores de referência

Mais workflows e modelos aceitam uma ou várias imagens de referência. É prático para personagens criados pelos usuários: salve retratos e use-os nas cenas seguintes.

Edição de imagens

Mais interessante ainda: editar um quadro existente em vez de gerar tudo de novo. Exemplo:

Imagem original:
Dina está sentada em um sofá.

Nova cena:
Make her stand up and look toward the door.

A longo prazo, acho que pode ser o caminho mais prático para visual novels com IA. Ajuda a preservar:

• A pessoa.
• A roupa.
• O cômodo.
• A iluminação.

Parte 4. Uma voz local

Houve um grande salto nos últimos dois anos. Antes, TTS local muitas vezes significava:

Tecnicamente, fala humana.

Agora existem modelos adequados para jogos. Eu dividiria em três grupos.

Opção 1: Supertonic 3 — velocidade

Para TTS local muito rápido, Supertonic 3 continua interessante. Usa ONNX e foi pensado para inferência rápida no dispositivo. Supertonic 3 saiu em abril de 2026 com 31 idiomas, leitura mais precisa e menos repetições ou omissões. A principal vantagem:

Latência.

Esperar cinco segundos pelo áudio depois da fala escrita mata a magia. TTS rápido começa a tocar mais cedo.

Atualização importante

O projeto original de código aberto foi arquivado em setembro de 2026. Desenvolvimento e suporte oficiais terminaram. Modelos e arquivos ONNX seguem disponíveis e funcionam localmente, mas não conte com suporte contínuo. Isso não piora o modelo; importa, porém, para um projeto novo.

Opção 2: Kokoro — pequeno e rápido

Kokoro é útil quando importam:

• Tamanho pequeno.
• Inferência na CPU.
• Baixa latência.

Kokoro tem só 82M de parâmetros. Implementações locais funcionam offline após baixar os arquivos. SillyTavern oferece kokoro.js, incluindo WebGPU em navegadores compatíveis. Uma voz simples pode consumir poucos recursos.

Opção 3: Qwen3-TTS — clonagem de voz

Agora fica interessante. Qwen3-TTS saiu em janeiro de 2026 nas versões 0.6B e 1.7B. Os modelos oficiais suportam dez idiomas:

• Chinês.
• Inglês.
• Japonês.
• Coreano.
• Alemão.
• Francês.
• Russo.
• Português.
• Espanhol.
• Italiano.

Conforme a variante, a família oferece:

• Fala em streaming.
• Clonagem de voz.
• Criação de vozes.
• Controle por instruções naturais.

A clonagem é especialmente interessante para RP. O checkpoint oficial 0.6B Base clona a partir de cerca de três segundos de áudio de referência. Cada personagem pode ter uma voz sem treinar um modelo inteiro.

Por que isso importa para RP

O método antigo:

Dina → voz 7
Fiona → voz 11
Laura → voz 3

O moderno:

Dina → reference_dina.wav
Fiona → reference_fiona.wav
Laura → reference_laura.wav

O TTS tenta preservar essa identidade vocal. Uma variante adequada de Qwen3-TTS aceita instruções como:

Speak quietly, slightly irritated,
trying not to show that she is scared.

1.7B CustomVoice e VoiceDesign suportam instruções de estilo; Base usa outro modo para clonagem. Para audiolivros é legal. Para RP é muito legal, porque o LLM já conhece o estado emocional.

Você pode montar:

LLM:
emotion = angry
intensity = 0.65

↓

TTS:
Speak in a restrained but clearly angry voice.

O personagem então faz mais do que simplesmente ler texto.

E o XTTS-v2?

Continua existindo e funcionando. Sua vantagem: a infraestrutura já está pronta. Há servidores API, integração com SillyTavern e muitos guias.

SillyTavern documenta um servidor local XTTSv2 e clonagem com WAV de cerca de dez segundos. Hoje eu olharia primeiro Qwen3-TTS. XTTS combina mais com:

Preciso de um pipeline conhecido e já testado.

Comparação de TTS

As estrelas são minha avaliação aproximada para RP, não um benchmark compartilhado. Velocidade e qualidade dependem do hardware, idioma e integração.

O mais importante: todos disputam uma GPU

O que muitos tutoriais esquecem. Você tem:

LLM
Modelo de imagens
TTS

Os três querem VRAM.

Os dois primeiros se encaram como dois gatos diante da única caixa de papelão.

Exemplo: RTX 3060 de 12 GB

Imagine Saiga Nemo Q5 ocupando aproximadamente:

~9 GB

SDXL/FLUX quer mais alguns gigabytes. Já não cabem juntos confortavelmente. O que fazer?

Opção 1: carregar e descarregar modelos

Faz sentido se a integração administra o carregamento. Dois servidores separados não descarregam modelos automaticamente um para o outro.

Chat:
O LLM está na GPU.

↓

Uma imagem é necessária:
Descarregar parte ou todo o LLM.
Carregar o modelo de imagens.
Gerar a imagem.
Liberar o modelo de imagens.

↓

Carregar o LLM novamente.

Não é ideal para latência, mas permite modelos capazes em uma GPU de consumo.

Opção 2: parte do LLM na RAM

Um compromisso possível:

• 70% das camadas do LLM → GPU.
• O restante → CPU/RAM.
• Parte da VRAM fica livre para ComfyUI.

O texto fica mais lento. As imagens podem evitar recarregar tudo a cada vez.

Opção 3: duas GPUs

Uma segunda placa NVIDIA deixa o conjunto multimodal mais confortável:

GPU 0:
LLM

GPU 1:
ComfyUI

O TTS pode ficar na CPU ou em uma GPU. Isso pode reduzir a espera entre texto e imagem.

Opção 4: imagens sob demanda

Gerar depois de cada frase é desnecessário e pode incomodar. Melhor quando:

• O local muda.
• A roupa muda.
• Aparece outro personagem.
• Acontece uma ação importante.
• O jogador pede uma imagem.

O LLM pode ajudar a detectar esses momentos. Isso reduz bastante a carga.

Quanto hardware é necessário?

Muito aproximadamente. São orientações, não garantia de que tudo caiba ao mesmo tempo na VRAM:

VRAM não é tudo. Também gostaria de:

RAM

16 GB como mínimo inicial. 32 GB são mais confortáveis. 64 GB ajudam com GGUF grandes e execução parcial na CPU.

SSD

Modelos consomem disco como se fosse grátis. Um LLM: 5–20 GB. Modelos de imagens, codificadores de texto e VAE: mais dezenas. LoRAs: outras dezenas conforme a coleção cresce. Saídas do ComfyUI após meses:

De onde vieram esses 180 GB de imagens?

Um espaço dedicado de 500 GB–1 TB some surpreendentemente rápido.

Tudo pode rodar sem internet?

Sim, com uma condição: depois de baixar todos os modelos e arquivos necessários. KoboldCpp roda localmente. ComfyUI com checkpoints locais também. Supertonic/Kokoro/Qwen3-TTS podem ser locais. A interface se comunica por:

localhost
127.0.0.1

Os dados não precisam sair do computador.

Como testar o modo offline

O teste mais simples:

Desconecte a internet.

Sério. É mais direto para testar o offline que ler vinte políticas de privacidade. Se depois:

• O LLM responde.
• ComfyUI gera imagens.
• O TTS fala.

A cadeia principal consegue funcionar localmente. Verifique separadamente as solicitações de rede quando conectado. Baixe antes também os arquivos buscados no primeiro uso.

Exemplo de configuração totalmente local

Um conjunto simples para Windows + NVIDIA:

Interface:
Multiic / SillyTavern

↓

LLM:
KoboldCpp
localhost:5001

Modelo:
Saiga Nemo 12B Q4/Q5
ou Qwen3.5-9B

↓

Imagens:
ComfyUI
localhost:8188

Modelo:
SDXL / FLUX / Qwen Imagem workflow

↓

Voz:
Qwen3-TTS
ou Supertonic/Kokoro

localhost:<porta TTS>

É isso. Por fora parece um personagem de IA. Por dentro trabalham três redes diferentes fingindo ser uma pessoa.

Sinceramente, bem realista.

Como funciona um turno

Você escreve, por exemplo:

Dina, você sabia que ele viria, não sabia?

Passo 1

A interface reúne o prompt:

Sistema
Ficha do personagem
Memória
Cena atual
Diálogo recente
Mensagem do jogador

Passo 2

KoboldCpp → Saiga Nemo:

Dina desvia o olhar.

“Talvez. Que diferença faz agora?”

Passo 3

A interface extrai o estado da cena:

character: Dina
emotion: defensive
location: kitchen
pose: looking away
camera: medium shot

Passo 4

Cria o prompt de imagem:

Dina standing in a dim kitchen at night,
looking away from the viewer,
defensive expression,
arms slightly crossed,
medium shot,
warm practical lighting

Passo 5

ComfyUI gera a imagem.

Passo 6

A integração TTS recebe:

text:
Talvez. Que diferença faz agora?

voice:
Dina

emotion:
restrained, defensive, slightly angry

Ela traduz os campos em controles suportados pelo modelo vocal escolhido.

Passo 7

O áudio começa. Isso já lembra uma pequena visual novel procedural.

Memória do personagem

Outro erro: guardar a vida inteira do personagem diretamente no contexto. Costuma funcionar mal. Melhor separar:

Ficha do personagem

O que muda pouco:

Personalidade
Biografia
Jeito de falar
Relacionamentos

Estado da cena

O que acontece agora:

Local
Roupas
Emoção
Personagens presentes
Horário

Memória de longo prazo

Eventos importantes:

O jogador mentiu para Dina sobre Josephine.
Dina descobriu depois.
A confiança diminuiu.

Mensagens recentes

O contexto dos últimos diálogos. Assim o LLM recebe informação útil sem transformar tudo em uma caçamba de 80k tokens.

Imagens também precisam de memória

Isso importa muito. Se o LLM sabe:

Dina está usando uma jaqueta vermelha hoje.

Mas o prompt de imagem usa só a fala atual:

Dina parece irritada.

Um minuto depois ela tem:

• Outro rosto.
• Um vestido verde.
• Três centímetros extras de decote.
• Talvez uma cauda.

O diretor visual precisa receber estado estruturado, não só a resposta. Exemplo:

{
  "character": "Dina",
  "hair": "curly dark hair",
  "clothes": "oversized red jacket",
  "location": "kitchen",
  "emotion": "annoyed"
}

Isso ajuda a consistência visual.

Separe instruções TTS do diálogo

Não peça ao LLM para escrever:

[voz triste]
Não sei...

E depois mande os colchetes diretamente ao TTS. Obtenha metadados separados:

text: "Não sei."
emotion: sad
energy: low
speed: 0.9

A integração transforma isso em controles de voz compatíveis. Variantes adequadas de Qwen3-TTS aceitam instruções naturais para estilo.

Tudo pelo KoboldCpp?

Curiosamente, bastante coisa é possível. Além de texto GGUF, KoboldCpp oferece:

• Geração de imagens.
• Edição de imagens.
• Whisper.
• TTS.
• Compreensão visual.
• Vários endpoints compatíveis com APIs.

Um sistema minimalista pode usar basicamente um motor. É atraente para iniciantes. Ainda prefiro KoboldCpp para LLM + ComfyUI para imagens + TTS separado.

Por quê? Os componentes evoluem em ritmos diferentes. Se surgir um ótimo modelo de imagens amanhã, quero trocar um workflow, não esperar que um motor monolítico o suporte.

A solução mais simples

Se você está pensando:

Ótimo. Só falta instalar cinco programas e virar administrador de sistemas.

Sim. Faz sentido. Por isso existem projetos que conectam as peças. Multiic reúne:

• GGUF locais.
• KoboldCpp.
• Geração local de imagens.
• Workflows ComfyUI.
• TTS local.
• Memória de personagens.
• Cenas visuais.

Em uma interface. As conexões estão na ajuda do Multiic. Em vez de montar:

SillyTavern
 + KoboldCpp
 + ComfyUI
 + TTS server
 + Seus próprios scripts

Você pode usar um conjunto conectado. Por baixo, a mesma ideia: modelos especializados trabalhando juntos.

O que eu instalaria hoje

PC modesto / 6 GB de VRAM

LLM:
Stheno 8B Q4

Imagens:
SD1.5

Voz:
Kokoro / Supertonic 3

Interface:
Multiic ou SillyTavern

Uma configuração relativamente leve.

8 GB de VRAM

LLM:
Qwen3.5-9B Q4
ou Saiga Nemo Q4 com execução parcial na CPU

Imagens:
SDXL

Voz:
Qwen3-TTS 0.6B / Kokoro

Interface:
Multiic / SillyTavern

Uma configuração útil, na minha opinião, com o planejamento de memória explicado acima.

12 GB de VRAM

Meu equilíbrio favorito:

LLM:
Saiga Nemo 12B Q5/Q6

Imagens:
SDXL / workflow moderno do ComfyUI

Voz:
Qwen3-TTS

Interface:
Multiic

Planeje carregar e descarregar modelos de texto e imagens quando necessário.

16–24 GB

Mais espaço para experimentar:

LLM:
20–30B / modelo MoE

Imagens:
FLUX / Qwen Imagem / workflow moderno de edição

Voz:
Qwen3-TTS 1.7B

Personagem:
Várias referências / LoRA

Contexto:
16–32k+

Os resultados ficam interessantes. As escolhas ainda dependem do consumo combinado de memória.

Quanto custa?

Se você já tem computador:

0 dólares de inferência na nuvem por mensagem.

Depois de baixar os modelos. É uma vantagem importante. Durante horas de RP, o LLM na nuvem processa repetidamente:

Prompt do sistema
Personagem
Memória
Histórico
Cena atual

Esses tokens de entrada podem afetar a conta. Depois vêm imagens e TTS. Localmente, o custo vira aproximadamente:

Eletricidade + hardware + tempo explicando ao CUDA quem manda.

A qualidade é pior que na nuvem?

Às vezes sim.

Um grande modelo de ponta na nuvem costuma superar um pequeno 8B em:

• Raciocínio.
• Instruções complexas.
• Enredos complicados.

Modelos de imagens na nuvem também produzem ótimos resultados com pouco ajuste. O local oferece outras vantagens:

Liberdade

Você pode trocar os componentes.

Privacidade

Com conexões e armazenamento locais, o histórico pode ficar na sua máquina.

Custo

Você não conta cada mensagem em uma fatura de inferência.

Latência

TTS leve pode responder muito rápido.

Personalização

LoRAs, ajustes de modelos, vozes de personagens e workflows próprios.

Reprodutibilidade

O modelo baixado não desaparece porque uma empresa substitui a versão hospedada. Um .gguf não pode passar por rebranding.

E isso é maravilhoso.

Está saindo do Character.AI? Aqui está uma comparação de nove alternativas ao Character.AI, de serviços online a configurações totalmente locais.

Para terminar

Em 2026, dá para montar RP com IA totalmente local: LLM local + personagem persistente + imagens + clonagem de voz em um PC gamer comum, com escolhas adequadas e gerenciamento de recursos.

Sem cluster de servidores, chave de API cloud ou assinatura para inferência local. Um começo:

KoboldCpp
+
8–12B GGUF
+
ComfyUI
+
TTS leve

Depois você pode adicionar:

• LoRA de personagem.
• Imagens de referência.
• Memória.
• Detecção de emoções.
• Clonagem de voz.
• Edição de imagens.
• Vários personagens.
• Estado do mundo.
• Geração local de vídeo.

Uma hora você percebe que queria montar um chatbot e acabou criando um pequeno motor de jogo procedural.

Foi mais ou menos assim que nasceu Multiic.