Ejecutar modelos locales ahora sí vale la pena
(vickiboykis.com)- Incluso en una Mac M2 de 2022, los LLM locales ya rinden lo suficiente como para usarse de forma práctica en preguntas de desarrollo, tareas de código y revisión de documentación
- Los primeros modelos locales eran lentos, difíciles de usar y poco precisos en tareas de programación, pero desde GPT-OSS disminuyó la frecuencia de volver a verificar con modelos por API
- Con los lanzamientos más recientes de la familia Gemma 4, el bucle de codificación con agentes en local funciona con cerca del 75% de precisión y velocidad frente a los modelos frontier
- La combinación de Pi y LM Studio ejecuta flujos de trabajo con agentes mediante un endpoint de inferencia local, artefactos del modelo y una configuración aislada con Docker
- Los modelos locales todavía tienen limitaciones de latencia de inferencia, ventanas de contexto pequeñas y restricciones de hardware, pero permiten observar y modificar directamente el procesamiento de tokens, el prompt del sistema, la cuantización y el harness
Dónde están hoy los modelos locales
- Los primeros modelos locales eran lentos, difíciles de usar y poco precisos en la mayoría de las tareas de programación
- La idea de que los modelos locales estaban muy rezagados era, en términos de uso personal, mayormente correcta hasta antes del lanzamiento de GPT-OSS
- El criterio personal de un “modelo suficientemente bueno” era si había que volver a comprobar con un modelo por API, y GPT-OSS fue el primer modelo que redujo mucho esa necesidad
- Hasta hace poco, los modelos locales se usaban sobre todo como una especie de Google rápido y personalizado para preguntas de desarrollo que no requerían información reciente
- Desde los lanzamientos más recientes de la familia Gemma 4, el bucle de codificación con agentes en local funciona con alrededor del 75% de la precisión y velocidad de los modelos frontier {p:75}
Modelos usados y entorno de ejecución
- Se probaron varios modelos locales en una Mac M2 de 2022 con 64GB de RAM y 1TB de almacenamiento
- Entre los modelos usados están Mistral 7B, Gemma 3, OpenAI OSS-20B, Qwen 3 MOE y Qwen 2.5 Coder
- La configuración de ejecución pasó por raw llama.cpp y Open WebUI, llama-cpp-python, Ollama, llamafiles y LM Studio
- Se usó como modelo local base la implementación
gemma-4-26b-a4bde LM Studio
Casos reales de trabajo con agentes locales
- Se refactorizó un script de Python que antes estaba en un notebook hacia un repositorio con 5 o 6 módulos
- Esos módulos se lintaron para que usaran type hints genéricos conforme a PEP 585
- También se usó la configuración local para corregir entradas de blog, escribir pruebas unitarias y armar la configuración inicial de un repositorio de modelo two-tower para recomendaciones
- El repositorio de modelo two-tower generado por el agente desde cero era básico, pero superó lo que el autor pensaba posible el año pasado
- Todos los flujos de trabajo con agentes se ejecutaron dentro de un contenedor Docker con permisos de ejecución restringidos
Uso de recursos y modelos pequeños recientes
- Las tareas realizadas se parecían más a una búsqueda personalizada en Google o una consulta de documentación que a trabajos realmente revolucionarios
- Durante las tareas, el uso de GPU y RAM aumentó, y la caché K-V llegó a crecer hasta 64GB de RAM
- Incluso este tipo de trabajo sencillo con modelos locales habría sido imposible hace apenas 6 meses
Gemma-4-12b-qatimpresionó por su rendimiento en relación con su tamaño desde poco después de su lanzamiento- La arquitectura del modelo lleva a preguntarse qué compromisos de diseño hacen falta cuando hay restricciones de rendimiento y costo
Configuración para ejecutar modelos de agentes locales
- Para ejecutar un flujo de agentes local se necesita un motor de inferencia local, un harness de agente y artefactos del modelo local
- El harness debe configurarse para apuntar al endpoint de inferencia local, y los artefactos descargados del modelo deben servirse a través del motor de inferencia
- La configuración local actual usa Pi como harness de agente y LM Studio como servidor de inferencia
- Se siguió la guía sobre cómo configurar codificación con agentes de Gemma 4 usando Pi y LM Studio, pero cambiando algunos ajustes
- En lugar de
Gemma 26B A4Bde la guía, se usógemma-4-12b-qat, que es más nuevo, más pequeño y más rápido, sin una pérdida grande de precisión - Por seguridad, todas las sesiones de Pi se ejecutaron dentro de contenedores Docker y se otorgaron solo permisos de bash, bloqueando la ejecución de código Python y la navegación web
- Para una imagen separada orientada a trabajo de investigación, se planea permitir
curl - Como todo corre dentro de Docker, se modificó el
models.jsonde Pi para que Pi pudiera comunicarse con el modelo
- En lugar de
Aislamiento basado en Docker
- En la configuración de Pi,
baseUrlse dejó comohttp://host.docker.internal:1234/v1y la API se configuró comoopenai-completions - La configuración de Docker Compose monta
models.json, el directorio de trabajo, la configuración de Pi y el directorio de sesiones dentro del contenedor - El script de ejecución conecta el directorio de trabajo actual como workspace del contenedor y, si hace falta, agrega un archivo Compose de sandbox más seguro
- Como Pi se ejecuta dentro del repositorio en el que se está trabajando y levanta Docker, no puede borrar directamente archivos o directorios del disco físico
- Fue posible pasar una configuración personalizada del modelo en
jsonal interior del contenedor, y eso funcionó relativamente bien en el entorno de pruebas
Limitaciones que siguen pendientes
- Los modelos locales todavía pueden ser lentos al inferir, tienen ventanas de contexto pequeñas y el contexto utilizable sigue limitado por el hardware disponible
- El ecosistema se ha vuelto mucho más fácil gracias a herramientas como LM Studio y el botón Use This Model de Hugging Face
- Las primeras versiones sufren problemas de desajuste de plantillas de prompt, pero estos problemas normalmente se corrigen muy rápido
- Todavía es difícil afirmar con certeza que ya estén listos para usarse directamente en desarrollo de software de producción
Ventajas de los modelos locales y posibilidades de experimentación
- Con los modelos locales se puede inspeccionar casi todo, e incluso ver en tiempo real el proceso de inferencia de tokens
- Se puede revisar directamente el flujo de tokens de entrada y salida
- Se puede observar cómo mejora o empeora el rendimiento al cambiar la ventana de contexto local
- Se puede profundizar en cómo se procesan los tokens en la GPU, y también modificar el prompt del sistema y la configuración de cuantización
- Se pueden enfrentar modelos entre sí o cambiar y observar la configuración del lado del harness, así que las posibilidades de experimentación siguen ampliándose
7 comentarios
"Debido al tamaño natural de los bloques de trabajo y a que los modelos pequeños prefieren instrucciones concretas, el usuario termina entendiendo el código con mucho más detalle.
Eso no significa que los modelos locales no puedan resumir la estructura de un proyecto o encontrar errores, sino que recompensan una forma de trabajo mucho más manual."
Hay una parte impresionante en el comentario.
Es una opinión con la que coincido.
Si vamos a decir que los modelos locales ya son realmente utilizables, entonces también habría que llamar a ChatGPT superinteligente... A los modelos locales todavía les falta muchísimo. Según mi criterio, para decir que un modelo local ya es utilizable, al menos habría que ponerle 4 RTX 5090 y correr un modelo de más de 100B para que sea "más o menos" usable.
Opiniones en Lobste.rs
Por eso me alegra ver que los modelos que se pueden alojar localmente realmente están mejorando.
Como vimos con el caso de Fable en Anthropic, existe un riesgo real de convertirse en tu propio siervo digital.
Si los modelos locales y los arneses de programación siguen mejorando, habrá cada vez menos razones para alquilar modelos de un proveedor, incluso si el rendimiento total del modelo local sigue siendo inferior. Por ejemplo, mucha gente usa DeepSeek en vez de Claude porque es suficientemente útil y mucho más barato; también en local, a partir de cierto punto importa más si el modelo local logra hacer el trabajo que si puedes alquilar uno mejor.
También hay mucho potencial para personalizar y afinar las herramientas. No he visto muchos casos de gente creando LoRA para un idioma específico, pero en dominios limitados pueden volver un modelo mucho más eficaz, y en esa etapa incluso podría rendir mejor que un modelo general enorme.
La electricidad necesaria para entrenar unos cuantos modelos de tamaño local al año podría quedar absorbida por el ruido de fondo de la civilización industrial. Todos los datos se quedan en local, y además se incentiva menos a los mercaderes.
Los modelos locales suelen ser más tontos, y eso en realidad hace que uno se mantenga más cerca del trabajo. En Fable puedes dar la instrucción “llena esta calle con casas” y te sacará un montón de McMansions chafas; con Qwen3.6 27B lo natural es más bien decirle algo como “pinta estas cuatro habitaciones”. Por el tamaño natural de los bloques de trabajo y porque los modelos pequeños prefieren instrucciones concretas, el usuario termina entendiendo el código con mucho más detalle.
Eso no significa que los modelos locales no puedan resumir la estructura de un proyecto o encontrar bugs, sino que recompensan una forma de trabajo mucho más manual. Fable es el modelo que de verdad me hizo pensar que estamos perdidos, porque realmente puede escupir proyectos completos de la nada. Esas “McMansions” se ven bien, pero el techo gotea, los cimientos tiemblan y la mano de obra apenas alcanza para venderlas. Claro, es muy probable que en el mercado tengan un gran éxito, y hasta el peor día de Fable sigue siendo mejor que mucho SaaS empresarial. Bueno, excepto por cumplimiento y seguridad.
Así que me parecen herramientas locales interesantes, pero de verdad no me entusiasma el desastre que van a producir los próximos modelos frontier.
qwen3-coder:30bme pareció decente para editar LaTeX y para hacer consultas sobre papers procesados con OCR, pero me pregunto si tienen otros usos.Cada vez que lo he intentado me ha decepcionado mucho, y además montar un pipeline de inferencia local es engorroso y frágil. La GPU de mi laptop es demasiado chica, así que tengo que usar un clúster de cómputo compartido.
A veces sí uso ollama/qwen3-coder o duck.ai. Más que nada cuando no se me ocurren las palabras clave para buscar cómo hacer algo en un lenguaje o una biblioteca que no conozco, o para tareas muy específicas en las que no soy bueno, como regex o SQL.
También lo uso para generar de una sola vez el primer borrador de scripts pequeños o mini herramientas personales. Por ejemplo, un arnés que excluya TikZ de solicitudes de traducción. Después hay que depurarlo, pero depurar es mucho más entretenido que escribir a mano las partes aburridas que el LLM acierta más o menos bien. La estrategia de validación es aún más importante que en algo escrito a mano, e idealmente debería ser del tipo en que “los bugs que queden se hagan bastante evidentes al ejecutar la herramienta”.
Francamente, me sorprendió que Qwen3.6 no fuera tan malo como esperaba para producir un borrador de solución de ejercicios estándar de redacción de demostraciones. Al editarlo para ajustarlo al estilo que uno quiere, puede terminar sintiéndose como sopa de hacha, pero algunas fórmulas sí podrían sobrevivir hasta el final. Al final depende de qué tan tediosa sea la tarea.
Estoy corriendo qwen3.6 27b a 1 token por segundo en una PC con DDR3 + i5 y gráficos integrados.
Antes, aunque esperara así, solo salían resultados desastrosos, pero ahora al menos sale algo que sí se puede usar.
En 6 meses ha avanzado al punto de que un rendimiento que antes requería tamaños de 80~120B ahora es suficiente con algo de clase 30B, y creo que en alrededor de 1 año también podríamos ver en 30B un rendimiento de código al nivel de opus4.8 o gpt5.5.
Entonces, creo que incluso un modelo local como este, que saca entre 50 mil y 70 mil tokens al día, puede ser una opción suficientemente válida como complemento.
Para usar bien un modelo local, necesitas hardware a la altura, pero ese hardware también es demasiado caro, así que, salvo que tengas una razón especial como la seguridad, por ahora parece que una suscripción o llamar a una API sigue siendo más rentable.
Para agentes, de una u otra forma funciona, pero para agentes de programación está medio...
Comentarios en Hacker News
No sé si diría que sí. Uso mucho modelos locales, pero ejecutarlos en local sigue siendo bastante doloroso
Los modelos densos como Qwen 27B y Gemma 31B son bastante inteligentes, pero lentos, y los modelos de mezcla de expertos (MoE) como Gemma 26B, Qwen 35B y North Mini Code 30B son rápidos, pero cometen muchos errores
Para correrlos bien se necesita mucha memoria, y si los cuantizas, las llamadas a herramientas se debilitan. La mayoría los ejecuta en cuantización de 4 bits y luego se pregunta por qué no rinden; en la práctica, es como haberle hecho una lobotomía al modelo. Recomiendo la cuantización de Unsloth, y sugiero 6 bits para MoE y 5 bits para modelos densos
Para que el prefill sea rápido necesitas capacidad de cómputo, para que el decode sea rápido necesitas ancho de banda, y para que quepa todo también necesitas mucha memoria. Además, las laptops se convierten en máquinas calientes y ruidosas, incómodas para trabajar
Entonces, ¿está bueno? No mucho. Funciona
Agregaría que creo que los modelos abiertos son el futuro y sigo contribuyendo al ecosistema. Me gustaría que la gente pruebe estos modelos y use
pipara aprender cómo funcionan, pero no deberían esperar que con solo descargar un modelo ya vaya a ser bueno. Para reemplazar el “agente de código” que la mayoría quiere, hace falta bastante ajuste y configuraciónLos modelos no enfocados en código solían atascarse en decir solamente “haré esta acción” sin hacer realmente la llamada a herramienta, y aunque preguntara qué había que configurar para cambiar ese comportamiento, no ayudaban. Qwen insistía en que no estaba corriendo en ollama, sino en la nube de Alibaba, y que no tenía acceso al sistema local
Incluso los modelos para código apenas pensaban un poco más rápido que mi velocidad al teclear, y también eran limitados en los casos en que podían mostrar su proceso de razonamiento
Hasta ahora, la mejor experiencia “gratis” que encontré es OpenCode + Big Pickle. No es súper inteligente, así que el primer resultado muchas veces está mal, pero el nivel gratuito es generoso y, aun usándolo varias horas con frecuencia durante cerca de un mes, solo me topé con límites unas dos veces. Si tu objetivo es una ejecución realmente local, no es lo adecuado, pero si el objetivo es “la mejor experiencia posible sin suscripción ni costo por tokens”, hasta ahora ha sido la opción menos mala
Intentar hacerlo con una Mac de memoria unificada, un procesador AMD AI Max o algo parecido a un DGX Spark se acerca más a buscarse problemas. El prefill arruina el rendimiento
Si le pones la GPU adecuada, mejora bastante, pero aun así sigue sin llegar al nivel de Sonnet o DeepSeek 4 Flash, y menos todavía a Opus / DeepSeek Pro o Mythos/Fable/GPT-5.5
Si tienes suficiente presupuesto, energía y refrigeración, puedes montar un pipeline de datos bastante decente, pero para código, en la mayoría de los casos, todavía tiene más sentido pagarle a un proveedor de API
Aun así, vale la pena intentarlo para no depender tanto de servicios centralizados
En mi experiencia, supera a los modelos Qwen, incluso a los de más de 100B, en seguimiento de reglas o tareas estilo automatización. También es muy buena interpretando imágenes, y en benchmarks sale por encima de Opus
Qwen tiende a ignorar instrucciones y, si no restringes explícitamente el formato de generación de tokens, tiende a producir de forma constante un formato incorrecto
Aun así, en un DGX Spark, Gemma 31B Q4 + MTP da alrededor de 20 tokens por segundo y Gemma 26B A4B alrededor de 60 tokens por segundo, así que sigue siendo bastante lento. En tarjetas Nvidia avanzadas debería correr mucho más rápido y además caber en memoria
A quien esté empezando con modelos locales le recomendaría enfocarse en el ancho de banda de memoria más que en la RAM. Hoy, los modelos de menos de 100B ya alcanzan para automatización y son muy útiles
Coincido en que todavía no hay una razón fuerte para usar modelos locales en tareas de código/creación. Pero para cosas como revisar listas de acciones y filtrar noticias en alta frecuencia, o interpretar logs y capturas de pantalla, los modelos locales ya son suficientes
Podría justificarse algo como un Mac Studio M6 con unos 256 GB de RAM, para que varias personas accedan a un modelo en el que todos estén de acuerdo. Las laptops se sienten demasiado calientes y lentas para este uso
Después de usar Qwen3.6-27B con mucha satisfacción durante unas semanas, ahora que estoy lejos de mi hardware tengo que usar Claude Sonnet 4.6, y se siente como un downgrade enorme
No entiendo cómo es posible. Tiene demasiadas opiniones fuertes que nadie le pidió, habla demasiado y, en general, se siente más tonto
Claro, al ser un modelo mucho más grande probablemente tenga más conocimiento codificado, pero si no da ganas de conversar con él, no ayuda. Encima, hablar con él cuesta dinero real
Me pregunto por qué me desagrada tanto. Tal vez sea porque parece verse a sí mismo no como una herramienta, sino casi como un igual. Actúa como si sus opiniones tuvieran peso
Qwen también puede comportarse como un practicante demasiado entusiasta, pero si le dices que está siendo tonto, baja el ego. Claude, según mi experiencia, no hace eso
En conclusión, estoy totalmente de acuerdo con el título
Lo he usado casi todos los días durante el último mes y medio en una M2 Ultra o en una máquina con RTX 5090. Lo uso para tareas pequeñas y normales de ggml-org [0]; nada espectacular, pero sin duda es una herramienta útil para un maintainer
Creo que lo habría usado mucho más si no pasara tanto tiempo revisando PRs. Ahora mismo uso un harness muy ligero: básicamente el agente pi sin nada extra (
pi -nc --offline) y un prompt de sistema corto [1] para ajustarlo a mi estiloLa velocidad de generación es de unos 100~150 tokens/seg en la RTX 5090 y unos 40 tokens/seg en la Mac. Definitivamente prefiero correrlo en la máquina con RTX porque es mucho más rápido, pero también lo ejecuto seguido en la Mac para probar configuraciones locales y tener una experiencia más amplia
[0] - https://github.com/search?q=%22Assisted-by%22+user%3Aggml-or...
[1] - https://github.com/ggml-org/llama.cpp/blob/master/.pi/gg/SYS...
Puede que sea peor que Opus para cosas como “agrégale la gran funcionalidad X”, pero yo no quiero eso de un modelo. Quiero pensar yo y que el modelo escriba. Para eso, Qwen 3.6 27B es completamente suficiente. En mi experiencia, 35A3B o la familia Gemma fueron un downgrade considerable
Además, no hay que preocuparse por rate limits, cuotas ni colas en horas pico. Siempre puedes ver todo el proceso de pensamiento, no tienes que preocuparte por a dónde se envían tus datos, y no existe el riesgo de que lo degraden a escondidas
Lo corro con llama.cpp en 2×3090 usando configuración Q6_K_XL + MTP, con prefill de 500~1000 tokens/seg, salida de 60 tokens/seg y una ventana de contexto de 220 mil tokens. Después de los 160 mil tokens empieza a volverse un poco más tonto, y no uso cuantización KV
Puede que esto sea un efecto secundario de la función de razonamiento, pero me gustaría que resumiera su proceso mental de una forma mucho más simple. Incluso en situaciones donde una respuesta de una sola oración bastaría, los modelos de punta escriben al menos 5 párrafos e intentan proponer entre 3 y 5 direcciones nuevas
Aunque les pidas que vayan de a un paso por vez, una sola opción a la vez, y que no propongan activamente caminos a seguir, es realmente difícil controlarlo bien por prompt
Aunque ahora mismo yo también acabo de hacer exactamente aquello de lo que me estaba quejando
Los programadores están acostumbrados a no pagar por sus herramientas. Incluso una laptop básica de trabajo (SSD, multinúcleo, 16 GB de RAM) es increíblemente potente para desarrollo en C/C++/Rust, e incluso Python
Pero de pronto eso deja de ser suficiente, y volvemos a la situación de usar la computadora de otra persona y alquilar herramientas todos los días. Peor aún, terminas usando un modelo distinto cada día, y algunos días una especie de mafia puede presionar al fabricante y ni siquiera dejarte alquilar una buena herramienta
La mayoría de las otras profesiones sí tienen que invertir bastante en sus herramientas. Si quieres buenas herramientas, necesitas algo como 64 GB de memoria GPU (por ejemplo, 2×5090) y unos 96 GB de RAM. Si le pagas 200 mil dólares a un ingeniero profesional, gastar 50 mil dólares en herramientas una vez cada dos años también parece bastante razonable
Es una tendencia que debería preocupar a empresas como Anthropic. Cuanto más fácil sea ejecutar modelos locales, más bajo será el techo de precio que podrán cobrar
No es que vaya a desaparecer por completo la gente dispuesta a pagar $$$$$ al mes, pero mucha gente va a multiplicar la cuota mensual por 12 o por 24 y preguntarse: “¿Podría montar un modelo local por menos dinero y recuperar la inversión en 1 o 2 años?”
Si una parte importante de los clientes empieza a elegir comprar en vez de alquilar, las empresas con modelos de negocio centrados en el alquiler podrían enfrentarse de repente a una falta de clientes
Ya está casi grabado en el modelo de negocios estadounidense. Externalizarlo todo. Nadie quiere administrar una sala de servidores por su cuenta, y aunque paguen 2 o 3 veces más, prefieren externalizar también ese dolor de cabeza y esa responsabilidad
Con la IA será igual. Da lo mismo si ese premium se lo pagan a Anthropic o a AWS
Trabajo en una empresa relativamente pequeña, y hace poco tuvimos un incidente relacionado con infraestructura local. Aunque el tiempo total de caída interna en los últimos 5 años fue muchísimo menor que una sola gran caída reciente de AWS, el CEO ahora está presionando con la idea de que alojar infraestructura propia ya no es confiable
Todo el mundo quiere quitarse de encima el trabajo pesado y la responsabilidad
El usuario promedio y masivo probablemente esté más dispuesto a pagar por algo que ya viene configurado y listo para usar. La gente más técnica o con más determinación lo hará por su cuenta, pero me da curiosidad qué proporción habrá entre ambos grupos
No sé si ya existe la idea de vender algo como una máquina de 4 GPU que el equipo de ingeniería pueda meter en algún armario y usar para correr el modelo que quiera
No sería atractivo para todo el mundo, pero ahora que existe el problema de confianza de que los hyperscalers absorben los datos de la gente para entrenar modelos, habrá lugares que valoren una máquina y unos modelos que puedan controlar de forma transparente y a los que incluso puedan ir a desconectarles el cable si hace falta
Con solo Sonnet 4.6, por 20 dólares al mes puedes trabajar casi todo el día. Y Sonnet sigue siendo mucho más potente que cualquier modelo que puedas autoalojar en una Mac M2
Tal vez cambiaría de opinión si todo el mundo pasara a cobrar por uso de tokens, pero con base en suscripción no me cuadran los números
Es divertido. Pero no es económicamente viable
OpenAI está comprando toda la RAM disponible en el mercado spot, haciendo que los precios de la RAM/VRAM suban 6 veces, y dejando las GPU y las computadoras decentes fuera del alcance de la mayoría
Unos pocos con dinero podrán comprar una Mac Studio de 512 GB o una RTX Pro 6000 por 13 mil dólares y correr modelos locales bastante buenos, pero la mayoría tendrá que usar APIs
En algún momento Nvidia podría decir: “No estamos vendiendo tantas 6000, y podemos ganar 4 veces más con GPUs solo para datacenter, así que mejor la cancelamos”. Entonces se volvería un producto imposible de conseguir, y podría volverse imposible para individuos correr en local modelos decentes que estén más o menos un año por detrás del estado del arte
Me gustaría que mostraran el código que salió de eso. Quiero usar modelos locales y tengo el hardware, pero comparados como reemplazo de modelos de frontera como GPT 5.5 xhigh u Opus, todavía no están listos
La calidad y los tropiezos hacen que el flujo de trabajo se vuelva demasiado lento, y a veces hasta rompen la sintaxis de las llamadas a herramientas
Aun así, para flujos más pequeños y bien definidos, o para ediciones como “cambia esta parte exactamente de esta manera”, parecen ser suficientes. Estoy esperando a que maduren lo bastante como para reemplazar lo mejor que hay hoy, y creo que ese será el punto de inflexión
Si hablamos de modelos locales, no hay que subestimar DiffusionGemma ni los modelos de difusión en general para uso local. Normalmente el problema de lo local es que los LLM no aprovechan bien el hardware salvo que agrupes varias solicitudes en lotes para ejecutarlas al mismo tiempo, y para eso hace falta cambiar por completo el enfoque. En cambio, los modelos de difusión son mucho más rápidos con un solo prompt, y la diferencia no es menor
Justo hoy porté el soporte de diffusiongemma-26B-A4B-it de Transformers a Candle, y además le sumé algunas optimizaciones, así que durante la inferencia está volando en Candle con unos 450 tokens por segundo (aprox. 19 iteraciones por segundo). En la librería HF Transformers estaba en unos 180 tokens por segundo (aprox. 11 iteraciones por segundo). Incluso corriendo un LLM de tamaño parecido con vLLM, no creo haber pasado nunca de 250 tokens por segundo con un solo prompt, así que es algo interesante para un modelo local
Por 2600 dólares puedes comprar dos GPU AMD 9700, con 32 GB de RAM por tarjeta y un consumo de unos 285 W. Tanto el costo como el consumo son menores que en una 5090
Si usas un build de VLLM con el parche de AITER, puedes correr Qwen3.6 27B FP8 a unos 45~50 TPS con la ventana de contexto completa en sesiones reales de programación con Opencode o PI
De verdad espero que sigan saliendo más modelos densos de alrededor de 30B, pero incluso solo con Qwen3.6 ya se puede resolver bastante trabajo de agentes
Eso sí, el stack de ROCm no es para alguien que no tenga ganas de meterse a fondo y aplicar parches por su cuenta
Me pregunto por qué el criterio de lo que es un agent coding “bueno” varía tanto de una persona a otra.
Por un lado, es realmente sorprendente que ya hayamos llegado desde un nivel de inteligencia tipo “reproducir ‘Set a Timer’ en Apple Music” hasta algo que incluso podría pasar la prueba de Turing; pero en términos prácticos, a los modelos pequeños todavía les falta mucho para llamarlos “buenos” más allá de una demo técnica.
Para mí, un modelo de 7B no es más que un eco borroso de Wikipedia. Un modelo Gemma de 4 bits es demasiado torpe incluso para generar de forma estable JSON de llamadas a herramientas o copiar una sola línea de código para aplicar un parche.
Qwen necesita demasiadas instrucciones detalladas y demasiado cuidado para no caer en bucles de desastre o perder el contexto; muchas veces las instrucciones que tengo que darle terminan siendo más largas que el código que deja al final.
¿Hay algún prompt mágico que yo no conozco? ¿O los demás simplemente tienen mucha más paciencia o expectativas mucho más bajas?
En scripts pequeños, glue code y cambios CRUD simples, un modelo pequeño como Qwen3.6-27B puede funcionar mucho mejor que en codebases más grandes y desordenadas.
Si ejecutas Qwen/Gemma de clase 27/35B en FP8, es mejor que gemini-2.5 pero peor que gemini-3.1. DS4-flash FP8 puede correrse en dos DGX Spark, y la situación sigue mejorando. DiffusionGemma recientemente mostró una velocidad de generación de tokens 4 veces mayor.
En resumen, parece que los modelos que probaste son demasiado pequeños o están cuantizados en exceso.
Me gusta ejecutar dos modelos en local. Son qwen3.6 27B 8 bits (denso) y qwen3.6 35B 4 bits (mixture of experts).
El 27B es más inteligente y confiable, pero más lento. El 35B es más rápido y sigue siendo muy inteligente, pero está por debajo del 27B y es un poco menos estable. La razón es que, por su arquitectura de mixture of experts (MoE), solo activa una parte de los parámetros, así que el modelo es mucho más rápido.
El 27B lo corro en una MacBook Pro M5 Max + 40 núcleos de GPU + 128 GB de RAM. En esta bestia puedo tener el 27B y el 35B cargados en memoria al mismo tiempo y todavía me sobra para otras tareas. Pero como es una laptop, no puedo tener un LLM local corriendo todo el tiempo. Se calienta demasiado y hace mucho ruido.
Lo más interesante es correr el modelo 35B en una MacMini M4 con 64 GB de RAM. Es rápido y saca bastante trabajo. Por ejemplo, escanea, extrae y clasifica correos, y sigue monitoreando el buzón para seguir trabajando. También lo uso como asistente personal Hermes y le pregunto cosas como “¿Cuándo es el próximo lanzamiento de Starship?” o “¿Quién juega hoy en el Mundial? Y cuéntame también alguna curiosidad”.
El siguiente plan es una workstation con RTX Pro 6000 Blackwell para poner en el sótano. Quiero correr Qwen muy rápido, con varios hilos/prompts/agentes al mismo tiempo. Si el presupuesto lo permite, me gustaría una configuración de 2×RTX Pro 6000 para correr DeepSeek v4 flash y usarlo para investigación.
En el día a día alojo Qwen3.6:27b, pero de verdad quisiera alojar deepseekv4 flash. Es un modelo demasiado “bueno” para su tamaño/velocidad/precio.
Me pregunto cuándo las empresas dejarán de pagar suscripciones para cada desarrollador y empezarán a alojar on-premises modelos para tareas cotidianas. Ya son suficientemente buenos y relativamente baratos.
Aunque nadie lo preguntó, ninguno de nosotros cree que se deban usar modelos de última generación y de máximo nivel para escribir código ni para casi ninguna tarea.
En cambio, deberíamos desarrollar modelos abiertos para tareas específicas, y aprender a programar, escribir y dibujar con dedos de hueso y cerebro de carne.
Las grandes empresas y los centros de investigación sí podrían usarlos para generar código, matemáticas, etc., poniendo expertos que verifiquen si la salida es correcta, pero incluso así puede que no valga la pena por costo-beneficio. Por ejemplo, OpenAI perdió 36 mil millones de dólares netos el año pasado, los modelos abiertos ya se acercaron bastante, y al plan general de la IA ya casi no le queda humo para seguir sosteniendo la estafa.
Hay muchísimas cosas que pueden hacerse incluso con modelos muy pequeños, y muchas tareas que no requieren niveles absurdos de cómputo y memoria, pero hay muy poca gente investigando bien esa dirección.