Contexto técnico
Me encantan este tipo de noticias, no por el hype, sino porque rápidamente ponen la implementación de IA con los pies en la tierra. Es sencillo: DeepSeek 4 Flash q2 ya se está ejecutando localmente en MacBooks M5 con 128 GB de RAM, y en vivo se obtienen unos 30 tok/s.
Para un escenario local de un solo usuario, esto ya no es un juguete. Especialmente si estás considerando la automatización con IA sin la nube, con datos privados y una latencia predecible.
Lo que realmente me llamó la atención: el propio DeepSeek ocupa hasta 80 GB de memoria. El resto lo consumen procesos adyacentes, como Claude Code, Codex y otras herramientas, que fácilmente pueden llevarse otros 35 GB.
Es decir, la historia no va solo sobre el modelo, sino sobre todo el stack de trabajo que lo rodea. Sobre el papel tienes 128 GB, pero en realidad la reserva se agota muy rápido si no mantienes la máquina casi dedicada a la inferencia.
Otro detalle del mundo real: el tool calling no funciona a la perfección y el modelo a veces se olvida de cerrar las etiquetas. Considero que esto no es un detalle cosmético, sino un problema de ingeniería, porque es precisamente en estos puntos donde se rompen los pipelines de agentes y las cadenas de acciones automatizadas.
La buena noticia es que parece un problema solucionable a nivel de wrappers, validación y postprocesamiento. La mala es que no puedes confiar ciegamente en ello de fábrica si tu lógica de producción depende de un formato estricto.
¿Qué cambia esto para el negocio y la automatización?
Veo tres conclusiones prácticas aquí. Primero: el despliegue local de grandes modelos en Apple Silicon ya se puede discutir de forma realista no como un experimento, sino como una integración de IA funcional para equipos que valoran la privacidad y el control.
Segundo: el umbral de hardware no ha desaparecido. Si no tienes 128 GB y disciplina con los procesos en segundo plano, la bonita idea se convierte rápidamente en una lucha por la memoria y una experiencia de usuario (UX) inestable.
Tercero: ganan aquellos que necesitan un asistente de código local, un agente interno o el procesamiento privado de documentos. Pierden los que esperan una velocidad de nube y un uso de herramientas perfecto sin ingeniería adicional.
En Nahornyi AI Lab, precisamente analizamos estos casos de forma práctica: dónde un modelo local es realmente más rentable que una API, cómo construir una arquitectura de IA sin costes innecesarios y cómo asegurar el tool calling para que la automatización no se desmorone por pequeños detalles. Si estás considerando un entorno de automatización de IA local, podemos evaluar tranquilamente tu stack y construir una solución sin tener que adivinar en foros.