La métrica más reveladora para la IA local no está impresa en grande en la caja. Se llama ancho de banda de memoria, se mide en gigabytes por segundo, y decide si un modelo corre fluidamente en tu máquina o tropieza lentamente hasta morir. Quien quiera probar la IA en serio y se apoye en las cifras de TOPS y NPU busca en el lugar equivocado. La potencia de cálculo se ha abaratado. El ancho de banda es el recurso escaso.

Suena contraintuitivo, y lo es. Por eso vale la pena mirar de cerca — no las clasificaciones de benchmark, sino lo que realmente ocurre dentro del chasis cuando un modelo compone token a token.

Por qué gana el ancho de banda

Los modelos de lenguaje funcionan de manera autorregresiva. Cada palabra siguiente aparece solo después de que todo el peso generado hasta entonces haya atravesado la memoria una vez. Las unidades de multiplicación no esperan matemática pesada — esperan memoria. Entiéndase esto, y se entiende por qué una GPU con poco VRAM no sirve frente a un modelo grande por rápido que ticten sus sombreadores: el modelo debe caber y circular, en cada paso.

A grandes rasgos: los tokens por segundo aproximan el ancho de banda de memoria dividido por el tamaño del modelo. Un modelo de setenta mil millones de parámetros en cuantización de 4 bits ocupa casi cuarenta gigabytes. Por una tubería de 273 GB/s salen, en teoría, unos siete tokens por segundo — menos sobrecarga, menos caché KV, menos lo que el sistema operativo haga al lado. Con una DDR de portátil corriente a 64 GB/s el mismo cálculo se vuelve un ejercicio de paciencia. Ambas veces los núcleos de cómputo están inactivos. La diferencia reside únicamente en lo ancha que sea la tubería.

Precisamente por eso han cobrado interés últimamente ciertos chips que nadie habría puesto en una lista de “aceleradores de IA”.

Dos chips que nadie tenía en la lista

Considérese primero el Apple M4 Pro. Apple especifica alrededor de 273 GB/s de ancho de banda de memoria unificada — almacenamiento compartido para CPU y GPU por igual, configurable hasta 48 gigabytes. Nada en él es un acelerador de centro de datos. Pero como la memoria está tan ampliamente conectada y resulta igualmente visible para CPU y unidad gráfica, los modelos medianos corren con sorprendente fluidez. Eso no es magia de marketing; es física.

Segundo, el AMD Ryzen AI Max+ 395, nombre en clave Strix Halo. AMD especifica hasta 256 GB/s, también unificado, y la plataforma admite hasta 128 gigabytes de LPDDR5X. Se encuentra en mini-PCs compactos, portátiles de estación de trabajo y dispositivos como el Framework Desktop. Una vez más: ni H100 ni máquina milagrosa. Pero quien pueda colocar un modelo grande íntegramente en memoria rápida mientras una tarjeta competidora se ahoga en swap fuera del núcleo obtiene de pronto rendimientos realistas por un dinero que en otra parte apenas compra una fracción de una tarjeta profesional.

La honestidad es aquí obligatoria. Ninguno de los dos chips es magia. El térmico bajo carga sostenida es real, sobre todo en carcasas estrechas. La madurez de controladores y runtimes difiere: el camino Metal de Apple es liso; la ruta ROCm/OpenCL de AMD ha mejorado pero sigue siendo más áspera que el mundo CUDA contra el cual todo se mide. Y desde luego, un único chip de escritorio queda a millas de lo que entrega una tarjeta H200 o B200 en un rack. Afirmar que el hardware de consumo es “tan bueno” carece de sentido. Afirmar que es irrelevante también.

Una observación seca: los diagramas de benchmark mienten rutinariamente, porque miden la latencia hasta el primer token con caché caliente — no un martes por la tarde, con seis pestañas abiertas y medio modelo swapeado. Planifica la IA bajo carga, no en condiciones de laboratorio.

Fase uno: hacer clic y maravillarse

El punto de entrada natural discurre por aplicaciones de escritorio. Ollama descarga un GGUF; LM Studio ofrece una interfaz pulcra para navegar modelos, comparar cuantizaciones, probar. Eso es valioso. Es la vía más rápida para sentir cómo se comporta un modelo 8B, 13B o 32B, dónde se curva la calidad, dónde el 4 bits sigue aceptable y dónde ya no.

Esta fase es lúdica, y así debe ser. Quien grite “¡arquitectura!” en este punto pierde el de vista: hay que sentir lo que hacen las herramientas antes de formalizarlas. Pero los límites aparecen pronto. Todo queda atado a una máquina, un usuario, una sesión gráfica. En cuanto una segunda persona quiere el modelo, en cuanto un script nocturno deba inferir automáticamente, la GUI se vuelve un obstáculo. El acceso por red parece pegado, no diseñado.

Fase dos: el escritorio se vuelve servidor

En algún momento eso deja de bastar. Se quiere un endpoint que toda la oficina, toda la red doméstica, todas las automatizaciones puedan alcanzar. Se vincula Ollama o un runner ligero a ::, se pone OpenWebUI delante — múltiples usuarios, autenticación, selección de modelos, charla con documentos — y se apunta herramientas como opencode, el agente de codificación por línea de comandos, hacia el endpoint local compatible con OpenAI.

De pronto la estación de trabajo es infraestructura. Cada editor, cada compañero, cada pipeline habla con la misma dirección. Eso supone un cambio de paradigma genuino aunque técnicamente parezca pequeño: una aplicación se ha vuelto servicio. Y con el servicio llegan los deberes familiares de la infraestructura — cifrado de transporte, autenticación, registro, actualizaciones, gobernanza de modelos. Quien da ese paso ha dejado de trastear y ha empezado a operar. Muchos lo advierten solo cuando alguien más accede al modelo por primera vez.

Fase tres: cuando deja de ser un juguete

La ambición creciente trae el siguiente nivel de herramientas. vLLM es el motor que hizo económica la inferencia en GPU — batching continuo, PagedAttention, alto rendimiento, manejo limpio de muchas solicitudes simultáneas. LiteLLM se coloca delante como proxy y enrutador: una API uniforme con forma de OpenAI sobre muchos backends, gestión de claves, rutas de respaldo, enrutado por presupuesto, integración con sistemas de métricas y logs. Y Bifrost es la clase de proyecto que uno encuentra en cuanto empieza a agrupar y compartir capacidad de GPU entre cargas o inquilinos en vez de dedicar una tarjeta a un único proceso — utilización frente a máquinas heroicas.

Estas herramientas premian hardware mayor: varias GPU por nodo, conexiones NVLink, un rack en lugar de un escritorio. Pero también castigan la negligencia con más fuerza. El batching continuo ayuda solo cuando llegan suficientes solicitudes a la vez — para el usuario potente aislado la sobrecarga nunca se amortiza. Un enrutador no sirve de nada con un backend lento detrás. El pooling solo funciona cuando equidad, profundidad de cola y arranques en frío se gestionan en serio. En resumen: en este punto termina la experimentación y comienzan los sistemas distribuidos. Monitorización, planificación, atribución de costes, estrategias de actualización — temas conocidos de la operación clásica, ahora parte inesperada de la IA.

Muchos aficionados al homelab chocan con este muro y eligen entre dos caminos: retroceder a una sola máquina cómoda que basta — o dar conscientemente el paso hacia una operación seria. Ambos legítimos. Creer que un clic más lo salvará es un error.

El arte difícil: pensar hardware y software juntos

Aquí reside la dificultad real. Ni el hardware solo ni el software solo ganan. El emparejamiento lo es todo.

Compra una GPU enorme y condúcela mediante un runner de flujo único sin batching y desperdicias el noventa por ciento de su capacidad. Levanta vLLM para un puesto con un único usuario y pagas sobrecarga sin retorno. Comprime un modelo grande en 4 bits donde 8 bits era cualitativamente necesario y ahorras memoria y pierdes precisión. A la inversa, haz correr todo en FP16 porque “mayor suena mejor”, cabe menos en VRAM, y se congela. La cuantización no es un interruptor sino un dial. Refrigeración, ruido y consumo eléctrico permanente deciden si un dispositivo puede vivir en el salón o pertenece al laboratorio del sótano. La amortización entra en el cálculo, no en la nota al pie.

Y luego el elefante que nadie gusta ver: los precios de las APIs. Parecen baratos — céntimos por millón de tokens — hasta que el volumen escala. Los bucles agénticos multiplican las solicitudes diez, cien veces. Tormentas de reintentos, pasadas de recuperación redundantes, prompts de sistema verbosos reenviados en cada turno, un modelo mal dimensionado para una tarea trivial: un experimento barato se vuelve una factura mensual de cuatro cifras. El método determina el precio más que la tarifa.

El autohospedaje invierte esto: coste fijo en lugar de variable. En algún punto sale rentable económicamente, pero solo con una utilización decente. Una GPU que holgazanea todo el día combina las desventajas de ambos mundos — inversión y coste de oportunidad. El romanticismo no ayuda aquí. Hace falta aritmética, y la honestidad de valorar la propia utilización de modo realista en lugar de idealizarla.

Razones para celebrarlo

Pese al esfuerzo, hay motivo para celebrar, y pesa: toda la escalera descrita arriba es open source. Ollama, llama.cpp, vLLM, LiteLLM, Bifrost, OpenWebUI, opencode — construidos por la comunidad, inspeccionables, auditables, susceptibles de bifurcación. Nadie puede quitártelos, nadie puede reescribir las condiciones de la noche a la mañana sin dejarte la opción de quedarte quieto.

Un matiz corresponde aquí: LM Studio es práctico, pero no es libre en sentido OSI. Gratuito para uso personal, con licencia comercial en caso contrario. Quien valore software consistentemente libre elige el camino de Ollama y llama.cpp. No es dogma; es una aclaración que conviene conocer antes de construir arquitecturas encima.

Visto más en conjunto: la IA ha sacudido nuestras vidas profesionales — todas, de alguna manera. Llegó, y se queda; de ello estoy seguro. Negarlo es nostalgia. Pero la ingenuidad es justo lo opuesto e igual de errónea. La comodidad oculta dependencia, y oculta costes que suben en silencio. La postura informada es: usar la IA deliberadamente, en tus propios términos, comprendiendo lo que cuesta, lo que sabe hacer y dónde falla. No es una postura contra la tecnología. Es una postura a favor de tu propia capacidad de acción.

Qué tiene que ver esto con libcom.de

Desde hace un cuarto de siglo yo — Jochen Demmer, libcom.de — construyo sobre infraestructura open source. En los últimos años eso incluye cada vez más operar pilas de IA en hardware propio: análisis de logs, redacción, revisión de código, sistemas de asistencia internos, búsqueda documental. No como demos, sino en la práctica diaria y en sistemas de clientes.

De esa práctica provienen juicios que ningún tutorial enseña: dónde se inclina el equilibrio entre API y explotación propia, cómo se ajusta el dial cuantización-calidad para cada carga, qué arquitectura de red y seguridad requiere un endpoint de inferencia expuesto limpiamente en la empresa — y dónde se traza la frontera entre un juguete de homelab y un servicio mantenido. La tarea más frecuente no es adquirir hardware, sino emparejar el hardware adecuado con la estrategia de servir adecuada, en vez de comprar primero una caja cara y buscar luego software que la justifique.

Si te preguntas si la IA local tiene sentido para tu entorno, qué hardware se aviene con el software planeado, y qué aspecto tendría una pila que no se derrumba a los tres meses: escribe a contact@libcom.de. Hacemos un inventario honesto — abiertamente, sin presión comercial, con la mirada en lo que dura a largo plazo.

Empieza con curiosidad y termina, para quien se lo toma en serio, en infraestructura. Entre medias se encuentra el oficio más fino que hoy se reinventa — pieza a pieza, en tu propio hardware, con herramientas abiertas.

Aviso: Este artículo ofrece orientación general sobre elecciones de hardware y software y consideraciones de costes, y no sustituye ni consejo de adquisición ni asesoría jurídica. Las cifras de rendimiento y precios son ilustrativas y pueden variar según configuración, estado de controladores y evolución del mercado; todos los datos se facilitan sin garantía.