Cómo servir un modelo de lenguaje grande desde tu workstation local

Montar un modelo de lenguaje grande en una workstation local ya no es un capricho de frikis de la IA: es algo perfectamente viable si tienes un buen equipo, algo de paciencia y claro qué quieres conseguir. Desde un portátil potente hasta una torre con una GPU seria o, como en tu caso, una máquina con AMD Ryzen AI MAX+ y una iGPU con un buen taco de VRAM compartida, puedes crear tu propio “ChatGPT privado” accesible desde otros dispositivos de tu red.

El reto no está solo en instalar herramientas como Ollama, LM Studio o GPT4All, sino en entender cómo sacar partido al hardware (CPU, GPU e iGPU), cómo exponer un servidor de IA remoto al que conectarte desde el móvil o el portátil, y cómo elegir el modelo y la cuantización adecuados para no matar tu máquina a la primera pregunta. Vamos a ver todo esto con calma, pero en plan práctico y sin perder los detalles técnicos importantes.

Qué implica servir un LLM desde tu workstation local

Cuando hablamos de “servir un modelo de lenguaje grande desde una workstation local” no es solo abrir un chat y ya está, sino levantar un servicio accesible por HTTP (normalmente con una API tipo OpenAI) que pueda usarse desde otros dispositivos: scripts en Python, aplicaciones web, móviles o incluso herramientas low-code. Tu máquina actúa como un mini-servidor de inferencia dentro de tu red doméstica o de oficina.

Esto tiene varias implicaciones: por un lado, necesitas que el modelo se ejecute con fluidez en tu hardware (ya sea CPU, GPU dedicada o iGPU) y, por otro, que el servicio escuche en una IP accesible para otros equipos (no solo en 127.0.0.1). Herramientas como Ollama y LM Studio facilitan mucho este proceso, ya que exponen un servidor local compatible con el API de OpenAI o con endpoints HTTP sencillos que puedes consumir desde cualquier lenguaje de programación moderno.

En equipos como una Framework Desktop con Ryzen AI MAX+ y Pop!_OS (u otra distro Linux), el objetivo suele ser exprimir los 98 GB de VRAM compartida asignados a la iGPU para acelerar los LLM, en lugar de depender únicamente de la CPU. Ahí entran en juego los drivers, ROCm (en el caso de AMD) y las opciones de aceleración GPU de cada herramienta.

Además del aspecto técnico, hay una parte estratégica: un LLM local te da más control sobre los costes, la privacidad y la latencia. No pagas por token, no dependes de la conexión a Internet, y los datos sensibles no salen de tu red. Eso sí, tú te comes la parte de mantenimiento, actualizaciones y control de seguridad del sistema.

Requisitos de hardware y sistema para LLMs locales

Antes de pegarte con instalaciones, conviene revisar qué hardware necesitas para servir un LLM desde tu workstation local con cierta dignidad. No hace falta tener un monstruo de datacenter, pero sí entender dónde están los cuellos de botella: RAM, VRAM, CPU y disco.

Para ejecutar modelos de lenguaje grandes, la memoria RAM suele ser el recurso crítico. Los modelos se cargan en memoria (RAM y/o VRAM), así que si te quedas corto verás errores de “Out of Memory” o directamente cuelgues. Con 8 GB de RAM puedes probar modelos muy pequeños (1B, 3B, 7B cuantizados), aunque notarás falta de fluidez. Con 16 GB ya puedes moverte con soltura con modelos de 7B y 13B bien cuantizados. A partir de 32 GB o más, empiezas a jugar seriamente con modelos grandes (30B, 40B, 70B) sin demasiados dramas.

En cuanto a CPU, los procesadores modernos de escritorio aguantan bastante bien la inferencia en local, sobre todo con modelos cuantizados. Lo ideal es contar con al menos 4 núcleos físicos y, si puedes, 8 o más cores para que la generación de texto sea razonablemente rápida, especialmente si vas a atender varias peticiones concurrentes desde diferentes dispositivos en tu red.

La GPU (o iGPU) marca la diferencia en rendimiento cuando quieres respuestas fluidas y tokens por segundo decentes. Una GPU dedicada con al menos 8 GB de VRAM (por ejemplo, una RTX 3060 o similar) ya permite mover modelos medianos con soltura. En tu caso, con un Ryzen AI MAX+ y una iGPU con 98 GB de VRAM compartida, el truco está en que el stack de IA (Ollama, llama.cpp, ROCm, etc.) consiga detectar y aprovechar esa iGPU. A veces hay que tocar variables de entorno como HIP_VISIBLE_DEVICES o ROCR_VISIBLE_DEVICES, revisar drivers y comprobar en los logs si la GPU está siendo usada o no.

El almacenamiento también importa: los ficheros de modelo ocupan desde un par de GB hasta cientos. Un modelo pequeño cuantizado puede ser de unos 2 GB, uno mediano de unos 5 GB, y modelos grandes de 40 GB o más. Existen incluso LLMs que superan el terabyte. Lo sensato es reservar entre 20 y 100 GB de espacio libre si planeas probar varios modelos sin andar borrando continuamente.

Por último, el sistema operativo. Tanto Windows 10/11 como Linux y macOS pueden ejecutar LLMs locales. Para entornos como el tuyo, con Pop!_OS y hardware AMD, suele ser más práctico quedarse en Linux para aprovechar mejor ROCm y las integraciones de GPU con Ollama o llama.cpp. Si una distro te da demasiada guerra con drivers, a veces merece la pena cambiar a otra más “amigable” con tu hardware (Ubuntu, Fedora, etc.).

Conceptos básicos: LLMs, Transformers y cuantización

Para no ir a ciegas, ayuda entender mínimamente qué hay detrás de los modelos de lenguaje grandes. Un LLM es una red neuronal entrenada de forma auto-supervisada sobre cantidades ingentes de texto para predecir la siguiente palabra de una secuencia, y a partir de ahí generar respuestas, traducir, resumir o programar.

La mayoría de LLMs modernos usan la arquitectura Transformer, que trabaja convirtiendo palabras en vectores numéricos (embeddings). Esos vectores se procesan a través de capas de atención y feed-forward, aprendiendo patrones estadísticos del lenguaje: básicamente, qué palabras tienden a aparecer juntas y en qué contextos. El modelo, en cada paso, estima la probabilidad de la siguiente palabra dada la secuencia anterior y otros parámetros configurables.

El Transformer se suele dividir en dos bloques conceptuales: un encoder, que se encarga de “entender” el texto de entrada y generar una representación contextual, y un decoder, que toma esa representación y va generando tokens de salida uno a uno. En los grandes modelos de chat actuales se suelen usar arquitecturas decoder-only, pero la idea de fondo es la misma: se procesa la secuencia y se generan tokens hasta completar la respuesta.

Durante la generación, entrar en juego parámetros como la temperatura, el top-k, el top-p, etc., que influyen en cuánto “arriesga” el modelo a la hora de elegir palabras menos probables. Cambiar estos ajustes puede hacer que la IA responda de forma más creativa o más conservadora, algo clave si vas a montar un servicio remoto para otros usuarios o aplicaciones.

Un concepto vital para poder servir LLMs en una workstation es la cuantización. En vez de almacenar los pesos de la red en coma flotante de 16 o 32 bits, se convierten a enteros de 8, 4 o incluso 2 bits. Esto reduce muchísimo el tamaño del fichero del modelo y la memoria necesaria para ejecutarlo, a costa de una ligera pérdida de precisión en las respuestas.

En la práctica, pasar un modelo de 32 bits a un formato como Q4_K_M o similares puede hacer que un modelo de 40 GB baje a la mitad o menos de tamaño. Las métricas como la perplexity ayudan a medir el impacto: un valor más bajo implica mejor calidad, y se observa cómo sube un poco al aplicar cuantización, pero muchas veces el usuario apenas nota la diferencia en el uso real mientras que el rendimiento mejora de forma brutal.

Ventajas de servir un LLM desde tu propia máquina

Levantar un servidor de IA en tu propio PC o workstation tiene varias ventajas claras frente a depender todo el rato de APIs en la nube. La primera es la privacidad y el control total de los datos. Todo lo que envías al modelo (prompts, documentos, historiales de conversación) se queda en tu equipo, sin pasar por servidores externos, lo que es crucial si trabajas con información médica, legal o financiera sensible.

También hay un tema de costes y rendimiento. Cada llamada a una API como GPT-4, Claude u otros modelos comerciales tiene un precio por millón de tokens. Si tu aplicación hace muchas peticiones, la factura puede dispararse. Con un modelo local, más allá del gasto en hardware y electricidad, no pagas por consulta. Y al no depender de la red, sueles ganar en latencia: el tiempo hasta el primer token y la velocidad de generación suelen ser mejores, especialmente en redes lentas o inestables.

Otra ventaja potente es la personalización. Muchas herramientas de ejecución local permiten ajustar parámetros de los modelos, cargar plantillas de prompts específicas, o incluso reutilizar pesos de otros modelos para afinarlos (fine-tuning ligero). Se ha creado una enorme comunidad de modelos derivados para diferentes casos de uso, desde asistentes de programación hasta chatbots creativos o modelos especializados en documentos legales.

A nivel de estrategia tecnológica, ejecutar LLMs en tu propia infraestructura reduce la dependencia de proveedores concretos. No estás expuesto a cambios de precios, límites de uso, restricciones de contenido o cierres de servicio. Y, si más adelante decides combinar esto con servicios de nube (por ejemplo, para picos de carga), puedes diseñar arquitecturas híbridas que repartan la carga entre tu hardware local y la cloud.

Eso sí, no todo son rosas: al ganar control, también asumes responsabilidades en gobernanza de modelos, actualizaciones, seguridad y monitorización. Si vas a usar este servidor para algo más serio que trastear en casa, conviene planificar desde el principio cómo vas a registrar logs, gestionar versiones de modelos y auditar su comportamiento.

Herramientas clave para servir LLMs en local

Para montar un servicio de IA accesible desde otros dispositivos, tienes varias herramientas a tu alcance. Algunas están orientadas a usuarios que no quieren saber nada de terminales, y otras son más técnicas pero ofrecen más control. Las más relevantes para tu caso son Ollama, LM Studio, GPT4All y entornos basados en llama.cpp/ROCm, además de plataformas como Comfy para la parte de generación de imágenes.

Ollama es una capa amigable sobre llama.cpp que permite descargar, ejecutar y gestionar modelos directamente desde la línea de comandos, ofreciendo además una API HTTP en el puerto 11434 por defecto. Soporta Windows, macOS y Linux, y es especialmente potente en máquinas con GPUs NVIDIA o AMD bien configuradas. Puedes pegarte con él en Pop!_OS sin problema siempre que tengas los drivers correctos.

LM Studio es más visual, con interfaz gráfica para buscar modelos en Hugging Face, descargarlos y chatear con ellos. Además, ofrece un modo servidor local compatible con la API de OpenAI, perfecto para integrarlo en tus aplicaciones como si estuvieras llamando a GPT-4, pero sin pagar y sin sacar datos de tu red. Soporta Windows, macOS y Linux, y se lleva bastante bien con GPUs modernas.

Por su parte, GPT4All combina una interfaz gráfica sencilla con herramientas de línea de comandos. Está pensado para usuarios que quieren algo intermedio: poder usar un chat en local, pero también hacer cosas más avanzadas vía terminal o integraciones con otros proyectos. Funciona bien sin GPU, tirando solo de CPU, lo que lo hace útil para equipos sin aceleración gráfica potente.

En el terreno gráfico, Comfy es una plataforma open source muy popular para generación y edición de imágenes con IA. Aunque no está centrada en LLMs, encaja bien en un setup de IA local más completo: usas Ollama o LM Studio para texto, y Comfy para imágenes, todo sirviéndose desde tu workstation.

Si quieres ir al extremo, plataformas basadas en AMD Ryzen AI Max+ con ROCm y llama.cpp permiten incluso ejecutar modelos de hasta un trillón de parámetros de forma distribuida en clústeres locales, cuantizados e hiperoptimizados. Es un escenario más propio de startups tech con ambiciones serias que de un usuario doméstico, pero demuestra que la inferencia local a gran escala es perfectamente real.

Ollama en Linux: instalación, configuración y uso como servidor

Volviendo a un caso práctico y alineado con tu entorno, Ollama en Linux es una opción muy sólida para servir un LLM desde tu workstation. La instalación oficial, en distros del estilo de Pop!_OS o Ubuntu, se hace normalmente con un único comando:

curl -fsSL https://ollama.com/install.sh | sh descarga e instala el servicio, que se ejecuta en segundo plano mediante systemd. Una vez instalado, Ollama descarga los modelos en una carpeta interna (en Linux suele ser /usr/share/ollama/.ollama/models salvo que cambies la ruta) y levanta una API en 127.0.0.1:11434.

Para adaptarlo a tus necesidades, puedes configurar varias variables de entorno editando la unidad de systemd: con sudo systemctl edit ollama.service añades un bloque [Service] donde defines opciones como OLLAMA_MODELS (ruta personalizada de modelos), OLLAMA_HOST (por ejemplo, 0.0.0.0:11434 para que otros dispositivos de la red puedan conectar), OLLAMA_ORIGINS para controlar CORS, o OLLAMA_KEEP_ALIVE para decidir cuánto tiempo permanece un modelo en memoria después de la última petición.

Tras guardar, haces un sudo systemctl daemon-reload y luego sudo systemctl restart ollama para aplicar los cambios. Es importante revisar los logs de Ollama, que en Linux se consultan con sudo journalctl -u ollama (puedes añadir -f para seguir en tiempo real o -n 100 para ver solo las últimas 100 líneas), porque ahí sabrás si está detectando la GPU, si hay errores CUDA/ROCm o si se está quedando solo en CPU.

Dentro de esos logs verás una línea con el mensaje “looking for compatible GPUs” y, si todo va bien, otra indicando que se ha encontrado una GPU usable. Si en cambio aparece “no compatible GPUs were discovered”, significa que Ollama está tirando únicamente de CPU, y ahí toca revisar drivers y variables de entorno de AMD (HIP_VISIBLE_DEVICES, ROCR_VISIBLE_DEVICES, etc.).

Con Ollama operativo, puedes gestionar modelos con comandos como ollama pull llama3.2:1b (descarga), ollama run llama3.2:1b (ejecución interactiva), ollama list (lista de modelos), ollama show (detalles), ollama rm (borrado) o ollama ps (modelos cargados en memoria y si usan CPU o GPU). El comando ollama stop <modelo> te permite descargar un modelo de la memoria si ya no lo necesitas.

Elegir y etiquetar modelos: tamaño, cuantización y variantes

Una vez tienes el servidor a punto, toca decidir qué modelo vas a servir a tus aplicaciones y dispositivos. En la web de Ollama o en los catálogos de LM Studio verás una enorme lista de modelos con etiquetas que pueden liar un poco al principio, pero que en realidad son bastante informativas.

Por un lado está el tamaño, normalmente expresado en “B” de billions de parámetros: 1B, 3B, 7B, 13B, 32B, 70B, etc. Más parámetros suelen implicar más conocimiento y mejor rendimiento, pero también más consumo de RAM y VRAM. Si tu workstation va justa de recursos o quieres baja latencia con muchos usuarios a la vez, puede ser más sensato servir un modelo de 7B o 13B bien afinado que uno gigante que se arrastra.

Luego está la cuantización, con etiquetas tipo Q2_K, Q3_K_M, Q4_K_S, q8_0, fp16, fp32, etc. Cuanto más bajo es el número (Q2 frente a Q8), más comprimido está el modelo y menos memoria usa, pero también hay una pérdida de precisión. Las variantes con sufijo K (K_S, K_M, K_L) suelen considerarse equilibradas entre tamaño y calidad, mientras que fp16 o fp32 significa prácticamente sin cuantizar, lo que da máxima calidad a costa de devorar recursos.

Además, verás variantes por tipo de uso: modelos etiquetados como instruct (pensados para seguir instrucciones), chat (conversación general), code (programación), vision (multimodales con imágenes), etc. Para servir un asistente general a otros dispositivos, normalmente te interesa algo tipo chat o instruct, mientras que para un backend de generación de código será mejor un modelo code como CodeLlama o DeepSeek Coder.

Finalmente, muchas veces aparece una etiqueta latest. Esto no significa que sea el último modelo creado, sino una especie de “versión recomendable por defecto”: suele ser un punto medio entre tamaño, calidad y requisitos de hardware. Si no tienes claro por dónde empezar, latest es un buen primer candidato para pruebas.

LM Studio y el modo servidor compatible con OpenAI

Si prefieres algo más visual y te interesa especialmente exponer un API tipo OpenAI desde tu workstation, LM Studio es un aliado muy cómodo. Tras descargar la versión para Windows, macOS o Linux desde su web, la instalas como cualquier otra aplicación y, al abrirla, te ofrece un buscador integrado de modelos alojados en plataformas como Hugging Face.

En LM Studio puedes filtrar por tamaño, tipo de tarea y compatibilidad con tu hardware. Para equipos con solo CPU y 8 GB de RAM, tendrás que ir a modelos pequeños y muy cuantizados. Si tienes más de 16 GB de RAM, ya puedes subir a 7B o 13B con más soltura. Con GPU y 16 GB de RAM (o un Mac con M1/M2) puedes probar modelos medianos, y con GPU y 32 GB de RAM ya entras en territorio de 40B sin que sea un drama, siempre ajustando la cuantización.

Una vez descargado un modelo, LM Studio te permite chatear directamente desde la propia interfaz, con estadísticas de tokens y velocidad. Puedes abrir varios chats, cambiar parámetros de generación en el panel lateral y ver cómo se comporta cada modelo con prompts reales. Esto es útil antes de decidir cuál vas a exponer como servicio remoto para tus apps.

La parte más interesante llega con la opción de “Local Server”. Al activarla con el botón de “Start Server”, LM Studio levanta un servidor en tu máquina que emula la API de OpenAI. Esto significa que desde tu código Python, JavaScript o lo que uses, puedes seguir utilizando el cliente de OpenAI, pero apuntando a http://localhost:1234/v1 (u otro puerto que configures) en lugar de a los servidores reales de OpenAI.

Por ejemplo, en Python usarías algo así: definir un OpenAI(base_url=»http://localhost:1234/v1″, api_key=»not-needed») y luego crear completions con el modelo «local-model» o el nombre que hayas configurado. Desde fuera parece que estás llamando a GPT-4, pero en realidad estás hablando con tu LLM local, ejecutándose en la workstation y aplicando tus reglas de privacidad y coste.

Esta compatibilidad con el formato OpenAI permite montar de forma sencilla arquitecturas híbridas: puedes hacer que tu código use primero el modelo local y, en caso de error, latencia inaceptable o necesidad de un modelo muy grande, delegar puntualmente en una API externa de pago. De este modo mantienes flexibilidad sin renunciar al ahorro y al control que da la inferencia local.

Rendimiento, problemas típicos y cómo afinarlos

Una vez que tienes el modelo en marcha y el servidor expuesto, llega el momento de pelearte con el rendimiento real y los errores comunes. Lo primero que suele aparecer son mensajes de “Memoria insuficiente” o “Out of Memory” al intentar cargar modelos demasiado grandes para tu RAM/VRAM. La solución suele pasar por cerrar aplicaciones pesadas, elegir una cuantización más agresiva (por ejemplo, Q4 en lugar de Q8) o directamente bajar de tamaño de modelo.

Si has apostado por usar la GPU o la iGPU del Ryzen AI MAX+ y notas que el sistema vuelve una y otra vez a la CPU, seguramente hay un problema de drivers o detección de GPU. En Windows, asegúrate de que los drivers NVIDIA/AMD son los más recientes y que la herramienta (LM Studio, Ollama, etc.) tiene habilitada la opción de aceleración por GPU en su configuración. En Linux, revisa ROCm, las variables de entorno y los logs para comprobar si realmente la GPU está visible.

Otra fuente de quebraderos de cabeza son las descargas corruptas o incompletas de modelos. Si un modelo no carga o se bloquea nada más arrancar, a veces basta con borrarlo desde la herramienta (ollama rm, borrar carpeta en LM Studio) y volver a descargarlo. Ten presente que un modelo de 30 o 40 GB descargado a medias no va a arrancar por arte de magia.

En entornos basados solo en CPU, la queja habitual es la lentitud de generación. Esto es normal: los LLMs son pesados. Para mejorarlo, céntrate en modelos más pequeños y bien cuantizados, sube el número de hilos que la herramienta puede usar y vigila que la CPU no esté haciendo thermal throttling por temperatura. A veces un cambio de pasta térmica o una mejora en la ventilación de la caja se nota más de lo que parece.

Si lo que buscas es servir un LLM a otros dispositivos de tu casa u oficina, no olvides revisar también la configuración de red y seguridad. Exponer el API en 0.0.0.0 hace que cualquier dispositivo de la red pueda llegar a tu servidor, lo cual es útil pero implica riesgos. Puedes limitar el acceso con cortafuegos, redes separadas o autenticación a nivel de aplicación, especialmente si manejas datos sensibles o si tu workstation está expuesta a Internet.

Más allá de estos problemas básicos, en despliegues más serios para startups o empresas hay que pensar en monitorización, logging estructurado, backups de modelos y estrategias de actualización. No es lo mismo jugar en casa que montar un producto comercial donde los modelos se convierten en un componente crítico del negocio.

En definitiva, servir un modelo de lenguaje grande desde una workstation local implica combinar buen hardware, herramientas adecuadas y algo de mimo en la configuración. Con CPU moderna, suficiente RAM, una GPU o iGPU bien soportada y plataformas como Ollama o LM Studio, puedes montar tu propia infraestructura de IA privada, accesible desde todos tus dispositivos, con un control fino de costes, privacidad y latencia que las soluciones 100 % cloud no siempre pueden igualar.