Hola,

Esta semana Moonshot y Alibaba han publicado modelos abiertos que no te caben en el ordenador ni de lejos. Kimi K3 ocupa 1,56 TB. Y sin embargo, por cada token que genera, activa 16 de sus 896 expertos. Un 1,8 % del modelo. Llevamos años cargando el cien por cien de algo para usar una centésima parte, porque dábamos por hecho que no había otra forma.

Resulta que hay al menos seis equipos demostrando que sí la hay. Y cuando tiras del hilo aparece algo más grande que un truco para exprimir la VRAM: un mismo patrón repitiéndose en la arquitectura de los modelos, en los motores de inferencia, en cómo compactas una conversación con un agente y hasta en sistemas de ficheros que no tienen nada que ver con la IA. En The Airtist te damos el tablero completo, con los números medidos y con lo que Marco decidió no ejecutar en su máquina y por qué.

Y en el G33K TEAM de esta semana, full equipo para hora y media de sistemas del bueno: Néstor moviendo una sesión de Codex viva desde su Mac a una Steam Deck sin perder el estado, el repaso a microVMs e hipervisores que se nos fue de las manos, la demo del agente de voz de Aitor montado sobre Asterisk, y un cierre sobre el precio de la RAM que enlaza directo con el artículo.

Vamos al lío 👇

📅 G33K TEAM de la Semana

🎙️ Episodio S2E55 — Mover un agente vivo de tu portátil a una Steam Deck

Semana de full equipo —Oriol, Néstor, Aitor y Tete— y estreno de sección: unos minutos al principio para enseñar en qué ha andado cada uno. La idea era que durasen cinco minutos. Duraron cuarenta. Y valieron la pena, porque de ahí salió hora y media de sistemas del bueno: virtualización, agentes portátiles, agentes de voz sobre centralita y una discusión final sobre el precio de la RAM que enlaza directa con el artículo de esta semana.

🔹 El experimento de Néstor: quiere arrancar un Codex en su Mac, cerrar el portátil, y que esa sesión —viva, con su historial, su configuración y sus cachés— se mueva sola a otra máquina y siga trabajando. Lo tiene funcionando contra una Steam Deck. Por debajo vuelca la RAM a disco, la mueve y la restaura al otro lado.

🔹 VM contra microVM, explicado en condiciones: una VM emula el ordenador entero (BIOS, USB) para engañar al sistema operativo. Una microVM no engaña a nadie: emula CPU, RAM, red y almacenamiento, y para de contar. A cambio arranca en una décima de segundo y aísla mucho mejor que un namespace, del que en teoría puedes escaparte.

🔹 El repaso al panorama de hipervisores: Firecracker (solo Linux como guest, y lo que hay debajo de los Cloud Agents de Cursor), gVisor —que resultó estar pensado casi solo para Kubernetes—, Cloud Hypervisor con su integración real en Windows, libkrun apuntando a macOS con HVF y Linux con KVM, Incus, y los unikernels, que Néstor abandonó pronto tras consultar con alguien que había construido uno.

🔹 El dato que sorprendió a todos: Rosetta corriendo Codex en x86 sobre Apple Silicon pierde apenas un 10 % de rendimiento. QEMU sobre Linux se va al 20-30 %. La capa de emulación que todo el mundo da por limitada resultó ser la que mejor funciona.

🔹 Inteligencia líquida contra cristalizada: el mejor momento no técnico del episodio. Lo que la IA sabe reemplazar hoy es la inteligencia líquida —la agilidad pura, que hace pico sobre los 25 años y cae con fuerza a partir de los 50—. La cristalizada solo se adquiere con años y con cosas hechas, y ésa no la sustituye. ¿En qué se traduce? En abrir un informe de la IA que parece impecable y darte cuenta de que falta un análisis que lo desmonta entero. O en oír tres buzzwords y saber en un segundo que no llevan a ninguna parte. En una empresa lo llamaban "tener muchos mejillones", por las rocas de mar: cuanto más tiempo llevan ahí, más se les pegan.

🔹 El agente de voz de Aitor: demo en directo de Nimbox SRE. Marcas un número, metes un PIN que identifica al tenant, y tu número de teléfono te identifica a ti. "Laura" te canta las incidencias abiertas, te da CPU, memoria y disco de cualquier máquina, apunta comentarios en un ticket con su rastro de auditoría, y te pasa la llamada a un humano. Montado sobre Asterisk a propósito: así vive como una extensión dentro de la centralita que la empresa ya tiene, en vez de exigir un número aparte. Para guardias, desbordamiento de llamadas y horario nocturno.

🔹 ZeroFS, que salió de un TopGit anterior: monta objetos de S3 como si fueran un disco de bloques. Parte tus 10 GB en bloques de 64 MB, se trae solo los que estadísticamente vas a necesitar y expulsa los que no caben, con caché en RAM y en disco local. Vuela en lectura; en escritura penaliza, porque la consolidación pasa por un único punto. Y ojo: S3 aquí es el protocolo, no el servicio — con un RustFS en tu LAN a 1 Gbit tienes de sobra para un homelab.

🔹 Y el cierre, que enlaza con el artículo: la RAM y el disco están artificialmente caros —un Mac Pro tope de gama se va a 20.000 €— y las fechas que se manejan son 2028 para que los precios se normalicen y 2030 para que Xiaomi y Huawei, ya fabricando con litografía propia, rompan el oligopolio de tres empresas. Mientras tanto, la frase que cerró el episodio: "un Qwen3.8 cuantizado es un Opus 4.6, son seis meses". En uno o dos años la conversación será qué servidor te metes en el homelab para correr en local lo que hoy es frontera.

🔗 Links del episodio:

• Firecracker — La microVM de AWS que hay debajo de media industria
• libkrun — Virtualización con macOS (HVF) y Linux (KVM) como objetivo, la que Néstor quiere probar
• Cloud Hypervisor — Respaldado por Microsoft, con integración nativa en el hipervisor de Windows
• Kata Containers — Lo que usa Aitor para aislar agentes: microkernel de por medio y procesos invisibles desde el host
• Incus — Virtualización y contenedores de Linux Containers. Solo Linux, pero muy bien hecho
• ZeroFS — S3 montado como block storage, con caché en RAM y disco local
• RustFS — Servidor de almacenamiento de objetos compatible con S3 para montártelo en casa
• cal.com/open — El referente de building in public: métricas, finanzas y salarios por posición

---

ℍ𝕠𝕣𝕚𝕫𝕠𝕟𝕥𝕖 𝔸𝕣𝕥𝕚𝕗𝕚𝕔𝕚𝕒𝕝

Te presentamos "Horizonte Artificial", la nueva y flamante sección de nuestra newsletter dedicada exclusivamente a la Inteligencia Artificial. Pero no esperes el contenido convencional que inunda TikTok o YouTube. Aquí, nos sumergiremos en el fascinante mundo del OpenSource, explorando proyectos libres que puedes desplegar en tu propio servidor. Y para guiarnos en esta travesía, contamos con la experticia de Jesús Pacheco, mejor conocido en nuestra comunidad HiveAgile como "Pachecodes". ¡Bienvenidos al horizonte!

---

🌟 TopGit - Resumen Semanal (2026-08-29)

📚 Repositorios Destacados de la Semana

Los siguientes repositorios han sido seleccionados por su relevancia, calidad y métricas de GitHub:

☁️ 🛡️ Servidor de Almacenamiento VaultS3

Categoría: Cloud & DevOps

VaultS3 es un servidor de almacenamiento de objetos ligero y eficiente, compatible con S3. Posee un panel web integrado y funciona con solo 17 MB de RAM, ideal para recursos limitados. Ofrece cifrado en reposo, soporte para múltiples operaciones S3 y administración de usuarios. Sus características incluyen cifrado AES-256-GCM, control de acceso IAM y búsqueda de texto completo. No tiene costos adicionales y se puede utilizar fácilmente, con una comunidad activa de soporte. Es útil para almacenamiento de archivos, copias de seguridad y gestión de datos en aplicaciones web.

📊 Estadísticas de GitHub:

• ⭐ 1,542 estrellas
• 🔄 87 forks
• 👀 10 observadores
• 📝 0 issues abiertos
• 🔤 Principal lenguaje: Go

---

🤖 🧠 Agent Reach: Tu AI con acceso total a la internet

Categoría: IA & Machine Learning

Agent Reach es una herramienta que permite a los agentes de IA acceder y buscar contenido en plataformas como Twitter, Reddit, YouTube y GitHub. Facilita la lectura y búsqueda de información sin API de pago. Se instala y configura fácilmente, ahorrando tiempo en la configuración manual. Ofrece acceso gratuito a APIs, garantiza privacidad al almacenar datos localmente, y permite actualizaciones simples ante cambios. Es un recurso técnico accesible para más usuarios.

---

⚡ 📈 ActivityWatch - Rastreador de Tiempo Automático

Categoría: Productivity

ActivityWatch is an open-source tool that automatically tracks the time spent on various digital activities. Its aim is to collect useful data about time usage while ensuring user privacy, allowing you to control your own data. The application is designed to be extensible and cross-platform, enabling customization according to individual user needs.

📊 Estadísticas de GitHub:

• ⭐ 18,744 estrellas
• 🔄 998 forks
• 👀 124 observadores
• 📝 185 issues abiertos
• 🔤 Principal lenguaje: Python

---

🤖 🤖 FreeToken

Categoría: IA & Machine Learning

FreeToken is a native Mixture-of-Experts (MoE) service engine for edge computing, designed to run large-scale open-weight models on consumer hardware. It leverages heterogeneous edge resources—GPUs, CPUs, host memory, and connections—acting as a unified, elastic inference platform.

Features include fast operation, elastic memory management, semantically-aware caching, and support for various MoE architectures.

Benefits include efficient modeling and execution of intelligent applications on gaming PCs and workstations, compatible with NVIDIA RTX GPUs. It is useful in natural language processing applications and AI models.

📊 Estadísticas de GitHub:

• ⭐ 9,612 estrellas
• 🔄 870 forks
• 👀 82 observadores
• 📝 226 issues abiertos
• 🔤 Principal lenguaje: Python

---

🤖 🤖 llm-d: Inferencia de Alto Rendimiento

Categoría: IA & Machine Learning

llm-d is a high-performance distributed inference service stack optimized for production deployments in Kubernetes. It aims to deliver unmatched performance for large-scale language models across various hardware accelerators. Additionally, it provides tools and optimizations for efficient and reliable traffic management under complex workloads.

---

🔧 🖥️ USBridge Remote

Categoría: Infrastructure

USBridge Remote is a high-performance unified solution for managing remote machines. It combines hardware-level BIOS access with software-based remote desktop in an optimized interface. It's ideal for users needing BIOS control before the operating system loads, integrating natively with USBridge-KVM 2.0 for base-level metal management. Additional features include support for multiple monitors, encrypted P2P integration, and a shared clipboard, enhancing connectivity and operation across various architectures and operating systems.

📊 Estadísticas de GitHub:

• ⭐ 567 estrellas
• 🔄 33 forks
• 👀 13 observadores
• 📝 4 issues abiertos
• 🔤 Principal lenguaje: Go

---

☁️ 🌐 Submariner

Categoría: Cloud & DevOps

Submariner es una herramienta para interconectar redes superpuestas de distintos clústeres de Kubernetes. Funciona de manera independiente del plugin de red (CNI) y permite el uso de túneles cifrados y no cifrados entre los clústeres. Sus características incluyen soporte para múltiples clústeres, integración con CNI, y facilidad de instalación usando herramientas como subctl y Helm. Los beneficios abarcan mejorar la comunicación entre los clústeres y facilitar la gestión de redes en entornos distribuidos. Se utiliza para interconectar microservicios en diferentes clústeres, migrar aplicaciones entre clústeres y optimizar redes en entornos multinube.

📊 Estadísticas de GitHub:

• ⭐ 2,687 estrellas
• 🔄 212 forks
• 👀 52 observadores
• 📝 23 issues abiertos
• 🔤 Principal lenguaje: Go

---

☁️ 🚀 RunSnack: Terminal Instantáneo en tu GPU

Categoría: Cloud & DevOps

RunSnack es una herramienta que convierte cualquier máquina con Docker en un terminal instantáneo. Permite crear conexiones directas y seguras entre usuarios sin la necesidad de cuentas o intermediarios, facilitando el acceso a GPUs para programación y colaboración. Es ideal para compartir recursos de manera rápida y eficiente.

📊 Estadísticas de GitHub:

• ⭐ 4 estrellas
• 🔄 1 forks
• 👀 0 observadores
• 📝 0 issues abiertos
• 🔤 Principal lenguaje: Shell

---

☁️ 🌐 Forgejo-Coolify Bridge

Categoría: Cloud & DevOps

A service that allows Coolify to work with Forgejo repositories by emulating the GitHub API. This enables the use of Forgejo as a source for deploying applications with Coolify without waiting for native support from Forgejo.

📊 Estadísticas de GitHub:

• ⭐ 24 estrellas
• 🔄 6 forks
• 👀 0 observadores
• 📝 2 issues abiertos
• 🔤 Principal lenguaje: JavaScript

---

☁️ ⚙️ WUD - ¿Qué hay de nuevo en Docker?

Categoría: Cloud & DevOps

WUD is a lightweight tool for monitoring and automating container updates. It proactively scans your container environments, detects image updates in public and private registries, conducts semantic version analysis, and alerts you through your preferred notification channels. It can also trigger seamless automatic container updates.

---

📈 Tendencias de la Semana

14 repositorios compartidos · 2.0/día de media

🤖 IA & Machine Learning █████         29%  (4 repos)
📊 Data & Analytics   ██            14%  (2 repos)
☁️ Cloud & DevOps     ██            14%  (2 repos)
☁️ Cloud & DevOps     █              7%  (1 repos)

💡 Análisis de Tendencias

---

16 de 896

Marco creyó que había encontrado un secreto en un Show HN con un punto y cero comentarios. Lo que encontró fue una de las seis casillas de un tablero que explica casi todo lo que ha pasado este mes.

---

Marco llevaba desde julio con el mismo cálculo atascado en la cabeza.

El 26 de julio, Moonshot publicó los pesos de Kimi K3 en Hugging Face. Dos coma ocho billones de parámetros. El primer modelo abierto de la clase de los tres billones. Un coma cinco seis terabytes en disco.

Una semana después, el 3 de agosto, Alibaba sacó Qwen3.8-Max: 2,4 billones de parámetros, unos 95.000 millones activos por token, contexto de un millón.

Marco hizo lo que hace siempre: abrir la calculadora y volver al mismo sitio. Su máquina es un portátil decente y nada más. Una RTX 3060 con 6 GB de VRAM, 16 GB de RAM, un NVMe que va bien. Con eso llega a modelos de unos 20 B cuantizados si no abre nada más. De ahí para arriba, la pared.

Tengo acceso legal a los mejores modelos abiertos del mundo. Y no puedo abrir ninguno.

Ese sábado por la noche estaba barriendo Hacker News, como hace siempre a esas horas. Y encontró un Show HN con 1 punto y 0 comentarios.

Show HN: MoE-Direct — MoE Models far larger than your RAM, on a consumer desktop

Marco lo abrió por costumbre, no por esperanza. Y leyó la frase que le ocupó el resto de la semana:

"Empecé con la idea de que quizá fuera posible aprovechando el hecho de que los modelos MoE usan solo algunos de los expertos, no todos."

Se quedó mirando la pantalla con esa sensación concreta: la de haber tropezado con algo que nadie más ha visto.

Se equivocaba en eso. Y el error resultó ser mucho más interesante que el hallazgo.

---

Dieciséis de ochocientos noventa y seis

Empecemos por el número que debería estar en todas las conversaciones sobre IA local y no está en casi ninguna.

Kimi K3 tiene 896 expertos. Por cada token que genera, activa 16.

Uno coma ocho por ciento del modelo.

Un modelo Mixture-of-Experts no es un modelo. Es un comité enorme del que, en cada turno de palabra, hablan cuatro. En un modelo denso cada token pasa por todos los parámetros, y por eso el modelo entero tiene que estar en memoria: en cualquier momento puedes necesitar cualquier parte. En un MoE hay un router diminuto en cada capa que decide qué expertos despertar, y el resto de los pesos son, para ese token, peso muerto literal.

Y aun así, todos hacemos lo mismo: cargar el 100 % del modelo para usar el 1,8 %.

La razón es sensata. No sabes de antemano qué va a pedir el router, y salir a buscarlo al disco en mitad de la inferencia suena a suicidio de rendimiento.

Toda esta historia va de gente cuestionando esa segunda mitad.

VRAM   →  atención, routing, KV cache      (rápido, pequeño)
RAM    →  caché de expertos calientes      (medio, medio)
NVMe   →  el modelo completo               (lento, enorme)

No metas el modelo en RAM. Déjalo en el NVMe. Cachea solo los expertos que el router pide de verdad. Y como el router elige antes de calcular, tienes una ventana de prefetch gratis: el modelo te dice lo que va a necesitar justo antes de necesitarlo.

Llevamos años intentando que el modelo quepa. Estos tíos han decidido que no hace falta que quepa. Solo hace falta que quepa la parte que estás usando ahora mismo.

---

El lunes, tirando del hilo, Marco descubrió que llegaba tarde

Marco pasó el domingo convencido de haber encontrado un proyecto ignorado. El lunes, buscando si alguien lo había probado con K3, abrió el repositorio de llama.cpp.

Y se encontró una discusión abierta sobre cuál de todas las implementaciones de streaming de expertos merecía entrar en el proyecto.

No había una. Había un montón.

Upstream, en llama.cpp. La PR #25294, de freedomljc, mantiene una caché por capa de "slots" de expertos y, tras el top-k del router, remapea los IDs a slots; lo que falta se carga bajo demanda con un pool de I/O asíncrono. El detalle de cirujano: usa O_DIRECT para saltarse la page cache del sistema operativo, porque cuando el modelo es mucho mayor que la RAM la page cache deja de ayudar y empieza a estorbar. Con GLM-5.2 en Q2_K_XL —254 GB, 256 expertos— y una caché de 90 slots: 5,69 tok/s de prefill, 2,20 de decode, 79 % de aciertos.

En un MacBook. La discusión #27149, del 15 de agosto, ataca el caso extremo: CPU sola, 8-16 GB totales. Lecturas selectivas de trozos de 3 MB directamente del GGUF sin tocar el formato, re-layout contiguo por experto que reduce los fallos de página 36 veces, y pipeline asíncrono de doble búfer. Sobre un MacBook Pro M1 de 16 GB con Qwen3-30B-A3B: 4,7 tok/s.

Como motor independiente. Pulsar: Rust con kernels CUDA, MIT, 212 estrellas. Expertos en NVMe leídos con io_uring a profundidad de cola 32, caché LFU en RAM persistida entre ejecuciones, y reparto multi-GPU que mide el ancho de banda PCIe real de cada tarjeta al arrancar en vez de fiarse de lo que pone en la caja. Sobre una máquina de piezas de consumo —RTX 5060 Ti + 4060 Ti, 30 GB de RAM:

Modelo	Total	Activos	Decode en caliente
Qwen3.6-35B	35B	3B	51,8 tok/s
Hy3 295B	295B	21B	6,0 tok/s
GLM-5.2 743B	744B	40B	2,7 tok/s
TML Inkling 1T	975B	41B	1,6 tok/s

Y el dato más honesto de todos, que Marco agradeció encontrar: para modelos que sí caben, llama.cpp le da una paliza a Pulsar (16,15 tok/s frente a 8,04 con la misma cuantización). El streaming no es mejor. Es lo que haces cuando no hay alternativa.

Marco cerró el portátil el lunes con una sensación distinta a la del sábado. No había encontrado un secreto. Había encontrado la instancia peor posicionada de una idea que persiguen media docena de equipos a la vez.

---

El martes vio el tablero, y ahí cambió todo

Lo que le desatascó fue un vídeo con un título que parecía exagerado: "Qwen3.8-Flash-Next: el fin de los LLM limitados por VRAM".

Alibaba había publicado ese modelo el 26 de agosto, tres días antes. 125.000 millones de parámetros, 6.000 millones activos por token — 512 expertos, 10+1 activos, un 2,1 %. Contexto nativo de 262.144, ampliable a un millón. Y una pieza que a Marco le hizo enderezarse en la silla: 51.000 millones de parámetros de embedding n-gram, veinte millones de bigramas y trigramas en la capa 2, diseñados explícitamente para vivir en la RAM del sistema y no en la GPU, porque son búsquedas deterministas y no cómputo.

El build más pequeño cabe en unos 75 GB de RAM sin necesitar VRAM de GPU en absoluto. Y no es un experimento suelto: es la vista previa de la arquitectura de Qwen4.

Ahí Marco entendió que llevaba una semana mirando la mitad del problema.

Porque el mismo día encontró otro vídeo, este sobre Qwen3.8-27B, el hermano pequeño y denso de la familia. Un modelo al que el streaming de expertos no le sirve absolutamente de nada —no tiene expertos que streamear. Y sin embargo ataca exactamente la misma restricción por el otro lado: de sus 64 capas, solo 16 usan atención completa; las otras 48 usan atención lineal con estado recurrente constante. Traducido: el KV cache no crece según se alarga la conversación.

Dos modelos, la misma empresa, la misma semana. Uno adelgaza los pesos, el otro adelgaza el contexto. Y usan el mismo backbone híbrido en el modelo de 2,4 billones y en el de 27.000 millones — la misma respuesta a escalas separadas por un factor de cien.

Marco cogió papel y dibujó lo que llevaba una semana sin ver:

	Los pesos	El contexto (KV)
Arquitectura del modelo	MoE: 16 de 896 activos	Atención lineal, estado constante
Motor / runtime	Streaming de expertos desde NVMe	Anchor checkpoints del KV
Tú, a mano	Cuantizar	Compactar la conversación

Seis casillas. Una sola guerra: el conjunto de trabajo no cabe en la memoria rápida.

Y de repente todo lo que había leído en un mes tenía sitio. Los seis proyectos de streaming: casilla del centro-izquierda. Qwen3.8-Flash-Next: arriba-izquierda. Qwen3.8-27B: arriba-derecha. Los GGUF de 1 bit de Unsloth, que dejan Kimi K3 en 594 GB conservando —según su propio benchmark— en torno al 78,9 % de la precisión: abajo-izquierda.

¿Y abajo-derecha? Eso lo hace Marco todos los días sin darle un nombre: cuando una conversación con un agente se hace larga, le pide un resumen conciso de lo establecido, abre una sesión limpia y lo pega. La recomendación que circula es hacerlo al 60 % de la ventana, sin esperar al límite.

Llevo dos años compactando conversaciones a mano y resulta que estaba haciendo streaming de expertos. En mi cabeza, y sobre el contexto en vez de sobre los pesos, pero es el mismo movimiento: mantén residente lo que estás usando y saca el resto.

---

La casilla que las une

Si el tablero fuera solo una metáfora bonita, no valdría gran cosa. Lo que lo convierte en algo real es que ya hay un motor haciendo las dos columnas a la vez.

FreeToken es, con diferencia, el proyecto más maduro de todos los que aparecieron estas semanas: 9.600 estrellas, 870 forks, Apache 2.0, Python, Windows y Linux, con soporte nativo para RTX de las series 30, 40 y 50. Se instala con una línea.

Y hace tres cosas que, puestas juntas, dibujan el tablero entero:

• Caché global LRU de expertos con co-ejecución CPU-GPU adaptativa al ancho de banda → columna de los pesos
• Anchor checkpoints semánticos del KV cache y del estado recurrente, para no recomputar contexto en bucles agénticos con llamadas a herramientas → columna del contexto
• Memoria elástica: reasigna VRAM entre la caché de expertos y la memoria de KV en caliente, sin reiniciar el motor → y esto es lo bueno, porque significa que el motor decide sobre la marcha a qué columna dedicarle la memoria rápida

Esa tercera es la que a Marco le pareció el futuro. No es "optimizo los pesos" ni "optimizo el contexto". Es un presupuesto único de memoria rápida que se reparte dinámicamente entre las dos guerras según lo que estés haciendo en ese momento.

Y lo que FreeToken hace con los anchor checkpoints es exactamente lo que Marco hacía copiando y pegando resúmenes: evitar recomputar lo que ya está resuelto. Solo que automático, dentro del motor, y sin que él tenga que acordarse.

Y esto ni siquiera es un tema de IA

Lo que terminó de convencer a Marco de que el tablero era real fue encontrárselo donde no tocaba.

ZeroFS monta objetos de S3 como si fueran un disco de bloques. Parte el volumen en trozos de 64 MB, se trae solo los que estadísticamente vas a necesitar, expulsa los que no caben, y sostiene todo con caché en RAM y en disco local.

RAM          →  caché caliente
Disco local  →  caché templada
S3           →  el volumen completo

Ahí no hay expertos, ni routers, ni tokens. Es almacenamiento. Y es exactamente la misma figura: tres niveles, tráete lo que vas a usar, echa lo que no. Hasta comparte la debilidad —vuela leyendo, penaliza escribiendo, porque la consolidación pasa por un único punto.

Cuando el mismo patrón aparece en un motor de inferencia, en la arquitectura de un modelo, en tu forma de compactar un chat y en un sistema de ficheros que no tiene nada que ver con la IA, deja de ser una técnica de moda.

Esto no es un truco de los que corren modelos. Es cómo se ha resuelto siempre la memoria en informática, y le ha tocado el turno de reaprenderlo a una generación que creía que bastaba con comprar más VRAM.

---

Dónde está de verdad el cuello de botella ahora

Durante años, la conversación sobre IA local giró alrededor de la VRAM. Cuánta tienes, cuánto te cabe, qué cuantización necesitas. La VRAM era la restricción y todo lo demás se ordenaba a su alrededor.

Nada de esto elimina esa restricción. La traslada. Y el sitio al que la traslada tiene otras reglas.

Si lees expertos del disco en cada token, tu velocidad ya no la marca la GPU. La marca cuántos bytes por segundo mueve tu almacenamiento. La documentación de Pulsar lo dice sin rodeos: la velocidad de lectura del disco se convierte directamente en velocidad de generación.

GDDR de una GPU moderna   →  cientos de GB/s
DDR5 de doble canal       →  decenas de GB/s
NVMe Gen5                 →  unidades de GB/s   (~7-11 GB/s medidos)
NVMe Gen3                 →  ~3,5 GB/s

De ahí una consecuencia que casi nadie tiene interiorizada:

Para IA local a esta escala, tu próxima mejora útil probablemente no es una GPU. Es un NVMe más rápido — y en Linux, io_uring y O_DIRECT bien usados.

Marco lleva años diciéndole a la gente que gaste el dinero en VRAM. Esta semana ha tenido que matizarlo, y le ha dado bastante rabia.

---

El error de leer 2 tok/s como un fracaso

La reacción instintiva a estos números es descartarlos. Marco la tuvo unos treinta segundos.

Dos tokens por segundo son 7.200 tokens por hora. Una respuesta larga y densa de un modelo frontera —un análisis técnico completo, una revisión de arquitectura, un informe— rara vez pasa de 2.000 tokens de salida. Un cuarto de hora.

Un cuarto de hora es un desastre si estás chateando. Es irrelevante si lanzas el trabajo y te vas.

CHAT INTERACTIVO    → necesitas 20-30 tok/s para no odiar la vida
TRABAJO ASÍNCRONO   → 2 tok/s va perfectamente
                      Cron a las 3 AM. Cola de tareas. Batch nocturno.
                      Nadie está mirando la pantalla.

Marco tiene exactamente ese trabajo. Resúmenes de los feeds de la semana. Clasificación de tickets acumulados. Primeras pasadas sobre documentación larga. Revisiones que se lanzan al terminar la jornada y están listas por la mañana.

Nada de eso necesita velocidad. Todo eso necesita que no salga de casa.

Ahí está el argumento de verdad, y no tiene que ver con el rendimiento. Marco tiene clientes cuyos datos no pueden ir a una API de terceros. No por paranoia: por contrato. Hasta ahora, para esos clientes, su techo era un modelo pequeño. Ahora el techo es un modelo de frontera que tarda toda la noche.

Prefiero un modelo enorme que tarda ocho horas y no sale de mi máquina, que uno mediocre e instantáneo que tampoco puedo usar porque el cliente no me deja.

---