Tú hablas. Esperas. El sistema decide si has terminado. Transcribe el audio. Piensa. Genera una respuesta. La convierte en voz. Y entonces te responde.

Funciona, pero no se parece demasiado a una conversación humana. Esto es lo que conocemos como arquitectura en cascada.

Las personas no esperamos a que haya un silencio perfecto para empezar a entender. Podemos asentir mientras alguien habla, detectar una interrupción, cambiar de idea a mitad de frase o responder con un “sí, sigue” sin convertirlo en un turno formal de conversación.

OpenAI ha presentado GPT‑Live, su tercera generación de sistema de voz, y lo interesante no es solo el modelo. Es la arquitectura que hay detrás: una arquitectura full duplex que es capaz de escuchar y hablar al mismo tiempo y esto es mucho más relevante de lo que parece.

TL;DR

En este artículo te explico qué cambia una arquitectura full duplex en los agentes de voz y por qué puede ser una referencia útil para diseñar sistemas de IA en tiempo real.

• Los sistemas de voz tradicionales funcionan por turnos: primero escucha, después piensa y luego habla.

• GPT‑Live elimina el detector de final de turno del camino principal del audio y mantiene un flujo continuo.

• El audio en vivo, el razonamiento profundo y las llamadas a herramientas se ejecutan en caminos separados.

• La conversación puede seguir mientras otro modelo busca información, razona o consulta una herramienta.

• El reto ya no es solo servir un modelo rápido sino que hay que mantener cada fragmento de audio llegando a tiempo.

¿Cómo funciona un asistente de voz de IA? - Arquitectura en cascada

La primera generación de asistentes de voz seguía una cadena como la siguiente:

Audio del usuario
  → transcripción
  → modelo de lenguaje
  → texto de respuesta
  → síntesis de voz

Este enfoque se conoce como arquitectura en cascada. Cada parte espera a la anterior y tiene sus ventajas como que cada componente es fácil de entender, sustituir y medir. Puedes cambiar el proveedor de transcripción o usar otro modelo de texto sin rehacerlo todo.

Peeero tiene un precio y es que la latencia se acumula.

Además, en la transcripción se pierden cosas. El tono, las pausas, la duda o el énfasis no siempre sobreviven cuando el audio se reduce a texto. Y, sobre todo, el sistema necesita decidir cuándo has terminado de hablar antes de hacer nada útil.

Ahí aparece el detector de turnos, un pequeño modelo que intenta identificar si la persona ya ha acabado de hablar: si se equivoca y decide demasiado pronto, te interrumpe. Si espera demasiado, parece lento.

Es una pieza incómoda porque está tomando una decisión social con una señal imperfecta: unos milisegundos de silencio pueden ser el final de una frase, una pausa para pensar o el momento en que alguien va a continuar.

¿Qué significa Full Duplex?

Full duplex significa que la comunicación puede ir en ambas direcciones a la vez. En una llamada telefónica puedes hablar mientras escuchas. Eso es full duplex.

Un walkie-talkie, en cambio, funciona de forma parecida a un sistema por turnos: habla uno, luego habla el otro. No hay conversación simultánea.

GPT‑Live lleva esta idea al modelo de voz. El audio entra continuamente al modelo y la voz generada sale de forma continua. El modelo puede seguir escuchando aunque esté hablando.

Esto cambia una decisión fundamental porque ya no hace falta que un detector externo dé permiso al modelo para empezar a inferir. El propio modelo participa en la conversación y puede manejar mejor cosas como estas:

• Empiezas a hablar mientras la IA está respondiendo.

• Dices “espera, espera” para corregir una petición.

• Haces una pausa larga a mitad de una explicación.

• La IA responde con una confirmación corta mientras sigues explicando el problema.

No significa que el sistema entienda siempre perfectamente las reglas de una conversación humana porque eso sigue siendo difícil pero si que elimina una frontera artificial. Ya no hay que convertir toda interacción en bloques cerrados de “usuario habla” e “IA responde”.

Dos caminos de audio en paralelo: delegación de tareas

En un producto de voz, una llamada lenta a una API no es simplemente una respuesta lenta. Puede convertirse en un silencio raro, un corte o un audio entrecortado. Por eso OpenAI separa la arquitectura en dos caminos: uno rápido y uno lento.

El camino rápido: audio en directo

Este es el camino que no puede bloquearse. Aquí el micrófono del usuario está siempre abierto siguiendo una capa de transporte de baja latencia. Aquí el trabajo es mantener el flujo de audio. Cada fragmento tiene que llegar cuando toca.

OpenAI usa WebRTC como base de transporte. WebRTC está pensado para comunicaciones en tiempo real y puede gestionar pérdidas de paquetes, cambios de red o pequeñas variaciones de reloj sin dejar huecos evidentes en el audio.

La compañía también explica que trasladó el frontend de medios y parte de la inferencia de Python con asyncio a Go. Según OpenAI, el percentil 95 de la entrega de audio del nuevo sistema igualó al percentil 50 del sistema anterior. (los momentos malos del sistema nuevo se parecían a los momentos habituales del anterior).

Ese dato no prueba que Go sea mejor que Python para cualquier proyecto (esa sería una conclusión bastante pobre), lo que demuestra es que, cuando cada frame de audio importa, el comportamiento predecible bajo carga importa tanto como la media.

El camino lento: pensar, buscar y usar herramientas

Ahora imagina que preguntas:

“¿Puedes revisar las ventas del último trimestre y compararlas con el presupuesto?”

Una respuesta natural puede empezar antes de tener el análisis completo:

“Sí, déjame revisar los datos…”

Mientras mantiene la conversación, el sistema puede consultar una base de datos, lanzar una búsqueda o pedir a un modelo más capaz que haga el análisis.

En GPT‑Live, este trabajo ocurre de forma asíncrona. El modelo de voz puede delegar una tarea a otro modelo como GPT‑5.5 según el artículo de OpenAI, sin bloquear el canal de audio.

La separación evita que una herramienta lenta congele la conversación. Si el CRM tarda tres segundos, su resultado llegará tarde pero el usuario no debería escuchar tres segundos de vacío porque el sistema decidió esperar.

La propuesta de OpenAI separa dos capacidades:

• Un modelo de voz rápido que gestiona el ritmo de la conversación.

• Un modelo más potente que se encarga del trabajo profundo cuando hace falta.

El modelo de voz no tiene que resolver una consulta compleja antes de decir una primera frase útil. Y el modelo de razonamiento no tiene que competir con la exigencia de producir audio de forma continua.

¿Cómo se convierte un flujo continuo de voz en mensajes?

El modelo de voz trabaja con audio continuo. Pero las interfaces, los sistemas de analítica, los registros de auditoría y muchas reglas de seguridad siguen necesitando mensajes discretos. Alguien tiene que decidir dónde empieza y termina cada intervención.

OpenAI explica que mantiene dos versiones de la conversación:

• Una vista provisional, que puede actualizarse mientras llega más audio.

• Un registro definitivo, para cuando ya hay suficiente certeza sobre quién dijo qué y cuándo.

Esto es importante porque las conversaciones reales se solapan. La IA puede decir “ajá” mientras hablas. Tú puedes intervenir a mitad de su frase. Puede haber una palabra mal transcrita que se corrige unos instantes después.

Si guardas cada fragmento demasiado pronto, el historia de la conversación queda roto y confuso. Si esperas demasiado para confirmar cada mensaje, retrasas todo lo que depende de ese texto: la interfaz, las herramientas, las métricas o la moderación.

¿Cómo gestiona OenAI la latencia en el modo de voz?

Cuando pulsas el botón para empezar una conversación de voz, el sistema todavía tiene trabajo por delante: crear la sesión, negociar la conexión, establecer el canal de medios y empezar a enviar audio.

OpenAI ha trabajado en ese arranque con una variante de WebRTC llamada WARP, diseñada para reducir los viajes de ida y vuelta necesarios al iniciar la conexión. Según la compañía, pasa de seis rondas de red a una.

Muchas veces nos obsesionamos con la latencia del modelo cuando lo importante puede ser:

• La red.

• El arranque de sesión.

• El procesamiento de audio.

• Las colas.

• Los servicios externos.

• La distancia física a la región donde se ejecuta la inferencia.

Un sistema de voz se percibe como rápido o lento por el conjunto entero. No por el tiempo que tarda un único modelo en generar tokens.

5 Tips que aplicar si construyes agentes de voz

No hace falta replicar toda la infraestructura de OpenAI para quedarte con las ideas importantes.

1. Separa lo que debe ocurrir ya de lo que puede esperar: El audio, las confirmaciones cortas y la detección de interrupciones pertenecen al camino rápido.

2. Diseña respuestas intermedias con sentido: Decir “un momento” por sistema es una mala experiencia. Pero una respuesta breve que explique qué está haciendo el agente sí puede mantener el contexto: “Estoy comprobando las reservas de mañana” o “Voy a revisar el estado del pedido”.

3. Mide el audio, no solo las peticiones: En un backend tradicional puedes mirar latencia media, errores y rendimiento de la GPU. En voz necesitas además saber si los frames llegan a tiempo, dónde se forman colas, cuánto tarda en empezar una sesión y qué ocurre cuando la red se degrada. La pregunta útil no es “¿cuántas peticiones por segundo soportamos?”, sino “¿cuántas conversaciones simultáneas podemos mantener sin que el audio se rompa?”.

4. Trata las herramientas como una fuente de variabilidad: Una herramienta externa puede ir rápida durante semanas y tardar cuatro segundos justo en el peor momento. Pon límites de tiempo, prepara rutas alternativas y deja claro qué hacer si el resultado llega tarde. El modelo de voz debe saber continuar la conversación sin inventarse una respuesta.

5. Prueba conversaciones largas y redes imperfectas: Una demo de dos minutos en una Wi‑Fi estable no descubre los problemas importantes. Hay que probar reconexiones, sesiones largas, cambios de red, usuarios que interrumpen, herramientas lentas y picos de tráfico. OpenAI cuenta que sus pruebas silenciosas con tráfico real revelaron saturaciones de componentes auxiliares que no habían aparecido en las pruebas de carga. Menudo recordatorio de que la GPU no es todo el sistema.

Referencias técnicas

• How we built a realtime system for responsive voice AI in six months: artículo de ingeniería de OpenAI sobre GPT‑Live, su modelo full duplex, la delegación asíncrona y la infraestructura de baja latencia.

• Realtime and audio: documentación oficial de OpenAI sobre capacidades y guías para experiencias de audio y tiempo real.

• WebRTC: Real-Time Communication in Browsers: especificación del estándar WebRTC, la base de transporte de baja latencia mencionada en el artículo.

Hay un tema al que se suele dar por sentado cuando se habla de agentes de código y es la caché de prompts. Se trata como un detalle de optimización, un ahorro de céntimos, pero en una sesión larga es la pieza que decide si el coste es razonable o se dispara.

Earendil, la empresa detrás del agente de código Pi, publicó hace poco un análisis bastante completo sobre cómo funciona el prompt caching y me ha parecido un buen punto de partida para explicarlo, con sus implicaciones para cualquiera que construya o use un agente.

TL;DR

El prompt caching determina si un agente reutiliza el trabajo de cómputo de turnos anteriores o lo repite entero, y eso cambia el coste, la latencia, y hasta el diseño de las herramientas del agente.

• Un modelo guarda, para cada token procesado, un par clave-valor por capa de atención. Ese estado (la caché KV) es lo que evita recalcular todo el historial en cada turno.

• Existen dos formas de guardar esa caché: pegada a la GPU que la calculó (afinidad de sesión) o repartida entre varias máquinas (caché distribuida), con trade-offs distintos entre velocidad y flexibilidad.

• Un cambio pequeño, como añadir una herramienta nueva o reordenar el listado de herramientas, puede invalidar toda la caché de una sesión de horas.

• La mayoría de proveedores, Anthropic incluido, usan cachés con un TTL corto (5 minutos por defecto). Ua pausa para comer o para revisar un build puede hacerte pagar el mismo prefijo otra vez entero.

• Borrar contexto antiguo para ahorrar tokens tiene un coste de caché que muchas veces supera el ahorro, así que podar agresivamente no siempre compensa.

¿Qué es y qué guarda exactamente una caché KV?

Un transformer procesa un prompt en dos fases. En la fase de prefill lee todos los tokens de entrada y calcula, para cada uno, el estado de atención de cada capa. En la fase de decode genera los tokens de salida, uno detrás de otro.

En cada capa de atención, cada token procesado produce dos vectores: una clave y un valor. Cuando el modelo procesa un token nuevo, compara su consulta (query) contra las claves de todos los tokens anteriores para decidir cuánto peso darle a cada uno, y con esos pesos construye una mezcla de los valores correspondientes. La clave es contra qué comparas, el valor es lo que recuperas, aunque aquí no hay coincidencia exacta como en un diccionario, es más una búsqueda difusa por similitud.

Esas claves y valores se guardan para que el siguiente token generado pueda mirar hacia atrás sin tener que recalcular nada de lo anterior. Eso es la caché KV.

Fíjate en lo que implica esto para un agente de código: cada turno vuelve a enviar el system prompt, las herramientas, el historial completo y el resultado de la última herramienta, más un poco de contenido nuevo. Si el prefijo (todo menos ese trocito nuevo) coincide token por token con una petición anterior, el proveedor puede reutilizar el cálculo ya hecho y solo procesar lo nuevo. Si un solo token cambia en medio del historial, todo lo que va después de ese punto deja de coincidir y hay que recalcularlo desde ahí.

¿Dónde vive esa caché? Afinidad de sesión frente a caché distribuida

Para que una caché sirva de algo tiene que estar en algún sitio localizable cuando llega la siguiente petición. Los sistemas de inferencia resuelven esto de dos maneras.

La más simple es la afinidad de sesión: la caché se queda en la GPU que la calculó, y el router manda la siguiente petición de esa misma sesión a esa misma máquina. Es rápido cuando funciona y apenas necesita infraestructura adicional, pero ata la sesión a un worker concreto. Si ese worker se satura, se reinicia, o el balanceador decide que repartir carga es más importante que conservar esa caché, la pierdes.

La alternativa es distribuir la caché: guardar los bloques KV en otra capa de memoria, o hacerlos accesibles desde varias máquinas, de forma que la petición no dependa de una GPU concreta. Gana en flexibilidad de scheduling y en recuperación ante fallos, pero mover, indexar y desalojar esos bloques es en sí mismo un problema de sistemas nada trivial.

No hay una opción objetivamente mejor. Cada proveedor mezcla memoria de GPU, memoria de host, almacenamiento local y remoto, y políticas de desalojo distintas. Lo que sí conviene saber como usuario de la API es que ninguna de las dos garantiza que tu caché siga viva cuando la necesites.

Una sesión no es una lista, es un árbol

Aquí hay un matiz que se pasa por alto casi siempre. Muchos agentes de código no representan una conversación como una lista lineal de mensajes, sino como un árbol donde puedes retroceder a un punto anterior y continuar por otra rama, sin borrar la rama original.

El problema es que, aunque todas esas ramas compartan el mismo identificador de sesión de cara al router, de cara a la caché de prompts son secuencias de tokens distintas con solo un solapamiento parcial de prefijo. Si saltas a una rama que se separó hace poco, puede que se reutilice casi todo lo anterior. Si saltas a una rama que se separó al principio de la conversación, puede que solo se aproveche el system prompt y las primeras herramientas, y todo lo demás haya que recalcularlo.

El caso contrario también existe: puedes crear una sesión nueva que en la práctica arrastra el mismo contexto que una anterior, y si el sistema de routing solo identifica sesiones por su ID, nunca se da cuenta de ese solapamiento y desperdicia caché reutilizable.

Caché explícita frente a caché automática

Las APIs de los proveedores de IA exponen esto de dos formas distintas.

Anthropic usa puntos de caché explícitos con cache_control. Tú marcas, dentro de la petición, el final del bloque estable (system prompt, herramientas, la última parte cacheable de la conversación), y el servidor escribe o busca la caché hasta ese punto. Algo así:

{
  "model": "claude-sonnet-4-5",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "Eres un agente de código. Usa las herramientas disponibles para leer, editar y ejecutar archivos.",
      "cache_control": { "type": "ephemeral", "ttl": "1h" }
    }
  ],
  "tools": [ { "name": "read_file", "description": "..." } ],
  "messages": [ { "role": "user", "content": "Arregla el test que falla en auth.py" } ]
}

Ojo con un detalle que se suele pasar por alto: en Anthropic no solo el punto de corte es explícito, también lo es el precio. Escribir en la caché cuesta más que un input normal, y tú eliges cuánto tiempo quieres retenerla (5 minutos o 1 hora, con precios distintos). En el momento de escribir este post Anthropic trataba con estos multiplicadores:

Por qué añadir una herramienta nueva te puede destrozar la caché

Las definiciones de herramientas normalmente van antes de la conversación dentro del system prompt de cara al modelo. Sus nombres, descripciones y esquemas JSON son texto de entrada como cualquier otro. Añadir una herramienta, quitar una, cambiar un esquema, o simplemente serializarlas en otro orden, puede mover el primer punto de desajuste muy cerca del principio del prompt, y todo lo que viene después de ese punto deja de coincidir con la caché anterior.

Esto sorprende mucho en sistemas de plugins o catálogos de herramientas al estilo MCP. Cargar una herramienta solo cuando hace falta suena eficiente, porque mandas menos esquemas al principio. El problema es que, en la mayoría de modelos, ese nuevo listado ampliado invalida toda la conversación cacheada que venía detrás. Ahorrarte unos pocos tokens de esquema puede obligarte a reprocesar decenas de miles de tokens de conversación.

Algunas APIs de modelos más recientes soportan carga aditiva de herramientas: una herramienta nueva se hace disponible a partir de un resultado de herramienta concreto dentro de la conversación, en vez de insertarse en el listado original. Si el cambio es puramente aditivo, el prefijo antiguo no se toca. La palabra clave aquí es aditivo: quitar herramientas, sustituir un listado por otro, o tocar cualquier fragmento anterior del prompt sigue rompiendo la caché igual.

El coste real de un fallo de caché

Imagina una sesión con 60.000 tokens de historial y una petición corta nueva. Cuando la caché funciona, casi todo ese historial se cobra al precio reducido de lectura de caché, y solo lo nuevo se procesa al precio normal. Cuando la caché falla, el proveedor tiene que reprocesar los 60.000 tokens enteros al precio normal, y puede que además cobre por volver a escribirlos en caché. Por eso un mensaje tan corto como “continúa” puede salir caro justo después de que caduque la caché: en una sesión larga, releer el historial antiguo cuesta más que generar la respuesta siguiente.

Esto también genera incentivos poco evidentes. Al usuario le interesa un buen ratio de aciertos porque baja coste y latencia. Al operador de la inferencia también, porque menos prefill significa servir más peticiones con el mismo hardware. Pero un intermediario que factura por tokens de input al precio sin descuento puede acabar generando una factura mayor precisamente cuando falla la caché, así que el rendimiento de caché debería ser algo visible, no algo que solo intuyes mirando la factura del mes.

¿Compensa podar el contexto para ahorrar tokens?

Es tentador controlar el coste borrando resultados de herramientas antiguos o reescribiendo el historial. A veces es necesario, sobre todo cerca del límite de contexto. Pero borrar algo del medio del historial cambia el prefijo justo en ese punto, así que todo lo que sobrevive después puede tener que reprocesarse entero.

Una forma simple de verlo:

coste único de reescribir  ≈ tokens supervivientes × (precio sin caché − precio de lectura de caché)
ahorro futuro por turno    ≈ tokens eliminados × precio de lectura de caché

El coste de reescribir un contexto largo cacheado puede superar de sobra el ahorro futuro de quitar unos pocos tokens que de todas formas se estaban cobrando barato. Y hay una segunda razón, menos de hoja de cálculo: los resultados de herramientas antiguos suelen contener la evidencia que el modelo usó para decidir algo más adelante, así que borrarlos puede empeorar el comportamiento aunque un resumen conserve la idea general.

Dicho esto, podar sí compensa en otros contextos: si trabajas con proveedores que no descuentan bien los aciertos de caché, o si por lo que sea no consigues buenos ratios de acierto, reducir contexto mejora la capacidad del router para repartir carga entre proveedores, precisamente porque las cachés no se pueden transferir de uno a otro.

Referencias técnicas

• Prompt Caching In Agents (Earendil): el análisis original sobre cómo el diseño de caché de KV afecta al coste, la latencia y el diseño de herramientas en el agente de código Pi.

• Prompt caching (Claude Platform Docs): documentación oficial de Anthropic sobre cache_control, TTLs de 5 minutos y 1 hora, y precios de lectura y escritura de caché.

TL;DR

El inference engineering es la disciplina que permite ejecutar modelos de IA en producción de forma eficiente para optimizar la latencia, el rendimiento y el coste computacional.

• El proceso de generación se divide en dos fases con cuellos de botella opuestos: el prefill, limitado por la capacidad de cálculo, y el decode, limitado por el ancho de banda de la memoria de la GPU.

• Técnicas como el batching y el prefix caching ayudan a maximizar el uso del hardware agrupando peticiones simultáneas y reutilizando el contexto procesado previamente.

• La cuantización permite reducir el peso del modelo en memoria bajando la precisión matemática de los datos, lo que acelera tanto el cálculo como la transferencia de información.

• Modelos avanzados utilizan speculative decoding para adivinar múltiples tokens a la vez usando un modelo más pequeño y validarlos en bloque con el modelo principal.

• Las arquitecturas a gran escala separan físicamente el hardware dedicado al prefill del dedicado al decode para escalar cada fase según sus necesidades específicas de tráfico.

El auge del inference engineering

Hace apenas tres años el inference engineering era una especialidad practicada casi exclusivamente dentro de los grandes laboratorios de inteligencia artificial. El trabajo recaía sobre un grupo reducido de ingenieros que construían modelos cerrados que el resto de la industria consumía a través de llamadas a una API. Ese panorama ha cambiado por completo desde la explosión de los modelos abiertos.

Hugging Face, el registro público de referencia para modelos de IA, aloja actualmente más de dos millones de modelos abiertos. Esto representa aproximadamente 25 veces el volumen de lo que existía hace 5 años. Lanzamientos abiertos recientes como DeepSeek V3 han cerrado la brecha de capacidad operativa con los modelos privados, dando a las empresas una opción real entre pagar por una API cerrada o ejecutar un modelo abierto en sus propios servidores.

Alojar tus propios modelos abiertos aporta tres ventajas operativas fundamentales frente a depender de servicios de terceros.

• Los perfiles de latencia se pueden afinar para el patrón de carga de trabajo de un producto específico, mientras que las APIs públicas optimizan el rendimiento general para atender a miles de clientes a la vez.

• El tiempo de actividad o uptime puede alcanzar niveles de disponibilidad mucho más altos con despliegues dedicados, superando los problemas de estabilidad típicos de las plataformas públicas en horas pico.

• Los costes suelen caer en torno a un 80 por ciento a gran escala una vez que el volumen de peticiones justifica la inversión inicial en infraestructura.

El resultado de este cambio de paradigma es que empresas construyen ahora pilas de inferencia serias. Esto incluye startups nativas de IA, productos consolidados que integran funciones inteligentes en flujos de trabajo existentes e incluso sectores tradicionalmente cautelosos con los datos de terceros como el sanitario. Un ejemplo representativo es Cursor. El equipo construyó su función Composer sobre un modelo abierto aplicando una extensa ingeniería de inferencia para ofrecer una latencia de autocompletado muy por debajo de lo que ofrecen las APIs cerradas del mercado.

¿Cómo genera respuestas un LLM? Fases Prefill y Decode

Para entender por qué el inference engineering tiene este nivel de complejidad es necesario comprender qué ocurre físicamente en la GPU cuando llega un prompt a un modelo de lenguaje. Antes de proceder a la explicación hay 4 máximas que deben estar claras:

• El proceso se divide en dos fases con demandas físicas totalmente diferentes: prefill y decode (ahora veremos cada una).

• La unidad atómica con la que trabaja un modelo es el token.

• Un token es un fragmento de palabra o una palabra entera. (Puedes jugar con este tokenizador para aprender más sobre Tokens).

• Las métricas de latencia en esta industria siempre se miden utilizando esta unidad base.

[1] La primera fase del proceso se llama prefill. El modelo toma todo el prompt de entrada y lo pasa por todas las capas de pesos de la red neuronal en paralelo. De esta ráfaga de procesamiento inicial salen dos cosas, el primer token de la respuesta y el KV cache.

El prefill está limitado por la capacidad de cálculo bruto, la GPU es el factor limitante porque cada token de entrada se procesa simultáneamente a través de cada capa del modelo. Si añades más potencia computacional a esta fase, el proceso se acelera.

La métrica que captura el rendimiento del prefill es el tiempo hasta el primer token o TTFT por sus siglas en inglés. Esa breve pausa entre que envías un mensaje a una IA y ves aparecer las primeras letras es el prefill trabajando al máximo de la capacidad de la tarjeta gráfica.

[2] La segunda fase es el decode. El modelo genera cada token de uno en uno, ejecutando una pasada completa hacia adelante a través de cada capa de pesos por cada nuevo token. Cada nuevo token depende de todos los tokens anteriores, lo que hace que el proceso sea fundamentalmente secuencial. La GPU repite esta operación miles de veces para generar una respuesta completa.

El decode está limitado por el ancho de banda de la memoria. La capacidad de cálculo de la GPU permanece mayoritariamente inactiva mientras el chip gasta sus ciclos leyendo los pesos del modelo desde la memoria VRAM para cada pasada hacia adelante.

El cuello de botella reside en el movimiento de los datos y no en el cómputo. La métrica que captura el rendimiento del decode son los tokens por segundo o TPS. El ritmo constante al que fluye una respuesta larga es la fase de decode operando bajo la restricción de la memoria.

Dado que el prefill y el decode tienen cuellos de botella opuestos, una técnica que acelera una fase suele tener un impacto nulo en la otra. Esta es la razón por la que los benchmarks técnicos reportan el TTFT y los TPS como números separados, ya que el rendimiento en cada fase debe medirse de forma independiente. Una vez que entiendes el prefill y el decode como dos operaciones distintas, las técnicas de optimización se dividen en tres grupos lógicos:

• Las que aceleran el prefill.

• Las que aceleran el decode.

• Y las que reequilibran ambas fases entre sí.

¿Qué es y cómo funciona el Batching?

El batching es la forma más básica de escalar la capacidad de salida de una única GPU en producción.

El motor de inferencia agrupa varias peticiones de diferentes usuarios token a token para que un solo servidor pueda atender a muchas personas a la vez. El rendimiento total del sistema aumenta significativamente porque la inmensa capacidad de cálculo de la GPU se utiliza por completo en lugar de quedarse inactiva esperando entre petición y petición.

Fíjate que el coste de esta técnica se paga directamente en la latencia por usuario.

• Un único usuario en un sistema sin batching obtiene el tiempo de respuesta más bajo posible.

• Ese mismo usuario en un sistema con un batching agresivo esperará más tiempo porque la GPU está dividiendo su atención para servir otras peticiones simultáneamente.

Esta compensación entre rendimiento global y latencia individual es el equilibrio principal sobre el que pivota cualquier otra técnica de inferencia. Los diferentes productos del mercado se sitúan en distintos puntos de este espectro. Las herramientas de chat para consumidores finales favorecen una latencia baja para dar sensación de inmediatez, mientras que los pipelines de procesamiento de datos en segundo plano favorecen un batching masivo para maximizar el rendimiento y reducir la factura de los servidores.

Prefix Caching: Gestión del contexto

El prefix caching es una técnica diseñada específicamente para acelerar la fase de prefill mediante la reutilización de los valores del KV cache entre diferentes peticiones.

Cuando dos prompts comparten un segmento de apertura idéntico, como por ejemplo un system prompt largo que define el comportamiento del modelo y que es igual en miles de peticiones de tus usuarios, el motor calcula ese prefijo una sola vez y lee el resultado desde la caché a partir de ese momento. Esta es la razón por la que los proveedores a través de la API cobran menos dinero por los tokens de entrada que han sido cacheados.

Ojo con esto porque la caché solo ayuda desde el inicio de la secuencia hasta el primer token que no coincide.

Si el primer token del texto difiere entre dos prompts distintos, el prefix caching ofrece cero ahorro computacional incluso si el resto de la secuencia es idéntica. Por lo tanto, la estructura del prompt que envías al modelo tiene implicaciones directas en el coste y en la latencia. La estrategia correcta es colocar siempre la entrada variable del usuario al final del prompt y mantener el contenido estático y compartido al principio para dar a la caché del servidor algo con lo que trabajar eficazmente.

{
  "system_prompt": "Eres un asistente experto en bases de datos SQL. Tu objetivo es optimizar consultas lentas...",
  "instructions": "Reglas de formato: 1. Usa mayúsculas para las palabras reservadas. 2. Añade comentarios...",
  "user_input": "Optimiza esta consulta: SELECT * FROM users u JOIN orders o ON u.id = o.user_id"
}

En un esquema como el anterior, el servidor de inferencia mantendrá cacheados el system_prompt y las instructions para todos los usuarios. Cuando llega la petición, la GPU solo tiene que calcular la fase de prefill para el user_input, reduciendo el tiempo de primera respuesta a una fracción del original.

Cuantización: Mejora Prefill y Decode a la vez

La cuantización ayuda a ambas fases de la inferencia aunque por razones completamente diferentes. La cuantización básica consiste en almacenar los pesos del modelo en un formato de número de menor precisión. La inmensa mayoría de los modelos modernos se entrenan utilizando una precisión de punto flotante de 16 bits. La cuantización comprime esos valores reduciéndolos a representaciones de 8 bits o incluso de 4 bits. Esto significa que los pesos del modelo son físicamente más pequeños, ocupan mucha menos memoria VRAM y requieren menos movimiento de datos a través de los buses de la placa base.

• El prefill se acelera porque las operaciones matemáticas de menor precisión se ejecutan más rápido en las unidades especializadas dentro de las GPUs modernas.

• El decode se acelera porque la menor presión sobre el ancho de banda de la memoria significa que los pesos se cargan mucho más rápido por cada pasada hacia adelante.

Un paso típico hacia abajo en la precisión del modelo produce un rendimiento entre un 30 y un 50 por ciento mejor, dependiendo del modelo exacto y de la técnica aplicada.

El coste a pagar aquí es la posible degradación de la calidad de las respuestas, y diferentes partes de una red neuronal toleran la cuantización de forma distinta. Los pesos lineales lo manejan bien, las activaciones son algo más sensibles, el KV cache es más sensible todavía y las capas de atención son las más críticas de todas.

La razón matemática de esta degradación es que los pequeños errores de precisión en las capas de atención se acumulan a lo largo de la secuencia de tokens. Dado que el cálculo de cada token se basa en los anteriores, los pequeños errores se convierten en una pérdida de calidad significativa en respuestas largas.

Acelera el decode con Speculative Decoding

El speculative decoding acelera el proceso de decode aprovechando una asimetría técnica muy interesante. Generar un token desde cero es extremadamente costoso a nivel computacional, pero verificar si un token candidato coincide con lo que el modelo principal produciría es una operación muy barata. Un ejemplo de modelo que aplica esta técnica es Gemma 4 de Google.

En esta técnica interviene un modelo borrador más pequeño que predice los siguientes tokens de la respuesta. El modelo principal toma estos tokens sugeridos y los verifica todos a la vez en una única pasada hacia adelante, aceptando los que coinciden con sus propias predicciones y rechazando el resto. El resultado en la práctica es que emergen múltiples tokens válidos por cada ciclo de cálculo del modelo principal en lugar del único token que se generaría de forma tradicional.

El speculative decoding mejora drásticamente los tokens por segundo mientras deja intacto el tiempo hasta el primer token porque la fase de prefill sigue ejecutándose de forma normal. Esta técnica funciona mucho mejor en tamaños de batch pequeños, cuando la GPU todavía tiene capacidad de cálculo libre para gastar en el proceso de verificación. En tamaños de batch grandes donde el servidor atiende a muchos usuarios a la vez, la GPU ya está saturada trabajando al límite. En esos momentos de alta demanda el sistema de inferencia desactiva dinámicamente la especulación porque necesita absolutamente todos los ciclos de reloj para procesar la carga de trabajo principal.

Paralelismo de LLMs en múltiples GPUs

Las técnicas de paralelismo permiten que los modelos masivos se ejecuten distribuidos en múltiples GPUs cuando una sola tarjeta se queda corta. Esto ocurre habitualmente porque el modelo es demasiado grande para caber en la memoria VRAM de un solo chip o porque la latencia usando una sola GPU es inaceptablemente alta para el usuario. Dos enfoques principales dominan el panorama actual de los modelos abiertos, el paralelismo de tensores y el paralelismo de expertos.

[1] El paralelismo de tensores divide cada capa del modelo entre múltiples GPUs. Cada tarjeta gráfica mantiene en su memoria un fragmento de cada capa y todas las GPUs comparten el trabajo aritmético para cada pasada hacia adelante.

Esta técnica requiere conexiones físicas de altísimo ancho de banda entre las tarjetas, como la tecnología NVLink, porque los resultados matemáticos necesitan combinarse y sincronizarse después de calcular cada capa individual. El paralelismo de tensores es la opción por defecto para servir modelos densos muy grandes, donde el enorme coste de comunicación entre los chips se compensa con el aumento masivo de velocidad al dividir el trabajo.

[2] El paralelismo de expertos se aplica específicamente a los modelos con arquitectura de mezcla de expertos o MoE. En estos modelos solo un subconjunto de los parámetros se activa para procesar cada token. Los diferentes componentes expertos se distribuyen entre distintas GPUs y los tokens se enrutan dinámicamente hacia el experto que necesitan en cada momento. La sobrecarga de comunicación por la red es mucho menor que en el paralelismo de tensores porque los expertos operan de forma independiente.

Esto hace que el paralelismo de expertos sea ideal para despliegues en múltiples nodos de servidores donde el ancho de banda de red es más limitado. La verdad es que la mayoría de los despliegues serios en producción combinan ambas estrategias, utilizando paralelismo de tensores dentro del mismo servidor físico y paralelismo de expertos entre diferentes máquinas conectadas por red.

Separa el Prfill y Decode con la técnica de Desagregación

La desagregación lleva la separación arquitectónica entre el prefill y el decode a su límite físico más extremo. La idea fundamental es ejecutar la fase de prefill en un grupo específico de GPUs y la fase de decode en otro grupo de máquinas completamente distinto, enviando el KV cache entre ellos a través de la red del centro de datos. Cada grupo utiliza hardware específicamente ajustado a su cuello de botella particular y cada clúster de servidores escala de forma independiente según su propio patrón de tráfico de usuarios.

El flujo de trabajo se convierte en un proceso de tres pasos:

• El motor de prefill toma la secuencia de entrada del usuario y produce tanto el primer token de respuesta como la enorme matriz de datos del KV cache.

• Esa matriz de caché se envía sobre una conexión de red de muy alta velocidad al motor de decode.

• Finalmente el motor de decode asume el control exclusivo y maneja la generación de cada token posterior hasta terminar la respuesta.

En configuraciones de desagregación condicional, las peticiones muy cortas o las que ya tienen su contexto almacenado en caché se saltan el intercambio de datos por la red por completo y se ejecutan exclusivamente en el motor de decode.

Este enfoque funciona muy bien frente al tráfico real de usuarios que suele incluir una mezcla impredecible de prompts largos, prompts cortos y peticiones repetitivas.

La desagregación trata el prefill y el decode como microservicios separados con preocupaciones operativas distintas y proporciona a los ingenieros controles independientes para escalar cada parte.

Las empresas que operan inferencia a escala masiva consideran este paso como un requisito casi obligatorio una vez que la mezcla de cargas de trabajo de sus usuarios está perfectamente monitorizada y comprendida.

Referencias técnicas

1. A guide to AI inference engineering - Análisis detallado de las técnicas de optimización y arquitectura para modelos de lenguaje en producción.

TL;DR

Entender el bucle agéntico sirve para dejar de ver a los agentes de IA como cajas negras y empezar a diseñarlos como sistemas predecibles y controlables.

• El bucle agéntico es un ciclo continuo donde el modelo evalúa una tarea, decide qué herramientas usar, observa los resultados y repite el proceso.

• Un turno es una vuelta completa de este ciclo, que consume tokens y debe limitarse por coste o iteraciones.

• La comunicación interna funciona mediante eventos o mensajes clave que marcan el inicio, la ejecución de herramientas y el resultado final.

• El contexto del modelo se llena rápidamente con los resultados de las herramientas, por lo que el bucle necesita mecanismos de compresión automática de contexto.

• Para que un bucle sea útil en producción, la infraestructura subyacente debe permitir guardar el estado y reanudar la ejecución si ocurren fallos de red o servidor.

¿Qué es el bucle agéntico o agent loop?

El discurso actual en LinkedIn, X y demás redes sociales sobre inteligencia artificial ha convergido en que los bucles son la pieza fundamental de los sistemas agénticos. Pero la pregunta que poca gente se hace es qué ejecuta realmente ese bucle. Un agente no es solo un modelo de lenguaje con acceso a herramientas aisladas sino que es un sistema orquestado.

El bucle agéntico es el ciclo de ejecución autónomo donde el modelo evalúa tu petición, llama a herramientas para ejecutar acciones, recibe los resultados de esas herramientas y repite el proceso hasta que la tarea se da por terminada.

Es decir, en lugar de darte una respuesta de texto plana y quedarse esperando, el agente toma la iniciativa, interactúa con el entorno local o remoto y corrige su rumbo en base a lo que va descubriendo por el camino.

¿Cómo funciona el bucle por debajo paso a paso?

Para entender el bucle a nivel técnico, la documentación oficial del SDK de agentes de Claude nos da una visión muy clara del proceso. Cada sesión de un agente sigue exactamente el mismo ciclo de vida estructurado en cinco fases.

El primer paso es recibir el contexto inicial. El sistema envía tu prompt junto con las instrucciones del sistema y las definiciones de las herramientas disponibles. Aquí es donde se inicializa la sesión.

Después, el modelo evalúa el estado actual y decide cómo proceder. Puede:

• Responder con texto.

• Pedir que se ejecute una herramienta.

• O hacer ambas cosas a la vez.

Si el modelo solicita usar una herramienta, el sistema detiene temporalmente la generación de texto, ejecuta la función solicitada y recoge el resultado.

Ese resultado se devuelve al modelo, lo que desencadena de forma natural una nueva evaluación. Este ciclo de evaluar, llamar a la herramienta y recibir el resultado se repite una y otra vez. Finalmente, cuando el modelo determina que la tarea está completa y no necesita recopilar más información, devuelve un mensaje final de texto cerrando el ciclo.

Para que lo veas más claro, piensa en cada uno de estos ciclos como un turno indivisible. Cuando el modelo decide que necesita usar una herramienta, como ejecutar un script en bash o buscar en un directorio, la generación de texto se pausa y esa herramienta se ejecuta realmente en tu máquina o en tu entorno local. Durante este tiempo de procesamiento, el modelo se queda esperando hasta que la herramienta termina su trabajo y el sistema recoge la salida y se inyecta de nuevo en la conversación mediante mensajes internos del sistema. Justo en ese momento se cierra el turno y el modelo vuelve a tomar el control con el contexto actualizado para decidir su siguiente paso.

¿Qué son los turnos y cómo limitan la ejecución del agente?

Aquí es donde la cosa se pone interesante. Un turno es básicamente un viaje de ida y vuelta dentro de este bucle. El modelo produce una salida que incluye llamadas a herramientas, el sistema ejecuta esas herramientas de forma secuencial o paralela, y los resultados vuelven al modelo automáticamente.

Todo esto ocurre en segundo plano sin devolver el control al hilo principal. Los turnos continúan de forma autónoma hasta que el modelo decide parar.

Un ejemplo: piensa en una tarea típica como arreglar unos tests que fallan en un proyecto de Node:

• El primer turno podría ser ejecutar un comando en la terminal para ver qué falla exactamente.

• El segundo turno sería leer el contenido de los archivos TypeScript afectados.

• El tercer turno consistiría en editar el código y volver a pasar los tests.

• El turno final es simplemente el modelo diciendo que todo funciona correctamente.

Dejar que un modelo itere de forma infinita es un peligro de cara a costes, por eso, a nivel de código, es fundamental establecer límites estrictos. Puedes limitar el número máximo de turnos permitidos o establecer un presupuesto máximo en dólares. Si no pones estos límites, un prompt un poco ambiguo podría hacer que el agente se quede atrapado leyendo archivos en bucle y consumiendo tokens sin parar.

¿Cómo se comunican el agente y las herramientas mediante mensajes?

A medida que el bucle funciona, el sistema emite un flujo constante de mensajes. Estos mensajes son la única forma que tienes como desarrollador de saber en qué etapa exacta se encuentra el proceso por debajo.

Tenemos los mensajes de sistema, que manejan los eventos del ciclo de vida de la sesión, como el inicio o el aviso de que el sistema se está apagando.

Luego están los mensajes del asistente, que se emiten cada vez que el modelo responde. Estos mensajes contienen el texto que genera y los bloques de llamadas a herramientas que quiere ejecutar en ese turno concreto.

Justo después, entran en juego los mensajes del usuario. Ojo, estos no son mensajes que tú escribas en tu teclado, sino que son los mensajes generados por el sistema para devolverle al modelo los resultados crudos de las herramientas que acaba de pedir.

Por último, cuando el bucle termina, se emite un mensaje de resultado. Este mensaje contiene el texto final, los tokens consumidos, el coste total de las operaciones y el identificador de la sesión. Fíjate que es crucial comprobar siempre el subtipo de este resultado en tu código, porque te dirá si el agente terminó con éxito o si se detuvo de forma forzosa porque alcanzó el límite de turnos o de presupuesto que definiste.

¿Qué pasa con la memoria y el contexto cuando el bucle se alarga?

La ventana de contexto en este tipo de arquitecturas lo es todo ya que durante una sesión, la información no se reinicia entre un turno y el siguiente: absolutamente todo se acumula (se acumula el prompt del sistema inicial, las definiciones de las herramientas, el historial de la conversación, los comandos enviados y, sobre todo, los resultados de esos comandos).

Cuidado con las herramientas que devuelven mucho texto plano porque si el agente decide hacer una búsqueda global en un repositorio grande o leer un archivo de log interminable, esa salida consume miles de tokens en un solo turno. Y como el contexto se arrastra, los turnos posteriores cargarán con todo ese peso, encareciendo brutalmente cada llamada a la API y ralentizando el tiempo de respuesta.

Para evitar que el agente colapse por exceso de información, los sistemas avanzados implementan la compactación automática de memoria. Cuando la ventana de contexto se acerca a su límite, el sistema hace una pausa, resume el historial antiguo para liberar espacio y mantiene intactos únicamente los intercambios más recientes y las decisiones clave.

Esto significa en la práctica que las instrucciones muy específicas que le diste al principio de la conversación pueden perderse diluidas en el resumen. Si tienes reglas estrictas que el agente nunca debe olvidar bajo ninguna circunstancia, debes inyectarlas en el prompt del sistema de forma persistente a través de archivos de configuración, no como un simple mensaje de chat al inicio de la sesión.

Referencias técnicas

1. Documentación del SDK de Agentes de Claude: El bucle del agente - Guía completa de implementación sobre la arquitectura interna, la gestión de turnos y el control del contexto en el bucle agéntico de Anthropic.

TL;DR

En este artículo te explico la complejidad metodológica para medir la verdadera diferencia de rendimiento entre la inteligencia artificial de código abierto y los modelos frontera.

• Los modelos con pesos abiertos tienen un retraso de en torno a 8/10 meses en benchmarks privados.

• En benchmarks públicos la diferencia se comprime a una ventana mucho más corta de 4/6 meses.

• ¿Están los modelos open source haciendo trampas en los benchmarks?

¿Cómo de detrás están los modelos abiertos?

Cuando intentamos medir el estado del arte de la tecnología siempre nos encontramos con el problema de las métricas y aquí la situación es bastante más enrevesada de lo que te cuentan en Twitter.

Preparando el post me encontré con este análisis que se apoya en una recopilación de 17 benchmarks seleccionados meticulosamente. De estos tenemos 8 que son privados y 9 que son públicos con un total de 110 puntos de datos validados.

Si miras los datos de los benchmarks privados, es decir, aquellos donde las preguntas y respuestas no están accesibles en internet para que nadie contamine los datos de entrenamiento, los modelos abiertos están entre 8 y 10 meses por detrás de la frontera cerrada.

Peeero si miras los benchmarks públicos la historia cambia por completo y la brecha se reduce a unos 4 o 6 meses.

Es una diferencia brutal que nos hace plantearnos muchas cosas.

Aquí puedes ver exactamente esta divergencia. Cada punto en esa gráfica representa un umbral de puntuación aceptado. La altura del punto te dice cuántos meses antes un modelo cerrado había cruzado ese mismo umbral.

Las curvas que ves son tendencias suavizadas donde se ve claramente cómo la brecha fue mínima alrededor del lanzamiento de DeepSeek R1 en enero de 2025. Desde ese momento la línea vuelve a subir.

Vemos que la diferencia entre las dos curvas nos dice que los benchmarks públicos subestiman la distancia real casi por un factor de dos.

¿Cómo medimos la diferencia entre modelos abiertos y cerrados?

Para entender de dónde salen estos números tienes que entender cómo se calculan y aviso que la lógica tiene trampa. El método define una serie de umbrales de puntuación para cada benchmark, normalmente en intervalos del 5 por ciento desde el 0.05 hacia arriba.

Cuando un modelo abierto cruza uno de estos umbrales por primera vez, el sistema mira hacia atrás en el tiempo para ver cuándo un modelo cerrado cruzó ese mismo umbral.

Un ejemplo para verlo mejor: imagina que o1-preview sale en septiembre de 2024 y cruza el umbral del 40 por ciento en una prueba. Luego llega DeepSeek R1 en enero de 2025 y cruza ese mismo 40 por ciento. El cruce se cuenta como un punto de datos que mide la brecha en 4.3 meses.

Aquí vemos la línea de tiempo de retraso para SimpleBench donde cada fila es un umbral y el marcador verde es el modelo cerrado y el azul es el abierto.

La barra roja en el medio es la brecha temporal en meses. Las flechas grises punteadas son los umbrales que la frontera cerrada ya ha alcanzado pero que siguen pendientes para los modelos abiertos.

Errores al evaluar los modelos abiertos chinos

Hay un factor enorme en todo esto que casi nadie menciona: cuando la gente evalúa modelos abiertos chinos en benchmarks privados normalmente utilizan proveedores de terceros.

Estos proveedores tienen políticas de retención de datos nula para proteger la privacidad de las evaluaciones. Instituciones como METR o Epoch AI son extremadamente cuidadosas con esto al evaluar cosas como FrontierMath.

A veces estos proveedores de terceros sufren problemas de implementación o pequeños bugs. Esto provoca una degradación sutil en el rendimiento del modelo abierto cuando se sirve a través de su infraestructura.

Detectar esta degradación es muy complicado. De nada sirve tener un modelo potentísimo si el flujo por el que pasa la evaluación le resta puntos por latencias o fallos de formato.

Si esta degradación está ocurriendo realmente, significa que la brecha que medimos en los benchmarks privados está artificialmente inflada. El modelo abierto sería mejor de lo que los datos privados nos están diciendo.

La trampa de los modelos abiertos para puntuar más en los benchmarks

El contraste entre los resultados con benchmarks públicos y privados sugiere algo bastante evidente y es que los desarrolladores de modelos abiertos están filtrando mal los datos de los benchmarks o directamente están optimizando sus entrenamientos para superar esas pruebas concretas.

Aunque esto también pasa con los laboratorios privados, aunque a menor escala. Los desarrolladores entrenan a sus modelos en el tipo de tareas que saben que van a ser evaluadas porque son las tareas verificables más fáciles de convertir en métricas.

Los grandes laboratorios cerrados tienen muchísimo más capital, acceso a flujos de datos variados y retroalimentación directa de millones de clientes empresariales. Su dependencia de la optimización pura para benchmarks es menor.

Por tanto la brecha real en tareas del mundo real, las que haces tú en tu trabajo diario, es probablemente bastante más grande que la que marcan incluso los benchmarks privados.

Categorías, modelos chinos y evaluaciones de la comunidad

Si separamos los datos por categorías de capacidades la situación no cambia mucho. La categoría de razonamiento muestra una brecha significativamente mayor que las demás.

Peeero hay que tener en cuenta que los tres benchmarks que componen esta categoría de razonamiento son privados. El factor de privacidad parece tener más peso que la categoría de la tarea en sí misma.

Un experimento interesante es aislar exclusivamente los modelos abiertos de origen chino frente a la frontera cerrada. Los resultados desde la salida de Llama 3.1 en julio de 2024 son idénticos a la gráfica general.

Antes de esa fecha la brecha medida utilizando solo modelos chinos era notablemente más grande. Esto demuestra la gran aceleración que ha tenido el ecosistema asiático en el último año.

En las discusiones técnicas de la comunidad surgen debates complejos sobre la integración de nuevos datos. Por ejemplo, hay casos donde un modelo como Kimi K2.5 aparece en un punto de datos con un retraso de 10 meses.

Esto ocurre precisamente por la definición retroactiva de la brecha ya que aunque ese modelo en particular estuviera menos atrasado respecto a la frontera en el momento de la prueba, la brecha histórica que estaba cerrando en ese umbral concreto era de 10 meses y el sistema lo asocia a su fecha de lanzamiento.

La procedencia de los datos y la asimetría de la contaminación

Para medir de manera justa cuándo un modelo abierto alcanza a uno cerrado los números tienen que ser comparables, idealmente una única entidad independiente debería ejecutar todos los modelos en el mismo entorno.

Pero la realidad es que el ecosistema de evaluación es un absoluto caos.

El análisis divide los benchmarks en un núcleo limpio y una periferia mucho más dudosa. En el lado limpio tenemos pruebas como GPQA Diamond, MATH Level 5 o WeirdML. Estas pruebas las ejecuta una sola entidad de principio a fin sin depender de números reportados por los propios creadores.

En el lado más oscuro tenemos MMLU, GSM8K o Terminal-Bench. Aquí las puntuaciones son una amalgama de envíos de la comunidad y auto-reportes de los laboratorios utilizando configuraciones que les favorecen.

Y aquí viene lo más crítico del estudio. Incluso el conjunto de pruebas privadas en las que más confiamos tiene problemas de asimetría.

Por ejemplo en el caso de FrontierMath: una prueba privada administrada por Epoch AI pero OpenAI financió el proyecto y tiene acceso a gran parte de los problemas. Esto puede inflar artificialmente las puntuaciones de la frontera cerrada.

Luego tienes ARC-AGI que utiliza un conjunto semi privado. Las entradas de evaluación se transmiten a través de APIs comerciales. La exposición es completamente asimétrica.

Los modelos cerrados reciben los datos a través de sus propias APIs nativas mientras que los abiertos lo hacen a través de servidores de terceros. Cualquier contaminación en este proceso infla el lado cerrado.

Si el lado cerrado se infla la frontera cruza los umbrales mucho antes en la línea de tiempo. Esto significa que la brecha que estamos midiendo podría estar sobrestimada. Los números privados podrían ser peores sobre el papel de lo que son en la realidad.

La complejidad de analizar el rendimiento real requiere cuestionar cada punto de datos. No basta con mirar un titular que dice que la brecha se cierra. Tienes que rascar, entender la procedencia del benchmark, la configuración del prompt, el tipo de acceso a la API y el momento temporal exacto en el que se validó ese conocimiento.

Referencias técnicas

1. How far behind are open models? - Análisis detallado de Håvard Tveit Ihle sobre las divergencias de rendimiento en base a 17 benchmarks seleccionados.

El último término que ha salido a la luz es el de Loop Engineering, un concepto que en el fondo agrupa automatizaciones que ya hacíamos previamente, pero donde ahora estamos incluyendo agentes de IA para tomar decisiones de forma autónoma.

TL;DR

El Loop Engineering sirve para dejar de escribir prompts manualmente y construir sistemas que orquesten el trabajo de los agentes de IA por ti.

• Pasas de chatear con la IA paso a paso a diseñar un flujo automatizado que evalúa y corrige su propio código.

• El sistema utiliza tareas programadas clásicas pero incluye un modelo de lenguaje en el centro para tomar las decisiones.

• Es fundamental separar las tareas: un agente escribe el código y otro distinto revisa que funcione correctamente.

• Tokenomics: Requiere un control estricto de los presupuestos, ya que un bucle infinito puede disparar tu factura de tokens en cuestión de horas.

¿Qué es el Loop Engineering y de dónde sale este concepto?

Hace apenas un mes parecía que el Harness Engineering era la única habilidad que necesitabas dominar para trabajar con modelos de lenguaje. Fíjate cómo cambian las cosas que ahora entras en X y el único término que acapara las conversaciones técnicas es el de Loop Engineering.

Todo esto viene impulsado por declaraciones recientes de desarrolladores como Peter Steinberger, el creador de OpenClaw o Boris Cherny, el creador de Claude Code. Básicamente ambos afirman que ya no deberíamos estar escribiendo prompts para interactuar con los asistentes de código. Su postura es que el trabajo de un ingeniero ahora consiste en diseñar bucles que se encarguen de escribir esos prompts de forma automática.

Hasta ahora, la mayoría de nosotros trabajábamos con la IA mediante un chat. Tú abrías la interfaz de Claude, escribías un prompt pidiendo una funcionalidad o la corrección de un bug, leías la respuesta, y volvías a escribir. A esto se le conoce como bucle abierto, muy relacionado con el concepto de human in the loop, porque el humano interviene en cada uno de los pasos del proceso.

La idea del Loop Engineering es evolucionar hacia un bucle cerrado donde aquí pasas a ser el supervisor que diseña el flujo de trabajo completo. Tú defines las reglas, los límites y las comprobaciones. El sistema se encarga de ejecutar las iteraciones necesarias hasta completar la tarea asignada, algo similar a /goal en Claude Code.

¿Cómo funciona realmente el loop engineering?

Siendo sinceros, la verdad es que el loop engineering tampoco tiene mucho… y es que se parece bastante a un cron job de toda la vida. La diferencia principal radica en lo que ocurre dentro de esa tarea programada.

En una automatización tradicional, el script sigue un camino rígido. Con el Loop Engineering, el script incluye un modelo de lenguaje que evalúa el estado actual de tu repositorio, decide cuál es la siguiente acción, la ejecuta y, lo más importante, comprueba si ha funcionado. El modelo es el que toma la decisión basándose en el contexto, no en una simple bifurcación de código predefinida determinista.

Para que este sistema no se rompa, necesita apoyarse en varios componentes técnicos:

• Primero están las automatizaciones que inician el proceso, ya sea por un evento temporal o por un trigger externo.

• Luego están las herramientas de aislamiento, como los worktrees de Git, que evitan que varios agentes trabajando en paralelo modifiquen los mismos archivos y generen conflictos.

• Aquí es donde entran en juego las habilidades o skills del agente. De nada sirve tener un bucle automatizado si el modelo tiene que adivinar las convenciones de tu proyecto en cada iteración. Proporcionar un contexto claro mediante archivos de instrucciones permite que la IA sepa exactamente cómo debe comportarse sin que tengas que explicárselo desde cero en cada ejecución.

• Además, la arquitectura más robusta para estos bucles implica el uso de subagentes. El modelo que escribe el código suele ser demasiado optimista para evaluar su propio trabajo. Un bucle fiable utiliza un agente enfocado en el desarrollo y otro completamente distinto, a menudo con un modelo de razonamiento superior, encargado de revisar y validar que el resultado cumple con las especificaciones.

¿De dónde viene el concepto de loop engineering? Origen y evolución

Para comprender cómo hemos llegado hasta aquí, conviene repasar cómo han madurado estos sistemas. El concepto no nació ayer y tiene un origen bastante claro en la investigación de modelos de lenguaje.

1. La primera etapa la vimos hace un par de años con el patrón ReAct. Era un bucle muy básico donde el modelo razonaba, utilizaba una herramienta externa, leía el resultado y repetía el proceso. Era un modelo ejecutando un único bucle bajo la atenta mirada de un operador humano.

2. La segunda fase llegó con experimentos como AutoGPT. Se le proporcionaba un objetivo general y se le daba libertad para autogestionarse. El problema recurrente es que solía perder el rumbo rápidamente, entrando en ciclos donde no lograba completar ninguna tarea útil. Esto generó bastante escepticismo sobre la viabilidad real de los agentes.

3. Posteriormente aparecieron soluciones más pragmáticas basadas en terminal mediante scripts de bash. La innovación principal fue la gestión adecuada del contexto. En lugar de mantener un historial de conversación interminable que terminaba confundiendo al modelo, el script reiniciaba el contexto en cada iteración basándose en un conjunto fijo de archivos clave.

Lo que hoy llamamos Loop Engineering no deja de ser una capa superior de abstracción sobre todo lo anterior. Ya no hablamos de un único script en tu ordenador personal, sino de orquestación. Los bucles ahora supervisan a otros bucles, se ejecutan de forma concurrente, responden a eventos del sistema y mantienen su estado respaldado en repositorios para poder recuperarse si el proceso falla.

Cómo aplicar Loop Engineering en tu día a día: Ejemplos prácticos

Imagina que tienes conectada tu plataforma de observabilidad, como Sentry, a tu código fuente. Cuando Sentry detecta una excepción en producción, en lugar de simplemente enviarte un correo de alerta, dispara un bucle de IA.

El sistema recopila el stack trace y el contexto del error, y lanza un agente que escribe una prueba automatizada para reproducir ese fallo. Una vez que la prueba falla en rojo, otro agente desarrolla el código necesario para solucionarlo. Finalmente, el bucle verifica que la prueba pasa en verde y abre una Pull Request para que tú la revises. Todo esto ocurre en segundo plano.

Otro caso de uso habitual empieza en el gestor de tareas. Se crea un ticket nuevo en Linear con las especificaciones de una nueva vista para tu aplicación. Esto dispara un flujo donde un agente redacta un borrador técnico y te envía un mensaje por Slack. Si tú das el visto bueno, el bucle continúa: asigna subagentes para escribir los componentes, añadir las pruebas unitarias y actualizar la documentación interna. Tú solo intervienes como supervisor en los puntos de control clave.

Tokenomics

Un concepto que me encanta es el de Tokenomics, o economía de Tokens y es que el loop engineering requiere de una buena gestión de recursos.

Dejar que las máquinas trabajen por ti suena espectacular sobre el papel pero la realidad de mantener estos sistemas funcionando de forma desatendida tiene matices importantes, especialmente cuando hablamos del impacto económico.

El recurso más caro en el desarrollo con IA ha dejado de ser la generación de código para pasar a ser la gestión del propio bucle. Si un agente empieza a iterar infinitamente intentando arreglar un error de dependencias, el consumo de tokens se dispara. Establecer límites estrictos de iteraciones, detectar la falta de progreso y configurar techos de gasto son reglas obligatorias antes de poner cualquier automatización a funcionar de forma aislada.

A nivel profesional también existe un riesgo técnico evidente. Cuanto más código genere el bucle sin tu intervención directa, mayor será la brecha entre lo que existe en el repositorio y lo que tú realmente entiendes de la base de código. Si dejas de leer lo que produce el sistema, tu capacidad para mantener el proyecto a largo plazo se hunde.

Adoptar el Loop Engineering no significa desentenderse del proyecto sino que significa mover el esfuerzo desde la escritura manual de funciones hacia el diseño y la supervisión del sistema que las construye. A fin de cuentas, la responsabilidad de lo que llega a tus usuarios sigue siendo tuya.

Referencias técnicas

1. ¿Qué es el LOOP ENGINEERING? El nuevo HYPE de la Inteligencia Artificial - Explicación detallada de Betta Tech sobre la automatización de agentes y desmitificación técnica del concepto.

Seguro que has leído sobre agentes que recuerdan cada interacción que tienes con ellos, un error común es asumir que la memoria de un modelo debe funcionar como un cajón de sastre donde todo se almacena pero… esto no es así.

El post de hoy no es tan técnico pero creo que es importante porque asienta las bases de cómo funciona la memoria en estos sistemas y como se asemeja al funcionamiento de nuestras memorias biológicas.

TL;DR

Hoy te explico cómo operan los sistemas de memoria en agente de IA y por qué guardar todos los detalles perjudica el rendimiento del agente.

• Los sistemas constan de un extractor para procesar conversaciones, un almacén de datos y un ‘recuperador’ para gestionar consultas.

• Las herramientas actuales prometen diversas memorias cognitivas pero acaban reduciendo todo a simples hechos estáticos almacenados en índices.

• Nuestro cerebro biológico no graba de forma continua, sino que filtra lo predecible y almacena únicamente las sorpresas/novedades o los errores de predicción.

• Un diseño eficiente debe capturar solo la información novedosa y emplear un modelo bitemporal que registre tanto cuándo ocurrió un evento como cuándo lo aprendió el sistema.

Las 3 partes de una memoria para agentes de IA

Cualquier librería de memoria para agentes de IA está construida con tres piezas fundamentales y lo bueno es que puedes entender el funcionamiento de cualquier herramienta conociendo estas partes:

• Extractor: Es la pieza encargada de leer las transcripciones y decidir qué se mantiene. Habitualmente utiliza un LLM para extraer afirmaciones cortas sobre el entorno o el usuario. La decisión más importante que toma es el momento de la extracción. Extraer tras cada mensaje consume tokens en charlas irrelevantes. Hacerlo al final degrada la calidad porque el modelo pierde la atención sobre la información intermedia. En este proceso se pasa de un evento contextualizado a un hecho aislado, perdiendo referencias de tiempo y énfasis por el camino.

• Almacén: Hablamos de la base de datos, que pueden ser vectoriales, tablas relacionales o grafos de conocimiento. Cada registro contiene metadatos con una marca temporal. La mayor dificultad aquí es gestionar las contradicciones cuando un dato nuevo difiere de uno antiguo. El sistema debe elegir entre sobrescribir el dato perdiendo el historial, guardar ambos, o mantener ambos marcando el antiguo como reemplazado. Si un sistema no puede responder qué dato consideraba cierto el mes pasado, no actúa como una memoria real.

• Recuperador: En el momento de la consulta, este módulo convierte la pregunta en una búsqueda para devolver las afirmaciones pertinentes. Estructuralmente es un sistema RAG aplicado a las afirmaciones acumuladas del usuario. A veces se incorpora un filtro temporal y una comprobación para bloquear hechos desactualizados.

Los 4 tipos de memoria y cómo se aplican a la IA

La terminología de estos sistemas suele tomarse de la ciencia cognitiva, pero la ingeniería rara vez está a la altura de esos conceptos. Te comento los cuatro tipos teóricos y cómo se aplican.

• La memoria episódica registra eventos concretos vinculados a un momento y lugar. Las librerías actuales lo solucionan con una tabla de afirmaciones etiquetadas temporalmente, reduciendo la experiencia a una simple observación.

• Luego está la memoria semántica, referida a hechos descontextualizados. La inmensa mayoría de lo que llamamos memoria de agentes pertenece a esta categoría. Un dato episódico se comprime y llega al almacén convertido en un hecho estático sobre el usuario.

• La memoria procedimental consiste en saber cómo hacer las tareas. Aquí es donde la brecha técnica es más evidente. Algunas herramientas aseguran incluir este tipo de memoria, pero la almacenan en el mismo índice que los hechos semánticos y solo alteran un campo en los metadatos. Podríamos entender que un Agent Skill es un tipo de memoria procedimental.

• Por último, la memoria prospectiva implica recordar acciones futuras. Ninguna librería actual resuelve esto en toda su complejidad. En realidad, la mayoría de estos sistemas actúan como sistemas autobiográficos que gestionan datos sobre la vida del usuario mediante un proxy. Un ejemplo de memoria prospectiva: “cuando ocurra X debo hacer Y”.

La memoria es el residuo de la sorpresa

Una cosa que debe quedar clara es que no podemos almacenar absolutamente todo. El cerebro biológico no funciona como una cámara, sino que predice experiencias. Según el principio de energía libre de Karl Friston, el cerebro crea un modelo del mundo y genera expectativas. Cuando hay un error de predicción y la realidad no encaja, esa sorpresa impulsa el aprendizaje. La memoria es literalmente el residuo de esa sorpresa.

Los sistemas de IA actuales hacen justo lo contrario. El flujo habitual consiste en extraer hechos de una conversación, guardar todo indiscriminadamente y luego recuperar la información mediante similitud vectorial. Esto convierte la base de conocimiento en un cúmulo de datos útiles y mucho contexto basura. Una aproximación mucho más inteligente, documentada en herramientas open-source como memv, es usar el error de predicción como filtro para extraer información.

En este enfoque, el sistema predice qué debería contener el episodio en función de lo que ya sabe. Al comparar el episodio real con la predicción, únicamente se extraen y almacenan los datos que violaron esa expectativa. Así, la base de datos se nutre exclusivamente de información verdaderamente novedosa.

Para complementar esto, se requiere un modelado bitemporal en el que un registro no solo necesita la marca de tiempo de cuándo fue almacenado por el sistema, sino también de cuándo empezó a ser cierto en el mundo real.

Por qué los agentes no deberían olvidar como hacemos los humanos

Hay una falsa creencia de que, puesto que la memoria biológica olvida datos, los agentes de IA deberían imitar este comportamiento mediante pesos de recencia o limpiezas programadas. Ojo, esto es un enfoque equivocado. El olvido biológico es una restricción por falta de capacidad física, no un objetivo a alcanzar.

Un sistema artificial no sufre esta limitación y puede almacenar un histórico completo a un coste computacional bajo. Un historial inmutable es muy útil porque permite depurar y auditar qué información manejaba el sistema en un momento exacto del pasado. El verdadero problema de guardar todo es que la recuperación empeora a medida que la base de datos crece. La solución pasa por mejorar los filtros de búsqueda y clasificar correctamente los datos obsoletos, no por eliminarlos del disco.

Referencias técnicas

1. Agent memory: an anatomy - Desglose de los componentes estructurales y las clasificaciones cognitivas en librerías de retención para inteligencia artificial.

2. Memory is the residual of surprise - Análisis del principio de energía libre aplicado a sistemas de extracción mediante errores de predicción y bases de datos bitemporales.

Lo que parecía un experimento aislado de unos pocos desarrolladores acaba de dar un salto de gigante. Hoy te cuento qué cambios ha habido en este aspecto y qué puedes hacer para mejorar el posicionamiento de tu web entre los buscadores de IA.

Resumen ejecutivo (TL;DR)

La adaptación del contenido web para inteligencias artificiales ha dejado de ser una teoría para convertirse en un estándar técnico auditable. Este artículo analiza cómo la adopción del archivo llms.txt y el enfoque de Agentic Engine Optimization (AEO) redefinen la estructura de la información en internet.

• Google Lighthouse incluye ahora una nueva sección llamada Navegación Agéntica donde se verifican explícitamente la presencia de un archivo llms.txt en la raíz del dominio.

• El consumo de tokens es la nueva métrica de rendimiento. El contenido debe estructurarse en formato Markdown para evitar que el exceso de etiquetas HTML agote la ventana de contexto de los modelos.

• Infraestructuras como Cloudflare ya permiten la conversión automática de HTML a Markdown en el borde mediante cabeceras de negociación de contenido, devolviendo estimaciones de tokens en tiempo real.

• El archivo llms.txt no reemplaza al robots.txt ni al sitemap.xml, sino que actúa como una capa de descubrimiento específica diseñada para la fase de inferencia de los agentes.

Google ahora analiza la Navegación Agéntica desde Lighthouse

Aquí hay una situación muy curiosa que da bastante que pensar. Por un lado, la documentación oficial de Google Search sobre optimización para características generativas afirma de forma rotunda que no necesitas crear archivos legibles por máquinas, ni formatos especiales, ni archivos de texto para IA para aparecer en los resultados generados. John Mueller, uno de los portavoces de búsqueda de Google, lo dejó claro recientemente argumentando que los sistemas pueden leer HTML sin problema y que preparar tu sitio para un futuro potencial lleno de agentes no debería distraerte de las bases del SEO.

Pero por otro lado, el equipo de Chrome acaba de introducir una nueva categoría de auditoría en Lighthouse llamada “Agentic Browsing” (Navegación Agéntica). Esta auditoría evalúa específicamente lo bien construido que está tu sitio para la interacción con máquinas.

Y adivina qué comprueba esta nueva auditoría de Lighthouse. Exacto. Verifica la presencia de un archivo llms.txt en la raíz del dominio.

La propia documentación de Lighthouse explica que, sin este archivo, los agentes pueden gastar mucho más tiempo rastreando el sitio para entender su estructura de alto nivel y su contenido principal. Esta categoría no te da una puntuación tradicional de 0 a 100, sino una ratio de aprobación fraccional basada en señales de preparación para agentes.

El SEO tradicional sirve para que un motor de búsqueda global encuentre tu página. La optimización para agentes sirve para que, una vez que el agente ha encontrado la página, pueda completar la tarea que el usuario le ha pedido de la forma más rápida y precisa posible.

¿Qué es Agentic Engine Optimization (AEO) y cómo influye en el uso de tokens?

Todo esto se alinea perfectamente con lo que Addy Osmani, director de ingeniería en Google Cloud AI, planteó hace poco bajo el concepto de Agentic Engine Optimization.

👉🏻Este concepto se refiere a estructurar y servir contenido técnico de manera que los agentes de inteligencia artificial puedan utilizarlo y no solo renderizarlo.

Fíjate en cómo consume información un modelo de lenguaje: A diferencia de un humano que escanea visualmente una página, un agente debe procesar el código fuente. Una página web moderna está llena de ruido de la propia estructura. Menús de navegación, pies de página, CSS, SVG integrados y scripts de seguimiento. Para un LLM, todo ese HTML es texto plano que consume su ventana de contexto y que no tiene utilidad.

El presupuesto de tokens es el nuevo presupuesto de rastreo. Si le pasas a un agente un documento HTML masivo y lleno de basura, corres varios riesgos graves. El agente puede truncar la página si supera su límite de contexto, puede omitir información importante enterrada en la parte inferior o, peor aún, puede alucinar una respuesta porque el ruido semántico le ha confundido.

Las recomendaciones técnicas para adaptar tu contenido bajo este nuevo paradigma son muy concretas y requieren replantear la arquitectura de la información:

• Mantener las guías de inicio rápido por debajo de los 15.000 tokens.

• Limitar las guías conceptuales a 20.000 tokens y las referencias de API a 25.000 tokens.

• Colocar la respuesta o el concepto principal en los primeros 500 tokens del documento, ya que los agentes tienen muy poca tolerancia a los preámbulos largos.

• Servir el contenido en formato Markdown limpio en lugar de HTML siempre que sea posible.

Aquí es donde entra en juego la necesidad de una capa de descubrimiento específica. Los agentes necesitan saber antes de empezar a leer si una página contiene la información que buscan o si solo van a gastar tokens en vano.

¿Qué es y cómo usar el llms.txt en tu web?

La propuesta de usar un archivo llms.txt fue impulsada originalmente por Jeremy Howard y está ganando mucha tracción en la comunidad. La idea principal es estandarizar un archivo en la ruta raíz de un sitio web que proporcione información adaptada para ayudar a los modelos a utilizar esa web durante la fase de inferencia.

El archivo robots.txt se utiliza para establecer reglas de acceso. Le dice a los bots qué rutas pueden rastrear y cuáles no. Es un mecanismo de permisos. Pero ojo, son recomendaciones y no una norma o protocolo.

El sitemap.xml es un inventario exhaustivo diseñado para los indexadores de los motores de búsqueda. Contiene todas las páginas de tu web, pero rara vez incluye versiones optimizadas para máquinas o enlaces a recursos externos.

El archivo llms.txt tiene un propósito muy diferente ya que funciona como un resumen y una guía de navegación para un agente que ya está interactuando con tu sitio a petición de un usuario. Es legible tanto por humanos como por modelos, pero sigue un formato preciso que permite su procesamiento mediante técnicas de programación clásicas.

¿Cómo crear un archivo llms.txt válido?

La especificación de llms.txt requiere que el archivo esté en formato Markdown y siga un orden estructural estricto. Esto es importante porque si no mantienes la estructura, los analizadores automáticos fallarán al intentar extraer el contexto.

La estructura técnica debe contener:

1. Un encabezado H1 con el nombre del proyecto o web. Esta es la única sección estrictamente obligatoria.

2. Un bloque de cita (blockquote) con un resumen conciso del proyecto que contenga la información clave necesaria para entender el resto del documento.

3. Cero o más secciones de Markdown genéricas con detalles adicionales sobre el proyecto y cómo interpretar los archivos proporcionados.

4. Cero o más secciones delimitadas por encabezados H2 que contienen listas de archivos.

5. Cada elemento de la lista debe ser un hipervínculo en formato Markdown seguido opcionalmente de dos puntos y una nota explicativa.

Este es un ejemplo real de cómo se estructura un archivo válido siguiendo la especificación. Nota cómo la limpieza del formato facilita la extracción de las URLs mediante expresiones regulares básicas.

# Ejemplo de proyecto API

> Esta es una biblioteca backend diseñada para gestionar autenticación y pagos de forma unificada. Utiliza Node.js y se integra directamente con proveedores externos.

Información importante:
- La biblioteca requiere una versión de Node igual o superior a la 20.
- No incluye componentes de interfaz de usuario.

## Documentación Principal

- [Guía de inicio rápido](https://miproyecto.com/docs/inicio.md): Configuración básica y primeros pasos.
- [Referencia de la API de Pagos](https://miproyecto.com/docs/pagos.md): Detalles sobre los endpoints de facturación.

## Opcional

- [Guía de migración desde v1](https://miproyecto.com/docs/migracion.md): Pasos para actualizar desde la versión anterior.

Hay un detalle de diseño muy inteligente en la especificación. La sección con el encabezado H2 llamado “Opcional” tiene un significado especial ya que si un agente necesita ahorrar contexto o busca una respuesta rápida, puede ignorar todos los enlaces listados bajo esta sección.

Junto a este archivo, la propuesta sugiere que las páginas web con información útil expongan una versión limpia en Markdown accesible añadiendo la extensión “.md” a la URL original. Proyectos como FastHTML ya lo hacen por defecto, y la diferencia en velocidad de procesamiento y precisión de respuesta cuando le pasas la versión Markdown a un modelo como Claude o GPT-4 es abismal.

Markdown for Agents de Cloudflare

Producir versiones en Markdown de todo tu sitio web puede ser complejo a nivel de infraestructura si utilizas un gestor de contenido tradicional o generas páginas dinámicamente. Cloudflare ha detectado esta necesidad y acaba de lanzar una funcionalidad que cambia la forma en que servimos contenido a las máquinas: Markdown for Agents.

Cloudflare ahora soporta la conversión de contenido en tiempo real en su propia red de distribución. Cuando un sistema de inteligencia artificial solicita una página desde un sitio protegido por Cloudflare que tiene esta opción habilitada, el agente puede usar cabeceras de negociación de contenido HTTP para expresar su preferencia por el formato Markdown. La red intercepta la petición, obtiene el HTML original del servidor de origen, limpia todo el ruido visual y estructural, lo convierte a Markdown y se lo devuelve al agente de forma transparente.

La magia ocurre mediante la cabecera Accept: text/markdown. Fíjate en cómo se ve una petición básica usando cURL.

curl https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/ \
  -H "Accept: text/markdown"

Si estás desarrollando tu propio agente usando JavaScript o TypeScript en un entorno de servidor, la implementación para solicitar esta versión es igual de directa.

const response = await fetch(
  `https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/`,
  {
    headers: {
      Accept: "text/markdown",
    },
  },
);

const tokenCount = response.headers.get("x-markdown-tokens");
const markdownContent = await response.text();

Ojo porque en la respuesta, Cloudflare incluye una cabecera personalizada llamada x-markdown-tokens. Esta cabecera devuelve una estimación del número de tokens que contiene el documento Markdown resultante.

Para un desarrollador que está construyendo un agente, este dato puede valer oro ya que te permite calcular dinámicamente si el contenido cabe en tu ventana de contexto antes de empezar a procesarlo, o decidir qué estrategia de fragmentación (chunking) aplicar para almacenarlo en una base de datos vectorial sin tener que tokenizar el texto tú mismo.

Formato y estructura de salida y retención de metadatos

Cuando Cloudflare realiza esta conversión, no se limita a pasar el texto por un conversor básico sino que devuelve un documento con una estructura predecible que elimina la necesidad de escribir lógica de parseo específica para cada sitio web.

El proceso de conversión sigue tres pasos rígidos.

• Primero, extrae los metadatos de las etiquetas <meta> del HTML original y los coloca en un bloque YAML frontmatter al principio del archivo. Si la página tiene etiquetas de título, descripción o imagen (priorizando las estándar sobre Open Graph), aparecerán aquí.

• Segundo, procesa el cuerpo del documento. Todo el contenido no esencial desaparece. Menús, pies de página, scripts de analítica, hojas de estilo. Todo el HTML innecesario se descarta durante el preprocesamiento, dejando únicamente el contenido semántico en formato Markdown.

• Tercero, preserva los datos estructurados. Si el HTML original incluía bloques de JSON-LD, vitales para entender el contexto semántico de un artículo o un producto, el conversor los extrae y los coloca al final del documento dentro de un bloque de código marcado como JSON.

La respuesta HTTP completa tiene este aspecto.

HTTP/2 200
date: Wed, 11 Feb 2026 11:44:48 GMT
content-type: text/markdown; charset=utf-8
content-length: 2899
vary: accept
x-markdown-tokens: 725
content-signal: ai-train=yes, search=yes, ai-input=yes

---
title: Markdown for Agents · Cloudflare Agents docs
description: Cloudflare's Markdown for Agents converts HTML to Markdown at the edge.
---

## What is Markdown for Agents

Markdown has quickly become the lingua franca for agents and AI systems
as a whole. The format’s explicit structure makes it ideal for AI processing.

La cabecera Content-Signal que aparece en la respuesta es parte de un marco de trabajo emergente que permite a los propietarios de sitios web expresar sus preferencias sobre cómo puede usarse su contenido tras ser accedido. Por defecto, esta función señaliza que el contenido puede usarse para entrenamiento de IA, resultados de búsqueda y entrada de agentes.

Cómo adaptar tu infraestructura para que sea consumid por agentes de IA

En paralelo al desarrollo ‘normal’ de una web, ahora debes mantener una capa subyacente optimizada para el procesamiento de máquinas.

Si utilizas Cloudflare, habilitar Markdown for Agents es un proceso sencillo que puedes realizar a nivel de zona entera o mediante reglas de configuración específicas para subdominios particulares. Si gestionas tu propia infraestructura, la recomendación técnica pasa por integrar bibliotecas de generación estática que produzcan artefactos .md durante el proceso de compilación y servirlos cuando la cabecera Accept lo indique.

El archivo llms.txt debe considerarse desde hoy como parte fundamental de la raíz de cualquier proyecto técnico o sitio de documentación. Generarlo no cuesta recursos significativos y el beneficio de visibilidad frente a herramientas es enorme.

Finalmente, la auditoría de Lighthouse no es una casualidad, es un indicador de que la industria está adoptando estas convenciones como estándares de calidad.

Los agentes de IA han llegado para quedarse. Ya no es suficiente con adaptar nuestras webs para nosotros, los humanos, sino que también debemos facilitar el trabajo a las máquinas para que puedan entendernos mejor y facilitar sus labores.

Referencias técnicas

1. Especificación oficial del estándar llms.txt - Documentación de la propuesta original de Jeremy Howard y guías de implementación.

2. Documentación de Cloudflare: Markdown for Agents - Guía técnica detallada sobre la conversión en el borde y negociación de contenido.

3. Artículo de Addy Osmani: Agentic Engine Optimization (AEO) - Análisis del director de ingeniería de Google Cloud AI sobre la estructuración de contenido para agentes.

4. Nuevas auditorías de Lighthouse para Navegación Agéntica - Cobertura sobre la inclusión del chequeo de llms.txt en las herramientas de desarrollo de Chrome.

5. Iniciativa Content Signals - Especificación técnica del marco de trabajo para expresar preferencias de uso de contenido por inteligencias artificiales.

Nos han vendido que los agentes de programación iban a solucionar todos nuestros problemas de desarrollo, pero la realidad no siempre es así. A veces los modelos hacen cosas totalmente increíbles pero otras veces fallan estrepitosamente en lo más simple.

La mayoría de gente en sector comete el error de pensar que la solución pasa por esperar a que salga la próxima versión de GPT o de Claude, confiando en que un modelo más grande y con más parámetros será mágicamente más inteligente. La verdad es que gran parte de las mejoras reales que estamos viendo hoy en día en el ecosistema del desarrollo no vienen de tener mejores modelos, sino de construir mejores entornos en los que estos modelos operan.

Ya tenemos una máquina capaz de escupir miles de líneas de código, nuestra responsabilidad ahora no es revisar cada línea a mano, sino intentar controlar el entorno.

Precisamente de esa necesidad de control nace una disciplina que está cambiando la forma en la que construimos software asistido: el Harness Engineering. Hoy te voy a enseñar a crear sistemas verdaderamente productivos basados en IA.

TL;DR

El Harness Engineering es la disciplina que se encarga de diseñar y construir el ecosistema tecnológico que rodea a un modelo de inteligencia artificial para convertirlo en un agente autónomo, seguro y fiable.

• Un agente funcional es la suma del modelo más su arnés de control (Agent = Model + Harness). El arnés orquesta las herramientas, la memoria y el contexto.

• La arquitectura se basa en un bucle REPL donde el arnés intercepta las peticiones del modelo, ejecuta las herramientas de forma segura y le devuelve los resultados.

• Incorpora guías preventivas (Feedforward) y sensores de corrección (Feedback) mediante evaluaciones computacionales (linters, tests) e inferenciales (IA revisora).

• Limitar artificialmente las herramientas y el tamaño del contexto mejora la precisión del modelo y reduce notablemente el gasto en tokens.

• Permite automatizar flujos complejos como el Spec Driven Development (SDD) coordinando subagentes aislados que se comunican mediante memoria externa.

Qué es el Harness Engineering y por qué es importante

Imagina un modelo, puedes ser Claude, GPT o cualquier otro que uses a diario, este modelo es nuestro cerebro. Por sí solo, este cerebro es capaz de procesar texto, predecir el siguiente token y razonar sobre conceptos abstractos, pero no tiene forma de tocar el teclado, ni de leer los archivos de tu proyecto y no tiene memoria a largo plazo más allá de la ventana de contexto que le proporciones en ese instante.

El Harness Engineering agrupa todas las prácticas y arquitecturas que consisten en agarrar ese modelo de inteligencia artificial y definirle el entorno que le rodea. El arnés equivale a las riendas que le ponemos al modelo para intentar dirigir su fuerza bruta hacia un objetivo concreto: Agente es igual a Modelo más Arnés en un bucle.

Este entorno o ecosistema que construimos alrededor del modelo se compone de varias piezas fundamentales que tenemos que orquestar:

• Por un lado, tenemos la gestión del contexto, que es decidir qué información le enviamos al modelo en cada momento.

• Por otro lado, la definición de herramientas (tools) a las que el modelo puede llamar para interactuar con el mundo real, como leer un archivo, ejecutar un comando de terminal o consultar una base de datos.

• También necesitamos un sistema de memoria persistente para evitar que la ventana de contexto se inunde con información irrelevante.

• Finalmente, también necesitamos mecanismos de validación.

Uno de los mayores beneficios de adoptar el Harness Engineering es que pasas a ser dueño del sistema y si mañana sale un modelo open source hiperbarato que sirve perfectamente para tareas de refactorización rutinaria, simplemente lo enchufas en tu arnés.

Ojo porque mucha gente piensa que construir un buen arnés consiste en darle al modelo acceso absoluto a todo (herramientas, acceso de lectura a todo el disco duro y ventanas de contexto de millones de tokens…) pero es justamente lo contrario. Ha quedado sobradamente demostrado que cuanto más complejo haces el arnés y más herramientas específicas le das al modelo, peor funciona.

El equipo de Vercel documentó hace poco cómo el rendimiento de su agente interno (D0) mejoró cuando eliminaron el 80% de las herramientas que le habían programado inicialmente. Además que reujeron el consumo de tokens en un 37%.

¿Cómo funciona el arnés? Bucles de evaluación y ejecución

En el desarrollo de videojuegos existe el patrón conocido como “Game Loop”, un bucle infinito que en cada iteración o frame lee la entrada del usuario, actualiza el estado físico y lógico del mundo, renderiza los gráficos en la pantalla y vuelve a empezar. Los agentes de inteligencia artificial operan exactamente con el mismo principio estructural.

En la literatura técnica, este patrón suele denominarse bucle REPL, por las siglas en inglés de Read, Eval, Print, Loop.

El bucle principal gestiona la interacción general. Lee lo que el usuario escribe en la interfaz (Read), decide qué hacer con ello (Eval), muestra el resultado en pantalla (Print) y vuelve a esperar (Loop).Pero en el Harness Engineering ocurre dentro de la fase de evaluación. Esa fase no es una simple llamada de red que devuelve un texto, sino que tiene su propio bucle interno, que es donde el agente puede actuar de forma autónoma.

Cuando el usuario introduce una petición, el arnés envía ese mensaje al modelo junto con la lista de herramientas disponibles (la inteligencia artificial no ejecuta ninguna herramienta por sí misma: el modelo no sabe abrir archivos ni compilar código). El modelo simplemente responde con una petición estructurada diciendo: “Oye, necesito que tú, el arnés, ejecutes la herramienta de leer fichero pasándole esta ruta exacta”.

El arnés recibe esta petición (el Tool Use), intercepta el flujo, ejecuta la función localmente en tu máquina para leer el fichero y agarra el contenido resultante. Luego, en la siguiente iteración de ese bucle interno, el arnés le manda al modelo un nuevo mensaje diciéndole: “Vale, he ejecutado la herramienta que pediste y aquí tienes el resultado”. El modelo lee la información, razona sobre ella y decide su siguiente paso. Puede pedir ejecutar un comando de bash para compilar, o puede determinar que ya tiene toda la información necesaria y formular la respuesta final para el usuario.

A continuación te muestro un ejemplo en Go donde defino un bloque donde se itera sobre las respuestas del modelo, evaluando el tipo de salida:

for {
    // 1. Enviamos el contexto y los mensajes actuales al modelo
    respuestas := proveedor.EnviarMensaje(contexto, mensajes)

    todasHerramientasEjecutadas := true

    for _, resp := range respuestas {
        if resp.EsLlamadaHerramienta() {
            // 2. El modelo pide usar una herramienta. El arnés toma el control.
            todasHerramientasEjecutadas = false
            
            // 3. Verificación de seguridad y permisos (Harness Engineering)
            if !pedirAprobacionHumana(resp.NombreHerramienta, resp.Argumentos) {
                agregarMensajeError(mensajes, "El usuario denegó la ejecución")
                continue
            }
            
            // 4. Ejecución real en el entorno local
            resultado := ejecutarHerramienta(resp.NombreHerramienta, resp.Argumentos)
            agregarResultadoHerramienta(mensajes, resp.ID, resultado)
        }
    }

    // 5. Si el modelo no pidió más herramientas, terminamos el bucle interno
    if todasHerramientasEjecutadas {
        break
    }
}

Esta abstracción es el core de cualquier sistema agéntico profesional.

Control: Feedforward y Feedback

Ya tenemos el bucle de ejecución pero… ¿Cómo comprobamos y nos aseguramos que ese código cumple con nuestros estándares? Sabemos que los LLMs son no deterministas, que carecen de contexto organizativo y que, en el fondo, no entienden semánticamente el código ya que operan prediciendo tokens de forma probabilística.

Para solucionar esto, un arnés bien diseñado incorpora dos tipos de controles complementarios: mecanismos de Feedforward (Guías) y mecanismos de Feedback (Sensores).

• Los controles de Feedforward, o guías, actúan antes de que el agente empiece a escribir. Su objetivo es anticipar el comportamiento de la inteligencia artificial y dirigirla para aumentar la probabilidad de que acierte al primer intento. Esto incluye desde el System Prompt general, hasta inyectar de forma dinámica las convenciones de código de tu proyecto, guías de estilo o documentos de arquitectura directamente en la ventana de contexto antes de formular la petición.
  
  Los sensores son programas ejecutados por la CPU como los tests unitarios, los linters, los analizadores estáticos de código o el propio compilador. El arnés pilla la salida de un linter que ha fallado y se la devuelve automáticamente al agente de IA con un mensaje como: “Tu código ha generado este error de compilación en la línea 45. Arréglalo”.
  

• Los controles de Feedback, o sensores, actúan después de que el agente haya escrito el código, permite corregirse sin intervención humana. Es imposible garantizar que un modelo probabilístico acierte siempre a la primera.

  Los sensores inferenciales se apoyan en otros modelos de IA (o en el mismo) para realizar juicios semánticos que herramientas programáticas no pueden evaluar. Este es el famoso patrón de “LLM como Juez”. Obviamente, estos controles inferenciales consumen GPU, tardan más y cuestan dinero, por lo que un buen Harness Engineering consiste en orquestarlos estratégicamente, manteniendo la calidad en las fases tempranas del ciclo de vida del desarrollo.

¿Cómo diseñar un buen arnés?

Tenemos tres grandes áreas de regulación que deberíamos considerar al crear un arnés (en el contexto de la programación y el desarrollo de software)

• La primera es el arnés de mantenibilidad (Maintainability harness): Su foco es la calidad interna del código. Aquí es donde integramos nuestras herramientas tradicionales. Son controles baratos y rápidos que el arnés puede invocar en cada iteración del bucle interno. Los LLMs pueden complementar esto identificando duplicidad semántica (código que hace lo mismo pero está escrito distinto), aunque su uso debe ser más esporádico por el coste de inferencia.

• La segunda categoría es el arnés de idoneidad arquitectónica (Architecture fitness harness): Ya no buscamos solo que el código esté limpio, sino que respete las características de la arquitectura de la aplicación. Podemos inyectar guías que dicten estándares de observabilidad y logging, y utilizar sensores como tests estructurales para asegurarnos de que el agente no ha roto los límites entre módulos de dominio al intentar solucionar rápido un bug.

• La tercera, y más compleja, es el arnés de comportamiento (Behaviour harness): ¿Cómo validamos que la aplicación hace funcionalmente lo que se supone que debe hacer? La solución aquí sigue requiriendo una fuerte especificación humana previa.

Ojo, hay que tener en cuenta que no todos los proyectos son igual de propensos a ser domados por un arnés y habrá casos donde funcione mejor que en otros.

Y, evidentemente, estas tres áreas están centradas en el desarrollo de software pero hay muchos usos y aplicaciones del uso de agentes fuera de la programación que necesitarían un arnés completamente diferente.

Referencias técnicas

1. Harness engineering for coding agent users - Artículo fundacional de Birgitta Böckeler en el blog de Martin Fowler sobre la aplicación de conceptos de cibernética y teoría de control a los agentes de programación.

2. ¿Qué es esto del Harness Engineering? - Análisis conceptual en vídeo sobre el rol del ecosistema en el rendimiento de los modelos, el problema de la hiperespecialización de herramientas y el uso de memoria externa frente a ventanas de contexto.

3. Esto es lo que Aprendí Adaptando Claude Code para SDD - Guía práctica de orquestación multiagente aplicando Spec Driven Development (SDD), curación de contexto y separación de responsabilidades estructurales.

4. Model Context Protocol (MCP) - Estándar abierto para conectar de forma unificada modelos fundacionales con herramientas de datos y sistemas en entornos de desarrollo.

5. Anthropic API Documentation - Tool Use - Referencia técnica oficial sobre la estructuración de bucles de evaluación en modelos de la familia Claude.

Seguro que alguna vez has entrado a HuggingFace con la intención de descargar un modelo de lenguaje para correrlo en tu equipo local y te has encontrado con una lista interminable de archivos con extensiones extrañas como el .gguf, pero este formato es el principal responsable de que hoy podamos ejecutar inteligencia artificial avanzada en nuestros equipos de forma sencilla.

Muchos de nosotros usamos herramientas locales para levantar modelos, pero la verdad es que pocos entienden qué ocurre por debajo cuando se carga uno de estos archivos.

Resumen ejecutivo (TL;DR)

GGUF (Generic GPT Unified Format) es un formato de archivo contenedor diseñado para almacenar y ejecutar grandes modelos de lenguaje de forma altamente eficiente en hardware de consumo.

• Resuelve los problemas de escalabilidad y compatibilidad de su predecesor (GGML).

• Funciona como un contenedor que empaqueta en un solo lugar los pesos cuantificados del modelo, la arquitectura, el tokenizador y las plantillas de chat.

• Permite leer y cargar en memoria únicamente las partes necesarias del modelo gracias a su tabla de tensores y metadatos estructurados.

• Soporta múltiples niveles de cuantificación (como 4-bit o 8-bit), lo que reduce drásticamente el consumo de memoria RAM y VRAM.

Historia de los formatos tradicionales: GGML

Para entender por qué necesitamos GGUF, tenemos que mirar un momento al pasado reciente. Antes, los modelos se guardaban en los formatos nativos de los frameworks con los que se entrenaban. Hablamos de archivos .pt de PyTorch o .pb de TensorFlow. Estos formatos estaban pensados para el entrenamiento y usaban una precisión completa de 32 bits para los números de punto flotante.

El problema era el tamaño: un modelo medianamente capaz pesaba ya decenas de gigabytes y exigía una cantidad de memoria de vídeo (VRAM) que solo estaba al alcance de centros de datos.

Después de GGML llegó ONNX como un intento de estandarizar los modelos entre frameworks, pero seguía sin solucionar el problema fundamental del consumo masivo de memoria para la inferencia en equipos de consumo.

Aquí es donde entró en escena Georgi Gerganov. Este desarrollador creó llama.cpp, un motor de inferencia en C++ puro, y junto con él, el formato GGML (que lleva sus iniciales). GGML fue el primer intento serio de hacer que los grandes modelos de lenguaje fueran accesibles en hardware estándar mediante técnicas de cuantización (si quieres entender bien qué es la cuantización te recomiendo leer el post de la semana pasada).

GGML tiene limitaciones importantes de diseño ya que es muy rígido. Si alguien añadía una nueva característica al modelo o un nuevo tipo de metadato, rompía la compatibilidad con los modelos más antiguos. Requería demasiados ajustes manuales y no escalaba bien para los modelos gigantescos que estaban por venir.

Qué es el formato GGUF y cómo funciona

Para empezar, no quiero que asocies GGUF a un modelo de IA, debes empezar a verlo como un gran contenedor como un ZIP que contiene muchos ficheros pero diseñado para redes neuronales.

Un modelo de lenguaje en local es, en esencia, una gran colección de números a la que llamamos pesos. Pero el motor de inferencia (ya sea llama.cpp, Ollama o LM Studio) necesita un mapa para saber qué hacer con todos esos números. No le basta con tener los datos en crudo.

El motor necesita saber qué arquitectura concreta está utilizando ese modelo. Necesita conocer qué tokenizador exacto debe aplicar para convertir tu texto en números. Requiere la plantilla de chat específica que usa el modelo para diferenciar los roles de usuario y asistente. Y lo más importante, necesita saber dónde empieza y termina cada tensor dentro de ese archivo.

GGUF empaqueta todo eso en un único archivo estandarizado. La parte más importante de toda esta estructura es la tabla de tensores que le dice al cargador cómo debe leer los datos. Mira este ejemplo simplificado:

tensor: blk.0.attn_q.weight 
shape: [4096, 4096] 
type: Q4_K_M 
offset: 1835008

Cuando el cargador de llama.cpp lee este bloque: sabe que tiene que ir a la posición del byte 1835008 del archivo, interpretar esos bytes bajo el esquema de cuantificación Q4_K_M y añadir el resultado a la capa de atención correspondiente con una forma de matriz de 4096 por 4096.

Esto es exactamente lo que hace que GGUF sea tan potente para la inferencia en local. Tienes un archivo completamente portable que incluye todo el contexto, los metadatos y la disposición en memoria de los pesos.

Gestión de la cuantización en GGUF

La cuantificación es el proceso matemático de reducir la precisión de los parámetros del modelo. Pasamos de números de alta precisión que ocupan mucha memoria a representaciones más simples y comprimidas.

GGUF tiene soporte nativo para muchos esquemas de cuantificación, lo que te permite elegir el equilibrio exacto entre el tamaño del modelo y su inteligencia.

En el post de la semana pasada te explicaba en profundidad el proceso de cuantización, su funcionamiento en detalle y ejemplos, te recomiendo echarle un ojo antes de seguir leyendo 👇🏻

Seguridad en los archivos GGUF y vectores de ataque

Solemos pensar que los modelos de IA son cajas negras que recopilan parámetros y ya, pero nos olvidamos que la carga del modelo sigue el mismo proceso que cualquier software tradicional.

Cuando cargamos un archivo GGUF se produce un análisis sintáctico (parsing) que conlleva implicaciones directas en la ciberseguridad. Como hemos visto antes, un archivo GGUF es una entrada de datos estructurada que se le pasa a un cargador en C, C++ o Rust. La tabla de tensores es la que dicta los tamaños, las formas y los desplazamientos en memoria.

Si descargas un archivo GGUF malicioso desde una fuente no confiable, ese archivo podría mentir deliberadamente sobre sus offsets o sobre el tamaño de sus tensores. Si el cargador del motor de inferencia no valida estrictamente esos metadatos, un atacante podría provocar un desbordamiento de búfer (buffer overflow) o lecturas de memoria fuera de los límites.

Técnicamente, los atacantes podrían diseñar un archivo GGUF manipulado para filtrar información privada que introduzcas en tu modelo local o incluso comprometer el entorno de ejecución del agente. Por eso es muy importante usar versiones actualizadas de herramientas como llama.cpp u Ollama.

Ecosistema y herramientas compatibles

La adopción de GGUF está sido masiva y prácticamente todo el ecosistema de IA en local pivota hoy en día sobre este estándar.

Si utilizas Ollama en tu terminal, por debajo estás utilizando llama.cpp y cargando archivos GGUF. Si usas interfaces gráficas como LM Studio o GPT4All, todas dependen de la eficiencia de este formato para mover los datos desde tu disco duro hasta tu memoria RAM a gran velocidad.

Incluso plataformas empresariales y bibliotecas enormes como Transformers de Hugging Face han tenido que integrar soporte para leer y cargar metadatos GGUF, reconociendo que el formato binario propuesto por la comunidad de código abierto es muy superior a las soluciones tradicionales cuando se trata de inferencia pura y dura.

Referencias técnicas

1. GGUF - Hugging Face Hub Documentation

2. GGUF versus GGML - IBM Think

La mayoría de la gente que se atasca trasteando con modelos de lenguaje en local no se queda bloqueada porque la tecnología sea compleja sino que se piensan que simplemente están ejecutando un modelo en la terminal… pero la realidad es que están tomando cinco decisiones técnicas: Hardware, Memoria, Entorno de ejecución (runtime), selección del Modelo y nivel de Cuantización.

Cada una de estas capas tiene sus propios puntos de fallo, cada una se puede optimizar por separado y, para complicarlo más, todas se limitan entre sí. Casi cualquier problema de rendimiento o error que te encuentres se puede rastrear hasta una de estas cinco variables.

Todo lo que te voy a detallar en este post lo he probado y lo ejecuto de forma recurrente en un Mac Mini M4. He querido centrar los ejemplos en el ecosistema de Apple porque ahora mismo es el punto de entrada más amigable, pero los conceptos base aplican a cualquier sistema. Si veo que hay interés en el tema, prepararé una versión de esta guía enfocada a entornos con gráficas dedicadas de NVIDIA.

Resumen ejecutivo (TL;DR)

Para entender y optimizar la ejecución de modelos de IA en local debes dominar cómo interactúan el hardware, la memoria y el formato del modelo. Esta guía desglosa la pila tecnológica de inferencia local.

Empezaremos levantando un modelo básico en minutos para luego profundizar en por qué el ancho de banda de memoria es más importante que la potencia bruta.

Exploraremos cómo calcular el coste real de la memoria RAM incluyendo la caché KV, aprenderemos a leer los ficheros GGUF para elegir la cuantización perfecta y revisaremos ajustes avanzados del entorno de ejecución.

Al final entenderás exactamente qué está pasando en tu máquina cada vez que generas un token.

¿Cómo ejecutar un modelo en local?

De nada sirve leerse la teoría sobre formatos de archivo o debatir si una cuantización es mejor que otra si todavía no has experimentado lo que es correr modelos de IA en tu ordenador.

Mi objetivo ahora no es que entiendas conceptos complejos sino que corras un modelo básico en tu equipo y te quites el miedo.

No empieces intentando descargar modelos de 70.000 millones de parámetros ni te vuelvas loco con configuraciones complejas. Los Mac con procesadores Apple Silicon (la serie M: M1, M2…) son el punto de partida más sencillo que existe ahora mismo.

En los ejemplos usaremos ollama en su versión de terminal. Si no te sientes cómodo siempre puedes descargar la versión de escritorio desde su web oficial aunque te animo a seguir el post desde la terminal 🦾.

Solo necesitas abrir tu terminal y lanzar tres comandos que no te llevarán ni 5 minutos:

brew install ollama  # Si no tienes Homebrew descarga Ollama desde su web oficial primero y salta este paso
ollama pull qwen3:8b
ollama run qwen3:8b

Si no tienes Homebrew en tu Mac, puedes descargar el instalador directamente desde la web de Ollama. Y si al hacer el pull te salta un error de que no encuentra el tag, pásate por ollama.com/library para comprobar las versiones disponibles.

Seguramente te preguntes por qué he elegido qwen3:8b para empezar. Hay varios motivos de peso.

Este modelo es lo suficientemente pequeño para ser manejable, pesando unos 5 GB con una cuantización Q4 (luego entenderemos qué es esto). Es lo bastante inteligente para que puedas darle un uso real y útil en tu día a día. Entra perfectamente en los 8 GB de RAM que tienen los equipos base. Y además se defiende de maravilla tanto en inglés como en otros idiomas.

Una vez que termine la descarga, verás que te aparece un prompt con tres símbolos de mayor que (>>>). Escribe cualquier cosa y mira cómo responde.

Cuando te canses de jugar, sal del chat y ejecuta estos dos comandos para entender qué tienes entre manos:

ollama list
ollama show qwen3:8b

El primer comando te muestra los modelos que tienes instalados, su nivel de cuantización y lo que ocupan en disco. El segundo es mucho más interesante porque te da todos los detalles del modelo, mostrando la plantilla de chat que utiliza, el número de capas y la longitud de contexto configurada.

Al trastear verás que hay dos métricas fundamentales que tienes que aprender a leer.

• La primera son los tokens por segundo (TPS), que básicamente es la velocidad de generación. En un chip de la serie M de Apple corriendo un modelo de 8B, deberías esperar entre 20 y 60 TPS, lo cual se debería sentir muy fluido y rápido. Si ves que tu rendimiento cae por debajo de los 5 TPS, seguramente tengas un problema de memoria o has elegido una cuantización incorrecta para tu máquina.

• La segunda métrica es el tiempo de evaluación del prompt (prompt eval), que es el tiempo que tarda el modelo en procesar tu texto inicial y empezar a generar el primer token de respuesta. Este tiempo va a depender directamente del tamaño del modelo y de lo largo que sea tu contexto. En otros posts me refiero a este concepto como TTFT o Time To First Token.

Vigila siempre el uso de memoria de tu sistema operativo: si ves que superas el 80% de uso, deberías empezar a prestar atención. La saturación aumentará la latencia y es muy probable que tu sistema empiece a usar memoria swap. Puedes vigilar el uso de memoria con el comando top o desde el monitor de actividad.

¿Qué hardware necesito para correr LLMs en local?

Técnicamente el dispositivo desde el que me estás leyendo puede correr un modelo de IA en local sin problema, ahora bien, si hablamos de modelos ‘serios’ debemos prestar atención a varios elementos.

La gran mayoría de personas que buscan comprar hardware para correr modelos locales se fijan casi exclusivamente en la potencia bruta de cálculo de la GPU, los famosos FLOPS. Ese instinto, aunque lógico en otros campos de la informática, aquí es totalmente erróneo.

La inferencia local casi siempre está limitada por el ancho de banda de la memoria, no por la capacidad de procesamiento de los núcleos.

Piensa en cómo funciona un LLM por dentro: cada vez que el modelo genera un único token, los pesos del modelo tienen que leerse desde la memoria RAM y enviarse a las unidades de cálculo. Los pesos son estáticos, no cambian, pero tienen que leerse en cada paso de generación de forma constante. El ancho de banda determina lo rápido que ocurre esa lectura y, por tanto, es el tope máximo de tus tokens por segundo.

Aquí es donde Apple destaca y sus chips Silicon rinden sorprendentemente bien para tareas de IA local.

Los procesadores de la serie M utilizan una arquitectura de memoria unificada. Esto significa que la CPU y la GPU comparten exactamente el mismo bloque de memoria física. No existe la VRAM dedicada como tal y la distancia física desde la memoria hasta los núcleos de la gráfica es muy corta. La eficiencia del ancho de banda es muy superior a la de una tarjeta gráfica dedicada que tiene que comunicarse a través de un puerto PCIe.

Por ponerte números reales de Apple. Un MacBook Pro con el chip M4 Max tiene dos variantes. La versión con CPU de 14 núcleos ofrece 410 GB/s de ancho de banda, mientras que el modelo superior con CPU de 16 núcleos y GPU de 40 núcleos llega a los 546 GB/s. Si te vas a un Mac Studio con el M3 Ultra, te plantas en unos 819 GB/s de ancho de banda. Esto lo convierte en la opción de escritorio más potente para el consumidor normal que quiere hacer trabajo serio con LLMs locales.

Si nos vamos al lado de NVIDIA, el rey del mercado de consumo es la RTX 4090 con sus 24 GB de VRAM, que te da unos 1008 GB/s de ancho de banda. La RTX 3090, que es la generación anterior, se queda en unos 936 GB/s pero tiene una ventaja clave: soporta NVLink para conectar varias tarjetas y sumar VRAM.

¿Qué modelo me cabe en memoria Cuantización

El hardware te marca el techo de tu rendimiento, pero es la memoria la que te dice qué modelo concreto cabe dentro de ese techo.

El consumo de memoria de un modelo local se divide principalmente en dos bloques:

• Los pesos del modelo.

• La caché KV (además de un pequeño margen para el entorno de ejecución).

¿Cómo calculo la memoria que necesitan los pesos del modelo?

Primero debemos entender los tamaños y parámetros de los modelos. Cuando vemos el nombre de un modelo como Qwen-3-8B, ese “8B“ significa que el modelo tiene 8 mil millones de parámetros (8 billion en inglés).

Por simplificar y sin entrar en detalle un parámetro es un número que el modelo aprendió durante su entrenamiento. Generalmente, a más parámetros mejor capacidad del modelo a capturar patrones complejos, razonar en tareas complejas… pero todo a costa de una memoria más grande para correrlos, más lentos en inferencia y más caros de servir en general.

Para calcular el espacio que ocupan los pesos solo tienes que multiplicar el número de parámetros por los bytes que ocupa cada parámetro.

Si usas el formato original sin comprimir (FP16 o BF16), cada parámetro ocupa 2 bytes. Por tanto, un modelo de 8B en FP16 se va a tragar unos 16 GB de memoria.

Si aplicas una cuantización Q8, reduces cada parámetro a 1 byte, dejando el modelo en unos 8 GB.

Si bajas a Q4, estamos hablando de medio byte por parámetro, por lo que un modelo de 8B ocupa unos 4 GB, a los que hay que sumar un 20% de sobrecarga operativa, quedándose en unos 5 GB reales.

Si te atreves a probar un Q3, el coste baja a 0.375 bytes por parámetro, lo que rozaría los 3 GB.

Pasar de 16 GB en formato puro a unos 4 o 5 GB con Q4 es un salto enorme. Por esto la cuantización Q4 es el punto dulce que usa casi todo el mundo.

Pero… ¿Qué es eso de la cuantización? Piensa en ella como una técnica de compresión que reduce la precisión de los pesos del modelo para que ocupen menos espacio. En su estado natural (FP16), los modelos usan números decimales muy largos y precisos, lo que consume muchísima RAM. Al cuantizar, lo que hacemos es “redondear” esos valores a números enteros más simples de 8, 4 o incluso 3 bits.

Por ejemplo, un peso que originalmente era un decimal complejo puede acabar representado por un valor mucho más sencillo. Aunque al redondear perdemos un pelín de precisión técnica y existe un riesgo real de pérdida de calidad, en la práctica el modelo sigue siendo casi igual de inteligente pero ocupando una fracción del espacio original. Esto es lo que nos permite correr modelos mucho más potentes en hardware doméstico sin que la experiencia se resienta.

¿Cómo calculo la memoria que necesito para la KV caché?

Como habíamos dicho la KV caché es la segunda variable de la ecuación, y sinceramente es la que la mayoría ignora por completo por desconocimiento.

La fórmula técnica de la caché KV es un poco compleja. Básicamente consiste en multiplicar el número de capas, por las cabezas de atención KV, por la dimensión de cada cabeza, por la longitud de la secuencia, por el tamaño del lote (batch) y por los bytes de cada elemento.

Hay que tener en cuenta que los modelos modernos utilizan técnicas como GQA (Grouped Query Attention) o MQA (Multi-Query Attention) para optimizar esto, donde el número de cabezas KV es mucho menor que el total de cabezas de atención. Y si estás usando el modelo tú solo en tu terminal, el tamaño de lote suele ser 1.

Lo importante que tienes que sacar de esa fórmula es que la caché KV escala de forma lineal con el tamaño del contexto. Pasar de un contexto de 4.000 tokens a uno de 128.000 tokens significa multiplicar por 32 el tamaño de tu caché KV.

El tamaño de la ventana de contexto es el que se va comiendo tu memoria. El error más común es asumir que el consumo de memoria se queda fijo una vez que el archivo del modelo se ha cargado en disco. La ventana de contexto es una variable enorme y dinámica.

Mira este ejemplo usando la API de Ollama para forzar el tamaño del contexto:

curl http://localhost:11434/api/generate \
  -d '{
    "model": "qwen3:8b",
    "prompt": "Explica la caché KV",
    "options": { "num_ctx": 32768 },
    "stream": false
  }'

El modelo qwen3:8b viene con un contexto por defecto de 4.096 tokens. Si lo aumentamos hasta los 32K como en el comando anterior, la memoria extra que consume el sistema se la come casi en su totalidad la caché KV. No es un error ni una fuga de memoria. Un contexto más largo obliga al sistema a almacenar en RAM las computaciones de muchos más tokens pasados para no tener que volver a calcularlos desde cero.

¿Qué aplicación (runtime) necesitas para correr modelos de IA?

Cuando antes has hecho la prueba y escribes tu comando en la terminal piensas que estás interactuando directamente con qwen3:8b pero la verdad es que primero estás pasando por Ollama, que es tu entorno de ejecución o runtime.

Ollama por su cuenta está tomando un montón de decisiones críticas por debajo: cómo cargar el modelo en memoria, qué plantilla de diálogo aplicar y cuántas capas puede mandar a la GPU para acelerar el proceso.

El runtime te quita abstrae de muchas decisiones técnicas para que tu no te preocupes por mucho.

Pero la idea es que seas un usuario avanzado y si quieres tener control absoluto, puedes saltarte a Ollama y llamar directamente a llama.cpp. Eso sí, todo lo que Ollama automatizaba, ahora te toca escribirlo a mano:

Puedes descargar llama.cpp desde su repositorio o siguiendo esta guía.

./llama-cli \
  --model ./models/Qwen3-30B-A3B-Q4_K_M.gguf \
  --ctx-size 32768 \
  --n-gpu-layers 99 \
  --flash-attn on \
  --jinja

En este comando de ejemplo mira el flag del final, el parámetro --jinja. Es fundamental mencionarlo porque le indica a llama.cpp que debe usar la plantilla de chat (chat template) que viene incrustada dentro del propio modelo, en lugar de intentar aplicar una por defecto. Añadir simplemente esta opción hace que desaparezcan muchos problemas de calidad y formato en las respuestas.

En el caso de Apple podemos aprovechar el framework MLX desarrollado directamente por el equipo de investigación de Apple. Está muy optimizado para sacar todo el provecho a la memoria unificada de la que hablábamos antes. tengo pensado sacar un post sobre MLX, mientras tanto te recomiendo este post si quieres profundizar.

La gracia de los modelos locales no es usarlos desde la terminal. Una vez que el entorno de ejecución levanta el modelo, este expone una API local a la que puedes conectar tus scripts de Python, tus agentes o tus herramientas habituales.

Es decir, nuestro runtime ya sea Ollama, MLX u otro no sólo nos permiten interactuar con los modelos de forma directa por la terminal sino que también exponen una API local que podemos consumir de igual modo que si llamáramos a la de OpenAI, Claude u otras…

Hacer una llamada directa a la API nativa de Ollama es tan sencillo como esto:

curl http://localhost:11434/api/generate \
  -d '{
    "model": "qwen3:8b",
    "prompt": "Explica la caché KV en tres frases",
    "stream": false
  }'

Lo mejor de esto es que generalmente el servidor es compatible con la API de OpenAI. Solo tienes que cambiar la URL base (base_url) en tu código de Python y, sin tocar nada más de tu lógica pasas a usar el modelo de tu máquina de forma totalmente privada.

⚠️ Ojo, quiero dejar claro un límite en todo esto: esta guía cubre la inferencia local en una única máquina para un solo usuario. Si lo que buscas es montar un sistema en producción para servir un modelo a múltiples usuarios concurrentes, eso es territorio de herramientas como vLLM o SGLang que da para otro post…

¿Cómo elegir un modelo? Entiende el formato GGUF

Cuando entras a HuggingFace a buscar un modelo, te vas a encontrar con nombres de archivo bastante raros, algo como esto:

Qwen3-30B-A3B-Q4_K_M.gguf

El formato GGUF se ha convertido en el estándar para distribuir modelos empaquetados listos para ejecutar. Cada bloque de texto en ese nombre de archivo te está dando información útil. Si sabes leerlo, sabrás exactamente qué estás bajando a tu equipo y como elegir algo adecuado a tus necesidades y capacidades.

El primer punto a entender es la diferencia entre los modelos Base y los Instruct (o Chat). Aunque pertenezcan a la misma familia tecnológica, su comportamiento es opuesto.

• Un modelo Base se dedica exclusivamente a continuar el texto que le pasas. No responde preguntas de forma natural, simplemente autocompleta el patrón.

• Los modelos Instruct, por el contrario, han pasado por una fase de fine-tuning para aprender a obedecer órdenes y seguir instrucciones precisas. Los modelos tipo Chat van un paso más allá y entienden el formato de diálogo entre usuario y asistente. Para tu día a día en local, casi siempre vas a querer descargar versiones Instruct o Chat.

Aquí debemos hacer un inciso, cuidado con la trampa del formato del prompt: los modelos Instruct son muy sensibles a cómo se les pasa el texto. Cada familia de modelos utiliza su propia plantilla de marcas especiales.

Si le envías simplemente la frase “Explica que es el formato GGUF” de forma cruda, estás forzando al modelo a adivinar el contexto. La forma correcta para un modelo como Qwen3 requiere marcas especiales que delimitan el sistema, el usuario y la respuesta. Herramientas como Ollama aplican estas plantillas automáticamente por detrás, y llama.cpp lo hace si usas la flag --jinja que comentamos antes. Equivocarse en este formato produce salidas ineseradas que los usuarios suelen diagnosticar erróneamente pensando que el modelo es malo.

El siguiente misterio que debemos resolver y del que te he hablado ya antes es la cuantización, que es básicamente el arte de sacrificar un poco de calidad para ahorrar memoria. Consiste en comprimir los pesos del modelo, pasando de utilizar variables flotantes de 16 bits a usar mucha menos precisión.

La escala de calidad va desde los formatos puros sin comprimir (FP16 o BF16) en lo más alto, bajando por Q8, Q6, Q4, Q3, hasta llegar a Q2 en lo más bajo. A medida que bajas escalones, el archivo encoge pero la coherencia y precisión del modelo se resiente.

Seguramente verás que muchas cuantizaciones llevan una ‘K’ y una ‘M’, como en Q4_K_M.

• Esa K significa que se ha usado cuantización K-means, que es un método de agrupamiento estadístico mucho más refinado que recortar los bits a lo bruto.

• La letra final indica el nivel de compresión dentro de esa técnica: Small, Medium o Large. Las cuantizaciones K-quants superan consistentemente a las compresiones uniformes tradicionales bajo el mismo nivel de bits.

Una regla que suelo usar para elegir la cuantización es bastante sencilla: Si tienes memoria RAM de sobra, tira a por Q8 porque es lo más cercano a la calidad original. Para un uso diario y constante, Q4_K_M es sin duda el sweet spot entre velocidad, tamaño y fiabilidad. Si la falta de memoria te afecta mucho, puedes probar Q3 asumiendo cierto riesgo de alucinación, pero te diría que huyas de Q2 para cualquier tarea medianamente seria.

Hay un resultado que choca bastante la primera vez que lo escuchas: Un modelo grande de 8B comprimido fuertemente a Q4 rinde mejor en la mayoría de tareas cotidianas que un modelo pequeño de 3B ejecutado en máxima calidad FP16.

La cuantización introduce pérdida de información, sí, pero la inteligencia base de una arquitectura más grande suele compensar con creces esa pérdida. Elegir un modelo pesado muy cuantizado suele ser mejor estrategia que elegir un modelo ligero sin comprimir.

Por último, tenemos que hablar de ese sufijo A3B, que es propio de los modelos MoE (Mixture of Experts).

En nuestro anterior ejemplo de Qwen3-30B-A3B-Q4_K_M.gguf lo que te está diciendo ese nombre es: este modelo tiene 30.000 millones de parámetros físicos en total, pero su diseño interno hace que solo active unos 3.000 millones de parámetros durante cada salto de cálculo.

Esto significa que seguimos necesitando cargar los 30.000 millones de parámetros en memoria pero el esfuerzo de cálculo recae solo sobre los parámetros activos.

En resumen, un modelo 30B-A3B va a requerir unos pesados 18 GB de memoria en Q4 para simplemente arrancar, pero a la hora de generar palabras, se sentirá casi tan rápido como un modelo de 3B.

Optimización avanzada de modelos en local

Si has llegado hasta aquí y tu modelo corre fluido y hace lo que le pides con precisión, puedes saltarte tranquilamente esta sección.

Si quieres trastear con los parámetros principales del modelo, te recomiendo hacerlo usando las opciones de la API, ya que suelen ser más estables entre actualizaciones que usar flags sueltas en la terminal.

Puedes fijar el tamaño de la ventana de contexto (num_ctx), forzar el número de capas que se envían a la gráfica (num_gpu) o ajustar el tamaño del lote (num_batch) de forma sencilla. Parámetros como la temperatura o el top_p solo modifican la aleatoriedad de las respuestas creativas, no vas a conseguir un mejor rendimiento, así que déjalos por defecto a menos que sepas lo que haces o tienes un caso especial donde aprovecharlo. Si quieres profundizar sobre estos parámetros avanzados te recomiendo esta guía.

Otra cosa que te recomiendo plantearte es aplicar cuantización directamente a la caché KV, comprimiéndola a Q8 o Q4. Esto es casi obligatorio en el momento que quieras trabajar con ventanas de contexto grandes de 32K en adelante sin fundirte toda tu memoria RAM. Sobre este tema te recomiendo este artículo.

Finalmente, de nada sirve obsesionarse con la métrica de tokens por segundo o TTFT si luego no rinde con las tareas reales del día a día. Aquí lo mejor es que hagas tus pruebas y tus benchmarks.

En función de para lo que lo uses de forma diaria, pídele que formatee una salida en JSON con campos muy específicos, pégale un artículo largo y hazle una pregunta trampa sobre un detalle del último párrafo para poner a prueba su recuperación de memoria (test de Needle In A Haystack).

Referencias técnicas

1. Especificación del formato GGUF - Documentación oficial sobre la estructura y metadatos de los archivos GGUF

2. Llama.cpp en GitHub - Repositorio principal y documentación del motor de inferencia nativo en C/C++

3. Documentación de la API de Ollama - Referencia completa de los endpoints y parámetros configurables en peticiones REST

4. MLX de Apple Research - Repositorio oficial del framework de machine learning optimizado para la arquitectura de memoria unificada de Apple Silicon

5. Michael Guo (X): Perfil de X de Michael. Todas las imágenes salvo la portada son originalmente de su propiedad y han sido traducidas al español con IA.

Es el gran dilema actual cuando integramos inteligencia artificial en entornos de producción es que queremos aprovechar al máximo la capacidad de razonamiento de los modelos, pero nos preocupa filtrar datos sensibles. Hasta ahora, la solución pasaba por crear pipelines de limpieza de datos basadas en regex principalmente.

Resumen ejecutivo (TL;DR)

OpenAI Privacy Filter es un modelo de lenguaje de pesos abiertos especializado en detectar y enmascarar información de identificación personal (PII) en textos no estructurados de forma rápida y local.

• Funciona con 1500 millones de parámetros, pero activa solo 50 millones por cada inferencia gracias a una arquitectura de mezcla de expertos dispersa.

• Procesa contextos masivos de hasta 128000 tokens en una única pasada bidireccional, entendiendo el contexto en lugar de buscar coincidencias exactas.

• Soporta la detección de ocho categorías de datos sensibles, desde números de cuenta bancaria hasta tokens de APIs.

• Se ejecuta enteramente en local con Python o directamente en el navegador del usuario utilizando Transformers.js y WebGPU.

¿Cómo filtrábamos los datos sensibles hasta ahora?

La protección de la privacidad en los sistemas de software tradicionales siempre ha dependido de la coincidencia de patrones. Si querías ocultar un número de teléfono en un registro del servidor, escribías una expresión regular que buscara secuencias de nueve dígitos o ciertos prefijos internacionales. Si querías ofuscar un correo electrónico, buscabas cadenas de texto que contuvieran una arroba rodeada de caracteres alfanuméricos.

El gran inconveniente de este enfoque determinista es que es muy rígido frente a la realidad de los datos. En un entorno controlado funciona de maravilla, pero en el mundo real la información es ruidosa. A veces los usuarios escriben los números de teléfono con separaciones extrañas, añaden comentarios en mitad de un formulario, o utilizan formatos de contraseñas que tu script simplemente no contempla.

Y lo más crítico para el filtrado de datos es que las expresiones regulares carecen de la capacidad de entender el contexto que rodea a la información. Un script clásico no es capaz de distinguir entre un correo genérico de soporte público de una gran empresa que debe conservarse para mantener el sentido del texto, y la dirección de correo personal de un cliente que debe ser eliminada obligatoriamente por normativas como el RGPD.

Aquí es exactamente donde entra en juego OpenAI Privacy Filter, planteando una solución basada en redes neuronales sensibles al contexto en lugar de reglas estáticas.

Qué es OpenAI Privacy Filter y por qué cambia el paradigma

Estamos hablando de un modelo de pesos abiertos publicado recientemente bajo la licencia permisiva Apache 2.0. Esto significa, en términos prácticos, que cualquier equipo de desarrollo puede descargarlo, modificarlo, integrarlo en su infraestructura privada y utilizarlo en entornos comerciales sin tener que pagar licencias ni depender de llamadas a una API externa.

Su objetivo principal es actuar como una barrera de seguridad, un filtro previo de privacidad. La idea es que lo instales en tu propia red y hagas que todo el texto generado por los usuarios o extraído de tus bases de datos pase por él antes de ser enviado a APIs de modelos de lenguaje externos, antes de ser indexado en bases de datos vectoriales para alimentar sistemas RAG de recuperación aumentada, o antes de ser almacenado de forma persistente en los registros de tu servidor.

Al ejecutar el modelo localmente, te aseguras de que la información de identificación personal se enmascara o se censura por completo sin que esos datos lleguen a salir de tu equipo o de tu servidor seguro.

Arquitectura de OpenAI Privacy Filter

El reto de OpenAI era crear algo lo bastante pequeño como para ejecutarse sin problemas en el portátil de un desarrollador, pero con la suficiente profundidad de parámetros como para entender matices lingüísticos complejos y evitar falsos positivos.

Privacy Filter es un modelo de clasificación de tokens bidireccional. La gran mayoría de los modelos de lenguaje a los que estamos acostumbrados, como ChatGPT, Claude o Gemini, son de naturaleza autorregresiva: leen el contexto izquierdo y generan texto de forma secuencial, prediciendo palabra por palabra.

Privacy Filter tiene un enfoque distinto donde los investigadores de OpenAI partieron de un punto de control preentrenado autorregresivo, con una arquitectura similar a gpt-oss, le quitaron la cabeza final de modelado de lenguaje y la sustituyeron por una cabeza de clasificación de tokens.

Al entrenarlo de forma bidireccional, el modelo no genera texto nuevo. Lee toda la secuencia de entrada de golpe, analizando tanto el contexto previo como el posterior de cada palabra, y asigna una etiqueta de privacidad a cada token en una sola pasada hacia adelante.

A nivel de diseño estructural, nos encontramos ante un transformer compuesto por ocho bloques repetidos y una dimensión de incrustación de 640. Pero el verdadero rendimiento proviene de dos optimizaciones fundamentales.

¿Cómo etiqueta los datos Privacy Filter?

Asignar etiquetas de privacidad a los tokens de forma completamente individual acarrea problemas severos de consistencia. Imagina que tienes en tu texto el nombre completo Alice Smith. Un modelo puramente individualista podría analizar la palabra Alice y etiquetarla correctamente como el comienzo de un nombre propio. Luego leería el espacio en blanco, se confundiría perdiendo el contexto, y podría clasificar Smith como un nombre común o ignorarlo por completo. El resultado sería una máscara fragmentada, inútil para proteger la identidad del usuario.

Para solucionar esta inestabilidad en los límites de los datos, Privacy Filter incorpora un sistema de decodificación de secuencias restringidas apoyado en el algoritmo de Viterbi, sustituyendo a la tradicional selección de la probabilidad máxima independiente.

El mecanismo funciona de tal manera que la cabeza de clasificación no decide simplemente si una palabra es privada o no, sino que emite 33 predicciones probabilísticas por cada token. El número 33 (pura coincidencia 😉) surge de utilizar el esquema de etiquetado de límites BIOES. Este sistema descompone cada una de las ocho categorías de datos sensibles del modelo en cuatro etiquetas posicionales.

• La letra B señala el inicio del dato.

• La letra I marca el interior de una frase privada.

• La letra E define el final de la cadena.

• La letra S indica que el dato sensible ocupa un único token.

Si multiplicas ocho categorías de privacidad por estas cuatro posiciones espaciales, y le sumas la clase de fondo que representa el texto no confidencial, obtienes exactamente los 33 valores de salida.

El decodificador de Viterbi toma esta matriz de probabilidades y no se queda con el valor más alto de la columna. Evalúa todas las rutas lógicas posibles a lo largo de la oración completa, penalizando las transiciones absurdas. Es matemáticamente imposible que el modelo marque el final de un número de cuenta si antes no ha marcado el inicio. Este control global sobre la secuencia garantiza que las máscaras generadas sean continuas, precisas y extremadamente coherentes incluso frente a textos desordenados.

Además, este sistema paramétrico permite a los desarrolladores ajustar el punto de funcionamiento del modelo en tiempo de ejecución. Alterando los sesgos de transición, puedes decidir si prefieres configurar un sistema altamente restrictivo que enmascare ante la más mínima duda para blindar el recall, o un sistema más permisivo que busque una precisión milimétrica para no borrar contexto valioso.

Las 8 categorías de detección y el enmascaramiento semántico

¿Qué tipo de información es capaz de detectar la arquitectura actual? El modelo ha sido entrenado, a través de conjuntos de datos públicos y sintéticos masivos, para clasificar el texto en ocho categorías de privacidad críticas para cualquier flujo de trabajo.

Identifica personas privadas, direcciones postales particulares, correos electrónicos, números de teléfono, URLs de entornos privados y fechas asociadas a información personal. Además, hay dos categorías especiales de especial relevancia:

La primera es la etiqueta account_number. Va mucho más allá de una simple búsqueda de números de cuenta bancaria o patrones de tarjetas de crédito de 16 dígitos. Engloba una enorme variedad de identificadores de bases de datos, claves primarias de facturación e información financiera que las expresiones regulares suelen ignorar sistemáticamente.

La segunda, y probablemente la más importante para la seguridad de la infraestructura, es la etiqueta secret. Esta categoría está específicamente adiestrada para localizar contraseñas en texto plano, tokens de autorización, claves de acceso a APIs, y cadenas alfanuméricas de alta entropía que suelen quedarse olvidadas en el código fuente, en los mensajes de confirmación de los repositorios o en los volcados de memoria tras un fallo del sistema.

Para que veas la capacidad del modelo frente a un texto no estructurado, observa este ejemplo proporcionado en la documentación técnica oficial. Partimos de un correo electrónico laboral cotidiano lleno de datos sensibles.

Asunto: Seguimiento de la planificación del T2

Hola, Jordan:

Gracias de nuevo por la reunión de esta mañana. Quería comentarte el calendario revisado para el despliegue del T2 y confirmar que el lanzamiento del producto está previsto para el 18 de septiembre de 2026. Como referencia, el archivo del proyecto figura con el código 4829-1037-5581. Si cambia algo por tu parte, escríbeme a maya.chen@example.com o llámame al +1 (415) 555-0124.

Atentamente,

Maya Chen

Si pasamos el texto crudo por el filtro de privacidad configurado para sustituir las detecciones por etiquetas delimitadoras, obtenemos una versión totalmente higienizada, lista para ser analizada por cualquier inteligencia artificial de terceros sin comprometer el cumplimiento normativo.

Asunto: Seguimiento de la planificación del T2

Hola, [PRIVATE_PERSON]:

Gracias de nuevo por la reunión de esta mañana. Quería comentarte el calendario revisado para el despliegue del T2 y confirmar que el lanzamiento del producto está previsto para el [PRIVATE_DATE]. Como referencia, el archivo del proyecto figura con el código [ACCOUNT_NUMBER]. Si cambia algo por tu parte, escríbeme a [PRIVATE_EMAIL] o llámame al [PRIVATE_PHONE].

Atentamente,

[PRIVATE_PERSON]

¿Cómo usar OpenAI Privacy Filter? Ejemplos

Entendida la teoría y la arquitectura, la siguiente parada lógica es ver cómo lo implementamos técnicamente. OpenAI ha puesto el modelo a disposición de la comunidad a través de los repositorios de Hugging Face.

Si tu backend principal está construido en Python, la forma más rápida de arrancar es utilizando Transformers.

from transformers import pipeline

classifier = pipeline(
    task="token-classification",p
    model="openai/privacy-filter",
)
classifier("My name is Alice Smith")

Este fragmento es perfecto para probar el modelo y validar los conceptos. Ahora bien, si estás construyendo una pipeline de datos para un entorno de producción exigente donde necesitas un control absoluto sobre la asignación de la memoria de los tensores, el enrutamiento de los dispositivos o el mapeo específico de las identificaciones de los tokens a las etiquetas de texto, la mejor estrategia es instanciar la clase de clasificación de tokens y el tokenizador de manera manual.

Presta atención a cómo se extraen las predicciones aplicando una función argmax sobre la última dimensión de la matriz de los logits generados por el modelo.

import torch
from transformers import AutoModelForTokenClassification, AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("openai/privacy-filter")
model = AutoModelForTokenClassification.from_pretrained("openai/privacy-filter", device_map="auto")

inputs = tokenizer("My name is Alice Smith", return_tensors="pt").to(model.device)

with torch.no_grad():
    outputs = model(**inputs)

predicted_token_class_ids = outputs.logits.argmax(dim=-1)
predicted_token_classes = [model.config.id2label[token_id.item()] for token_id in predicted_token_class_ids[0]]
print(predicted_token_classes)

Y aquí llegamos a la parte que considero más importante ya que puedes ejecutar el filtro de privacidad directamente en el navegador del cliente utilizando Transformers.js.

Si integras esto en tu aplicación web frontend, los datos altamente sensibles ni siquiera llegan a abandonar el dispositivo local del usuario para ser procesados. La evaluación y el enmascaramiento ocurren de manera descentralizada aprovechando la capacidad de la tarjeta gráfica del propio equipo mediante la API de WebGPU. Combinando esto con una cuantización de nivel q4 para comprimir los pesos del modelo y reducir la ocupación de memoria RAM se obtiene un rendimiento bastante bueno:

import { pipeline } from "@huggingface/transformers";

const classifier = await pipeline(
  "token-classification", "openai/privacy-filter",
  { device: "webgpu", dtype: "q4" },
);

const input = "My name is Harry Potter and my email is harry.potter@hogwarts.edu.";
const output = await classifier(input, { aggregation_strategy: "simple" });
console.dir(output, { depth: null });

Rendimiento y benchmarks

En las pruebas de evaluación contra el benchmark estándar de la industria PII-Masking-300k, el Privacy Filter obtiene una puntuación F1 del 96 por ciento (94,04% de precisión y 98,04% de recall).

Además, si operas en un sector de nicho con convenciones de nombres atípicas o identificadores de bases de datos heredadas con formatos muy particulares, puedes reentrenar el modelo con un conjunto de datos interno pequeño. En las pruebas de adaptación de dominio, el modelo fue capaz de elevar su precisión desde un modesto 54% hasta rozar el 96% tras someterlo a un ajuste fino concentrado, acercándose rápidamente a la saturación de aprendizaje.

Limitaciones y responsabilidades de cumplimiento

OpenAI Privacy Filter es una buena herramienta pero no es algo seguro ni una garantía legal de anonimización absoluta bajo ninguna jurisdicción.

Como ocurre con cualquier red neuronal, este modelo es susceptible a cometer errores de clasificación. Puede pasar por alto convenciones de nombres regionales poco comunes, iniciales aisladas o referencias ambiguas que requerirían conocimientos previos sobre las personas involucradas.

Es por todo esto que, en entornos de despliegue crítico con alta sensibilidad de datos, como pueden ser los sistemas de historiales médicos hospitalarios, las auditorías legales profundas o la gestión de transacciones financieras internacionales, tanto la revisión humana periódica como las auditorías de exactitud en dominio siguen siendo un eslabón insustituible.

Referencias técnicas

1. OpenAI Privacy Filter - Anuncio Oficial - Artículo fundacional sobre el lanzamiento, el ecosistema de seguridad y los casos de uso sugeridos.

2. Hugging Face - Tarjeta del modelo Privacy Filter - Repositorio oficial con la arquitectura detallada, instrucciones de instalación, descargas y pesos abiertos.

No tiene absolutamente nada que ver balancear una API o un front o un servidor para inferencia de LLMs. Si pones un balanceador round-robin de toda la vida delante de tus réplicas de GPU, la latencia se disparará y los costes de inferencia se multiplican. ¿Y esto por qué ocurre? Por el prompt caching, un término del que te he hablado varias veces en el blog y hoy volvemos a él.

Resumen ejecutivo (TL;DR)

El balanceo de carga especializado para LLMs resuelve el problema de la fragmentación de memoria al distribuir las peticiones basándose en el contexto previo almacenado en las GPUs de inferencia.

• El enrutamiento clásico tipo round-robin anula las ventajas del prompt caching, reduciendo el hit rate de forma casi lineal al escalar el clúster.

• La solución técnica pasa por un enrutamiento consciente de la caché que analiza los tokens y envía la petición a la instancia que ya tiene ese contexto en su VRAM.

• El proceso de inferencia se divide en dos fases con necesidades de hardware distintas: Prefill y Decode.

• Para contextos enormes, la industria de la IA está adoptando arquitecturas desagregadas, separando los nodos de procesamiento de los nodos de generación.

¿Por qué el balanceo de carga clásico no funciona en infraestructuras de IA?

En una arquitectura web tradicional, el balanceo de carga es bastante predecible: Hay un balanceador que reparte el tráfico entre los N servidores que tengas usando algoritmos como round-robin, enviando una petición a cada máquina de forma secuencial. Como la mayoría de estos servicios guardan el estado o las sesiones en una base de datos externa, da exactamente igual qué servidor atienda la petición en la mayoría de los casos.

Pero los LLMs no funcionan así. El estado aquí no vive en una base de datos externa tradicional, vive en la memoria de la GPU en forma de contexto.

Aquí es donde entra el prompt caching. Esta técnica es la que reduce los costes de los tokens de entrada entre un 50% y un 90%. Además, recorta el tiempo hasta el primer token (TTFT) hasta en un 80%.

El problema es que estos ahorros de costes asumen que la petición del usuario llega exactamente a la réplica (servidor) que ya tiene ese prefijo de contexto concreto almacenado en su caché.

Fíjate en lo que pasa si usas un balanceador aleatorio o un round-robin ingenuo en una flota de N réplicas. Tu probabilidad de aprovechar la caché es de 1 dividido entre N.

Es decir, a medida que escalas tu infraestructura para soportar más tráfico, la eficiencia de caché cae en picado de forma lineal. El balanceador clásico no sabe qué hay en la memoria de cada nodo, así que termina enviando peticiones ciegas a máquinas que no tienen el contexto del usuario.

Cómo procesan los tokens los motores de inferencia: Prefill y Decode

Para entender cómo solucionar el enrutamiento, primero hay que entender qué pasa dentro de motores de inferencia como vLLM, SGLang o TensorRT. Cuando lanzas una petición HTTP, el motor ejecuta dos fases muy diferenciadas.

• La primera es la fase de Prefill. Aquí el prompt se tokeniza y se procesa de golpe en una sola pasada hacia adelante. Es una fase que requiere mucha capacidad de cálculo bruto. Durante este paso se calculan los tensores Key y Value (KV) especiales y se devuelve el primer token de salida.

• La segunda es la fase de Decode. Este es el bucle auto-regresivo donde se genera un token, se actualizan los tensores KV, y se repite hasta llegar al límite de longitud o al token de fin de secuencia. A diferencia del Prefill, el Decode está limitado casi exclusivamente por el ancho de banda de la memoria de la GPU, no por el cómputo puro.

Enviar peticiones a servidores al azar es tirar dinero y recursos. La industria de la IA para solucionar este problema empezó usando el hashing aunque seguramente hayáis leído más el término de sticky sessions que consiste en vincular el identificador de un usuario a un servidor en concreto. Funciona bastante bien para historiales de chat largos, pero la primera petición del usuario sigue siendo una lotería y puede caer en una máquina completamente fría.

La evolución natural de esta solución fue el enrutamiento consciente de la caché. Aquí el router mantiene una estructura de datos, para cada instancia de tal mod que cuando llega un prompt, itera sobre la estructura de datos para encontrar la instancia con el prefijo coincidente más largo.

Esta solución puede sonar genial en la teoría, pero en la práctica no funciona tan bien ya que genera desincronización.

El enrutamiento preciso de prefijos

Para solucionar este problema de desincronización entra en juego el enrutamiento preciso de prefijos conscientes de la caché (precise prefix cache-aware routing).

La diferencia respecto al resto de soluciones es que este sistema elimina las suposiciones por completo. En lugar de que el router adivine qué tiene cada servidor en su memoria, captura eventos reales de la KV caché. Es decir, los propios motores de inferencia avisan al router en tiempo real sobre qué información guardan y cuál descartan.

Pero claro, para aprovechar esta precisión y saber exactamente a qué máquina enviar la petición, el router tiene que comunicarse con las GPUs por lo que debe asumir un pequeño trabajo extra que consiste en tokenizar el prompt de entrada antes de buscar la coincidencia de prefijos en su árbol de datos.

Añadir este paso de procesamiento en el balanceador podría parecer una mala idea, pero tokenizar es una muy barata a nivel computacional. Si lo comparamos con el tiempo y dinero que cuesta hacer la fase de inferencia completa por haber mandado la petición a una máquina fría, el balance final compensa:

En los benchmarks de la comunidad, este tipo de enrutamiento logra aumentar el rendimiento hasta un 108% (usando la misma configuración de hardware), simplemente asegurando que cada petición llega donde ya existe el contexto.

Servidores desagregados para secuencias kilométricas

Llega un punto donde tener el router perfecto no es suficiente. Imagínate que le inyectas a un modelo un documento enorme de unos 100.000 tokens de contexto solo para generar una respuesta corta de 1.000 tokens, un caso extremo.

La fase inicial de procesar todo ese texto de golpe (Prefill) requiere mucha fuerza bruta de cálculo pero luego la fase de generar la respuesta token por token (Decode) no necesita tanta capacidad de cálculo, pero exige una memoria muy rápida. Si usas el mismo tipo de GPU para las dos tareas, estarás desperdiciando recursos.

La solución para optimizar esto a gran escala es el serving desagregado. La idea consiste en separar físicamente las máquinas para que unas se dediquen en exclusiva a procesar la entrada y otras solo a generar la salida.

Pero claro, la máquina que escribe la respuesta necesita disponer del contexto (la caché KV) que acaba de calcular la máquina que procesó la entrada. Mover toda esta información de un servidor a otro tiene que hacerse a una velocidad muy rápida para evitar latencia. Para lograrlo la industria utiliza tecnologías de transferencia por red muy específicas como NCCL de Nvidia o RCCL de AMD.

Por muy avanzado que sea el cable de red, transferir datos de un equipo a otro siempre será más lento que leerlos directamente de la memoria local de una GPU. Por eso esta separación física solo compensa cuando los contextos de entrada son extremadamente grandes. Si trabajas con secuencias pequeñas o interacciones de chat normales, el tiempo que se pierde moviendo la caché por la red perjudica el rendimiento. En la gran mayoría de casos comunes, es mucho más rápido dejar que una sola máquina haga todo el trabajo.

Referencias técnicas

1. Load Balancing and Scaling LLM Serving - Análisis técnico detallado sobre el funcionamiento de las fases de inferencia, estrategias de enrutamiento basado en árboles Radix y arquitectura desagregada.

Hace poco Andrej Karpathy del que ya os he hablado varias veces en el blog, compartió una idea sobre cómo está utilizando los LLMs últimamente y me encantó.

En lugar de usar herramientas de recuperación de datos o bases de datos vectoriales, está usando modelos locales para construir y mantener una base de conocimiento personal en formato texto plano.

Él lo llama una LLM Wiki. La premisa es que tú te encargas de investigar y el modelo se encarga de hacer el trabajo sucio de mantener los enlaces, crear resúmenes y estructurar la información. He estado probando este sistema durante las últimas semanas y hoy vengo a explicarte por qué tú también deberías.

Resumen ejecutivo (TL;DR)

Este sistema sustituye los flujos tradicionales de RAG por una base de conocimiento persistente donde el modelo de lenguaje actúa como bibliotecario automatizado de tus archivos locales. En lugar de buscar en documentos cada vez que preguntas algo, el modelo compila, enlaza y mantiene notas estructuradas que crecen con el tiempo.

• Los documentos originales se guardan en una carpeta de fuentes y nunca se modifican.

• El modelo lee esas fuentes, extrae la información clave y genera páginas de la wiki en formato Markdown conectadas entre sí.

• Utilizas Obsidian como entorno visual para leer y navegar por el grafo de conocimiento que la máquina ha creado.

• Empleas agentes de terminal como Claude Code para ejecutar consultas, generar nuevos documentos y realizar tareas de mantenimiento directamente sobre tu sistema de archivos.

¿Por qué el RAG tradicional no es eficiente para este problema?

La inmensa mayoría de las implementaciones que vemos hoy en día para interactuar con documentos funcionan bajo el mismo patrón de Retrieval-Augmented Generation o RAG de hecho herramientas como NotebookLM o la subida de archivos de ChatGPT operan así. Tienes un montón de documentos, haces una consulta, el sistema busca los párrafos más similares semánticamente, los inyecta en el contexto y te da una respuesta.

Esto funciona bien para consultas puntuales, pero tiene un fallo de diseño cuando se trata de conocimiento personal que evoluciona: el modelo redescubre la información desde cero en cada consulta. No hay acumulación de saber. Si haces una pregunta sutil que requiere sintetizar cinco documentos distintos, el sistema tiene que encontrar y unir esos fragmentos en ese preciso instante. Nada se construye a largo plazo.

La idea de la LLM Wiki es que en lugar de recuperar información de los documentos tal cual en el momento de la consulta, el modelo construye de forma incremental y mantiene una wiki persistente.

Cuando añades un nuevo artículo sobre un tema a tus notas, el modelo no se limita a indexarlo para buscarlo luego. Lo lee, extrae la información clave y la integra en la wiki existente. Actualiza las páginas de los conceptos, revisa los resúmenes de los temas, anota dónde los nuevos datos contradicen afirmaciones antiguas y fortalece la síntesis general. El conocimiento se compila una sola vez y se mantiene actualizado.

👉🏻 La wiki es un artefacto compuesto y persistente. Las referencias cruzadas ya están hechas. Y lo mejor de todo es que tú casi nunca escribes en la wiki. El modelo escribe y mantiene todo. Tú te encargas del abastecimiento de datos, la exploración y de hacer las preguntas correctas. El modelo hace el trabajo de crear la base de conocimiento para sea realmente útil con el paso de los meses.

¿Por qué usamos Markdown?

La mayoría de aplicaciones de notas están diseñadas para la lectura humana, están optimizadas para que tú encuentres las cosas manualmente.

Una LLM Wiki está optimizada para que el modelo lea en tu nombre. Ese pequeño cambio de paradigma cambia cómo estructuramos la información. El modelo no entiende de carpetas de colores, etiquetas visuales o bases de datos relacionales bloqueadas tras una interfaz web. El modelo lee texto. Por tanto, el Markdown, que no deja de ser texto plano con una sintaxis mínima, es el formato perfecto.

Además, la mayoría de los modelos han sido entrenados con cantidades masivas de contenido en Markdown procedente de repositorios de GitHub, documentación técnica y foros. La sintaxis es parte nativa de su comprensión. Un encabezado, una lista de viñetas, un bloque de código o un texto en negrita son interpretados por el modelo como estructura jerárquica pura, no como ruido visual.

La arquitectura de LLM Wiki: Fuentes, Wiki y Esquema

Karpathy propone una arquitectura minimalista pero muy estricta basada en tres capas lógicas para que sea un sistema que no se vuelva un caos a los meses de usarlo.

1. La primera capa son las fuentes originales. Esta es tu colección curada de documentos originales. Pueden ser artículos web descargados, papers en PDF, repositorios de código, imágenes o archivos de datos. Esta carpeta es inmutable. El modelo lee de aquí pero jamás modifica un archivo de esta carpeta. Es tu fuente de verdad absoluta.

2. La segunda capa es la wiki en sí misma. Es un directorio lleno de archivos Markdown generados íntegramente por el modelo. Aquí encontrarás resúmenes, páginas de entidades, páginas de conceptos técnicos, tablas comparativas y documentos de síntesis. El modelo es el dueño absoluto de esta capa. Crea páginas, las actualiza cuando llegan nuevas fuentes, mantiene los enlaces internos y asegura la consistencia.

3. La tercera capa es el esquema. Este es el cerebro del sistema operativo. Consiste en un archivo de configuración, típicamente llamado CLAUDE.md si usas la herramienta de Anthropic, que le dice al modelo cómo está estructurada la wiki, cuáles son las convenciones de nombrado y qué flujos de trabajo debe seguir al procesar fuentes o responder preguntas. Tú y el modelo evolucionáis este archivo con el tiempo a medida que descubres qué funciona mejor para tus necesidades concretas.

Cómo operan los modelos sobre tu sistema de ficheros

El valor de LLM Wiki viene de las operaciones que el modelo ejecuta sobre los documentos originales. Existen tres flujos de trabajo principales que automatizan casi por completo la gestión del conocimiento.

1. La ingesta de datos. Dejas un paper, PDF o lo que sea en la carpeta y le dices al agente de terminal que la procese. El flujo normal sería que el modelo lea el documento, discuta contigo las conclusiones clave, escriba una página de resumen en la wiki, actualice el archivo de índice general, modifique las páginas de conceptos relevantes en toda la wiki y finalmente añada una entrada al registro de actividad.

2. Las consultas. Le haces preguntas al modelo contra el directorio de la wiki. El agente busca las páginas relevantes, las lee y sintetiza una respuesta con citas directas a tus propios archivos. Aquí es donde las respuestas no tienen por qué ser simplemente texto en la terminal. Puedes pedirle que genere un nuevo archivo Markdown con la respuesta, que cree una presentación de diapositivas usando el formato Marp, o que genere un script en Python que pinte un gráfico con matplotlib basado en los datos de tus notas.

3. Mantenimiento y linting. Periódicamente, le pides al modelo que haga un chequeo de de toda la wiki. Le pides que busque contradicciones entre páginas, afirmaciones obsoletas que hayan sido superadas por fuentes más recientes, páginas huérfanas sin enlaces entrantes, conceptos importantes que se mencionan mucho pero no tienen su propia página dedicada, o huecos de información que podrían requerir una búsqueda en internet.

Para facilitar todo esto, el sistema depende de dos archivos de control:

• Un archivo index.md que actúa como un catálogo de todo el contenido, organizado por categorías y con resúmenes de una línea. El modelo lee este índice primero para saber dónde buscar sin tener que procesar gigabytes de texto.

• Archivo log.md que es un registro cronológico de todo lo que ha pasado. Si cada entrada del log empieza con un prefijo consistente, puedes usar herramientas de terminal básicas para revisarlo.

Guía paso a paso: Construye tu LLM Wiki con Obsidian y Claude Code

Implementar todo esto que te he contado es rápido y no necesitas configurar nada complejo como en otras soluciones. Vamos a montar un entorno funcional en menos de cinco minutos utilizando Obsidian como interfaz gráfica y Claude Code como motor de procesamiento.

(1) Lo primero es instalar Obsidian y crear tu vault. Descargas la aplicación desde su web oficial y creas un nuevo vault en una carpeta accesible de tu equipo (en Obsidian, un vault no es más que una carpeta normal del sistema operativo)

(2) El segundo paso es definir una plantilla base. La consistencia es lo que permite que el modelo pueda consultar los datos de forma fiable. Crea una carpeta llamada _templates y dentro un archivo note.md con una estructura estandarizada. Algo como esto:

# {{title}}

**Resumen**: Una sola frase describiendo el contenido de esta nota.
**Etiquetas**: #tema1 #tema2
**Fecha de creación**: {{date}}
**Última actualización**: {{date}}

---

## Contenido
Desarrollo principal de la nota.

## Notas relacionadas
- [[Título de otra nota]]

No hace falta que uses exactamente esta estructura, adáptalo a tus necesidades pero es muy importante que cada nota tenga una línea de resumen y etiquetas en la cabecera. Estas pequeñas pistas dan al modelo señales rápidas sobre la relevancia de un documento sin obligarle a leer el archivo completo cada vez.

(3) El tercer paso es organizar la jerarquía básica de carpetas. Empieza con cuatro o cinco carpetas de nivel superior. Una carpeta _templates para las plantillas, una carpeta _fuentes para los documentos inmutables, una carpeta proyectos, una de investigacion y finalmente un inbox. La carpeta inbox es el cajón desastre donde tiras notas rápidas que aún no están procesadas. Más adelante, el modelo te ayudará a clasificarlas.

(4) El cuarto paso es instalar el agente. Necesitas tener Node.js instalado en tu equipo. Abre la terminal y ejecuta el comando de instalación de Claude Code.

npm install -g @anthropic-ai/claude-code

Una vez instalado, te pedirá que te autentiques con tu cuenta de Anthropic. Este agente funciona directamente en tu terminal y tiene permisos para leer y escribir en el directorio donde lo ejecutes.

(5) El último paso es empezar a consultar tu wiki. Navegas con la terminal hasta la carpeta de tu vault y lanzas el agente.

cd ~/Documentos/llm-wiki
claude

A partir de este momento, puedes empezar a darle órdenes. Puedes pedirle cosas como: “Revisa todos los documentos de la carpeta de investigación relacionados con Kubernetes y hazme un resumen comparativo de las herramientas mencionadas, guardando el resultado en un nuevo archivo llamado comparativa-k8s.md”. El agente leerá los archivos, procesará la información, redactará el documento y lo guardará en tu disco. Si tienes Obsidian abierto a un lado de la pantalla, verás aparecer el archivo en tiempo real.

Buenas prácticas para estructurar tus notas y evitar alucinaciones

A medida que tu base de datos crezca, la calidad de las respuestas del modelo dependerá directamente de cómo estén tus archivos. Aquí te dejo varias claves que comparte Karpathy:

• Escribir resúmenes explícitos es probablemente la práctica más rentable. Cuando haces una consulta grande, el modelo a menudo lee primero las cabeceras de muchos archivos para decidir cuáles merecen una lectura profunda. Un buen resumen te cuesta diez segundos escribirlo y ahorra un montón de tokens y tiempo de inferencia evitando lecturas innecesarias.

• La consistencia terminológica es otro factor clave. Si en unas notas escribes K8s y en otras Kubernetes, los modelos actuales son lo bastante inteligentes para conectarlo la mayoría de las veces, pero obtendrás resultados mucho más limpios y un grafo de conocimiento más robusto si eliges un término y lo mantienes.

• Obliga al modelo a enlazar las notas entre sí. El formato de enlaces de Obsidian usando dobles corchetes [[Nombre de la nota]] crea conexiones explícitas. Un modelo navegando por tu sistema de archivos puede seguir estas conexiones. Una wiki bien enlazada le da a la máquina un grafo relacional rico sobre el que razonar, en lugar de una simple colección plana de archivos aislados.

• Mantén las notas enfocadas en un solo tema. Un documento enorme de diez mil palabras que abarca cinco proyectos distintos es una pesadilla para el análisis posterior. Si una nota empieza a cubrir múltiples conceptos claramente diferenciados, pídele al modelo que la divida en archivos más pequeños e interconectados. Cuanto más específica sea cada página, con mayor precisión podrá el modelo localizarla y aplicar su contenido a tus futuras preguntas.

Referencias técnicas

1. Claude Code Documentation - Guía oficial de instalación y uso del agente de terminal de Anthropic.

2. Obsidian - Entorno de desarrollo y visualización de conocimiento en formato Markdown local.

3. Marp for VS Code / Obsidian - Ecosistema de herramientas para crear presentaciones técnicas directamente desde archivos Markdown.

4. Dataview Plugin GitHub Repository - Documentación técnica del motor de consultas y visualización de metadatos para Obsidian.

La semana pasada, AWS lanzó oficialmente Amazon S3 Files. Y la comunidad ya está diciendo que es la actualización más grande e importante que ha recibido S3 en sus veinte años de historia.

Después de estudiar y probar esta actualización te cuento qué es AWS S3 Files, cómo funciona, cómo usarlo y por qué es tan importante como dicen.

Resumen ejecutivo (TL;DR)

Amazon S3 Files sirve para montar buckets de S3 como sistemas de ficheros nativos en tus instancias EC2, contenedores o funciones Lambda, eliminando la necesidad de herramientas de terceros o sincronizaciones complejas.

Las ideas clave de esta actualización son:

• AWS permite ahora acceso completo de sistema de ficheros a tus buckets de S3, reflejando automáticamente los cambios en el almacenamiento de objetos.

• Funciona utilizando Amazon EFS por debajo para ofrecer latencias de submilisegundo en los datos activos.

• Soporta operaciones NFS v4.1+ y permisos POSIX nativos (UID/GID), integrándose directamente con IAM y KMS.

• Es ideal para sistemas de IA agénticos y pipelines de machine learning que necesitan mutar datos de forma compartida sin duplicarlos.

• Se configura creando un sistema de ficheros y puntos de montaje en tu VPC, accesibles mediante comandos estándar de Linux.

El problema histórico con el almacenamiento de objetos

Para entender por qué este lanzamiento es tan importante, tenemos que dar un paso atrás y ver cómo hemos estado trabajando hasta ahora. Estamos acostumbrados a interactuar con ficheros en nuestro ordenador. Abres un archivo, modificas una línea, lo guardas y listo.

Pero Amazon S3 nunca ha funcionado así. S3 es un almacén de objetos. Como explicaba el propio equipo de AWS, la mejor analogía es comparar los objetos de S3 con los libros de una biblioteca. Si quieres editar una página de un libro en esa biblioteca, no puedes ir con un bolígrafo y cambiarla: tienes que sacar el libro entero, escribir un libro nuevo con la corrección y poner el libro nuevo en la estantería sustituyendo al anterior. En cambio, los ficheros de tu ordenador sí te permiten modificar página a página.

Si tenías una aplicación legacy que escribía logs añadiendo líneas al final de un fichero, no podías apuntarla a S3 directamente. Tenías que usar un disco EBS, llenar el disco y luego hacer un volcado periódico al bucket.

Qué es exactamente Amazon S3 Files

Lo que AWS ha presentado con S3 Files es el primer y único almacén de objetos en la nube que ofrece acceso completo y de alto rendimiento como sistema de ficheros. Básicamente, hace que tus buckets sean accesibles como sistemas de ficheros nativos.

Esto significa que a partir de ahora, S3 se convierte en un centro de datos real que es accesible directamente desde cualquier instancia de computación, contenedor o función en AWS. Cualquier cambio que hagas en los datos a través del sistema de ficheros se refleja automáticamente en el bucket de S3, y además tienes control detallado sobre cómo ocurre esa sincronización.

Puedes acceder a cualquier bucket de propósito general como un sistema de ficheros nativo desde tus instancias Amazon EC2, contenedores corriendo en Amazon ECS o Amazon EKS, o incluso funciones AWS Lambda. El sistema presenta tus objetos de S3 como ficheros y directorios normales, soportando todas las operaciones del protocolo Network File System (NFS) v4.1 y superiores. Puedes crear, leer, actualizar y borrar ficheros exactamente igual que harías en tu terminal de Linux local.

Cómo funciona la arquitectura de AWS S3 Files

AWS no ha reinventado nada sino que ha combinado dos de sus servicios más robustos de una forma muy inteligente. S3 Files utiliza la tecnología de Amazon Elastic File System (Amazon EFS) para entregar latencias cercanas al milisegundo para los datos activos.

Cuando trabajas con ficheros y directorios específicos a través de este nuevo montaje, los metadatos y el contenido de esos ficheros se colocan en un almacenamiento de alto rendimiento propio del sistema de ficheros. Por defecto, los ficheros que se benefician de un acceso de baja latencia se almacenan y se sirven desde esta capa rápida.

Peeero, AWS sabe que mover terabytes de datos a una capa rápida es caro e ineficiente si no los vas a usar todos a la vez. Por eso, para los ficheros que no están almacenados en la capa de alto rendimiento, como aquellos que necesitan grandes lecturas secuenciales, S3 Files los sirve automáticamente de forma directa desde Amazon S3 para maximizar el ancho de banda.

Para las lecturas de rangos de bytes específicos el sistema solo transfiere los bytes solicitados, minimizando el movimiento de datos. Si tienes un fichero de video de 50 GB y tu aplicación solo necesita leer los metadatos de la cabecera, no te descargas los 50 GB por ejemplo.

Además, el sistema soporta un mecanismo inteligente de pre-fetching para anticiparse a tus necesidades de acceso a los datos. Te da control granular sobre qué se almacena en la capa de alto rendimiento, permitiéndote decidir si quieres cargar los datos completos del fichero o únicamente sus metadatos. Esto te permite optimizar el sistema para tus patrones de acceso específicos.

Cómo impacta AWS S3 Files a los Agentes de IA y Machine Learning

Todo esto de los sistemas de ficheros está muy bien para aplicaciones legacy, pero donde S3 Files creo que va a destacar mucho es en el desarrollo de Inteligencia Artificial.

Piensa en cómo funcionan los agentes de IA hoy en día. Si estás construyendo un sistema agéntico, probablemente estés usando herramientas que dependen de librerías de Python. Librerías como Pandas, NumPy o utilidades de línea de comandos esperan interactuar con un disco local. Esperan poder hacer un simple open() y leer un archivo CSV.

Antes, para que tu agente leyera un dataset de S3, tenías que escribir código con la librería Boto3 para descargar el objeto, guardarlo en el disco temporal de la instancia, procesarlo con el agente y luego volver a subir el resultado.

Ahora, con S3 Files, los agentes de IA pueden colaborar a través de herramientas basadas en ficheros leyendo y escribiendo directamente en el montaje como si fuera un disco local. Ahora podemos acceder a esos mismos objetos a través de la API estándar de S3 mientras los agentes mutan la información.

Para los pipelines de entrenamiento de Machine Learning todo vuelve a cambiar cuando queremos procesar datasets inmensos de forma colaborativa. Ahora tienes acceso compartido a través de clústeres de computación sin tener que duplicar los datos. El pipeline de ML entrena leyendo directamente de la ruta montada, con latencias de submilisegundo, y los resultados o los pesos del modelo se escriben directamente en el mismo directorio, sincronizándose automáticamente con el bucket.

Cómo probar y montar tu primer bucket de S3 Files

Crear el primer sistema de ficheros de Amazon S3, montarlo y usarlo desde una instancia EC2 es un proceso bastante directo.

AWS permite hacer esto mediante la consola de administración, a través de la interfaz de línea de comandos (AWS CLI) o utilizando infraestructura como código (IaC). Vamos a repasar el flujo usando la consola para entender bien las piezas involucradas. Este es el diagrama de arquitectura de ejemplo que seguiré de AWS:

Paso 1: Crear el sistema de ficheros en la consola

Lo primero que necesitas es tener una instancia EC2 y un bucket de propósito general ya creados.

Te vas a la sección de Amazon S3 en la consola de AWS. Allí verás una nueva opción llamada File systems (Sistemas de ficheros). Haces clic ahí y luego seleccionas Create file system.

El sistema te pedirá que introduzcas el nombre del bucket que quieres exponer como un sistema de ficheros. Simplemente pones el nombre de tu bucket y confirmas la creación.

Paso 2: Configurar los puntos de montaje en tu red

Aquí entra en juego la parte de red. Para que tu servidor pueda hablar con este nuevo sistema de ficheros, necesitas un target de montaje (mount target). Un mount target es un endpoint de red que vivirá dentro de tu Nube Privada Virtual (VPC) y es lo que permite que tu instancia EC2 acceda al sistema de ficheros de S3.

Si usas la consola web, estos puntos de montaje se crean automáticamente. Solo tienes que ir a la pestaña de Mount targets y apuntar los IDs que se han generado, porque los necesitarás luego.

Paso 3: Montar el sistema en tu instancia EC2

Una vez que tienes el ID del sistema de ficheros y el punto de montaje en tu VPC, te conectas a tu instancia EC2.

El proceso es idéntico a montar cualquier otro disco de red en Linux. Primero creas el directorio donde quieres que aparezcan tus datos:

sudo mkdir /home/ec2-user/s3files

Y luego ejecutas el comando de montaje indicando que el tipo es s3files y pasando el ID de tu sistema de ficheros:

sudo mount -t s3files fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files

A partir de ese momento, puedes trabajar con tus datos de S3 directamente a través de ese directorio montado usando operaciones de fichero estándar.

Si haces un echo “Hola” > s3files/test.txt, el archivo se crea localmente. S3 gestiona automáticamente las actualizaciones y exporta esos cambios como un nuevo objeto (o una nueva versión si tienes el versionado activado) de vuelta a tu bucket de S3 en cuestión de segundos.

Si el cambio se hace a la inversa, es decir, si alguien sube un objeto directamente al bucket de S3 vía API, esos cambios son visibles en el sistema de ficheros montado en unos pocos segundos, aunque a veces puede tardar un minuto o algo más en reflejarse según Amazon.

Seguridad, permisos POSIX y monitorización

En cuanto a control de acceso, S3 Files se integra de forma nativa con IAM para que puedas utilizar políticas de identidad y políticas de recursos para gestionar los permisos tanto a nivel del sistema de ficheros como a nivel del propio objeto.

Los datos siempre viajan cifrados en tránsito utilizando el protocolo TLS 1.3. Para los datos en reposo, el sistema utiliza cifrado mediante claves gestionadas por Amazon S3 (SSE-S3) o mediante claves gestionadas por el cliente utilizando AWS Key Management Service (AWS KMS).

Un detalle técnico importante si vas a usar esto en instancias antiguas: debes asegurarte de tener instalada la última versión del driver de EFS, el paquete amazon-efs-utils. Si usas las imágenes oficiales de Amazon (AMI), este paquete ya viene preinstalado, pero siempre conviene actualizarlo a la última versión disponible.

S3 Files VS. Amazon FSx, ¿Cuál elegir?

AWS ya tiene muchos servicios de almacenamiento que se solapan entre ellos . Si S3 ahora actúa como un sistema de ficheros, ¿qué pasa con Amazon FSx?

Siguiendo el blog de Amazon, S3 Files funciona mejor cuando necesitas acceso interactivo y compartido a datos que ya viven o deben vivir en Amazon S3, utilizando una interfaz de sistema de ficheros de alto rendimiento. Como decíamos antes, es la opción ideal cuando múltiples recursos de computación necesitan leer, escribir y mutar datos de forma colaborativa.

Por otro lado, Amazon FSx sigue siendo la herramienta adecuada para cargas de trabajo específicas. Si estás migrando entornos NAS locales (on-premises) a la nube, FSx te proporciona las características familiares y la compatibilidad estricta que necesitas.

A nivel de facturación, con S3 Files vas a pagar por la porción de datos que esté almacenada en tu sistema de ficheros, por las operaciones de lectura de ficheros pequeños, por todas las operaciones de escritura al sistema de ficheros, y por las peticiones de S3 generadas durante la sincronización de datos entre el sistema de ficheros y el bucket.

Referencias técnicas

1. Launching S3 Files, making S3 buckets accessible as file systems - Anuncio oficial y guía técnica de implementación en el blog de AWS.

¿Alguna vez has pensado la cantidad de dinero que tiramos a la basura repitiendo las mismas instrucciones en cada llamada a una API de IA? Es una de esas ineficiencias que, cuando escalas un proyecto, se convierte en un pozo de dinero en tu factura a tu proveedor de IA. Llevamos un par de años aceptando que, cada vez que enviamos un prompt de 10.000 tokens, el modelo tiene que procesar esos 10.000 tokens desde cero, aunque el 90% del contenido sea exactamente igual al que enviamos hace cinco minutos.

El prompt caching ha venido a solucionar este problema (por lo menos en parte). Ya no es solo una optimización técnica para que la respuesta tarde menos en salir, es un cambio estructural en cómo diseñamos la arquitectura de nuestros prompts y cómo gestionamos el flujo de caja de nuestras aplicaciones. Si no estás usando prompt caching, estás pagando un recargo por desconocimiento técnico.

Resumen ejecutivo (TL;DR)

El prompt caching es una técnica que permite a los modelos de IA reutilizar el trabajo computacional ya realizado sobre partes de un prompt que se repiten entre diferentes peticiones. En lugar de recalcular la atención de todo el texto, el sistema guarda un estado matemático (KV Cache) del prefijo compartido.

• Permite ahorrar hasta un 90% en los costes de tokens de entrada y reducir la latencia del primer token (TTFT) en un 80%.

• Funciona mediante la coincidencia exacta de prefijos de al menos 1024 tokens, con incrementos de 128 tokens.

• La optimización crítica consiste en mantener el contenido estático (instrucciones, herramientas, esquemas) al principio y lo volátil (entrada del usuario) al final.

• OpenAI permite mejorar la tasa de acierto mediante el parámetro prompt_cache_key, que ayuda a dirigir peticiones similares al mismo servidor físico.

¿Qué es y cómo funciona el prompt caching?

Para entender por qué el prompt caching ahorra dinero, hay que bajar un momento al barro de cómo funciona un Transformer. Cuando envías un texto a un modelo como GPT-4o o GPT-5, el proceso se divide en dos fases: el prefill y la generación. En el prefill, el modelo lee todo tu prompt de golpe para entender el contexto. Aquí es donde ocurre el proceso de la atención: cada token mira a todos los demás tokens para establecer relaciones semánticas.

Técnicamente, el modelo genera tres vectores por cada token: una consulta (Query), una clave (Key) y un valor (Value).

El prompt caching se enfoca específicamente en los vectores Key y Value (la famosa KV Cache de la que te hablaba la semana pasada). Si envías una instrucción de 5.000 tokens sobre cómo debe comportarse un agente legal, el modelo calcula esos vectores para esos 5.000 tokens. Si un segundo después envías otra pregunta con esa misma instrucción, ¿por qué deberíamos calcularlo otra vez?

El prompt caching permite que el sistema detecte que el prefijo del mensaje es idéntico a uno procesado recientemente. En lugar de encender los núcleos de la GPU para volver a calcular la atención de esos 5.000 tokens, simplemente carga los vectores K y V desde la memoria.

Esto cambia la complejidad del prefill. Tradicionalmente, procesar el prompt tiene un coste computacional que escala de forma cuadrática o lineal-pesada con la longitud. Con la caché, si el hit es total, el tiempo de procesamiento del prompt tiende a cero, y la latencia total de la respuesta pasa a depender casi exclusivamente de cuántos tokens nuevos tiene que generar el modelo.

¿Cuánto podemos ahorrar usando Prompt Caching?

Hablemos de dinero, que es lo que suele convencer a los managers para priorizar estas tareas. OpenAI y Anthropic han implementado estructuras de precios donde los tokens servidos desde la caché tienen un descuento masivo. No es una pequeña rebaja del 5%; estamos hablando de órdenes de magnitud que cambian la viabilidad de ciertos productos.

En los modelos más recientes de OpenAI, como gpt-5-nano o gpt-5.2, el descuento por caché llega al 90%. Para que te hagas una idea, si el millón de tokens de entrada te cuesta 2 euros, el millón de tokens de caché te cuesta 0.20 euros. En modelos de audio en tiempo real, la diferencia es todavía más ridícula, con descuentos que superan el 98% en algunos casos.

Vaya, que si tienes un chatbot que gestiona conversaciones largas donde el historial se reenvía en cada turno, tu factura puede pasar de ser inasumible a ser un gasto residual. Lo interesante es que, a diferencia de otras optimizaciones, esto no requiere que cambies de modelo ni que sacrifiques calidad. Estás usando la misma inteligencia, el mismo razonamiento, pero de forma más eficiente.

⚠️ Hay un pequeño detalle que mucha gente pasa por alto que es el umbral mínimo. En OpenAI, el prompt debe tener al menos 1024 tokens para que la caché empiece a funcionar. Si tus prompts son cortos, de 300 o 400 tokens, la caché no se activa y pagas el precio completo. He visto casos donde sale a cuenta alargar un poco el prompt con contexto útil o ejemplos de few-shot para superar los 1024 tokens y empezar a disfrutar de los descuentos. Si pasas de 900 tokens (precio completo) a 1100 tokens con un 70% de caché, la llamada te sale más barata siendo el prompt más largo.

Latencia y el muro del Time To First Token (TTFT)

El gran enemigo de las aplicaciones de IA es el tiempo que pasa desde que el usuario pulsa Enter hasta que aparece la primera palabra en pantalla. Ese tiempo es conocido como TTFT de Time to First Token.

En prompts masivos de 100.000 o 200.000 tokens (pensemos en analizar un repositorio de código o un libro entero), el TTFT puede ser de varios segundos solo para procesar el texto de entrada. He visto benchmarks donde, para prompts de unos 150.000 tokens, la caché reduce la latencia de respuesta en un 67% como en este ejemplo de OpenAI:

Esto ocurre porque el sistema se salta la fase de prefill compute. Cuando el hit de caché es exitoso, el modelo empieza a muestrear y generar el primer token casi de forma instantánea. Si estás construyendo agentes que necesitan iterar rápido, la caché es lo que permite que el bucle de razonamiento no se rompa por culpa de la espera.

La importancia del prefijo y cómo gestionarlo correctamente

Para que la caché funcione, el prefijo debe ser exactamente igual, token por token. Cualquier cambio mínimo, un espacio extra, un salto de línea o un timestamp dinámico, invalida toda la caché a partir de ese punto.

👉🏻 La regla de oro es: pon lo que no cambia al principio y lo volátil al final. La estructura ideal de un prompt optimizado para caché sigue este orden:

1. Instrucciones del sistema (System Prompt).

2. Definiciones de herramientas y funciones (Tools).

3. Esquemas de salida (Structured Outputs).

4. Contexto estático (documentación, ejemplos fijos).

5. Historial de la conversación (mensajes anteriores).

6. Entrada específica del usuario actual.

Un error común que comenta OpenAI es meter la fecha y hora actual o el ID del usuario al principio del prompt. Si haces eso, cada petición será única desde el token 1 y nunca tendrás un hit de caché. Mueve esa información a los metadatos de la petición o métela al final del todo, justo antes de la pregunta del usuario.

Otro truco que menciona la gente de OpenAI es el orden de las herramientas. Si tienes un array de herramientas (tools), el orden en el que aparecen en el JSON importa. Si en una llamada pones primero la función de clima y luego la de calendario, y en la siguiente las inviertes, has roto la caché. Mantén tus definiciones de herramientas estables y consistentes.

prompt_cache_key: Optimizando la afinidad del servidor

Este es uno de los conceptos más avanzados y potentes de la API de OpenAI. Para que haya un hit de caché, no basta con que el prompt sea igual sino que la petición tiene que caer en la misma máquina física que procesó el prompt anterior. OpenAI tiene miles de servidores, y por defecto, las peticiones se distribuyen para equilibrar la carga.

Si envías dos peticiones idénticas pero caen en centros de datos o servidores distintos, no hay caché que valga. Aquí es donde entra prompt_cache_key. Este parámetro le da una pista al sistema de enrutamiento para que intente mandar peticiones con la misma clave al mismo motor de inferencia.

¿Cómo elegir una buena clave? Si la clave es demasiado genérica (una sola clave para todos tus usuarios), saturarás un servidor y el sistema tendrá que desbordar las peticiones a otras máquinas, perdiendo la caché. Si la clave es demasiado específica (un ID único por cada mensaje), las peticiones se dispersarán tanto que nunca coincidirán en el mismo sitio.

Para casos de uso de programación, lo ideal suele ser una clave por repositorio o por usuario activo. Si quieres profundizar en este tema te recomiendo leer esta sección de la guía de OpenAI.

El conflicto con el Context Engineering

El context engineering busca reducir el número total de tokens eliminando mensajes antiguos o resumiendo la conversación para que el modelo no se pierda. Pero, cada vez que resumes o eliminas un mensaje intermedio, cambias el prefijo del prompt y, por tanto, destruyes la caché.

Te toca decidir: ¿Prefieres ahorrar tokens reduciendo la longitud total mediante compactación agresiva o prefieres mantener el historial intacto para aprovechar los descuentos de la caché? Depende del modelo que uses y de lo caro que sea el token de entrada frente al de caché. En modelos como gpt-4o-mini, a veces sale más a cuenta no compactar nada y dejar que la caché haga su trabajo, porque el coste del token de caché es despreciable frente a la inteligencia que pierdes al resumir.

Referencias técnicas

1. Prompt Caching 201: Fundamentals and Optimization - Guía avanzada de OpenAI sobre el funcionamiento interno de la KV Cache.

2. Anthropic: Context Caching Guide - Documentación oficial sobre la implementación manual de puntos de caché en modelos Claude.

3. Deep dive into KV Caching in Transformers - Explicación visual de cómo se almacenan las proyecciones de atención en arquitecturas de lenguaje.

4. Pricing and Model Limits for Prompt Caching - Tabla de precios actualizada para los diferentes modelos de la familia GPT.

El problema es que ese apunte temporal para un solo usuario en una conversación medianamente larga puede llegar a ocupar unos 40 GB de memoria (por contexto esto es más de la mitad de una GPU H100 que cuesta unos 30.000€).

Aquí es donde la economía de la inteligencia artificial se rompe y el modelo de negocio se vuelve insostenible. Todo esto ha sido así hasta que Google ha presentado su algoritmo de compresión TurboQuant.

Resumen ejecutivo (TL;DR)

TurboQuant es un algoritmo de compresión desarrollado por Google que reduce drásticamente el consumo de memoria de los modelos de inteligencia artificial al hacer más eficiente su caché de contexto.

• Reduce el tamaño de la memoria caché en 6 veces, bajando hasta los 3 bits por valor numérico.

• Mantiene un 0% de pérdida de precisión en las respuestas del modelo en todos los benchmarks de contexto largo probados.

• No requiere reentrenar ni afinar los modelos existentes y funciona como un reemplazo directo en la arquitectura.

• Multiplica por 8 la velocidad de cálculo de atención en hardware moderno como las aceleradoras Nvidia H100.

• Permite a los proveedores dar servicio a aproximadamente 6 veces más usuarios simultáneos en el mismo servidor.

Primero, ¿Qué es el KV Cache?

Para entender la magnitud del anuncio que acaba de hacer Google con TurboQuant, primero tenemos que entender cómo funciona la inferencia en un modelo de lenguaje grande (LLM).

La inferencia es el proceso de usar el modelo ya entrenado para generar texto. Hoy en día, la inferencia representa el 55% de todo el gasto en computación de inteligencia artificial a nivel mundial. Las grandes tecnológicas planean inyectar cerca de 700.000 millones de dólares en infraestructura de IA para 2026 y la mayor parte de ese hardware se va a dedicar a servir respuestas a usuarios.

Los LLMs generan texto de forma autorregresiva. Esto significa que predicen la siguiente palabra basándose en todas las palabras anteriores, luego añaden esa nueva palabra a la lista y vuelven a predecir la siguiente. El mecanismo principal que les permite entender el contexto se llama atención o self-attention.

Durante este cálculo de atención, el modelo convierte cada palabra (≃token) en vectores matemáticos llamados Keys y Values. A medida que la conversación avanza, el modelo guarda estas claves y valores en un espacio de memoria dedicado que conocemos como KV Cache. Si le has pasado un PDF de 100 páginas, el modelo calcula los Keys y Values de ese PDF una sola vez y los guarda en la memoria de la GPU.

El problema es que estos vectores son enormes. En un modelo de 70 mil millones de parámetros, cada token genera miles de números en coma flotante de alta precisión. Si multiplicas esos números por miles de tokens de contexto y luego por miles de usuarios conectados simultáneamente, llegas a un muro conocido como el memory wall.

La GPU tiene mucha capacidad de cálculo, pero se queda sin memoria RAM para almacenar el KV Cache de los usuarios. De nada sirve tener un procesador ultra rápido si no tienes dónde guardar los datos que necesita procesar. Cuando el servidor llega a este límite, simplemente deja de aceptar nuevas peticiones, lo que encarece muchísimo el servicio.

¿Cómo se solucionaba el problema de KV Cache hasta 2026?

Hasta ahora, la forma de lidiar con esto era la cuantización. Cuantizar es básicamente redondear números. Si tienes un número muy preciso como 3.14159265 (que ocupa 32 bits en memoria), lo redondeas a 3.14 (que ocupa 16 u 8 bits). Ahorras espacio, pero pierdes detalle.

En el mundo de los LLMs, pasar el KV Cache de 16 bits a 8 bits o incluso a 4 bits es una práctica común. El problema es que a medida que bajas la precisión, el modelo se vuelve menos preciso. Empieza a olvidar detalles sutiles del contexto, falla en tareas de razonamiento lógico y sufre alucinaciones.

Para que la cuantización clásica funcione, el sistema tiene que guardar metadatos adicionales (factores de escala y puntos cero) para cada pequeño bloque de números, de forma que sepa cómo reconstruir el valor original aproximado. Esta sobrecarga a veces añade 1 o 2 bits extra por cada número. Si intentas cuantizar a 4 bits, pero necesitas 2 bits de metadatos, en realidad estás usando 6 bits y perdiendo mucha precisión por el camino.

Aquí es donde entra el equipo de investigación de Google con su publicación sobre TurboQuant. Han conseguido comprimir este KV Cache a solo 3 bits por valor. Y lo más sorprendente no es la compresión en sí, sino que afirman haber logrado cero pérdida de precisión en los resultados finales del modelo.

PolarQuant: La solución de Google para comprimir el KV Cache sin pérdida

Para lograr esta compresión sin cargarse la inteligencia del modelo, Google dividió el problema en dos partes. La primera tecnología clave se llama PolarQuant.

Normalmente, los vectores dentro de un modelo de inteligencia artificial se representan en un sistema de coordenadas cartesianas. Piensa en el clásico eje X, Y, Z que dábamos en el instituto. Un vector te dice la posición exacta indicando distancias en línea recta.

La analogía que da la propia Google es muy buena. En un sistema cartesiano, dar una dirección sería algo como: “Avanza 3 calles hacia el este y 4 calles hacia el norte”.

PolarQuant coge estos vectores y los convierte a un sistema de coordenadas polares. En lugar de usar distancias en una cuadrícula, usa un radio y un ángulo. La misma dirección de antes se expresaría como: “Avanza 5 calles en un ángulo de 37 grados”.

Parece un cambio menor, pero en espacios de alta dimensionalidad como con los que trabajan los LLMs con vectores con miles de dimensiones, este cambio matemático lo es todo para la compresión. El radio representa la magnitud de los datos centrales, mientras que el ángulo indica la dirección, que es lo que realmente define el significado semántico del vector en los cálculos de similitud del modelo.

QJL: La corrección de errores en un solo bit para PolarQuant

Por muy eficiente que sea PolarQuant, la compresión siempre genera pequeños errores residuales. Si dejas esos errores sin tratar, se acumulan a lo largo de las capas de la red neuronal y terminan destrozando la salida del modelo.

Para solucionar esto, TurboQuant aplica una segunda capa matemática llamada QJL (Quantized Johnson-Lindenstrauss).

El lema de Johnson-Lindenstrauss es un principio matemático clásico que demuestra que puedes proyectar puntos de un espacio de muchas dimensiones a un espacio de menos dimensiones manteniendo casi intactas las distancias relativas entre esos puntos.

La capa QJL coge los pequeños errores residuales que dejó PolarQuant y les aplica este principio, reduciendo cada valor resultante a un único bit de signo: un +1 o un -1. Es una especie de bit de corrección de errores de bajísima resolución que actúa como contrapeso matemático.

Durante el cálculo de la atención, el modelo utiliza un estimador especial que cruza la consulta original (que se mantiene en alta precisión) con estos datos ultra comprimidos y corregidos. El resultado final es una puntuación de atención precisa que le dice a la red neuronal qué partes del texto son importantes y cuáles puede ignorar, pero calculada consumiendo una fracción minúscula de la memoria original.

Benchmarks y rendimiento en hardware real

En el mundo de la inteligencia artificial importan (y mucho) los benchmarks objetivos. Google puso a prueba TurboQuant contra modelos de código abierto muy utilizados como Llama (de Meta), Gemma (su propio modelo) y Mistral.

Los investigadores pasaron estos modelos por pruebas diseñadas específicamente para medir el rendimiento con contextos muy largos. Pruebas como LongBench, ZeroSCROLLS o la famosa Needle In A Haystack de la que te hablé en el blog hace unas semanas. Esta última prueba consiste en esconder un dato muy específico en medio de decenas de miles de palabras de texto irrelevante y pedirle al modelo que lo recupere.

Los resultados muestras que TurboQuant logró puntuaciones perfectas en estas pruebas de recuperación de datos manteniendo la calidad original del modelo, pero reduciendo el tamaño del KV Cache por un factor de 6.

Y aquí viene el beneficio secundario que a veces es incluso más importante que la memoria: la velocidad. Mover datos desde la memoria de la GPU hasta los núcleos de procesamiento es una de las operaciones más lentas en hardware moderno. Al reducir el tamaño de los datos 6 veces, el ancho de banda de memoria deja de ser un problema tan grave.

Google midió el rendimiento en GPUs de Nvidia H100 y reportó un aumento de velocidad de hasta 8 veces en el cálculo de los logits de atención utilizando TurboQuant a 4 bits en comparación con el uso de claves no cuantizadas a 32 bits.

Es decir, tenemos un modelo que ocupa una sexta parte de la memoria y hace los cálculos matemáticos pesados ocho veces más rápido.

El impacto de TurboQuant en las bases de datos vectoriales

Ojo, porque el impacto de esta tecnología no se limita a chatear con un LLM. Hay otro campo enorme en la IA que se beneficia directamente de esto que es la búsqueda vectorial y los sistemas RAG (Retrieval-Augmented Generation).

Hoy en día, las búsquedas modernas (incluyendo la del propio Google) ya no se basan únicamente en palabras clave exactas, sino en buscar por significado. Esto se hace convirtiendo todo el contenido indexado en vectores de alta dimensionalidad y buscando cuáles son los más cercanos matemáticamente a la consulta del usuario.

Google procesa miles de millones de estas búsquedas diariamente. Para hacerlo rápido, necesitan mantener índices vectoriales gigantescos en la memoria RAM de sus servidores. El coste de infraestructura de mantener bases de datos vectoriales a escala global es astronómico.

TurboQuant se probó en tareas de búsqueda en alta dimensionalidad contra métodos tradicionales evaluando el ratio de recuperación. El algoritmo demostró ser capaz de acelerar drásticamente el proceso de construcción de índices y de búsqueda, operando con la eficiencia de un sistema de 3 bits pero manteniendo la precisión de modelos mucho más pesados.

Esto significa que los motores de búsqueda semántica pueden indexar bases de datos corporativas enormes consumiendo poquísima memoria y con tiempos de preprocesamiento casi nulos.

Referencias técnicas

1. Lema de Johnson-Lindenstrauss - Fundamento matemático clásico sobre la proyección de espacios de alta dimensionalidad.

2. TurboQuant: Redefiniendo la eficiencia de la IA con una compresión extrema - Post oficial de Google.

3. LongBench: A Bilingual, Multitask Benchmark for Long Context Understanding - Repositorio oficial del benchmark utilizado para evaluar el rendimiento de contexto largo.

4. Modelos Gemma de Google - Documentación oficial de la familia de modelos abiertos utilizados en las pruebas del KV Cache.

Hoy analizamos el proyecto Autoresearch de Andrej Karpathy que merece que lo analicemos a fondo.

Estamos en un punto donde la narrativa de los agentes de programación nos vende que le puedes dar acceso a tu repositorio a un modelo y te va a resolver la vida. En mis predicciones de IA para 2026 critiqué mucho estos agentes y es que la realidad es que Autoresearch no intenta ser un científico de IA de propósito general ni un desarrollador senior autónomo. Es un sistema pequeño, muy restringido y diseñado para un trabajo muy específico: permitir que un agente modifique un script de entrenamiento, ejecute un experimento acotado, mida el resultado, mantenga el cambio si ayuda y lo descarte si empeora las cosas.

El repositorio es enano, apenas tiene dos scripts en Python de pocas líneas, pero el diseño que hay detrás es uno de los ejemplos más limpios que he visto sobre cómo construir un arnés de mejora autónoma que realmente funciona sin que tengas que estar vigilándolo de reojo cada cinco minutos. En este artículo vamos a ver cómo funciona Autoresearch por dentro y, lo más importante, qué nos enseña sobre la construcción de sistemas agénticos fiables.

Resumen ejecutivo (TL;DR)

Autoresearch es un sistema de investigación autónoma de IA diseñado por Andrej Karpathy que transforma la experimentación abierta en un problema de optimización estrictamente delimitado.

• El agente no navega por internet ni diseña arquitecturas desde cero, su único trabajo es modificar un archivo específico de entrenamiento para mejorar una métrica concreta.

• Cada experimento tiene un límite de tiempo fijo de 5 minutos, forzando al modelo a optimizar el rendimiento por unidad de tiempo real en lugar de por pasos de entrenamiento.

• El sistema utiliza un sistema inmutable para garantizar que la evaluación no sea manipulada por el agente y se mantenga consistente.

• El flujo de trabajo y la toma de decisiones se controlan mediante un documento en texto plano, demostrando que los prompts estructurados son ahora una pieza arquitectónica fundamental.

• Los sistemas autónomos más útiles a día de hoy son aquellos que tienen las restricciones más severas y el margen de error más acotado.

Qué es Autoresearch y por qué deberías prestarle atención

A un nivel alto, Autoresearch convierte la investigación en IA en un problema de optimización acotado.

Como comentaba antes, el agente no está navegando por internet leyendo papers, ni creando teorías originales sobre el futuro del deep learning, ni decidiendo qué debería importar. Su trabajo es muchísimo más acotado.

El ciclo de vida de Autoresearch se reduce a unos pasos muy marcados.

1. Primero edita el código de entrenamiento.

2. Segundo, ejecuta un experimento durante una cantidad de tiempo fija.

3. Tercero, mide el resultado utilizando una métrica inamovible.

4. Cuarto, guarda el commit si mejora la puntuación anterior.

5. Quinto, revierte los cambios mediante git si el resultado es peor. Y sexto, repite el proceso en bucle.

Este enfoque importa mucho ya que en lugar de tratar la investigación y el desarrollo de software como una tarea creativa abierta donde el modelo puede perderse por las ramas, Autoresearch lo trata como un siste,a de búsqueda disciplinado sobre una superficie muy bien definida.

La configuración es mínima por diseño, el agente solo tiene permiso para modificar un archivo concreto del repositorio. La preparación de los datos, la tokenización y la evaluación final se mantienen completamente fuera del espacio de búsqueda.

Cómo funciona la arquitectura de Autoresearch

Para entender por qué este sistema funciona también vamos a analizar su código por encima. Autoresearch gira en torno a tres archivos fundamentales. La interacción entre estos tres componentes es lo que permite que el sistema opere durante horas sin supervisión.

prepare.py: Gestión del entorno

Este archivo se encarga de descargar los fragmentos del dataset, entrenar el tokenizador, construir el dataloader y definir la evaluación. El agente no tiene permiso para tocar este archivo bajo ninguna circunstancia.

Si revisamos el código, vemos que define constantes críticas que dictan las reglas del juego. Por ejemplo, establece la longitud del contexto con MAX_SEQ_LEN = 2048 y el presupuesto de tiempo con TIME_BUDGET = 300 (los famosos 5 minutos que te comentaba antes).

Sobre las métricas, Autoresearch evalúa los modelos utilizando bits por byte (bpb) en lugar de la clásica pérdida de validación (validation loss).

@torch.no_grad()
def evaluate_bpb(model, tokenizer, batch_size):
    token_bytes = get_token_bytes(device="cuda")
    val_loader = make_dataloader(tokenizer, batch_size, MAX_SEQ_LEN, "val")
    steps = EVAL_TOKENS // (batch_size * MAX_SEQ_LEN)
    total_nats = 0.0
    total_bytes = 0
    for _ in range(steps):
        x, y, _ = next(val_loader)
        loss_flat = model(x, y, reduction='none').view(-1)
        y_flat = y.view(-1)
        nbytes = token_bytes[y_flat]
        mask = nbytes > 0
        total_nats += (loss_flat * mask).sum().item()
        total_bytes += nbytes.sum().item()
    return total_nats / (math.log(2) * total_bytes)

train.py

Este fichero contiene el modelo GPT, el optimizador, las tasas de aprendizaje, los hiperparámetros y la propia lógica del bucle de entrenamiento. Aquí es donde el agente experimenta a sus anchas y ocn libertad.

El agente puede cambiar la profundidad de la red, alterar la tasa de aprendizaje, modificar el tamaño del lote, simplificar la arquitectura borrando bloques enteros o ajustar los coeficientes del optimizador. Todo tiene que ocurrir dentro de este archivo delimitado. Si rompe la sintaxis de Python o introduce una operación que causa un desbordamiento de memoria (OOM) en la GPU, la ejecución fallará, pero el impacto está contenido localmente.

program.md: Programando al investigador, no al modelo

Lo que gestiona el agente y el proyecto no es el código Python. Es el archivo program.md que es el documento que le dice al agente cómo debe comportarse. En otras palabras, el humano no está programando únicamente al modelo de lenguaje, el humano está programando al investigador virtual.

Este archivo es el manual de instrucciones que le indica al agente cómo configurar una ejecución, qué archivos están dentro de su alcance, qué tiene permitido modificar, cómo registrar los experimentos, cuándo mantener o descartar un commit y cómo recuperarse de los fallos.

Un fragmento de este fichero que me llamó la atención (traducido al español):

A igualdad de condiciones, lo más simple es mejor.
Una pequeña mejora que añade complejidad fea no vale la pena.
Por el contrario, eliminar algo y obtener resultados iguales o mejores es un gran resultado.
Una mejora de 0.001 val_bpb que añade 20 líneas de código sucio probablemente no merezca la pena.
¿Una mejora de 0.001 obtenida al borrar código? Definitivamente quédatela.”

Esto es espectacular porque le estamos dando al agente un marco de desarrollo. Le estamos diciendo que el código limpio y mantenible tiene valor intrínseco, evitando que el script evolucione hacia una amalgama incomprensible de condicionales y parches espagueti solo para rascar una milésima en la métrica final.

4 lecciones de diseño para construir agentes de IA útiles basados en Autoresearch

Analizar Autoresearch es importante porque demuestra que de nada sirve tener un modelo de lenguaje con capacidades de razonamiento altísimas si el entorno en el que opera le permite desviarse del objetivo o corromper el sistema.

Basado en este diseño, aquí tienes cinco lecciones clave si estás construyendo sistemas basados en agentes o flujos de trabajo automatizados.

1. Las restricciones hacen que el agente sea mejor

Existe la falsa creencia de que un agente de IA necesita libertad absoluta en tu máquina para ser útil y autoresearch nos demuestra lo contrario. El agente edita un solo archivo, persigue una única métrica, opera dentro de un espacio fijo y solo avanza cuando la puntuación mejora empíricamente.

Muchos sistemas de agentes fallan porque intentan maximizar la libertad de acción demasiado pronto. Les dan acceso a terminales completas, a internet, a sistemas de archivos enteros, MCPs... Más libertad generalmente significa una superficie de error inmensamente mayor.

2. Los prompts son parte de la arquitectura del sistema

En este proyecto, el archivo program.md no es contexto secundario alrededor del código en Python, es la parte central del agente que define el flujo de trabajo, los límites del sistema, la persistencia de los datos, el registro de errores, los protocolos de recuperación y los criterios de selección.

A medida que los productos basados en agentes maduren en los próximos meses, veremos que una mayor parte de la arquitectura real vivirá en esta capa. No solo escribiremos código de aplicación tradicional, sino que redactaremos instrucciones operativas de alto nivel para trabajadores autónomos que actúan como middleware entre nuestras intenciones y la ejecución técnica. De hecho esto ya lo estamos viviendo en GitHub con Copilot Review.

3. El límite de tiempo

La decisión de imponer un límite de tiempo de 5 minutos es una de las ideas más brillantes del repositorio porque en los sistemas reales de producción, el tiempo suele ser la verdadera restricción limitante. Hablamos de latencia de red, costes de computación en la nube, velocidad de iteración en despliegues o simplemente la paciencia del usuario final.

Los bucles delimitados por tiempo obligan al sistema a optimizar para la utilidad en el mundo real en lugar del rendimiento idealizado. Si pides a un agente que redacte un informe perfecto, podría pasarse 10 horas iterando. Si le das 5 minutos, se verá forzado a encontrar las herramientas más eficientes para entregar el máximo valor en ese intervalo restrictivo.

4. Observabilidad y reversibilidad

Autoresearch hace que los experimentos fallidos sean baratos de descartar y hace que cada iteración sea auditable a través de los registros de terminal, el historial de commits y el archivo TSV de resultados.

Si una ejecución defectuosa deja el sistema en un estado irrecuperable o corrompe la base de datos, el agente no podrá explorar agresivamente el espacio de soluciones por miedo a romper algo crítico. Del mismo modo, si el sistema no te deja un rastro claro de qué acciones tomó, con qué parámetros y por qué falló, te será imposible confiar en él o mejorar sus instrucciones base.

Limitaciones actuales del experimento de Karpathy

Son varias las limitaciones del sistema de Autoresearch:

La primera limitación obvia es que optimiza para un benchmark extremadamente local. El agente intenta mejorar la métrica de validación bajo un presupuesto estricto de 5 minutos en una configuración de hardware muy específica. Que el agente encuentre una mejora aquí no significa automáticamente que esté descubriendo estrategias de entrenamiento superiores a nivel general aplicables a modelos de trillones de parámetros. Es muy posible que simplemente esté sobreajustando el código para encontrar lo que funciona mejor bajo las peculiaridades de este arnés concreto.

La segunda limitación es el hardware. El proyecto está construido mentalmente alrededor de una única GPU de gama ultra alta, concretamente una NVIDIA H100. El código asume capacidades computacionales masivas, utilizando núcleos de tensores de última generación y versiones de Flash Attention que solo funcionan bien en arquitecturas recientes. Aunque en el repositorio oficial se mencionan forks adaptados para MacBooks usando MLX, la experiencia por defecto está claramente sesgada hacia hardware que la mayoría de los mortales no tiene en casa.

La tercera limitación es que somos nosotros los que definimos la métrica, delimitamos qué archivos se pueden tocar, preparamos la canalización de datos y escribimos las instrucciones operativas. El sistema no tiene iniciativa propia fuera de esa definición. Los sistemas autónomos a corto plazo son mucho más valiosos cuando operan dentro de andamiajes fuertes, no cuando se les da libertad ilimitada y objetivos vagos.

Si estás trabajando en la integración de agentes en tu empresa, esta es la lección que deberías robar sin miramientos. No empieces preguntándote cómo hacer que el agente de IA sea más inteligente o tenga más autonomía. Empieza preguntándote cómo hacer que el sistema que lo rodea sea más restrictivo, seguro y fiable.

Porque en la práctica, los mejores sistemas autónomos rara vez son los que tienen mayor libertad de acción. Suelen ser los que tienen las restricciones más severas.

Referencias técnicas

1. Repositorio oficial de Autoresearch - Código fuente completo del experimento documentado por Andrej Karpathy.

2. Nanochat / NanoGPT - Repositorio padre del cual se simplificó el script de entrenamiento para este proyecto, útil para entender implementaciones mínimas de modelos de lenguaje.

3. Flash Attention 3 - Repositorio de la implementación optimizada de atención utilizada en el código base para acelerar el entrenamiento en GPUs Hopper.

Llevaba un par de semanas con la duda y me he puesto a investigar y descubrí la imagen scratch de Docker que viene a solucionar esto y la verdad me ha sorprendido porque tiene muchas más aplicaciones prácticas de lo que pensaba.

Resumen ejecutivo (TL;DR)

La imagen scratch es el punto de partida reservado y completamente vacío de Docker, diseñado para construir contenedores ultra minimalistas o crear tus propias imágenes base de sistemas operativos desde cero.

• Es una palabra clave reservada que le dice al motor de Docker que no añada ninguna capa previa al sistema de archivos.

• Físicamente está vacía, no contiene archivos ni carpetas, lo que obliga a usar ejecutables compilados estáticamente y autocontenidos.

• Reduce drásticamente el tamaño final de los contenedores y minimiza la superficie de ataque, siendo ideal para entornos regulados o dispositivos edge con conectividad limitada.

• Permite crear imágenes base funcionales (como Debian) mediante la directiva ADD, la cual extrae automáticamente un archivo comprimido para formar el sistema de archivos raíz.

• Su principal limitación es la enorme dificultad para depurar errores, ya que carece por completo de herramientas básicas del sistema como terminales, ping o curl.

¿Qué es exactamente Docker scratch?

Para entender qué es esta imagen original, primero hay que desaprender lo que creemos saber sobre máquinas virtuales. Cuando trabajamos con hipervisores tradicionales, siempre partimos de una ISO virtualizada que contiene un kernel propio, un sistema de arranque y un disco duro emulado.

Un contenedor de Docker NO es una máquina virtual.

La contenerización virtualiza a nivel de aplicación y utiliza directamente el kernel del sistema anfitrión. Esto significa que, en realidad, un contenedor solo necesita un proceso para existir y los archivos estrictamente necesarios para que ese proceso se ejecute de forma aislada. Sabiendo esto, el concepto de imagen base cobra otro sentido.

Puedes utilizar la imagen mínima y reservada de Docker, llamada scratch, como punto de partida para construir tus propios contenedores. Al usar esta palabra clave, le estás enviando una señal directa al proceso de construcción indicándole que el siguiente comando en tu archivo será, literalmente, la primera capa del sistema de archivos de tu imagen.

Construir desde este punto significa referenciar una imagen que crea el entorno más pequeño posible, el cual, para ser exactos, está completamente vacío y no contiene absolutamente ningún archivo ni carpeta.

Vaya, que no hay nada. Ni un binario, ni un gestor de paquetes, ni un directorio /bin.

La verdad es que tiene un comportamiento especial a nivel interno. A partir de la versión 1.5.0 de Docker, utilizar esta referencia actúa como una operación nula en el archivo de construcción y no crea ninguna capa extra en tu imagen. Aunque veas que aparece en los repositorios oficiales del Hub de Docker, es imposible descargarla, ejecutarla o etiquetar cualquier otra imagen con ese nombre. Simplemente está ahí para ser referenciada en tus construcciones.

Cómo funciona Docker Scratch: El kernel del host y el sistema de archivos

Si un contenedor está diseñado para iniciar un único proceso y no hay procesos del sistema operativo corriendo por debajo, ¿cómo es posible que imágenes como Ubuntu o Busybox funcionen partiendo de un entorno vacío?

La respuesta está en cómo Docker maneja la descompresión de archivos.

Si miras el código fuente de una imagen oficial de Debian, verás que empieza con la referencia vacía y luego usa un comando para añadir un archivo llamado rootfs.tar.xz. Muchos desarrolladores asumen que con solo copiar un archivo comprimido, la imagen resultante no debería volverse ejecutable mágicamente. Y tendrían razón si usaran el comando de copia tradicional.

Existe una diferencia fundamental entre los comandos ADD y COPY, y ese comportamiento específico es lo que hace que todo esto funcione.

Si utilizas el comando de copia estándar para mover ese archivo comprimido a la raíz, simplemente tendrías un archivo inerte depositado en el contenedor. Peeero, la directiva ADD tiene una función adicional: si detecta un archivo comprimido (como un .zip, .tgz o tar.xz), lo expande automáticamente.

En la práctica, esto significa que la directiva extrae los binarios y archivos de configuración holgadamente en una capa de la imagen, la cual debe incluir todo lo necesario para satisfacer las dependencias del proceso principal. Descomprime el sistema de archivos raíz completo, dando como resultado una imagen ejecutable capaz de lanzar una terminal interactiva.

¿Debería usar imágenes scratch en mis proyectos?

Hay dos motivos por los que podrías elegir trabajar con la imagen scratch de Docker: peso y seguridad.

El primer motivo es el peso. Las imágenes que usamos normalmente vienen cargadas de utilidades de red, editores de texto, bibliotecas compartidas y gestores de paquetes que en la mayoría de casos no aprovechamos y usamos. Todo ese peso muerto ralentiza los despliegues.

Disponer de imágenes pequeñas permite realizar actualizaciones mucho más rápidas en entornos que sufren de conectividad limitada a internet.

El segundo motivo, y para mí el más importante, es la seguridad.

Cada binario que existe en tu contenedor es un posible vector de ataque. Si un atacante logra comprometer tu aplicación y ejecutar código de forma remota, lo primero que hará será buscar una terminal o herramientas para descargar scripts. Si tu contenedor no tiene sistema operativo, no hay terminal. No hay forma de descargar nada. Tienes el control absoluto de todo lo que hay dentro de la imagen, lo cual es vital en entornos altamente regulados.

¿Puedo desplegar cualquier aplicación con scratch?

Hay que tener en cuenta que no siempre es posible desplegar nuestra app en un contenedor scratch debido a la naturaleza de los lenguajes de programación.

• Los lenguajes compilados como Go o Rust permiten generar binarios estáticos que incluyen todas sus dependencias en un único archivo ejecutable, por lo que pueden correr perfectamente sobre una imagen vacía.

• Los lenguajes interpretados como Python, Node.js o Ruby necesitan que el contenedor incluya obligatoriamente su intérprete y una serie de bibliotecas dinámicas del sistema para funcionar, lo que hace inviable el uso de scratch de forma directa.

Entonces puedes usar imágenes vacías si tu código es capaz de ser totalmente independiente, pero te verás obligado a usar imágenes base más completas si tu tecnología depende de un entorno de ejecución externo.

Ejemplo práctico de imagen Scratch desplegando una API en Go desde cero

El lenguaje Go es perfecto para este caso de uso por lo que te acabo de comentar de los binarios.

Imagina una aplicación pequeña escrita en Go que expone un único punto de enlace /hello. Si consultas ese punto, te devuelve un mensaje JSON de respuesta simple para el ejemplo.

Primero, necesitamos establecer un punto de referencia construyendo la imagen con un sistema base convencional como Alpine en su versión 3.18. Para hacerlo correctamente y poder comparar, utilizamos un Dockerfile en dos etapas: una para compilar la aplicación y otra para ejecutarla.

En la etapa de construcción partimos de la imagen golang:1.21.6-alpine3.18. Definimos el directorio de trabajo, copiamos el código fuente, descargamos los módulos necesarios y compilamos el binario para Linux.

FROM golang:1.21.6-alpine3.18 AS build
WORKDIR /go/src/app
COPY ./src/* .
RUN go mod download
RUN GOOS=linux go build -o /go/bin/app -v .

FROM golang:1.21.6-alpine3.18 
COPY --from=build /go/bin/app /go/bin/app
EXPOSE 8080
ENTRYPOINT [ "/go/bin/app" ]

Al compilar esta imagen de referencia, el proceso toma unos 12.3 segundos y el tamaño resultante se dispara hasta los 230MB.

Ahora, vamos a probar a compilar la segunda fase con la imagen scratch.

Tomamos el Dockerfile anterior como base cambiamos el comando de compilación, donde añadimos banderas de enlazado específicas para eliminar la información de depuración y otros detalles innecesarios y cambiamos la imagen base de la etapa final por nuestra referencia vacía de scratch.

FROM golang:1.21.6-alpine3.18 AS build
WORKDIR /go/src/app
COPY ./src/* .
RUN go mod download
RUN GOOS=linux go build -ldflags="-s" -o /go/bin/app -v .

FROM scratch
COPY --from=build /go/bin/app /go/bin/app
EXPOSE 8080
ENTRYPOINT [ "/go/bin/app" ]

Al ejecutar la construcción, el tiempo baja ligeramente a 10 segundos que no está mal pero el cambio importante es el tamaño de la imagen que se desploma a tan solo 6.8MB.

Reducimos el tamaño a un 3% del original y si arrancamos el contenedor podemos comprobar con una petición local que el servidor responde perfectamente al punto de enlace esperado.

El problema del usuario root en Docker Scratch

Si has probado este ejemplo te habrás dado cuenta que solo hay un proceso activo, pero se está ejecutando bajo el usuario administrador por defecto.

Dejar que una aplicación web corra con los máximos privilegios es una mala práctica. Para prevenir posibles escaladas de privilegios, necesitamos que el proceso se ejecute con un usuario sin permisos de administración.

Pero hay un problema un problema y es que nuestro entorno final está vacío. No existe el comando para añadir usuarios, ni grupos, ni consola.

La solución pasa por crear el usuario durante la etapa inicial de compilación (que sí tiene un sistema operativo base) y luego copiar el archivo de contraseñas resultante a la imagen final.

Añadimos este paso en la primera etapa: RUN adduser --disabled-password -u 10001 appuser. Y en la etapa final, justo después de copiar el binario, copiamos el registro del usuario y le decimos a Docker que lo utilice:

COPY --from=build /etc/passwd /etc/passwd
USER appuser

Ojo, hay una forma todavía más sencilla de hacer esto. En lugar de ejecutar el comando de creación de usuarios que genera varios archivos de configuración en el sistema, podemos crear un archivo de contraseñas desde cero que solo contenga el usuario que necesitamos.

Simplemente inyectamos la cadena de texto exacta en un archivo temporal durante la construcción: RUN echo "appuser:x:10001:10001:App User:/:/sbin/nologin" > /etc/minimal-passwd.

Luego, en la etapa final, copiamos ese archivo mínimo renombrándolo en el destino:

FROM scratch
COPY --from=build /go/bin/app /go/bin/app
COPY --from=build /etc/minimal-passwd /etc/passwd
USER appuser
EXPOSE 8080
ENTRYPOINT [ "/go/bin/app" ]

Si inspeccionas los bytes exactos de las imágenes generadas, verás que esta técnica de copiar un archivo apenas supone un incremento de 47 bytes en el tamaño total.

Al arrancar nuevamente el contenedor e inspeccionar los procesos, confirmamos que la aplicación se ejecuta correctamente bajo el identificador de usuario 10001, sin necesidad de saber el nombre del usuario porque el sistema subyacente no tiene contexto sobre él.

Curiosidades y limitaciones técnicas de Docker Scratch

Al trabajar con Docker Scratch te darás cuenta que hay limitaciones impuestas por la propia naturaleza del entorno que debes tener en cuenta antes de migrar toda tu infraestructura.

El principal inconveniente que vas a sufrir es un aumento significativo en la dificultad para investigar problemas, dado que las típicas utilidades comunes para comprobar la red o descargar contenido no están en el contenedor.

Si la aplicación falla no puedes simplemente abrir una sesión interactiva en el contenedor y empezar a lanzar comandos para ver qué falla: no tienes consola, ni herramientas de diagnóstico, estás completamente ciego frente a lo que ocurre en el sistema de archivos en tiempo real.

Toda la observabilidad y depuración debe estar integrada en el propio código de la aplicación.

Alternativas a scratch: ¿Cuándo usar distroless o Alpine?

usar una imagen scratch no siempre es necesario ni justificable para todos los equipos.

Si buscas seguridad extrema y tamaños reducidos, pero tu aplicación requiere ciertas librerías dinámicas o utilizas lenguajes que no pueden compilarse de forma estática pura, existen alternativas intermedias muy maduras en la industria.

Las imágenes distroless que fueron popularizadas por Google, son un punto intermedio ya que contienen únicamente la aplicación y sus dependencias de ejecución directas y no tienen gestores de paquetes, ni consolas, ni programas estándar de Linux. A nivel de seguridad ofrecen ventajas casi idénticas al entorno vacío, pero proporcionan versiones preconfiguradas para Java, Node.js o Python que facilitan enormemente el trabajo.

Por otro lado, imágenes como Alpine Linux ofrecen un sistema operativo completo y funcional en apenas 5 megabytes.

Al final, la decisión arquitectónica debe basarse en tus necesidades reales. Entender cómo funciona la capa más profunda de la virtualización de aplicaciones te da las herramientas necesarias para tomar esa decisión con criterio.

Ahora lo bueno es que la próxima vez que escribas un archivo de configuración para Docker, sabrás exactamente qué hay debajo de ese sistema operativo base.

Referencias técnicas

1. Docker Hub: Repositorio oficial de la imagen base reservada - Documentación oficial sobre la palabra clave reservada y su comportamiento sin capas.

2. Construyendo imágenes de contenedores desde un entorno vacío - Análisis detallado sobre la compilación estática de binarios en Go y la gestión de usuarios sin privilegios.

3. Comunidad Docker: Discusión técnica sobre el funcionamiento interno de contenedores y directivas de extracción - Explicación arquitectónica sobre la diferencia entre hipervisores y aislamiento a nivel de aplicación, junto con el análisis de comandos de expansión de archivos comprimidos.

GitHub Actions es una tecnología que me encanta, pero en el momento que escala tienes que pelearte con archivos YAML interminables para configurar nuestras integraciones continuas. La lógica se vuelve más compleja y frágil que el propio código de la aplicación que intenta desplegar.

Lo que acaba de lanzar GitHub en technical preview es conceptualmente diferente e interesante. Han presentado los GitHub Agentic Workflows, una iniciativa de GitHub Next y Microsoft Research que nos permite definir flujos de automatización en repositorios escribiendo en lenguaje natural (Markdown) en lugar de YAML puro. Y lo más importante: ejecutándolos bajo un entorno altamente seguro, aislado y auditable dentro de la infraestructura de GitHub Actions que ya conocemos.

Ojo, esto no es un sustituto de GitHub Actions. Piensa en ello como un complemento para acciones periódicas no deterministas.

Resumen ejecutivo (TL;DR)

GitHub Agentic Workflows es una nueva capa de abstracción para crear automatizaciones en repositorios usando lenguaje natural en lugar de programación imperativa, ejecutada por modelos de IA con fuertes medidas de seguridad.

• Permite describir la intención de un workflow como “revisa este issue” o “crea un reporte de estado cada día a X hora” en un archivo Markdown, y el agente decide la mejor manera de ejecutarlo.

• Introduce el concepto de Continuous AI, diseñado para complementar, no reemplazar, a tu CI/CD determinista tradicional.

• Prioriza la seguridad ejecutando los modelos con permisos de solo lectura por defecto y utilizando un mecanismo de safe-outputs para autorizar explícitamente operaciones de escritura como crear Pull Requests o comentar.

• Requiere un paso de compilación local que traduce tus instrucciones en un archivo .lock.yml blindado, el cual es interpretado finalmente por GitHub Actions.

El problema del YAML y el nacimiento del Continuous AI

Si lo piensas fríamente, GitHub Actions tradicional te obliga a pensar como una máquina. Tienes que definir el paso exacto, la herramienta exacta, el comando bash exacto y cómo procesar la salida con jq o awk. Esto es ideal para compilar un binario de Go o ejecutar tests unitarios porque quieres que el resultado sea determinista: la misma entrada debe producir la misma salida siempre.

Sin embargo, en el día a día del mantenimiento de un repositorio hay cientos de tareas que no son deterministas. Piensa en las issues, la actualización de la documentación cuando cambia el código, la revisión de accesibilidad o la sugerencia de refactorizaciones menores. Son tareas que requieren contexto, comprensión del lenguaje natural y un cierto grado de conocimiento técnico.

Aquí es donde entra el concepto de Continuous AI.

• El CI/CD se encarga de las tareas predecibles y repetitivas.

• El continuous AI se encarga de aplicar inteligencia automatizada y sistemática a la colaboración de software.

Los Agentic Workflows son la primera implementación real y nativa de este concepto en GitHub, permitiendo que agentes como Claude Code, OpenAI Codex o GitHub Copilot actúen como colaboradores asíncronos en tu equipo.

Diferencia entre Workflows Tradicionales vs Agénticos

En un workflow tradicional de GitHub Actions, tú defines un conjunto de reglas imperativas (si pasa X, ejecuta el script Y). La máquina no entiende lo que está haciendo, solo sigue instrucciones.

En un workflow agéntico, tú defines el estado final deseado usando lenguaje natural y proporcionas herramientas (tools), mientras que la IA se encarga de leer el contexto, analizar la situación y tomar decisiones sobre cómo alcanzar ese estado.

La trampa en la que cae mucha gente es pensar que podemos simplemente meter un script de Python que llame a la API de OpenAI dentro de un Action normal y corriente. Y sí, poder se puede, pero es un peligro a nivel de arquitectura. Hacer eso otorga a un agente de IA un acceso excesivo y sin restricciones a tu entorno de ejecución. Los Agentic Workflows solucionan este problema de raíz integrándose con GitHub Actions desde una filosofía de diseño centrada en la seguridad y el principio de mínimo privilegio.

Seguridad: Cómo evitar que la IA destruya tu repositorio

De nada sirve tener un agente muy inteligente si un usuario puede hacer un ataque de prompt injection en un issue y lograr que la IA borre tu base de datos o filtre secretos del repositorio (si, si que se puede… ).

La arquitectura de seguridad de GitHub Agentic Workflows se basa en defensa en profundidad en 4 capas:

1. Aislamiento y solo lectura por defecto: Cuando el agente se ejecuta en el contenedor de GitHub Actions, lo hace en un entorno aislado (sandboxed) y sus permisos son estrictamente de solo lectura. No puede hacer git push ni modificar el repositorio directamente.

2. Safe Outputs (Salidas seguras): Si el agente está en modo solo lectura, hace su trabajo mediante un concepto llamado safe-outputs.

   Tú defines en la configuración qué operaciones tiene permitidas (por ejemplo, create-pull-request o create-issue).

   El agente solo puede solicitar que se ejecute esa acción preaprobada con el contenido sanitizado, y es la infraestructura la que realiza la escritura, no el modelo de IA. Esto garantiza que siempre quede un rastro auditable (una PR, un comentario) y que nosotros, los humanos tengamos siempre la última palabra antes de integrar código.

3. Integración con MCP (Model Context Protocol): Ya hemos hablado de MCP anteriormente en la newsletter. Este protocolo permite conectar modelos de IA con fuentes de datos externas de forma segura. Los Agentic Workflows exponen capacidades específicas del entorno de GitHub (leer archivos, consultar issues) mediante servidores MCP controlados y aislados en la red.

4. Compilación y Lock Files: El código fuente de tu workflow es un archivo Markdown (.md), pero GitHub Actions no sabe leer Markdown. La herramienta de línea de comandos gh aw compile procesa tu Markdown, valida la seguridad, revisa los permisos y genera un archivo .lock.yml que es el que realmente se ejecuta. Este archivo bloqueado es el que evita inyecciones en tiempo de ejecución.

Si quieres profundizar en la parte de seguridad de los Workflows agénticos te recomiento esta página de documentación de GitHub.

Multi-Agente por diseño: Copilot, Claude o COdex

Un detalle que me encanta es la neutralidad del motor de IA. Aunque por defecto utiliza GitHub Copilot, la arquitectura está diseñada para ser agnóstica respecto al agente que haya por debajo.

Puedes configurar el flujo para que el motor de inferencia sea Claude de Anthropic o Codex de OpenAI. Esto es vital porque evita el vendor lock-in a nivel de prompt. Mantienes tu workflow en lenguaje natural intacto y simplemente cambias el motor en la configuración para comparar resultados, evaluar costes o aprovechar las fortalezas específicas de cada modelo.

Guía paso a paso: Cómo crear tu primer Agentic Workflow

Lo primero, necesitas preparar tu entorno local porque la generación del YAML final ocurre en tu máquina.

Primero, asegúrate de tener instalado la CLI de GitHub (gh) y luego instala la extensión específica para flujos agénticos:

gh extension install github/gh-aw

Ahora necesitas autenticar el entorno para que pueda hacer llamadas al modelo de IA. Debes generar un Personal Access Token (PAT) en la configuración de desarrollador de GitHub asegurándote de marcar el scope Copilot Requests. Una vez lo tengas, guárdalo como secreto en tu repositorio usando la CLI:

gh aw secrets set COPILOT_GITHUB_TOKEN --value TU_PAT_AQUI

La estructura básica se compone de un archivo Markdown ubicado en la ruta habitual .github/workflows/nombre-del-flujo.md. Este archivo tiene dos partes claramente diferenciadas: un Frontmatter en formato YAML en la cabecera (donde defines las reglas estrictas) y el cuerpo en Markdown (donde defines la lógica agéntica). Si leiste el post sobre Agent Skills seguramente te resulte familiar este formato.

Ejemplo real de un workflow agéntico: Solucionar Issues del repositorio

Para enseñarte un ejemplo de cómo se combinan el determinismo y la IA, fíjate en este ejemplo adaptado de un flujo para mejorar la calidad de los issues entrantes a un repositorio.

Imagina que un usuario abre un issue con muy poca información, sin etiquetas y con un título vago. El objetivo es que la IA lo analice, le dé un formato estructurado y asigne etiquetas pertinentes.

Primero creamos el archivo .github/workflows/mejorar-issues.md:

# Esta primera sección es el Frontmatter
---
on:
  issues:
    types: [opened]
permissions:
  issues: read
safe-outputs:
  update-issue:
    title:
    body:
tools:
  github:
    toolsets: [issues]
---
# Mejorador de Calidad de Issues

Tu objetivo es mejorar los nuevos issues para que sean claros, estén bien estructurados y sean fáciles de entender para el equipo de desarrollo.

## Contexto del Issue
| Campo  | Valor          |
| ------ | -------------- |
| Número | #$ISSUE_NUMBER |
| Autor  | @$ISSUE_AUTHOR |
| Título | $ISSUE_TITLE   |
| Cuerpo | $ISSUE_BODY    |

## Tareas a realizar

1. Obtener contexto:
   - Lee el archivo README para entender el propósito del proyecto.
   - Lista las etiquetas disponibles en el repositorio.

2. Traducción y Claridad:
   - Si el issue NO está en inglés, tradúcelo al inglés manteniendo intactos todos los detalles técnicos y logs de error.

3. Mejora del Título:
   - Añade un prefijo estandarizado basado en el tipo de issue detectado (Bug, Feature, Docs, Refactor).
   - Ejemplo: "[Bug] Error de login con caracteres especiales".

4. Reestructuración del Cuerpo:
   - Utiliza secciones claras en formato Markdown.
   - Para bugs, asegúrate de crear las secciones "Descripción", "Pasos para reproducir" y "Comportamiento esperado vs actual".

5. Aplicar cambios:
   - Utiliza la herramienta de salida segura para actualizar el issue #$ISSUE_NUMBER con el nuevo título y cuerpo.
   - Añade un comentario breve resumiendo los cambios realizados.
   - Asigna entre 1 y 3 etiquetas relevantes basadas en el contexto del repositorio.

## Reglas estrictas
- Nunca cambies el significado técnico original reportado por el usuario.
- Si el issue ya está perfectamente redactado, realiza cambios mínimos o ninguno.
- Mantén un tono de ayuda profesional.

Aquí hay varios elementos de diseño que merecen un análisis profundo.

• En el Frontmatter, utilizamos el trigger estándar de GitHub Actions (on: issues), muy similar a como lo hacemos en GitHub Actions. La sección permissions está restringida únicamente a lectura, limitando la superficie de ataque si algo sale mal.

• En safe-outputs le estamos diciendo a la infraestructura de ejecución: “El modelo de IA tiene permiso exclusivo para actualizar el título y el cuerpo de un issue existente” (update-issue). Si el agente alucina e intenta borrar una rama del repositorio, la petición será interceptada y bloqueada en la capa de seguridad porque no está declarada explícitamente como una salida segura.

• En la sección de tools, limitamos el servidor MCP de GitHub únicamente al conjunto de herramientas (toolsets) relacionadas con issues, evitando que la IA pierda tiempo o recursos explorando partes irrelevantes de la API de GitHub.

• Finalmente, el cuerpo del documento mezcla variables de entorno inyectadas en tiempo real ($ISSUE_TITLE, $ISSUE_BODY) dentro de una tabla de contexto, seguidas de instrucciones paso a paso muy precisas y reglas de restricción.

¿Cómo lanzar el workflow agéntico? Compilación y ejecución

El archivo Markdown de arriba no hace nada por sí solo. Tienes que compilarlo ejecutando:

gh aw compile

Este comando analiza tu archivo Markdown, valida que las herramientas y los safe-outputs solicitados existen y son seguros, y genera un archivo .github/workflows/mejorar-issues.lock.yml junto con una carpeta interna .github/aw. El archivo YAML generado es ilegible para un humano (y no se debe editar), pero contiene toda la lógica de orquestación, aprovisionamiento de contenedores y proxy MCP necesarios para ejecutar el flujo de manera segura en la infraestructura de Actions.

Debes hacer un commit y hacer push tanto del .md como del .lock.yml a tu repositorio. A partir de ese momento, cada vez que alguien abra un issue, GitHub Actions levantará el entorno y ejecutará la lógica agéntica.

Patrones de diseño para casos de uso reales: ¿Qué es DailyOps y MultiRepoOps?

Una vez que entiendes la mecánica, las posibilidades son muchas y seguro que ya tienes alguna idea en mente de cómo integrarlo en algún repositorio.

Al basarse en la lectura de contexto natural, se abren patrones de automatización que antes eran imposibles de mantener mediante scripts bash. La propia documentación oficial categoriza estos casos de uso en varios patrones, siendo DailyOps y Continuous Documentation los más potentes.

Fíjate en este ejemplo de un workflow programado diariamente para generar un reporte de estado del equipo:

---
on:
  schedule: daily
permissions:
  contents: read
  issues: read
  pull-requests: read
safe-outputs:
  create-issue:
    title-prefix: "[estado-equipo] "
    labels: [reporte, estado-diario]
    close-older-issues: true
---

## Reporte Diario de Issues

Genera un reporte de estado diario positivo y estructurado para el equipo en forma de issue de GitHub.

## Qué debes incluir

- Actividad reciente del repositorio (issues, PRs, discusiones, releases, cambios en el código).
- Seguimiento del progreso, recordatorios de objetivos del sprint y aspectos destacados.
- Estado general del proyecto y recomendaciones.
- Próximos pasos accionables para los mantenedores.

Este workflow se levanta cada mañana, el agente consume el estado actual del repositorio, obtiene los datos de los Pull Requests mergeados, lee los comentarios de los issues cerrados y sintetiza todo en un formato sencillo de leer.

Otros patrones de diseño que se están explorando incluyen:

• Continuous QA: Diagnóstico automático de fallos en la integración continua (CI), análisis de logs de errores complejos y propuestas de parches (fixes) mediante PRs.

• Continuous Documentation: Mantenimiento activo de los archivos README y de la documentación técnica para asegurar que siempre reflejen los últimos cambios del código fuente, evitando el clásico problema de documentación obsoleta.

• MultiRepoOps: Flujos que sincronizan estados, características o métricas a través de múltiples repositorios de una misma organización, actuando como un orquestador inteligente.

• Si quieres ver la lista completa de agentes de diseño, GitHub los ha recopilado aquí.

Costes y limitaciones de GitHub Agentic Workflows

Respecto los compromisos técnicos. Ejecutar IA dentro de un pipeline de integración tiene un coste directo en cuanto a costes de facturación y de precisión.

Cuando utilizas GitHub Copilot con la configuración por defecto, cada ejecución de un Agentic Workflow suele incurrir en dos llamadas de tipo premium request: una para procesar la tarea principal del agente y otra independiente para validar la seguridad y los guardrails a través de los safe-outputs. A escala empresarial, si lanzas un flujo agéntico en cada push a cualquier rama, la factura puede escalar rápidamente.

La recomendación oficial de GitHub es comenzar vinculando estos flujos a eventos de baja frecuencia como tareas programadas diarias, creación de releases o a triggers manuales workflow_dispatch antes de automatizarlos completamente por evento.

Otro aspecto vital es el factor humano. La IA es una herramienta de asistencia, no un desarrollador autónomo infalible como ya todos habremos comprobado. Un principio de diseño fundamental de GitHub Agentic Workflows es que los Pull Requests generados por agentes nunca se mergeen automáticamente, siempre debe haber un humano responsable (el famoso Human-in-the-loop) que revise, valide y apruebe los cambios propuestos por la IA. Las alucinaciones en modelos de lenguaje siguen siendo una realidad técnica.

El código fuente en Markdown de estos flujos debe tratarse con el mismo rigor que el código de producción. Debes aplicar code reviews, iterar sobre las instrucciones progresivamente y versionar los cambios con cuidado. A veces, alterar una sola frase en el Markdown puede cambiar drásticamente el comportamiento del agente.

Referencias técnicas

1. Repositorio oficial y documentación de GitHub Agentic Workflows - Especificaciones técnicas, CLI y guía de configuración inicial.

2. Documentación sobre cómo funcionan bajo el capó (How they work) - Explicación profunda de la compilación WASM, aislamiento y dependencias.

3. Artículo de lanzamiento en el Blog de GitHub - Contexto sobre el concepto de Continuous AI y ejemplos de aplicación en la industria.

4. Portal de GitHub Next: Agentic Workflows - Estado de la investigación, filosofía de diseño y modelos soportados.