Un modelo de 8000 millones de parámetros, cuantizado, ocupa unos 4,7 GB de disco y arranca en el mismo servidor donde vive tu WordPress. Con eso basta para montar un buscador semántico o un asistente que responda sobre tu contenido sin enviar ninguna consulta a un servicio externo. Montar IA local en WordPress se ha reducido a tres piezas: Ollama sirve los modelos, Qdrant guarda los vectores y un plugin o un script propio cierra el circuito. El orden de montaje sigue esa secuencia: Ollama, después Qdrant, y al final el puente con WordPress.
Por qué autoalojar la IA de tu sitio
Cada llamada a una API comercial saca del servidor los textos que procesas: entradas, comentarios o preguntas de los usuarios. Con un stack self-hosted, esos datos y sus vectores se quedan en tu infraestructura, lo que convierte la IA local en WordPress en una opción seria para intranets, documentación interna o proyectos con requisitos de privacidad. El coste también cambia de naturaleza: pagas en RAM, VRAM y electricidad en lugar de tokens.
Qué datos cruzan la frontera con una API comercial
Cada llamada saca del servidor los textos que procesas: entradas, comentarios, preguntas. Con stack self-hosted esos datos no abandonan la máquina, y el criterio de privacidad deja de depender de condiciones de servicio.
Antes de escribir código, haz la lista de datos que tocaría enviar a un tercero en cada petición. Esa lista decide si el proyecto merece la pena.
Ollama, el servidor de modelos que se instala en un minuto
Ollama se distribuye como aplicación única para Linux, macOS y Windows, y también está disponible como imagen oficial de Docker. Con ollama pull llama3.1:8b descargas un modelo cuantizado de unos 4,7 GB; en su librería hay alternativas como gemma3 o qwen3 en varios tamaños. El servicio expone una API REST en el puerto 11434 con endpoints compatibles con OpenAI, de modo que cualquier herramienta que hable con la API de OpenAI puede apuntar a tu máquina sin cambios de código. Esa misma compatibilidad es la que aprovechan, por ejemplo, los bots de Telegram con modelos locales.
Instalación y primer modelo
Un curl de instalación en Linux, una imagen de Docker si lo prefieres aislado, y un ollama pull llama3.1:8b para tener el primer modelo sirviendo en el puerto 11434.
Próximo paso: instala Ollama, descarga un modelo y lanza un curl contra http://localhost:11434 para confirmar que responde.
Qdrant, el almacén de vectores del stack
Un LLM no sabe nada de tu contenido hasta que se lo entregas en el contexto, y la vía habitual es RAG: trocear las entradas, calcular sus embeddings y almacenarlos en una base vectorial. Ese almacén puede ser Qdrant: escrita en Rust, publicada bajo licencia Apache 2.0, con API REST en el puerto 6333 y filtrado por payload para acotar búsquedas por categoría, autor o fecha. También admite vectores dispersos y cuantización, dos opciones útiles cuando la colección crece y el consumo de RAM empieza a preocupar. En el payload conviene guardar el post_id y la URL para poder vincular cada resultado con su entrada original.
RAG: trocear, embeber, almacenar
El flujo RAG parte de trocear las entradas, calcular sus embeddings con nomic-embed-text y almacenarlos en una colección de Qdrant con el payload que necesites filtrar después.
Despliégala con docker run -p 6333:6333 qdrant/qdrant y crea una colección de prueba con un par de vectores.
Plugins y código: el puente con WordPress
Para la capa conversacional, plugins como AI Engine permiten conectar Ollama como proveedor y montar el chat sin escribir código. Si prefieres una interfaz completa fuera del CMS, Open WebUI monta un chat de IA privado sobre Ollama en un contenedor propio. Lo que casi ningún plugin cubre es la sincronización con Qdrant: trocear el contenido, generar los embeddings con un modelo como nomic-embed-text (unos 274 MB en la librería de Ollama) y hacer el upsert en la colección. Para un prototipo basta un script PHP enganchado a wp_insert_post y a WP-Cron, con wp_remote_post como cliente HTTP hacia ambos servicios.
AI Engine para el chat, código propio para el pipeline
AI Engine conecta Ollama como proveedor para el chat sin código; el pipeline de embeddings merece un script propio que controle troceo y actualización.
La fragmentación y la elección del modelo de embeddings concentran buena parte de los fallos en estos montajes; antes de indexar nada, repasa los tres errores comunes al montar RAG en WordPress. Después, indexa diez entradas a mano y comprueba que las búsquedas devuelven lo esperado.
Requisitos reales y límites
Un modelo 8B cuantizado funciona en CPU con unos 8 GB de RAM, suficiente para búsquedas o asistentes internos con tráfico moderado; con una GPU el rendimiento sube de forma notable. Ollama gestiona el paralelismo mediante variables de configuración como OLLAMA_NUM_PARALLEL, pero un único servidor puede quedarse corto con muchos usuarios simultáneos. Tampoco conviene sobrevender la calidad: un 8B se equivoca más que los modelos grandes de pago, y si el asistente es público hay que revisar sus respuestas o acotar su ámbito. Mide tokens por segundo con tu hardware antes de comprometer tiempos con un cliente.
8 GB de RAM en CPU, GPU opcional
Un modelo 8B cuantizado funciona en CPU con unos 8 GB de RAM para búsquedas y asistentes con tráfico moderado; la GPU acelera la inferencia conversacional, no la búsqueda vectorial.
Conclusión: el orden que ahorra semanas
Si quieres probar la IA local en WordPress, sigue esta secuencia: instala Ollama y un modelo 8B; levanta Qdrant en Docker; escribe un script que embeba veinte entradas en una colección; y monta un endpoint de búsqueda que consulte Qdrant y pase los fragmentos recuperados al modelo como contexto. Con ese núcleo funcionando, el resto (chat flotante, resúmenes, clasificación) son variaciones sobre lo mismo. La barrera real ya no está en el hardware ni en las licencias, sino en el diseño del pipeline: qué trocear, cómo embeber y cuándo reindexar. Empieza por la búsqueda semántica, porque es el caso de uso donde los fallos se ven claros y las mejoras se pueden medir.