Retrospectiva

Probé LLM locales en una Mac Studio: para personas y equipos pequeños brillan más como workers lentos pero potentes

AAnonymous
10 min de lectura

Introducción

Las historias sobre correr LLM en local casi siempre empiezan por la instalación. Te explican qué runtime usar, qué modelo descargar y qué puerto abrir.

Pero cuando los usas durante un tiempo, aparece otra pregunta mucho más importante. Cómo usar un LLM grande en local de forma realmente útil. Porque lograr que arranque y seguir usándolo todos los días son problemas completamente distintos.

Yo también empecé con Ubuntu + vLLM + 2x 3090 Ti. Y ahora me pasé a una Mac Studio M3 Ultra(512GB) con LM Studio, donde corro en local modelos grandes de las familias deepseek, qwen y glm.

Este texto no es una guía de instalación. Quiero resumir, de forma ligera, por qué sentí el límite con dos 3090, por qué me cambié a la Mac Studio y cómo estoy usando en trabajo real un LLM local aunque sea lento.

Al principio empecé con dos 3090 Ti

La configuración inicial era bastante simple. Conseguí dos GPU 3090 Ti usadas por unos 2.2 millones de wones, las monté sobre Ubuntu y usé vLLM como runtime.

En ese momento gemma 3 era uno de los modelos que mejor se sentían en local. Para asistentes que resolvían instrucciones muy simples o para armar workflows pequeños, resultaba lo bastante impresionante. El rendimiento multilingüe no estaba nada mal y la velocidad de generación de tokens, para la época, también me dejó bastante satisfecho.

De hecho, en ese entorno construí y probé varios asistentes.

  • Agente de chat
  • Lector de tarot
  • Asistente con perfil de traductor
  • Ejecutor simple orientado a workflows

La conclusión de esa etapa fue clara. El LLM local ya no estaba en fase de juguete. Pero todavía le faltaba bastante para decir que ya podías construir de inmediato un agente realmente útil.

El problema era menos el software y más la realidad del hardware

Al principio la razón de elegir vLLM también era simple. Era relativamente fácil de configurar y mucho más conocido que sglang.

Pero con el tiempo entendí que, cuando haces funcionar un setup doméstico de 3090 en multi-GPU, el cuello de botella no está tanto en qué runtime eliges, sino en cuestiones mucho más terrenales.

  • La factura eléctrica pesaba.
  • El calor era demasiado.
  • Era difícil mantenerlo corriendo siempre en casa.
  • Y, sobre todo, el tipo de modelo grande que yo realmente quería correr seguía fuera de alcance.

En ese momento lo que yo quería era trabajar en local, con suficiente contexto, con modelos del nivel de deepseek v3. Pero con dos 3090 el límite era evidente. Correr bien modelos pequeños y usar de forma constante modelos grandes como un activo real de trabajo son cosas totalmente distintas.

Al final terminé deshaciéndome de las GPU y comprando una Mac Studio M3 Ultra(512GB). Ese cambio no fue solo reemplazar el equipo, sino cambiar la forma en que veía los LLM locales.

Lo que se volvió posible después de pasarme a la Mac Studio

Después de cambiar a macOS + LM Studio, la diferencia más grande fue que modelos que antes ni siquiera eran una opción real empezaron a entrar en un rango posible.

Cuando pude montar por mi cuenta modelos grandes como deepseek, glm y Qwen3-235B-A22B y revisar sus resultados, me sorprendió bastante el desempeño. La calidad de razonamiento fue mejor de lo que esperaba. Incluso con instrucciones un poco más complejas, muchas veces entregaban resultados mucho más finos y estables que antes.

Pero al mismo tiempo las limitaciones también quedaron clarísimas. El rendimiento de pp era más lento de lo esperado y, para usos que exigen reacción inmediata, como el chat en tiempo real, claramente no encajaba. Ya sabía por mis lecturas que iba a ser lento, pero usarlo todos los días hace que esa limitación se sienta mucho más fuerte.

En ese punto cambié mi criterio. Empecé a preguntarme menos ¿este modelo es rápido? y más ¿para qué tipo de trabajo debería usar este modelo?.

Trabajos en los que, aun siendo lento, la satisfacción fue alta

Curiosamente, en cuanto dejé de exigir respuesta en tiempo real, el LLM local se volvió mucho más útil.

Las áreas donde quedé más satisfecho eran casi siempre las mismas.

  • Trabajos que requieren resultados precisos, como el análisis de datos
  • Tareas como escribir historias para juegos, donde no importa que tome tiempo
  • Workflows de análisis complejos con muchas etapas
  • Trabajos de desarrollo automático al estilo OpenHands, que puedes dejar corriendo toda la noche en lugar de hacerlos tú

Por ejemplo, crear una sola historia puede tardar entre 40 y más de 60 minutos. Si lo mides con la vara de un chat en tiempo real, esa velocidad es terrible. Pero si cambias el esquema y antes de dormir dejas en cola entre 3 y 5 tareas, la historia cambia por completo.

A cambio de la lentitud, el resultado es mucho más grande y refinado. La persona no se pasa la noche esperando; al día siguiente revisa el resultado y vuelve a cargar la siguiente cola.

Con OpenHands me pasó algo parecido. En lugar de usarlo como un copiloto que responde al instante, funcionaba mucho mejor acumular tareas en la cola y dejarlo correr de forma automática. Visto así, un LLM local se parece menos a un chatbot lento y más a un worker silencioso y persistente.

Aunque no sea rápido como una liebre, puede ganar como una tortuga

Cuando pienso en los LLM locales, a menudo se me viene a la cabeza la fábula de la liebre y la tortuga.

Los LLM en la nube suelen parecerse a la liebre. Son rápidos, responden bien al instante y se dejan usar de inmediato. En cambio, los modelos grandes en local se parecen más a la tortuga. Son lentos, bajo el criterio de inmediatez resultan frustrantes y, si haces la comparación equivocada, decepcionan muy rápido.

Pero si cambias la vara de evaluación, el resultado también cambia.

En una pelea de chat en tiempo real, los LLM locales pierden a menudo. Pero si llevas el problema a una estructura donde gana la constancia, con colas, trabajo repetitivo, ejecución por lotes y procesamiento nocturno, la historia cambia. Yo, de hecho, obtuve una satisfacción muy alta así. Además, el consumo energético fue mucho más estable que con un setup multi-GPU. También fue importante que, al menos en mi experiencia, podía mover modelos más grandes con menos de una séptima parte de la energía que consumía la configuración con GPU.

Al final, lo importante no era la velocidad del modelo, sino cómo diseñas el ritmo de tu trabajo.

Al final, mi código también terminó cambiando hacia un enfoque centrado en colas

No es solo una impresión; quedó reflejado tal cual en la implementación real.

Si miras mi módulo ai-service, se nota bastante claro que veo el LLM local menos como chat en tiempo real y más como un worker de fondo.

Primero, la conexión con el modelo en sí es más simple de lo que parece. En RunnableAiModel, vllm y lm studio se tratan como proveedores compatibles con OpenAI y solo hay que cambiar el baseUrl. Es decir, desde la aplicación superior, mientras se mantenga la forma de un endpoint compatible con OpenAI, puedes cambiar el backend local de manera bastante natural.

También hay un ejemplo de uso específico para LM Studio. LMStudioVisionClient está implementado para conectar modelos de visión usando el endpoint /v1 de LM Studio. En otras palabras, deja listo el camino para conectar un VLM local y extenderlo hasta el análisis de imágenes.

Lo más importante, sin embargo, es la forma de ejecución.

AiAgentExecutor no ejecuta el workflow de inmediato, sino que lo registra en una cola como un job DTE. LoopJobService y LoopWorkflowExecutor están diseñados para procesar en segundo plano trabajos largos y repetitivos, y también tienen flujo de checkpoint y recuperación. WritingToolExecutor, los workflows multiagente y el pipeline de generación de marketing también están pensados, en general, más para ejecución asíncrona que para respuesta inmediata.

No es casualidad. En vez de meter a la fuerza un modelo lento en una interfaz en tiempo real, resulta mucho más realista mandar a la cola tareas donde la lentitud sí es aceptable.

En pocas palabras, terminé entendiendo así los LLM locales.

  • Encajan mejor con una cola de trabajo que con un bot de respuesta de chat.
  • Encajan mejor en tareas donde la complejidad y el refinamiento importan más que la velocidad.
  • Funcionan muy bien con el patrón de dejarlos corriendo toda la noche y revisar el resultado por la mañana.
  • Si mantienes una API compatible con OpenAI, no es difícil integrarlos en la estructura de un servicio existente.

Entonces, ¿para quién tiene sentido un LLM local?

Si llegaste hasta aquí, probablemente tienes la misma duda: si un LLM local de verdad vale la pena y si justifica gastar mucho dinero.

Mi criterio es bastante claro.

Un LLM local encaja bien con personas como estas.

  • Personas que tienen más trabajo por lotes que chat en tiempo real
  • Personas que quieren dejar corriendo toda la noche generación y análisis complejos
  • Personas que quieren seguir aprovechando modelos grandes con costos operativos bajos
  • Personas que pueden rediseñar su flujo de trabajo alrededor de colas

En cambio, si lo más importante para ti es la experiencia de conversación inmediata, al principio te va a resultar claramente frustrante. En ese caso, hay mucha probabilidad de que un LLM local sea una decisión montada sobre una expectativa equivocada.

Para cerrar

Hacer correr LLM grandes en local pasa más rápido de lo que parece del éxito en la instalación al fracaso en la adopción. Que el modelo levante no significa que automáticamente se vuelva útil.

Yo empecé con 2x 3090 Ti + Ubuntu + vLLM, y ahora me moví a una Mac Studio M3 Ultra(512GB) con LM Studio. Después de atravesar ese proceso, mi conclusión es simple.

Fuera de una lógica enterprise, para personas y equipos pequeños los LLM locales brillan mucho más cuando se usan como workers lentos pero potentes que como herramientas para reemplazar el chat rápido.

Si ya tienes una Mac, y sobre todo si es una máquina del nivel de una Mac Studio, vale la pena probar los LLM locales de esta manera. No hace falta empezar con algo grandilocuente. En vez de pensar en chat en tiempo real, basta con elegir una tarea difícil para dejar en cola esta noche.

Más posibilidades de las que uno cree empiezan justo ahí.