Cómo ejecutar roleplay con IA totalmente en local — LLM, imágenes y voz

En 2026, el roleplay con IA local ya no significa necesariamente:

Abrir la terminal, instalar 48 paquetes de Python, romper CUDA, llorar, reinstalar Windows.

Bueno. A veces todavía significa eso.

Pero hoy puedes montar un sistema que funcione por completo en tu computadora:

El personaje piensa en local → responde en local → genera una imagen de la escena en local → habla con una voz local.

Una vez descargados los modelos, no necesitas internet. Sin API en la nube. Los componentes siguen comunicándose mediante API locales en tu computadora.

Sin cobros por tokens. Sin cuotas de mensajes. Sin enviar tu historial a un servidor ajeno.

Y lo más interesante: las piezas ya pueden ofrecer una experiencia que no se sienta como una demo técnica para quienes disfrutan mirando el consumo de VRAM.

Voy a reunir una configuración práctica de cuatro partes: LLM → interfaz → generación de imágenes → TTS. También veremos qué tiene sentido con 6, 8, 12 y 16+ GB de VRAM.

¿Qué estamos construyendo?

Si primero quieres ver el juego que rodea este stack, el resumen del roleplay con IA en Multiic muestra cómo encajan las tarjetas de personaje, las escenas grupales, la memoria y las imágenes.

Un personaje de IA local, simplificado, se ve así:

                 ┌─────────────────┐
Tu mensaje →   │       LLM       │
                 │ KoboldCpp/GGUF  │
                 └────────┬────────┘
                          │
                  Respuesta del personaje
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
         Interfaz      ComfyUI        TTS
                         Imagen        Voz
             │            │            │
             └────────────┴────────────┘
                          │
                        Escena

Un detalle importante: no es un único modelo gigantesco. Suele ser mejor usar varios modelos especializados.

El LLM se encarga de:

• Diálogo.
• Personalidad.
• Memoria.
• Lógica de la escena.

El modelo de imágenes se encarga de:

• Apariencia del personaje.
• Pose.
• Entorno.
• Iluminación.
• Cámara.

El TTS se encarga de:

• Voz.
• Entonación.
• Emoción.
• Pronunciación.

La interfaz conecta todo. Esa modularidad hace interesante la configuración local. ¿No te gusta la voz? Cambias el TTS. ¿No te gusta el estilo visual? Cambias el checkpoint.

¿Encontraste otro modelo RP en Hugging Face a las tres de la mañana? Cargas un GGUF nuevo.

Diez minutos después, vuelves a convencerte de que descargar un modelo de 9 GB es investigación científica.

Mi configuración recomendada

Si quieres primero la respuesta breve:

No tienes que usar exactamente estos programas. Pero son un buen comienzo.

Parte 1. Un LLM local

Empecemos por el cerebro.

Los modelos en formato GGUF son una opción cómoda para RP local. Con un motor compatible puedes ejecutarlos:

• Totalmente en GPU.
• Parcialmente en GPU.
• Con parte de los pesos en RAM.
• Completamente en CPU, si tienes paciencia de monje.

En Windows, KoboldCpp es una opción sencilla.

KoboldCpp

KoboldCpp pasó de ser un lanzador sencillo de llama.cpp a una herramienta bastante monstruosa. Un ejecutable independiente corre GGUF compatibles en CPU/GPU, con descarga total o parcial al GPU, y expone la generación mediante una API. También admite imágenes, reconocimiento de voz, TTS y varias API compatibles.

En Windows, aproximadamente:

1. Descargar koboldcpp.exe.
2. Descargar un modelo .gguf.
3. Seleccionar el modelo.
4. Elegir el tamaño del contexto.
5. Activar CUDA en un GPU NVIDIA compatible.
6. Iniciar.

Sin instalar Python aparte, sin conda ni sacrificios rituales a requirements.txt. Lo recomiendo a quienes quieren jugar, no conseguir un segundo título en gestión de dependencias.

KoboldCpp ofrece una API compatible con OpenAI en /v1, así que la interfaz no necesita saber que hay un modelo local debajo. Una dirección típica:

http://127.0.0.1:5001

La interfaz envía allí el prompt y recibe texto.

¿Qué LLM elegir?

Tengo una guía específica de modelos locales para roleplay, así que aquí iré al grano.

6 GB de VRAM

Stheno 8B Q4 para RP en inglés. O una cuantización más pequeña de Qwen3.5-9B si te importan más la inteligencia y los idiomas.

8 GB

Qwen3.5-9B Q4 como opción general.

Para ruso: Saiga Nemo 12B Q4_K_M. El archivo pesa unos 7.5 GB por sí solo, así que necesitarás un contexto pequeño o ejecución parcial en CPU.

12 GB

Mi favorito para ruso: Saiga Nemo 12B Q5/Q6.

Para inglés: Rocinante-X / Impish Bloodmoon / otros buenos ajustes RP de Nemo.

16 GB o más

Puedes considerar modelos 20–30B y MoE: Gemory 26B-A4B, Gemma 4 y Qwen más grandes.

La cuantización y el tamaño total de los pesos siguen importando. En un MoE, los parámetros activos no indican cuánta memoria necesitan todos los pesos.

¿Cuánto contexto usar?

No pongas automáticamente el máximo de la página del modelo. Que admita 128k no significa:

Excelente, voy a poner 128000.

El contexto consume memoria mediante la caché KV. Para RP normal empezaría con:

8192–16384

Y aumentaría solo cuando hiciera falta. Un contexto útil de 16k suele aportar más que 128k que mandan medio modelo a RAM y lo hacen responder al ritmo de una tortuga pensativa.

Usar CPU no es una derrota

Existe esta idea extraña:

El modelo entero debe caber en el GPU.

No necesariamente. KoboldCpp permite dejar capas en RAM y calcularlas en CPU. Será más lento, pero RP no exige 100 tokens/s.

8–20 tokens/s pueden ser cómodos, especialmente con streaming. El texto aparece mientras se genera el resto. Para iniciar la voz de la misma manera, hace falta soporte separado de TTS en streaming.

Parte 2. La interfaz

Un LLM por sí solo no administra:

• Fichas de personajes.
• Relaciones.
• Memoria persistente.
• Apariencia.
• Imágenes.
• Voces.
• Mundo.

Eso suele hacerlo la interfaz. Dos opciones:

• SillyTavern: para armar tú mismo la configuración.
• Multiic: para unir texto, imágenes, personajes, voz y sandbox en un sistema.

SillyTavern

SillyTavern se ha convertido en una interfaz de referencia para chats locales con personajes. Admite:

• Fichas de personajes.
• Chats grupales.
• Lorebooks.
• Personas.
• Funciones de memoria.
• TTS.
• Generación de imágenes.
• Conexión con KoboldCpp.
• Conexiones API.

Su documentación describe KoboldCpp como una API independiente para GGML/GGUF e incluye un inicio rápido para NVIDIA. Si tu objetivo es:

Quiero hablar con un personaje y armar toda la configuración por mi cuenta.

Es una buena opción.

Multiic

Multiic toma otro rumbo: LLM + imágenes + voz + personajes + estado de la escena + sandbox. El LLM responde dentro de una escena visual.

Puedes usar:

• GGUF locales.
• API externas.
• Un motor de imágenes local.
• ComfyUI.
• TTS local.

La ventaja se nota cuando trabajan varias modalidades juntas. Por ejemplo:

Jugador:
Voy a la ventana y le pregunto a Dina qué vio.

↓

LLM:
Genera la reacción de Dina.

↓

Director de escena:
Define posición, expresión y cámara.

↓

ComfyUI:
Genera la escena.

↓

TTS:
Pronuncia la réplica.

Aquí el RP empieza a sentirse como una novela visual interminable más que como un chatbot.

Parte 3. Generación local de imágenes

La siguiente capa son las imágenes. Para adaptar la generación a personajes y escenas, elegiría ComfyUI. No porque su interfaz sea especialmente amigable.

Parece el diagrama eléctrico de un reactor nuclear conectado por accidente a un generador de chicas de anime.

Pero es muy flexible. Esa flexibilidad hay que aprenderla: entender nodos, elegir modelos compatibles y montar o configurar un workflow. Lleva tiempo.

Si quieres empezar rápido y generar imágenes directamente en el juego, KoboldCpp es más sencillo. Genera imágenes y ya está integrado en Multiic. No necesitas aprender ComfyUI ni construir un grafo de nodos para comenzar. Sí debes descargar y seleccionar un modelo de imágenes compatible.

Empezaría con KoboldCpp y pasaría a ComfyUI cuando quisiera más control: LoRA propias, referencias de personajes, poses y flujos más elaborados.

¿Por qué ComfyUI?

En lugar de una cadena fija:

Prompt → image

Construyes un flujo:

Prompt
  ↓
Referencia del personaje
  ↓
Pose
  ↓
Checkpoint
  ↓
LoRA
  ↓
ControlNet
  ↓
Muestreador
  ↓
Retoque facial
  ↓
Ampliación
  ↓
Imagen

La interfaz puede enviarle datos automáticamente. Lo construyes una vez y el juego cambia:

• Prompt.
• Personaje.
• Seed.
• Referencia.
• Pose.
• Ropa.
• Entorno.

¿Qué modelo de imágenes usar?

Aquí todo cambia incluso más rápido que con los LLM. En 2026 podemos distinguir varios grupos.

El buen SD1.5 de siempre

Ventajas:

• Ligero.
• Enorme ecosistema de LoRA.
• Entrenamiento de personajes relativamente accesible.
• Generación rápida.
• Funciona en GPU modestos.

Desventajas:

• Anatomía menos fiable.
• Menor comprensión de prompts complejos.
• Resolución y composición por detrás de modelos modernos.

Con 4–6 GB de memoria GPU sigue teniendo sentido, sobre todo si ya tienes buenas LoRA de personajes.

SDXL

También es un clásico, pero sigue siendo práctico para RP local. Ventajas:

• Muchos checkpoints.
• Muchas LoRA.
• Requisitos relativamente moderados.
• Buen equilibrio velocidad/calidad.
• Opciones para mantener personajes reconocibles.

Con 8 GB es accesible, según el flujo y los demás modelos cargados.

FLUX

FLUX entiende mejor el lenguaje normal. Es más fácil describir:

Una chica junto a la ventana mira a la cámara por encima del hombro. Su mano izquierda toca el vidrio, y afuera se ve la ciudad al anochecer.

Que intentar escribir:

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

Algunas variantes recientes son más ligeras. La guía oficial de ComfyUI para FLUX.2 Klein 4B informa de unos 8.4 GB de VRAM para la versión destilada en su RTX 5090 de prueba y apunta a flujos interactivos rápidos.

Para RP es interesante: la rapidez importa más que una imagen perfecta en dos minutos.

Qwen Image y modelos guiados por instrucciones

Otra tendencia: los modelos entienden mejor frases normales, referencias y edición. Para juegos es más práctico que los viejos prompts con etiquetas. El LLM puede escribir:

Fiona está sentada de lado en un sofá desgastado, mirando al jugador con fastidio. Luz cálida desde la cocina, plano medio, cámara a la altura de los ojos.

Y enviarlo al modelo de imágenes. El LLM se convierte también en un pequeño director de escena. Así construiría la integración hoy.

Consistencia del personaje

Aquí empieza el verdadero dolor del RP con IA. Dibujar una chica bonita es fácil. Dibujar a la misma chica veinte veces es más difícil. Opciones:

LoRA de personaje

Método establecido: entrenar una LoRA del personaje y añadirla al flujo. Ventajas:

• Ayuda a conservar la identidad.
• Archivo pequeño.
• Uso rápido.

Desventaja:

• Hay que entrenar una LoRA para cada personaje.

Adaptadores de referencia

Más flujos y modelos aceptan una o varias referencias. Útil para personajes creados por usuarios: guardas retratos y los reutilizas al generar escenas nuevas.

Edición de imágenes

Más interesante aún: editar un fotograma existente en vez de regenerarlo todo. Ejemplo:

Imagen original:
Dina está sentada en un sofá.

Nueva escena:
Make her stand up and look toward the door.

A largo plazo creo que puede ser la forma más cómoda para novelas visuales con IA. Ayuda a conservar:

• La persona.
• La ropa.
• La habitación.
• La iluminación.

Parte 4. Una voz local

Aquí hubo un salto grande en dos años. Antes, TTS local solía significar:

Técnicamente, habla humana.

Ahora hay modelos adecuados para juegos. Los dividiría en tres grupos.

Opción 1: Supertonic 3 — velocidad

Para TTS local muy rápido, Supertonic 3 sigue siendo interesante. Usa ONNX y se diseñó para inferencia rápida en el dispositivo. Supertonic 3 salió en abril de 2026 con 31 idiomas, lectura más precisa y menos repeticiones u omisiones. Su principal ventaja:

Latencia.

Esperar cinco segundos por el audio después de una respuesta mata la magia. Un TTS rápido empieza a reproducir antes.

Actualización importante

El proyecto original de código abierto fue archivado en septiembre de 2026. El desarrollo y soporte oficiales terminaron. Los modelos y archivos ONNX siguen disponibles y funcionan localmente, pero no debes contar con soporte continuo. No empeora el modelo; sí importa para proyectos nuevos.

Opción 2: Kokoro — pequeño y rápido

Kokoro es útil si buscas:

• Tamaño reducido.
• Inferencia CPU.
• Baja latencia.

Kokoro tiene solo 82M parámetros. Hay implementaciones locales que funcionan sin conexión tras descargar los archivos. SillyTavern lo admite mediante kokoro.js, con WebGPU en navegadores compatibles. Una voz sencilla consume pocos recursos.

Opción 3: Qwen3-TTS — clonación de voz

Esto se pone interesante. Qwen3-TTS salió en enero de 2026 en versiones 0.6B y 1.7B. Los modelos oficiales admiten diez idiomas:

• Chino.
• Inglés.
• Japonés.
• Coreano.
• Alemán.
• Francés.
• Ruso.
• Portugués.
• Español.
• Italiano.

Según la variante, la familia ofrece:

• Voz en streaming.
• Clonación de voz.
• Diseño de voces.
• Control mediante instrucciones naturales.

Para RP, la clonación es lo más interesante. El checkpoint oficial 0.6B Base permite clonar con unos tres segundos de audio de referencia. Cada personaje puede tener una voz sin entrenar todo un modelo.

Por qué importa para RP

El método anterior:

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

El moderno:

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

El TTS intenta conservar esa identidad. Con la variante adecuada de Qwen3-TTS puedes dar instrucciones como:

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

1.7B CustomVoice y VoiceDesign admiten control de estilo mediante instrucciones; Base usa otro modo de clonación. Para audiolibros está bien. Para RP está muy bien: el LLM ya conoce el estado emocional.

Puedes construir:

LLM:
emotion = angry
intensity = 0.65

↓

TTS:
Speak in a restrained but clearly angry voice.

Y el personaje hace más que leer texto.

¿Y XTTS-v2?

Sigue existiendo y funcionando. Su ventaja: la infraestructura ya está montada. Hay servidores API, integración con SillyTavern y muchos tutoriales.

SillyTavern documenta un servidor local XTTSv2 y clonación con WAV de unos diez segundos. Hoy miraría primero Qwen3-TTS. XTTS encaja más con:

Necesito un flujo probado que ya conozco.

Comparación de TTS

Las estrellas son mi valoración aproximada para RP, no un benchmark común. Velocidad y calidad dependen del hardware, el idioma y la integración.

Lo importante: todos compiten por un GPU

Lo que muchos tutoriales olvidan. Tienes:

LLM
Modelo de imágenes
TTS

Los tres quieren VRAM.

Los dos primeros se miran como dos gatos ante la única caja de cartón.

Ejemplo: RTX 3060 de 12 GB

Imagina Saiga Nemo Q5 ocupando aproximadamente:

~9 GB

SDXL/FLUX quiere varios gigabytes más. Ya no caben cómodamente juntos. ¿Qué hacer?

Opción 1: cargar y descargar modelos dinámicamente

Tiene sentido si la integración administra la carga. Dos servidores independientes no descargan modelos automáticamente uno por el otro.

Chat:
El LLM está en el GPU.

↓

Hace falta una imagen:
Descargar parte o todo el LLM.
Cargar el modelo de imágenes.
Generar la imagen.
Liberar el modelo de imágenes.

↓

Volver a cargar el LLM.

No es ideal para latencia, pero permite modelos capaces en una tarjeta de consumo.

Opción 2: parte del LLM en RAM

Un compromiso posible:

• 70% de las capas del LLM → GPU.
• El resto → CPU/RAM.
• Parte de la VRAM queda para ComfyUI.

El texto se vuelve más lento, pero las imágenes quizá no exijan recargar todo cada vez.

Opción 3: dos GPU

Con una segunda tarjeta NVIDIA, la configuración multimodal es más cómoda:

GPU 0:
LLM

GPU 1:
ComfyUI

El TTS puede quedarse en CPU o usar un GPU. Puede reducir la espera entre texto e imagen.

Opción 4: imágenes bajo demanda

No hace falta generar tras cada frase; puede molestar. Mejor cuando:

• Cambia el lugar.
• Cambia la ropa.
• Aparece otro personaje.
• Ocurre una acción importante.
• El jugador pide una imagen.

El LLM puede ayudar a detectar esos momentos. La carga baja bastante.

¿Cuánto hardware necesitas realmente?

De forma muy aproximada. Son orientaciones, no garantías de que todo quepa simultáneamente en VRAM:

La VRAM no lo es todo. También querría:

RAM

16 GB como mínimo inicial. 32 GB es más cómodo. 64 GB ayuda con GGUF grandes y ejecución parcial en CPU.

SSD

Los modelos consumen disco como si fuera gratis. Un LLM: 5–20 GB. Modelos de imágenes, codificadores de texto y VAE: decenas más. LoRA: otras decenas al crecer la colección. Salidas de ComfyUI después de meses:

¿De dónde salieron estos 180 GB de imágenes?

Unos 500 GB–1 TB dedicados a modelos desaparecen sorprendentemente rápido.

¿Todo puede funcionar sin internet?

Sí, con una condición: haber descargado todos los modelos y archivos necesarios. KoboldCpp funciona localmente. ComfyUI con checkpoints locales también. Supertonic/Kokoro/Qwen3-TTS pueden ser locales. La interfaz puede conectarse por:

localhost
127.0.0.1

Los datos no tienen por qué salir de tu computadora.

Cómo comprobar el modo sin conexión

La prueba más sencilla:

Desconecta internet.

En serio. Es más directo para probar el modo offline que leer veinte políticas de privacidad. Si después:

• El LLM responde.
• ComfyUI genera imágenes.
• El TTS habla.

La cadena principal puede funcionar localmente. Comprueba por separado las solicitudes de red cuando tengas conexión. Descarga antes los archivos que las aplicaciones buscan en el primer uso.

Ejemplo de configuración totalmente local

Una configuración simple para Windows + NVIDIA:

Interfaz:
Multiic / SillyTavern

↓

LLM:
KoboldCpp
localhost:5001

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

↓

Imágenes:
ComfyUI
localhost:8188

Modelo:
SDXL / FLUX / Qwen Imagen workflow

↓

Voz:
Qwen3-TTS
o Supertonic/Kokoro

localhost:<puerto TTS>

Eso es todo. Por fuera parece un personaje. Por dentro trabajan tres redes completamente diferentes fingiendo ser una persona.

La verdad, bastante realista.

Cómo se ve un turno

Por ejemplo, escribes:

Dina, sabías que iba a venir, ¿no?

Paso 1

La interfaz reúne el prompt:

Sistema
Ficha de personaje
Memoria
Escena actual
Diálogo reciente
Mensaje del jugador

Paso 2

KoboldCpp → Saiga Nemo:

Dina aparta la mirada.

«Quizá. ¿Qué diferencia hace ahora?»

Paso 3

La interfaz extrae el estado de la escena:

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

Paso 4

Construye el prompt de imagen:

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

Paso 5

ComfyUI genera la imagen.

Paso 6

La integración TTS recibe:

text:
Quizá. ¿Qué diferencia hace ahora?

voice:
Dina

emotion:
restrained, defensive, slightly angry

Traduce esos campos a controles admitidos por el modelo vocal elegido.

Paso 7

Empieza el audio. Ya se parece a una pequeña novela visual procedural.

Memoria del personaje

Otro error: guardar toda la vida del personaje directamente en el contexto. Suele funcionar mal. Mejor separar:

Ficha de personaje

Lo que cambia poco:

Personalidad
Biografía
Forma de hablar
Relaciones

Estado de la escena

Lo que ocurre ahora:

Lugar
Ropa
Emoción
Personajes presentes
Hora

Memoria a largo plazo

Eventos importantes:

El jugador le mintió a Dina sobre Josephine.
Dina lo descubrió después.
La confianza disminuyó.

Mensajes recientes

El contexto de los últimos intercambios. Así el LLM recibe información útil sin convertirlo en un contenedor de basura de 80k tokens.

Las imágenes también necesitan memoria

Es importante. Si el LLM sabe:

Hoy Dina lleva una chaqueta roja.

Pero el prompt de imagen solo usa la réplica actual:

Dina parece enojada.

Un minuto después tiene:

• Otra cara.
• Un vestido verde.
• Tres centímetros extra de escote.
• Quizá una cola.

El director visual necesita estado estructurado, no solo la respuesta. Por ejemplo:

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

Eso mejora la consistencia visual.

Separa las instrucciones TTS del diálogo

No pidas al LLM escribir:

[voz triste]
No lo sé...

Y luego le des los corchetes al TTS. Mejor obtener metadatos por separado:

text: "No lo sé."
emotion: sad
energy: low
speed: 0.9

La integración los convierte a controles vocales compatibles. Las variantes adecuadas de Qwen3-TTS aceptan instrucciones naturales de estilo.

¿Todo mediante KoboldCpp?

Curiosamente, permite bastante. Además del texto GGUF, admite:

• Generación de imágenes.
• Edición de imágenes.
• Whisper.
• TTS.
• Comprensión visual.
• Varios endpoints compatibles API.

Puedes montar algo minimalista alrededor de un solo motor. Atractivo para principiantes. Aun así, prefiero KoboldCpp para LLM + ComfyUI para imágenes + TTS separado.

¿Por qué? Los componentes evolucionan a ritmos distintos. Si mañana aparece un modelo de imágenes excelente, quiero sustituir un flujo, no esperar a que un motor monolítico lo admita.

La solución más sencilla

Si estás pensando:

Genial. Solo falta instalar cinco programas y obtener el título de administrador de sistemas.

Sí. Se entiende. Por eso hay proyectos que conectan las piezas. Multiic reúne:

• GGUF locales.
• KoboldCpp.
• Generación local de imágenes.
• Flujos ComfyUI.
• TTS local.
• Memoria del personaje.
• Escenas visuales.

En una interfaz. Las conexiones están en la ayuda de Multiic. En vez de montar:

SillyTavern
 + KoboldCpp
 + ComfyUI
 + TTS server
 + Tus propios scripts

Puedes usar un sistema conectado. Debajo sigue la misma idea: modelos especializados trabajando juntos.

Qué instalaría hoy

PC modesto / 6 GB de VRAM

LLM:
Stheno 8B Q4

Imágenes:
SD1.5

Voz:
Kokoro / Supertonic 3

Interfaz:
Multiic o SillyTavern

Una configuración relativamente ligera.

8 GB de VRAM

LLM:
Qwen3.5-9B Q4
o Saiga Nemo Q4 con ejecución parcial en CPU

Imágenes:
SDXL

Voz:
Qwen3-TTS 0.6B / Kokoro

Interfaz:
Multiic / SillyTavern

Una configuración útil en mi opinión, con la planificación de memoria mencionada.

12 GB de VRAM

Mi equilibrio favorito:

LLM:
Saiga Nemo 12B Q5/Q6

Imágenes:
SDXL / flujo moderno de ComfyUI

Voz:
Qwen3-TTS

Interfaz:
Multiic

Planifica cargar y descargar los modelos de texto e imagen cuando haga falta.

16–24 GB

Más espacio para experimentar:

LLM:
20–30B / modelo MoE

Imágenes:
FLUX / Qwen Imagen / flujo moderno de edición

Voz:
Qwen3-TTS 1.7B

Personaje:
Varias referencias / LoRA

Contexto:
16–32k+

Los resultados se ponen interesantes. La selección exacta depende del consumo combinado de memoria.

¿Cuánto cuesta?

Si ya tienes computadora:

0 dólares en inferencia cloud por mensaje.

Después de descargar los modelos. Es una ventaja clave. En horas de RP, un LLM cloud procesa repetidamente:

Prompt del sistema
Personaje
Memoria
Historial
Escena actual

Esos tokens de entrada pueden influir en el cobro. Después vienen imágenes y TTS. En local, el costo es aproximadamente:

Electricidad + hardware + tiempo explicándole a CUDA quién manda.

¿La calidad es peor que en la nube?

A veces sí.

Un gran modelo cloud de última generación suele superar a un 8B pequeño en:

• Razonamiento.
• Instrucciones complejas.
• Tramas complicadas.

Los modelos cloud de imágenes también pueden dar resultados excelentes sin ajustes. Lo local ofrece otras ventajas:

Libertad

Puedes cambiar los componentes.

Privacidad

Con almacenamiento y conexiones locales, el historial puede quedarse en tu máquina.

Costo

No cuentas cada mensaje en una factura de inferencia.

Latencia

Un TTS ligero puede responder muy rápido.

Personalización

LoRA, ajustes de modelos, voces propias y flujos personalizados.

Reproducibilidad

El modelo descargado no desaparece porque una compañía cambie su versión hospedada. Un .gguf no puede cambiar de marca.

Y eso es maravilloso.

¿Te vas de Character.AI? Aquí tienes una comparación de nueve alternativas a Character.AI, desde servicios en línea hasta configuraciones totalmente locales.

Para terminar

En 2026 puedes construir RP con IA totalmente local: LLM local + personaje persistente + imágenes + clonación vocal en una computadora gaming normal, con modelos adecuados y gestión de recursos.

No hace falta un clúster, una clave API cloud ni una suscripción para la inferencia local. Un punto de partida:

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

Después puedes agregar:

• LoRA de personaje.
• Referencias visuales.
• Memoria.
• Detección de emociones.
• Clonación de voz.
• Edición de imágenes.
• Varios personajes.
• Estado del mundo.
• Generación local de video.

En algún momento notas que estabas armando un chatbot y terminaste construyendo un pequeño motor de juego procedural.

Más o menos así nació Multiic.