#348 – IA en local y modelos (casi) open source

Síguenos en: Seguimos con los monográficos dedicados a la IA y en este caso hablamos sobre cómo utilizarla en local y con modelos open source. ¿Qué tal la semana? Semana Nahuai Follow-up del episodio de la semana pasada. Le pasé a Claude la transcripción y le pregunté si había dicho algún dato incorrecto y el único que me rebatió fue el escaneo y destrucción de libros por parte de Anthropic. Pero una simple búsqueda web arroja decenas de enlaces sobre el proyecto Panama. ¡Ojo! Lectura recomendada, parcialmente relacionada. Implementando una restricción a contenido pasado personalizado en Restrict Content Pro. Última Meetup de WP Terrassa. Campus Connect en Lleida con charlas de Nilo, Ana y Celi. Además de un concurso de webs de los estudiantes. Tema de la semana: ¿Por qué correr LLMs en local? Privacidad: tus datos no salen de tu máquina Sin costes por token: sin APIs de pago ni límites de uso Modo offline: funciona sin conexión a internet Control total: elige el modelo, la cuantización y el contexto Descentralizar la tecnología y no contribuir al oligopolio de las big tech Herramientas principales LM Studio: interfaz gráfica, ideal para empezar, tiene chat integrado y servidor local. Ollama: orientado a terminal y desarrolladores, muy fácil de integrar con otras apps. Factores clave a entender Tamaño del modelo (parámetros) El número de parámetros (1B, 7B, 13B…) indica la "capacidad" del modelo Más parámetros = más calidad, pero más recursos necesarios Un modelo pequeño bien cuantizado puede superar a uno grande mal cuantizado Cuantización Proceso de reducir la precisión de los pesos del modelo para que ocupe menos memoria Q2/Q3: muy comprimido, baja calidad, pero cabe en casi cualquier máquina Q4_K_M: buena calidad con tamaño razonable Q6/Q8: casi calidad completa F16/F32: precisión completa Tipo de modelo Modelo denso: todos los parámetros se activan en cada inferencia. Es más predecible y estable, pero más exigente en recursos por parámetro. Mezcla de Expertos (MoE): solo se activan una fracción de los parámetros por token. Mucho más eficiente en velocidad y memoria. Velocidad de inferencia (tokens/s) Cuántos tokens genera el modelo por segundo En CPU suele ser lento (3–10 tok/s); con GPU dedicada puede ser 10x más rápido La RAM unificada de Apple Silicon es especialmente eficiente para esto Formatos de modelo GGUF: el formato estándar para correr modelos en local con llama.cpp (lo usan LM Studio y Ollama) MLX: formato optimizado por Apple para correr modelos directamente sobre Silicon, mejor rendimiento que GGUF en Mac. Ventana de contexto Cuántos tokens puede "recordar" el modelo en una conversación Contextos largos (32k, 128k) consumen más RAM aunque el modelo sea pequeño Reducir el contexto es una palanca útil si te quedas sin memoria Requerimientos de hardware Memoria RAM 8 GB: modelos de hasta 7B en Q4 (justo), mejor quedarse en 3B–4B para fluidez 16 GB: cómodo con modelos de 7B–8B en Q4-Q6, o 13B en Q3/Q4 32 GB: modelos de 13B–30B con buena cuantización, o 70B en Q2/Q3 64 GB+: modelos de 70B en Q4+ con buena velocidad En Apple Silicon la RAM unificada actúa como VRAM, lo que lo hace muy eficiente para inferencia local Código abierto vs. pesos abiertos Código abierto: se publican los pesos del modelo, el código y datos de entrenamiento. Pesos abiertos: solo se publican los pesos, puedes usar y modificar el modelo, pero no sabes exactamente cómo fue entrenado ni con qué datos. La mayoría de modelos llamados open source en realidad son open weight: puedes correrlos y afinarlos libremente, pero el proceso de entrenamiento sigue siendo una caja negra. Modelos de pesos abiertos recomendados (para programar) Local Qwen3.6 (Alibaba): familia orientada a coding agéntico con dos modelos locales: 27B denso (~17 GB en Q4) y