La semana en que quedó claro: los agentes en producción no se rompen por falta de modelo — se rompen por falta de ingeniería de datos, gobernanza de permisos y átomos de silicio.
Cero coma uno seis seis.
Es la nota promedio de los mejores agentes del mundo intentando rediseñar su propio algoritmo de entrenamiento. El techo de la auto-mejora recursiva que están vendiendo como el futuro de tu stack.
Esta es la edición de ai|expert. La semana en que quedó claro: los agentes en producción no se rompen por falta de modelo — se rompen por falta de ingeniería de datos, gobernanza de permisos y átomos de silicio.
Existe un mito de producción que la industria ha perpetuado en silencio durante dos años. El mito dice: cuando tu agente falla, reescribe el prompt. Invierte más en el modelo, aumenta el contexto, intenta otra arquitectura de chain-of-thought. Thoughtworks publicó esta semana la autopsia más directa que he leído sobre por qué los equipos prototipos una semana y se quedan atascados seis meses. Y la conclusión es incómoda: la brecha no es de modelo. Es organizacional. [ref: agent-readiness-gap-why-databr]
El diagnóstico comienza con un número. Un cliente de Thoughtworks tenía cuarenta y siete tablas con la palabra "revenue" en su catálogo de datos. El agente podía consultar las cuarenta y siete. El problema no era capacidad de consulta — era que no sabía cuál usar, no podía aplicar definiciones regionales correctamente y no podía explicar la opción que hizo. Para el agente, cuarenta y siete tablas de revenue son cuarenta y siete respuestas igualmente probables. Para el equipo de finanzas, solo una importa. [ref: agent-readiness-gap-why-databr]
Thoughtworks divide la falla en dos capas. La capa de plataforma — Unity Catalog, controles de acceso, linaje — está casi resuelta. La capa de significado no lo está. "Revenue" en la misma empresa puede significar revenue reconocida, facturada o contabilizada, según el equipo. "Customer" significa cosas diferentes para ventas y operaciones. Dos tablas compartiendo una columna customer_id comparten una clave — no necesariamente un join válido. La recomendación: marca relaciones como inferidas hasta que un dueño de dominio las verifique. Esta disciplina evita errores silenciosos que aparecen solo cuando el output del agente se verifica después de que ya se tomó una decisión. [ref: agent-readiness-gap-why-databr]
La evidencia empírica de que la curación de contexto supera la reescritura de prompts viene del benchmark interno de Databricks. Veintiocho preguntas, junio de 2026: el Genie Agent respondió 84.5% correctamente en el primer intento. El mejor agente de código de propósito general probado alcanzó 52.4%. El peor, 25%. Y Genie fue dos veces más rápido. La diferencia no es el modelo subyacente — es la capa de contexto gobernada heredada de Unity Catalog. Los competidores fueron anonimizados, la replicación independiente aún no es posible, pero el principio se sostiene en el campo. [ref: agent-readiness-gap-why-databr]
Databricks tiene un nombre para el problema estándar que ocurre sin contexto gobernado: "first revenue table it finds". El agente toma la primera tabla de revenue que encuentra en una búsqueda por palabras clave — no la que el equipo de finanzas realmente mantiene. El resultado es técnicamente originado de datos, pero operacionalmente incorrecto. La solución no es un prompt mejor. Es curación en Unity Catalog: definiciones de métricas formalizadas, con fórmula, dueño, dimensiones, sistema de registro, reglas temporales y excepciones explícitamente documentadas y versionadas. [ref: databricks-designing-productio]
Y cuando tu Genie Agent devuelve respuestas inconsistentes, Databricks es directo: audita los assets de Unity Catalog antes de tocar el prompt. El Genie Ontology — en preview restrito — escanea notebooks, dashboards, pipelines y linaje, extrae fragmentos de conocimiento, los ranquea vía OntoRank — un engine inspirado en PageRank que pondera autoridad del creador, amplitud de uso, linkage con datasets certificados y frescura — e inyecta los más relevantes en el momento de la consulta. Se auto-mantiene, lo que es fundamental porque las definiciones de métricas se desvían después de que los equipos las construyen manualmente. [ref: agent-readiness-gap-why-databr]
Pero un contexto que se auto-actualiza es correcto para descubrimiento. No es correcto para presentaciones de junta al CFO. Necesitas versionar definiciones al lado de la capa aprendida, fijar agentes a un release nombrado y probar contra ese release específico — no contra datos en vivo. Thoughtworks hace un punto de poner esto en negrita.
Hay un caso de producción que va más allá de curación de tablas y cierra este primer bloque elegantemente. Netflix open-sourced en junio el `oci-agent` — un paquete Python para inferencia causal observacional usando un loop actor-critic — y desde entonces ha estado ejecutando más de cien análisis causales por mes con él. La arquitectura es instructiva para cualquier equipo que despliega agentes en workloads analíticos de alto riesgo. [ref: netflix-open-sources-agentic-w]
Describe el loop.
Un agente Actor recibe el plan del humano, lo refina en una spec de análisis, rellena un notebook Jupyter con template y lo ejecuta. Un agente Critic recibe el output, lo evalúa en tres niveles — insatisfactorio, satisfactorio con salvedades, totalmente satisfactorio — y recomienda cambios de spec. El loop corre hasta que el Critic aprueba o se alcanza una condición de parada. Cada artefacto — planes, specs, plots, notebooks ejecutados — es versionado y publicado en un file store donde el humano puede verificar resultados localmente. Netflix llama esto "process audits". [ref: netflix-open-sources-agentic-w]
¿Por qué process audits en vez de acurácia en leaderboard? Porque la inferencia causal de datos observacionales no tiene ground truth. No evalúas este agente con acurácia numérica contra un oráculo externo — evalúas si siguió el playbook, si el Critic marcó los diagnósticos correctos, si un humano puede re-ejecutar el notebook y llegar a la misma respuesta. Eso cambia fundamentalmente lo que necesitas construir como infraestructura de eval.
El case study que publican es la demostración más clara de por qué la estructura causal importa. Le pidieron a Claude bruto y al `oci-agent` la misma pregunta: ¿cuál es el impacto de involucrarse con un nuevo tipo de entretenimiento — su vertical de games, llamada Tipo X — sobre retención de dos meses. El `oci-agent` devolvió una estimación que era solo 25% del resultado de Claude bruto. El modelo sin estructura causal sobreestimó el efecto causal cuatro veces. El Critic marcó sesgo de adoptante temprano y una prueba placebo que falló, e impulsó iteraciones con parámetros ajustados hasta llegar a una estimación defendible. [ref: netflix-open-sources-agentic-w]
Cuatro veces. Esa es la diferencia entre una decisión de producto correcta y una que se ve correcta.
Y cuatro diagnósticos corren automáticamente en el `oci-agent`: balance de covariables — diferencia de media estandarizada por debajo de 0.2 después de ponderación; overlap — propensity score entre 0.1 y 0.9; una prueba de resultado placebo; y análisis de sensibilidad a confundidores ocultos. El Critic los evalúa antes de emitir cualquier rating. Si tu stack de data science ejecuta trabajo causal observacional hoy — estimación de métricas proxy, análisis de impacto de retención, atribución de features — el `oci-agent` entrega un template actor-critic ya probado bajo carga de producción, con thresholds de diagnóstico y playbooks definidos. El mensaje que Thoughtworks y Netflix entregan en conjunto: curar datos es la palanca que importa. Reescribir el prompt es el reflejo de quien aún no ha encontrado la causa raíz. [ref: netflix-open-sources-agentic-w]
Pero mientras arquitectos peleaban con ontologías y evals de proceso, una segunda narrativa avanzaba en silencio. La narrativa de que el modelo se mejora a sí mismo — y por lo tanto, los problemas de producción se resuelven por ósmosis conforme llega la próxima generación. Esta narrativa tuvo una semana muy mala.
Dos papers. Publicados con horas de diferencia. Llegando a la misma conclusión por caminos opuestos.
El primero: "Phantom Gains: Auditing Self-Improvement Against a Measured Null". Xu, Yan, Chen y Kechadi, publicado en arXiv el 20 de agosto de 2026. Tres rondas de self-training con LoRA rank-32 en un Qwen3-8B. Resultado: ganancias detectables — cero. Peor: el self-training degradó problemas que el modelo base ya resolvía, a tasas mediblemente arriba del ruido de medición. [ref: phantom-gains-auditing-self-im]
El dato aislado no es lo que me preocupa. Es la metodología que escondió este dato todo este tiempo. Los autores identificaron siete fallas de medición en el pipeline de evaluación de auto-mejora estándar. Cada una, aisladamente, es capaz de invertir un resultado publicado. No distorsionar ligeramente — invertir completamente.
La más reveladora: la estadística de "expansión", diseñada para separar adquisición genuina de capacidad de simple refinamiento de conocimiento parcial — esta estadística asignó al modelo Qwen3-8B congelado, sin ningún entrenamiento adicional, una tasa de adquisición de capacidad de 0.280. El modelo no aprendió absolutamente nada. La métrica dice que aprendió. Eso significa que cada vez que ves un número de "expansión de capacidad" en un paper de self-training, probablemente estés viendo ruido de inferencia, no aprendimiento. [ref: phantom-gains-auditing-self-im]
El paper propone una prueba exacta por problema contra una baseline agrupada bajo control de false-discovery-rate. Aplicada a réplicas held-out, detecta nada — la respuesta correcta cuando el modelo no cambió — y permanece estable bajo cambios en corrección de pruebas múltiples, tasa de error y tamaño del pool. Un indicador que se mueve con threshold de FDR no está midiendo capacidad. Está midiendo la sensibilidad del pipeline de evaluación. [ref: phantom-gains-auditing-self-im]
Y hay un finding de corrupción que demanda acción inmediata de quien ejecuta self-training iterativo. El self-training degradó problemas que el modelo base resuelve en baseline — a tasas arriba del ruido medido. Equipos rastreando acurácia agregada no ven esto: una ganancia nueva en un problema compensa numéricamente una regresión en otro. Auditoría por nivel de transición expone la regresión. Auditoría por acurácia promedio la esconde. La implicación práctica: antes de hacer ship de cualquier pipeline de self-training, corre el modelo base congelado a través de tu stack completo de eval tantas veces como cada arm entrenado, y construye estadísticas de cambio de capacidad contra ese null medido — no contra cero asumido. [ref: phantom-gains-auditing-self-im]
Y el segundo paper va directo al mecanismo que justificaría auto-mejora recursiva. El AI4AI-Bench, del Navers Lab y Einsia.AI, también publicado el 20 de agosto. La pregunta de investigación: ¿pueden los agentes LLM rediseñar algoritmos de entrenamiento para producir modelos mejores? Esta es la base teórica de mejora recursiva — la idea de que un agente puede mejorar el proceso que va a producir el próximo agente. [ref: ai4ai-bench-can-agents-design-]
La escala: 0 es modelo no-informativo, 0.1 es el algoritmo que el repositorio ya trae, 1.0 es el óptimo teórico. Resultado: nota promedio de 0.166 en 29 configuraciones de 6 sistemas en 10 repositorios de investigación congelados. El mejor sistema individual llegó a 0.250 — cerrando menos de una quinta parte del gap entre baseline actual y posible. Seis sistemas probados, ninguno demostrando invención algorítmica confiable. [ref: ai4ai-bench-can-agents-design-]
El design del benchmark es adversarial a atajos. Cada repositorio cubre una familia distinta de algoritmos de entrenamiento: objetivos, reglas de actualización, schedules de regularización. El agente tiene cuatro horas en un single GPU B300 para leer el código, proponer cambios y probar ideas contra una métrica proxy. Produce un patch de código-fuente — nada más. Sin pesos cacheados, sin estado retenido. Este patch corre en contenedor limpio por hasta doce horas, evaluado por un evaluator fijo que estaba oculto del agente durante esas cuatro horas. [ref: ai4ai-bench-can-agents-design-]
La mayoría de agentes nunca llegan a cambiar cómo aprende el modelo. Mueven pesos de loss, ajustan batch sizes, o simplemente no hacen nada sustantivo. Las submissiones que de hecho editan el algoritmo de aprendizaje promedian 0.226. Las que no editan: 0.126. Este gap de 0.100 es toda la diferencia entre un intento significativo e inercia algorítmica. [ref: ai4ai-bench-can-agents-design-]
Más razonamiento compra disposición para entrar al código de entrenamiento. Cambia la fracción de submissiones que editan el algoritmo de 8% a 64%, y el promedio de 0.094 a 0.196. Pero no compra capacidad de mejorarlo una vez adentro. Design algorítmico — la capa donde ganancias se componen por todos los entrenamientos futuros, incluyendo el que produce el próximo agente — sigue siendo el único nivel de auto-mejora recursiva que todavía requiere un humano. [ref: ai4ai-bench-can-agents-design-]
Lo que estos dos papers matan en conjunto es una narrativa específica: que el modelo, al auto-mejorarse, va a eventualmente resolver los problemas de producción que discutimos en el bloque anterior. La respuesta es: no con el mecanismo de self-training disponible hoy. Y quizá más importante — el hecho de que no diéramos cuenta de esto sugiere que buena parte de las "ganancias" publicadas en los últimos dos años puede ser ruido de medición bien presentado.
Entonces, si el modelo no se audita a sí mismo — ¿quién lo hace? ¿Y con qué infraestructura? Porque esta semana dos piezas de gobernanza agentica quedaron más concretas que nunca, y ambas resuelven problemas que ningún prompt resuelve.
Cloudflare puso WriteGuard en beta privado. Es una capa de policy, atribución y auditoría que se sienta entre el portal de servidores MCP de Cloudflare y cada tool conectada. Clasifica cada llamada por tier de riesgo e intercepta writes antes de ejecutar. La política se define en TypeScript al lado de la configuración de la tool — sin cambios en el servidor MCP en sí. Este punto importa a escala. [ref: mcp-gets-its-first-granular-ac]
El incidente que lo motivó está descrito en su propio blog de ingeniería. Un agente corriendo en background bajo la identidad OAuth de un ingeniero cerró miles de tickets de Jira una tarde — a un ritmo que ningún humano sustentaría — antes de que alguien se diera cuenta. El sistema registró cada acción bajo el nombre del ingeniero, sin forma alguna de separar lo que fue acción humana de lo que fue acción del agente. Y el portal interno de Cloudflare creció de 13 servidores conectados en abril de 2026 a 27 hoy. Construir controles en cada servidor separadamente habría producido comportamiento inconsistente cada vez que se añadiera un nuevo servidor. [ref: mcp-gets-its-first-granular-ac]
Los cuatro tiers son directos. Las llamadas read-only — buscar issues, leer un merge request, ver status de pipeline — pasan sin alteración. Las llamadas de impacto mínimo — agregar una reacción, marcar notificación como leída — solo se registran. Los writes contenidos — crear un merge request, agregar comentario, actualizar campo de issue — reciben atribución de agente inyectada en la aplicación downstream en el formato que la aplicación acepta, más un evento de auditoría asíncrono. Las operaciones críticas — merge en main, trigger de deploy en producción, bulk delete de records — se bloquean antes de ejecutar. Los tiers son configurables por tool; una tool merge_mr clasificada como Critical nunca ejecuta sin una policy explícita permitiendo. [ref: mcp-gets-its-first-granular-ac]
El detalle de design que importa en la práctica: WriteGuard no crea cuentas standalone de agente. Hereda los permisos del humano vía Cloudflare Access y OAuth. Si el ingeniero no puede cerrar determinado issue, el agente tampoco puede. Pero herencia de permiso sola no resuelve atribución. El audit trail distingue "Joe, Claude Code, sesión abc123" de "Joe, navegador". Los eventos de auditoría se envían de forma asíncrona — latencia cero adicionada al camino de tool call — y se limpian de valores que contengan secrets. Cada evento registra: server, tool, risk tier, outcome, usuario, cliente y duración. [ref: mcp-gets-its-first-granular-ac]
El contexto regulatorio es más urgente de lo que parece. Investigadores de seguridad encontraron más de 21 mil instancias de servidores MCP expuestos en internet, con aproximadamente 92% sin autenticación OAuth básica. WriteGuard es la respuesta del lado del servidor — y porque el control se sienta en el servidor, el usuario final no puede contornearlo cambiando cliente o deshabilitando un hook local. Es protección que no depende de la disciplina del usuario. [ref: mcp-gets-its-first-granular-ac]
Y AWS fue más lejos en el problema de secuencia con Dogwood — extensión de Cedar para gobernar secuencias de llamadas de tools de agentes, no solo requisiciones individuales. El Cedar tradicional es stateless por design: la misma requisición devuelve la misma respuesta independientemente del estado anterior, haciendo razonamiento automatizado y auditoría tratables. Pero los agentes operan en secuencias. Las restricciones que los equipos quieren viven en secuencias: obtener aprobación antes de actuar, quedarse bajo un total acumulado, dejar de contactar partes externas después de tocar datos confidenciales. Estas reglas son inaplicables en la capa de policy hoy sin Dogwood. [ref: aws-dogwood-sequence-aware-pol]
La cláusula `when temporal` es el mecanismo. Lee el histórico de eventos del agente: requisiciones de tool calls, outcomes, argumentos de input, principal solicitante. Cuatro operadores cubren la superficie práctica: `formerly` — ¿algo pasó en una ventana de tiempo? — `count_within`, `count_distinct_within` y `sum_within`. Un operador `bind` asigna un agregado a un nombre para comparación contra la requisición actual. El schema de action se genera directamente del manifest de tools MCP del agente. [ref: aws-dogwood-sequence-aware-pol]
Hay un detalle de concurrencia que es casi una trampa lista para producción. Una política de rate limit expresada como suma sobre eventos de respuesta falla contra llamadas paralelas. Tres transferencias de dos mil dólares llegan antes de que cualquiera liquide — la policy sumando respuestas no ve nada en vuelo y aprueba las tres contra un cap de cinco mil dólares. Sumar eventos de requisición en vez de respuesta niega la tercera. Una palabra separa correcto de roto. En configuraciones multi-agente donde las llamadas se entrelazan, la exposición se multiplica. [ref: aws-dogwood-sequence-aware-pol]
El costo de usar condiciones temporales: pierden el razonamiento automatizado de Cedar. Una policy usando `when temporal` no puede ser formalmente analizada por completitud o contradicción. AWS construyó un lenguaje separado en vez de extender Cedar porque las dos propiedades están en tensión fundamental. El interpreter de referencia está disponible bajo Apache 2.0, pero no es para autorización en producción — es exploración mientras el lenguaje se estabiliza. Las policies Cedar existentes permanecen válidas en Dogwood sin migración. [ref: aws-dogwood-sequence-aware-pol]
Dogwood y Cloudflare MCP 2026-07-28 resuelven mitades adyacentes del mismo problema. Los headers MCP — Mcp-Protocol-Version, Mcp-Method, Mcp-Name — hacen el tráfico de agente legible para infraestructura HTTP. Dogwood expresa qué una secuencia de llamadas tiene permiso de totalizar. Ambos son pre-requisitos para ejecutar agentes con nombre dentro de un perímetro de compliance.
La gobernanza del agente se convirtió en stack de infra. Ya no es una checklist de compliance al final del proyecto — es una decisión de arquitectura al inicio.
Y debajo de toda esta discusión de software — modelos, ontologías, políticas de secuencia — hay una física que no se dobla a la voluntad de ningún ingeniero. La física de los átomos de silicio. Y esta semana la estructura financiera que governa esos átomos quedó más visible y más concentrada que en cualquier punto de los últimos dos años.
En agosto de 2026, Nvidia anunció dos movimientos que remodelan la naturaleza de su ventaja competitiva. Primero: un memorando con Goldman Sachs, Apollo Global Management, Blackstone, BlackRock, Brookfield y KKR para movilizar más de 500 mil millones de dólares en capital de terceros para financiamiento de GPUs. Segundo: un compromiso de hasta 105 mil millones de dólares para un datacenter de OpenAI en el campus Pike County, Ohio, incluyendo una inversión directa de 1.5 mil millones en energía y una capacidad aproximada de 4 gigawatts. [ref: nvidias-capital-moat-why-chip-]
La lectura superficial es: Nvidia está apostando fuerte al ecosistema. La lectura correcta es diferente. El free cash flow trimestral de Nvidia alcanzó 48.5 mil millones de dólares — crecimiento de dieciocho veces en tres años. Tienen 30.2 mil millones en valores de equity negociables, contra 12.9 mil millones un año antes. Las holdings de private equity subieron de 3.39 mil millones a 22.25 mil millones en doce meses. En el año fiscal pasado, invirtieron 17.5 mil millones en empresas privadas y fondos de infraestructura, "primariamente para soportar startups en etapa temprana", según el filing en SEC. Startups que entonces compran sus productos directamente o vía cloud providers. [ref: nvidias-capital-moat-why-chip-]
El patrón es repetitivo suficiente para ser llamado estrategia. CoreWeave: stake de Nvidia más un acuerdo de compra de compute de 6.3 mil millones de dólares con vigencia hasta 2032. Cuando Nvidia invirtió diez mil millones en Anthropic en noviembre de 2025, el lab entró en un acuerdo separado para comprar 30 mil millones en capacidad de compute en Microsoft Azure y comprometer deploy de sistemas Grace Blackwell y Vera Rubin. La inversión de 30 mil millones en OpenAI, finalizada en febrero de 2026 en una valuation post-money de 852 mil millones, está estructurada parcialmente alrededor de leases de GPU. [ref: nvidias-capital-moat-why-chip-]
El analista de Mizuho, Jordan Klein, lo llamó "pre-financiar la compra de tus propios GPUs". SemiAnalysis encontró que 9 de los 10 startups más financiados en Forbes AI50 recibieron capital de Nvidia — incluyendo OpenAI, Anthropic y Mistral. Cuando el budget de infraestructura inicial de un startup incluye capital de Nvidia y el lease de GPU corre hasta 2032, la decisión de procurement deja de ser análisis neutral de costo por FLOP. Se vuelve bloqueada. El lock-in se convirtió en balance sheet. [ref: nvidias-capital-moat-why-chip-]
Pero el moat tiene una debilidad real y es importante nombrarla. El costo de switching de CUDA cae cuando los modelos corren, no cuando entrenan. AMD ROCm y el TorchTPU de Google — un path de ejecución PyTorch nativo para TPUs, co-desarrollado con Meta — están ganando tracción en stacks de inferencia. Y la adquisición de Groq por Nvidia — cuyas Language Processing Units basadas en SRAM superan GPUs en la fase de generación autoregressiva — señala que la empresa se está moviendo para dominar el segmento de inferencia especializada antes de que los competidores lo reclamen. [ref: nvidias-capital-moat-why-chip-]
Dicho esto: dejar Nvidia ahora no es portar kernels CUDA. Es deshacer arreglos financieros incrustados en la arquitectura del stack de capital del proveedor. Son escapes de naturaleza diferente, con costo diferente.
Y el piso de precio del token no es definido por eficiencia del modelo. Es definido por capacidad de fab de TSMC. Que está llegando al límite físico.
El nodo N3 de TSMC es el cuello de botella actual. Todo roadmap principal de acelerador convergió en él: Rubin de Nvidia, ASICs customizados de Broadcom, TPUv7 de Google, serie MI de AMD, Annapurna, MediaTek. SemiAnalysis modela demanda de IA — aceleradores, CPUs host, silicio de red — consumiendo poco menos de 60% de toda la producción N3 en 2026. En 2027, esa cifra llega a 86%, prácticamente expulsando chips de smartphone y PC del mismo nó. Se espera que la utilización de N3 supere 100% en la segunda mitad de 2026. [ref: fab-capacity-not-model-efficie]
Las wafers se hacen más caras cada ciclo. Una wafer 3nm cuesta entre 19.500 y 21.000 dólares. Una wafer 2nm: arriba de 30.000 — una prima de más de 50%. TSMC anunció aumentos de precio por cuatro años consecutivos a partir de 2026, con 3nm subiendo aproximadamente 3% y nós más avanzados pudiendo llegar a 10%. Estos aumentos no son una anomalía de ciclo — son una trayectoria de precificación que puedes modelar hoy para los próximos cuatro años. [ref: fab-capacity-not-model-efficie]
Y el packaging es donde el cuello de botella se aprieta aún más. Una wafer fabricada perfectamente no se vuelve un acelerador de IA funcional sin CoWoS — el proceso 2.5D de TSMC que bonda el die del acelerador a pilas de memoria de alta largura de banda en un interposer de silicio. El CEO de TSMC, C.C. Wei, declaró que CoWoS está agotado hasta el final de 2026. TSMC está escalando la producción de CoWoS en aproximadamente diez veces desde el final de 2023, llegando a 120.000 a 130.000 wafers por mes hasta el final de 2026 — una expansión totalmente consumida antes de ser entregada. Los lead times corren de 52 a 78 semanas. Nvidia reservó la mayoría de la alocación disponible. [ref: fab-capacity-not-model-efficie]
El efecto en el precio de inferencia es directo. Los precios de contrato de lease de un año del H100 subieron 40% desde el piso de octubre de 2025. Los precios de memoria aumentaron seis veces en el último año. DRAM se espera que doble o triplique nuevamente, con capacidad creciendo solo 20 a 30% anualmente. Los nuevos fabs, accionados por señales de demanda de finales de 2025, no van a entregar volumen relevante antes de 2027 o 2028. [ref: fab-capacity-not-model-efficie]
SemiAnalysis rastreó su propio gasto en tokens saliendo de aproximadamente diez mil dólares por año a finales de 2023 a siete millones anualizados a principios de 2025 — 28% de una base salarial de 25 millones. Cuando costos de inferencia representan más de un cuarto de tu nómina, el piso de token se vuelve una pregunta existencial, no una línea de item en el budget de infra. [ref: fab-capacity-not-model-efficie]
Dylan Patel, co-fundador de SemiAnalysis, proyecta que TSMC alcance cien mil millones de dólares de capex anual en 2028, con alivio real de capacidad llegando no antes del final de 2027. La eficiencia de modelo importa — los modelos de razonamiento que entregan más outputs por token desplazan la economía unitaria. Pero no desbloquean starts de wafer adicionales. No acortan la cola de CoWoS de 52 a 78 semanas. No alteran la trayectoria de precificación de cuatro años de TSMC. [ref: fab-capacity-not-model-efficie]
Entonces ¿dónde están apostando los hyperscalers para escapar del cuello de botella de ancho de banda de memoria mientras aguardan capacidad de fab? En disaggregación de memoria. Marvell está entregando un portafolio en tres tiers, cada uno atacando un radio diferente de la GPU — y la tesis es directa: en grandes clusters de inferencia ejecutando modelos con footprints de cientos de gigabytes y ventanas de contexto largas, presión de KV-cache y saturación de ancho de banda de memoria llegan antes de que el budget de FLOP se agote. [ref: memory-disaggregation-architec]
A nivel de servidor: el Bravera SC6 — un controlador SSD PCIe 6.0 para offload de KV-cache. El diferenciador es una flash translation layer gestionada por el host, dando a los hyperscalers control directo sobre amplificación de escritura, recolección de basura y wear leveling — en vez de delegar al firmware. Soporte a múltiples vendedores de NAND importa cuando la cadena de suministro de SSD está inestable. [ref: memory-disaggregation-architec]
A nivel de rack: la familia Structera CXL. Structera X entrega expansión de memoria usando inventario DDR4 o DDR5 existente, con compresión a bordo que entrega de 2 a 2.5 veces la capacidad efectiva versus configuraciones estándar. Meta está usando expansión de memoria basada en CXL en millones de servidores, reciclando módulos DDR4 de máquinas desactivadas en vez de comprar nuevos. El Structera S4 es un switch CXL 3.1 con una capa de conversión de protocolo PCIe-over-CXL, conectando CPUs y GPUs a pools CXL incluso cuando el silicio host carece de lanes CXL nativos — crítico para clusters construidos en generaciones anteriores de GPU. [ref: memory-disaggregation-architec]
Más allá del rack: Photonic Fabric usa links ópticos para extender un tier de memoria compartida hasta 50 metros — atravesando racks adyacentes dentro de un pod de datacenter. El objetivo es inferencia de contexto largo, modelos donde KV-cache solo agota la DRAM por servidor. Marvell reporta offload de hasta 32 TB de KV-cache caliente y afirma mejora de 2 a 3 veces en throughput de tokens dentro del mismo envelope de energía y footprint. [ref: memory-disaggregation-architec]
Con una salvedad que ellos mismos colocan: la ganancia de 2 a 3 veces asume workload limitado por ancho de banda de memoria. Las configuraciones limitadas por compute verán menos. Y Photonic Fabric es la apuesta más audaz arquitectónicamente — memoria compartida óptica introduce nuevos modos de falla, jitter de latencia en links de 50 metros y complejidad operacional que DDR local no tiene. Para arquitectos escalando ahora, el punto de entrada de menor riesgo está en Structera X y S4 — reciclaje de DDR4 y pooling de CXL funcionan sin cambios de infraestructura óptica. La evaluación de Photonic Fabric queda para clusters donde 32 TB de offload de KV-cache caliente cambian los fundamentos económicos. [ref: memory-disaggregation-architec]
Y el punto que conecta este bloque con todo lo que discutimos hoy: modela la economía de costo de inferencia alrededor de economía de fab primero, curvas de eficiencia de modelo segundo. El piso de precio del token está definido por schedule de precios de nó de TSMC, colas de alocación de CoWoS y mercados spot de HBM. Ninguno de estos factores rastrean conteos de parámetros de modelo. Nvidia se aseguró de que, cuando el silicio exista, lo financie. TSMC determinará cuándo existe. Y Marvell está apostando que la memoria será el cuello de botella hasta entonces. [ref: memory-disaggregation-architec]
Tres bloques, una tesis: lo que limita agentes en producción no es el modelo — es lo que el modelo no puede ver, lo que no tiene permiso de hacer, y lo que cuesta producir el siguiente token. Wire el lunes abre con números de Databricks Document Intelligence — extracción siete puntos mejor a un quinto del costo — y el reordenamiento de schedule que recuperó treinta y tres puntos de utilización de GPU sin CapEx. Hasta entonces.