1 puntos por GN⁺ 2 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Incluso en una MacBook Pro M4 con 24 GB es posible armar una configuración de modelos locales para trabajo básico, investigación y planificación
  • Qwen 3.5-9B Q4 ofrece alrededor de 40 tokens/segundo, modo de razonamiento, uso de herramientas y contexto de 128K
  • No puede resolver de forma autónoma problemas complejos durante mucho tiempo como los modelos de primer nivel, así que necesita instrucciones paso a paso
  • Corrigió advertencias de Elixir Credo, pero falló al resolver un conflicto de rebase sin editar archivos
  • Los modelos locales tienen la ventaja de funcionar sin conexión y sin suscripción, pero implican grandes trade-offs en rendimiento y configuración

Entorno para ejecutar modelos locales y criterios de selección

  • Se probó una configuración para ejecutar modelos locales en una MacBook Pro M4 con 24 GB de memoria, y aunque no alcanza la salida de los modelos de última generación (SOTA), sí fue posible una configuración capaz de manejar trabajo básico, investigación y planificación sin conexión a internet
  • Entre las herramientas para ejecución local están Ollama, llama.cpp y LM Studio, cada una con restricciones y modelos disponibles distintos
  • Al elegir el modelo, era necesario que cupiera en memoria y aun así dejara margen para ejecutar aplicaciones Electron comunes, además de requerir una ventana de contexto de al menos 64K, idealmente de 128K o más
  • Intentos recientes con Qwen 3.6 Q3, GPT-OSS 20B y Devstral Small 24B entraban en memoria, pero eran difíciles de usar en la práctica; Gemma 4B corría bien, pero mostró dificultades con el uso de herramientas
  • Los parámetros de configuración van desde valores conocidos como temperature hasta opciones especiales como K Cache Quantization Type, y los valores adecuados pueden cambiar dependiendo de si el razonamiento (thinking) está activado

Configuración con cuantización de 4 bits de Qwen 3.5-9B

  • qwen3.5-9b@q4_k_s fue el mejor modelo al ejecutarlo en LM Studio: entregó alrededor de 40 tokens/segundo, razonamiento activado, uso exitoso de herramientas y una ventana de contexto de 128K
  • Se distrae con más facilidad que un modelo de primer nivel, a veces cae en bucles y en ocasiones interpreta mal las solicitudes, pero como modelo que corre en una MacBook Pro de 24 GB dejando espacio para otras tareas, resultó bastante bueno
  • La configuración recomendada para modo de razonamiento y trabajo de programación fue la siguiente
temperature=0.6, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=0.0, repetition_penalty=1.0
  • Para activar el razonamiento, en LM Studio hay que seleccionar el modelo, ir a configuration y agregar el siguiente valor en Prompt Template, al final de la pestaña Inference
{%- set enable_thinking = true %}
  • Este modelo se usó tanto en pi como en OpenCode; pi se sintió más ágil, pero aparte de la ventaja de poder construir y personalizar directamente el harness, carecía de valores predeterminados razonables
  • Era posible terminar dedicando más tiempo a ajustar la configuración de pi que al proyecto real

Configuración de pi

  • En ~/.pi/agent/models.json se registró el endpoint compatible con OpenAI de LM Studio junto con el modelo qwen3.5-9b@q4_k_s
{
  "providers": {
    "lmstudio": {
      "baseUrl": "http://localhost:1234/v1";,
      "api": "openai-completions",
      "apiKey": "lm-studio",
      "models": [
        {
          "id": "qwen3.5-9b@q4_k_s",
          "reasoning": true,
          "compat": { "thinkingFormat": "qwen-chat-template" }
        }
      ]
    }
  }
}
  • Para ocultar bloques de razonamiento dispersos, se agregó "hideThinkingBlock": true a ~/.pi/agent/settings.json

Configuración de OpenCode

  • En ~/.config/opencode/opencode.json se registró LM Studio como provider local compatible con OpenAI, y se configuraron uso de herramientas, longitud de contexto de 131072 y máximo de 32768 tokens
{
  "$schema": "https://opencode.ai/config.json";,
  "provider": {
    "lmstudio": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LM Studio (local)",
      "options": {
        "baseURL": "http://127.0.0.1:1234/v1";
      },
      "models": {
        "qwen3.5-9b@q4_k_s": {
          "name": "Qwen 3.5 9B Q4_K_S",
          "tools": true,
          "context_length": 131072,
          "max_tokens": 32768
        }
      }
    }
  },
  "model": "lmstudio/qwen3.5-9b@q4_k_s"
}

Diferencias frente a los modelos de primer nivel

  • Modelos como Qwen 3.5 9B Q4 no estaban al nivel de los modelos de primer nivel cuando se trataba de resolver de forma autónoma problemas complejos durante largos periodos
  • Pedirle que construyera una aplicación completa de una sola vez no era un enfoque adecuado, y podía terminar calentando la laptop sin producir resultados
  • Un enfoque que funcionaba mejor era un flujo de trabajo interactivo, con comunicación clara por pasos y muchas instrucciones
  • Al usar modelos locales, la persona usuaria debe encargarse directamente de más razonamiento y planificación, y dar instrucciones más específicas, pero seguían siendo útiles como asistentes de investigación, rubber duck y apoyo para recordar al instante detalles de lenguajes de programación y llamadas de línea de comandos
  • No es la mejora de productividad de 10x que promocionan las grandes empresas de IA, pero sí ofrece ayuda real y una experiencia de uso interesante

Tareas que funcionaron y tareas que fallaron

  • Corrección de advertencias de Elixir Credo

    • Después de actualizar el linter de Elixir credo a la versión más reciente, aparecieron advertencias en el código, y se le pidió a Qwen que ejecutara mix credo --strict, propusiera cómo resolverlas, pero sin editar nada
    • Qwen detectó en 4 archivos de prueba el problema de usar length/1 para comprobar si una lista no estaba vacía, y sugirió usar list != [] en lugar de length(list) > 0
    • Después, cuando se le pidió editar, Qwen realizó de forma limpia 4 ediciones en paralelo
    • Era una tarea simple que también podía hacerse manualmente entre terminal y editor, pero cumplió bien como asistente conveniente
  • Manejo de conflicto de rebase en un PR de Dependabot

    • Tras una actualización de dependencias, había un conflicto de git en un PR de Dependabot; como Dependabot rechazó el rebase, se descargó el cambio manualmente, se hizo rebase y luego se le pidió a Qwen que revisara
    • El conflicto era simple: bastaba con elegir versiones más nuevas de cada dependencia, y Qwen recomendó conservar sentry en 13.0.1 y tailwind en 0.4.1
    • Pero al pedirle el cambio real, Qwen intentó ejecutar git add mix.lock && git rebase --continue sin modificar el archivo, dejando los marcadores de conflicto intactos
    • Tampoco reconoció que git rebase --continue abriría un editor, OpenCode se quedó colgado y era posible que el problema hubiera sido algo puntual

Ventajas y límites de los modelos locales

  • Los modelos locales implican trade-offs importantes, pero tienen la ventaja de permitir trabajar incluso en un avión, sin conexión a internet
  • Si de todos modos se asume la compra de la computadora, el costo queda limitado al consumo eléctrico y no hace falta ninguna suscripción
  • El entrenamiento de modelos sigue teniendo un alto costo ambiental, pero las empresas de modelos abiertos están lejos de estar entre las de mayor impacto ambiental, y usar hardware personal reduce la dependencia de los centros de datos
  • También está la diversión de ajustar y experimentar por cuenta propia
  • Los LLM ya han tenido un gran impacto y también traen muchos aspectos negativos, pero parecen ser una tecnología que llegó para quedarse; experimentar con modelos locales se sintió como una forma más sostenible y positiva de interactuar con esta tecnología

1 comentarios

 
GN⁺ 2 시간 전
Comentarios de Hacker News
  • Ejecutar LLM localmente es divertido y potente, pero terminar trabajo real puede ser bastante engorroso
    Hay que planear, hacer especificaciones y preparar todo de antemano, mientras que los modelos grandes de OpenAI o Claude suelen entender con solo darles unas cuantas frases

    • Sí. Sobre todo en los últimos 6 meses, para mucha gente la suscripción a modelos frontier ya se volvió un gasto de trabajo
      Si ya estás haciendo trabajo serio con modelos grandes, simplemente sigue usándolos
      Eso sí, veo distinto las tareas de visión/OCR. Incluso los modelos pequeños y medianos con pesos abiertos están cerca del estado del arte, y en trabajos por lotes grandes el costo de los tokens de prefilling sí duele
      Además, a menudo se olvida que, incluso para usar un LLM pequeño como un servicio personal confiable, hay que dejar 16~24 GB de RAM/VRAM libres y mantenerlo corriendo todo el tiempo
    • Ahora ya es técnicamente fácil correr modelos grandes en casa para uso offline. Gran parte del mérito es de China, que está publicando modelos de primer nivel
      El problema central al final sigue siendo el dinero
  • Creo que ya llegaron a un nivel casi realmente útil
    Gemma 4 31B se siente como una nueva línea base para modelos locales. Obviamente está por debajo de los modelos frontier, pero se siente menos como un experimento científico que los modelos locales que he probado hasta ahora, como GPT OSS 120B o Nemotron Super 120B
    En una M5 Max con 128 GB de RAM, usar la ventana de contexto completa de 256K hace que el uso de RAM suba hasta unos 70 GB, y se ven unos 14 GB de sobrecarga del sistema
    Parece que una máquina Panther Lake de 64 GB con Arc B390 completa o una máquina Snapdragon X2 Elite de 48 GB podrían mover una ventana de contexto de 128K~256K, y con 32 GB tal vez se podría forzar una ventana de 32K
    Apenas el año pasado, ver este nivel de rendimiento en una configuración premium cercana al mainstream parecía un sueño imposible

    • Gemma 4 es realmente bueno. Incluso me ha acertado cosas que Opus 4.7 pasó por alto, y aunque tiene asperezas, sigo encontrando usos donde en la práctica se puede usar como equivalente
      Al final el criterio es: “¿qué le puedo confiar a este modelo de forma consistente?”. Opus claramente sabe más y puede hacer tareas más complejas, pero si le das buen contexto, Gemma sorprende por lo bien que funciona
      La diferencia en el rango de tareas que confiaría a uno u otro es más pequeña de lo que parece. Últimamente me ha dado muy buenos resultados en herramientas personales y varios proyectos, y fue el primer modelo local al que pude confiarle implementar funcionalidades en modo agente en proyectos que no eran triviales
      https://thot-experiment.github.io/gradient-gemma4-31b/
      Esta es una herramienta relativamente compleja hecha casi por completo por Gemma 4 dentro de OpenCode, y durante varias horas solo hubo unas 4 intervenciones manuales
      Q6_K_XL, contexto 128K @ q8, lectura de unos 800 tok/s, escritura de unos 16 tok/s
      Estoy esperando turboquant y MTP de llama.cpp; si los rumores son ciertos, podría llegar a 256K y 25~30 tok/s
    • Los modelos pequeños de Qwen 3.6 manejan el contexto un poco mejor que Gemma 4, pero especialmente Gemma 4 26B destaca por ofrecer una solución muy compacta y eficiente para su categoría
      Justo después de su lanzamiento escribí sobre eso porque su desempeño en benchmarks fue impresionante [0]. Pero al usarlo en entornos de coding con agentes y contexto más largo, su posición en la tabla bajó un poco después
      [0] https://gertlabs.com/blog/gemma-4-economics
    • Para la mayoría de las tareas de edición uso el Gemma E2B más pequeño, y sorprendentemente funciona bien
      El flujo es planear con un modelo más moderno y ejecutar con el pequeño. Si se planifica bien y no se deja ambigüedad para que el modelo pequeño la interprete, funciona bien
    • Estaría bueno que compartieras el tiempo hasta el primer token y los tokens por segundo
    • Me da curiosidad si en la práctica sientes que Gemma funciona mejor que qwen3
  • Ojalá hubiera visto este post antes de pasar todo el fin de semana llegando a la misma conclusión
    Hice una prueba artificial en la misma laptop pidiéndole arreglar unas 50 advertencias de lint en un repositorio pequeño de vibe coding en C++. Esperaba que pudiera resolver muchas tareas pequeñas sin atascarse tan seguido
    GPT OSS 20B se podía usar, pero era lento, agregaba frases innecesarias o repetidas, y seguido cometía el error de listar cosas como arregladas sin haber modificado realmente el código
    Qwen 3.5 9B usado con Opencode fue mucho más rápido, resolvió la mayoría de las advertencias de lint sin atascarse incluso durante la compresión, y corrigió todas las advertencias con cambios correctos
    También probé una cuantización MLX de 4 bits de Qwen 3.5 9B, pero al final se cayó por falta de memoria; al cambiar a GGUF ejecutado con llama.cpp funcionó sin crashes
    No se puede comparar en absoluto con los modelos frontier. Son mucho más lentos, se equivocan incluso en información básica y no pueden resolver de una sola vez tareas que no sean triviales
    Le pedí que resumiera la arquitectura del proyecto y aseguró que usaba librerías que no existen en ninguna parte del repositorio. Aun así, depende de cada quien, pero sí tiene algo de utilidad, y ojalá con el tiempo el entorno de LLM locales mejore mucho más incluso en hardware razonable

    • Esa frase de “no se puede comparar en absoluto con los modelos frontier” no aparece lo suficiente
      Los LLM locales son excelentes, pero si lees muchos posts sobre el tema, podrías salir pensando que están casi al nivel de Opus 4.7
      En HN hay un grupo muy pequeño, muy ruidoso y muy entusiasta que exagera muchísimo las capacidades de los LLM locales
    • En vez de qwen3.5 9b, te conviene probar qwen3.6.35 a3b. Es completamente distinto
    • Sí sorprende bastante que GPT OSS 20B corra lento en hardware Mac
      Entre los modelos de ese tamaño, fue de los más rápidos que probé en GPU local, aunque solo lo probé en tarjetas Nvidia
      Luego vi que era MoE y que solo tenía 3.6B de parámetros activos, así que eso explica bastante
  • Es útil tener una visión realista de lo que se puede hacer con modelos locales, especialmente con modelos pequeños como el 9B que usa el autor
    Un modelo de 9B está más o menos al nivel de Sonnet 3.6, así que puede hacer autocompletado y funciones pequeñas, pero si intentas que entienda un problema grande, pierde el hilo
    Aun así es interesante y divertido para experimentar. Principalmente he estado armando cosas como harnesses de agentes locales por pura diversión
    El proyecto actual es un agente sin instalación: https://gemma-agent-explainer.nicklothian.com/
    Python, SQL y React corren completamente dentro del navegador. Para la mejor experiencia recomiendo Gemma E4B
    Sigue en desarrollo activo, y por el soporte de HTML5 Filesystem API y LiteRT necesita Chrome. Aun así, probablemente se puede hacer funcionar en la mayoría de navegadores basados en Chromium
    Lo que lo diferencia de la mayoría de agentes es que no requiere instalación. El modelo corre dentro del navegador con LiteRT/LiteLLM y rinde mejor que Transformers.js. Además, con Filesystem API puede tener acceso opcional de lectura a un directorio sandbox
    Está autodocumentado, así que si preguntas en el panel de ayuda en tiempo real algo como “¿cómo se usa el system prompt?”, puede acceder a su propio código fuente y responder
    Si haces clic en “Tour” puedes ver todo, y planeo liberarlo como open source la próxima semana

    • Con Sonnet 3.5 hacía bastante más que autocompletado y funciones pequeñas
    • No por ponernos quisquillosos, pero muchos modelos de 4~12B están en algún punto entre GPT-3.5 y GPT-4o-mini
      Eso sí, como los benchmarks que la gente usa para evaluar modelos cambian demasiado seguido, cuesta encontrar comparaciones buenas. Como referencia, Sonnet 3.6 salió aproximadamente un año después de GPT-3.5
  • Viéndolo críticamente, es cierto que estos modelos no están al nivel del estado del arte actual en tareas complejas de programación
    Pero gran parte del trabajo de oficina consiste en procesar Excel, mover archivos, traducir documentos legales rígidos, redactar correos y hacer tareas menores en PPT
    Para este tipo de trabajo, un modelo de 30~35B o más ya es suficiente, con la ventaja adicional de mantener privados los datos de la empresa

    • Creo que esa conclusión está un poco mal. Es obvio que qwen3.5 9b está lejos de los modelos más recientes. ¿No es un modelo de 9B y además de hace un año?
      Cuando la gente habla de modelos locales, lo que espera son modelos salidos en abril de este año. El foco está en Qwen 3.6 27B y, si la GPU es más débil, en qwen 35b a3b
      Estos modelos sí se pueden comparar seriamente con modelos de primer nivel actuales
    • De hecho, Excel y lo legal pueden ser mucho peores que el código. Porque puede ser más difícil detectar errores
      El caso emblemático es el London Whale de JPMorgan, donde un error en Excel provocó una pérdida de 6 mil millones de dólares
  • Estoy pensando en una MacBook M5 Pro de 18/20 núcleos con 64 GB de RAM, pero encontrar benchmarks reales de modelos es muy difícil
    Por ejemplo, me gustaría que alguien dijera cuántos tokens por segundo da Qwen 3.6 35B/A3B con cuantización Q4 y Q6

    • No te fijes solo en los tokens por segundo; también hay que ver el tiempo hasta el primer token
      La inferencia local se está inclinando hacia modelos MoE, y en muchos de ellos los tokens por segundo son decentes, pero el tiempo hasta el primer token es terrible
  • Publiqué en Bluesky una configuración medio aleatoria que uso en una M2 Studio de 32 GB y me gustaría recibir feedback
    Soy de los que no lo hacen bien si no lo ven directamente, así que lo comparto esperando ayuda
    https://bsky.app/profile/mooresolutions.io/post/3mliilyf2i22...

  • Estoy corriendo un modelo cuantizado qwen 3.6 9b en una M4 Pro de 48 GB, y apenas alcanza para desarrollo básico con pi.dev/cc
    Para hacer trabajo realmente significativo, parece que el sweet spot es una desktop de 128 GB. Aunque ahora mismo conseguir una así no es nada fácil
    Ejecutarlo localmente es divertido, pero no hay que olvidar que tu tiempo tampoco es gratis
    En proyectos personales cada vez me estoy moviendo más a OpenRouter, y aun usando en serio los modelos qwen más grandes, gasto menos de 2~3 dólares al día

    • Me da curiosidad si elegiste un modelo tan pequeño por la alta velocidad de tokens por segundo
      Con una M4 Pro de 48 GB puedes correr modelos más grandes, así que si la inteligencia del modelo es la clave para que sea útil, quizá tenga más sentido usar uno más grande
    • En el mismo hardware uso un modelo MoE de 30B con 65K tokens como subagente con herramientas, y escribe código bastante decente
      Sí coincido en que un 9B denso se queda corto
    • Hay demasiadas tonterías en internet diciendo que los modelos locales son mejores que algo como Opus 4.7. Para usuarios normales eso no es cierto
      He probado modelos locales incluso en la configuración tope de una MacBook Pro M5 reciente, y casi todo funciona apenas a duras penas
    • Me da curiosidad cómo se compara la versión de OpenRouter frente a ChatGPT 5.5 o Claude Opus 4.6
  • En una 4090 de 24 GB estoy corriendo qwen3.6:27B con unos 128K de contexto aprovechando las optimizaciones recientes de memoria de activaciones de turboquant/rotorquant
    Recomiendo mucho subir a un modelo de ese nivel. La combinación q4_xl+rotorquant está bastante bien
    También hay código de referencia para pasarle a un agente
    https://github.com/rapatel0/rq-models

  • Me parece mejor gastar miles de dólares en una Mac que en suscripciones de API
    Los modelos locales te permiten trabajar cuando sea, donde sea y sin preocuparte por filtrar tu privacidad