Cómo integrar modelos locales de Ollama en Word

Recientemente necesité conectar un modelo de lenguaje local servido por Ollama con un complemento para Microsoft Word. El add-in requiere que el backend permita CORS (Cross-Origin Resource Sharing) y, en ciertos entornos webview, una conexión HTTPS o endpoints bien definidos en localhost. Inicialmente consideré envolver la API de Ollama en un servidor Node.js/Express, pero descubrí cómo resolver las políticas de origen y los conflictos de puertos utilizando exclusivamente la configuración nativa de Ollama en Windows.

1. El planteamiento inicial: ¿Proxy intermediario o servidor nativo?

Los complementos de Word funcionan dentro de contenedores WebView2 o navegadores embebidos, lo que implica restricciones estrictas de seguridad de origen. Para realizar peticiones HTTP hacia un modelo local, el servidor de IA debe permitir encabezados CORS específicos. Una primera alternativa era crear un proxy intermedio en Node.js con Express, el paquete cors y certificados autofirmados mediante mkcert:

const express = require('express');
const cors = require('cors');
const app = express();

app.use(cors());

app.post('/api/chat', (req, res) => {
  // Lógica para interactuar con Ollama
});

app.listen(3000, () => {
  console.log('Servidor corriendo en https://localhost:3000');
});

Sin embargo, agregar una capa middleware aumenta la complejidad innecesariamente si el propio binario de Ollama puede gestionar las peticiones de red de forma directa.

2. Explorando las opciones del CLI y el error de Socket

Al revisar el ejecutable de Ollama en la ruta de instalación de Windows (C:\Users\usuario\AppData\Local\Programs\Ollama\ollama.exe), confirmé la presencia del comando serve para iniciar el servicio de API HTTP:

ollama.exe serve

Al intentar ejecutarlo, el sistema devolvió un error de enlace de socket:

Este fallo confirmó que el puerto predeterminado 11434 ya estaba siendo acaparado por otra instancia del sistema.

3. Diagnóstico de procesos y sintaxis de comandos

Mi primera reacción fue intentar cambiar el puerto directamente mediante un argumento por línea de comandos:

ollama.exe serve --host 127.0.0.1:11435

La consola rechazó la instrucción de inmediato: Error: unknown flag: --host. Esto confirmó que la CLI de Ollama no acepta flags de Host directamente en el comando serve.

Para identificar qué proceso estaba bloqueando el puerto predeterminado 11434, utilicé netstat filtrando por el puerto:

netstat -ano | findstr :11434
  TCP    127.0.0.1:11434        0.0.0.0:0              LISTENING       11572

El identificador de proceso (PID) 11572 pertenecía a la aplicación residente de Ollama que se inicia automáticamente con el sistema en segundo plano.

4. La solución: Variables de entorno nativas (OLLAMA_HOST y OLLAMA_ORIGINS)

Al inspeccionar la ayuda extendida (ollama.exe serve -h), identifiqué las variables de entorno que el binario reconoce de forma nativa para controlar su comportamiento:

• OLLAMA_HOST: Dirección IP y puerto donde escuchará el servidor (por defecto 127.0.0.1:11434).
• OLLAMA_ORIGINS: Lista separada por comas con los orígenes permitidos para peticiones CORS.
• OLLAMA_KEEP_ALIVE: Tiempo de permanencia de los modelos en memoria VRAM.
• OLLAMA_MAX_LOADED_MODELS: Número máximo de modelos cargados por GPU.
• OLLAMA_NUM_PARALLEL: Límite de peticiones concurrentes.

Con esta información, es posible resolver la integración sin necesidad de instalar proxies intermedios como Express. Si se desea cambiar el puerto de escucha y permitir orígenes cruzados para el complemento de Word, basta con definir las variables en la sesión antes de iniciar el servicio:

set OLLAMA_HOST=127.0.0.1:11435
set OLLAMA_ORIGINS=*
ollama.exe serve

Alternativamente, si se prefiere mantener el puerto estándar 11434, basta con terminar la instancia en segundo plano que ocupaba el socket mediante taskkill y relanzar el servidor con los orígenes de CORS configurados:

taskkill /PID 11572 /F
set OLLAMA_ORIGINS=*
ollama.exe serve

Una vez iniciado el servidor bajo esta configuración, el complemento de Word puede apuntar directamente a http://127.0.0.1:11434 (o el puerto secundario 11435) y consumir la API local de IA sin bloqueos de red ni rechazos de políticas de origen.