Neuralwatt, nube de GPU: la caché decide tu gasto de IA

Una petición a un modelo de IA con la caché fría consume el doble de energía que una idéntica con la caché caliente. Neuralwatt, la nube de inferencia que publicó el análisis, revisó un mes de tráfico y encontró que esa diferencia no la decide el modelo ni el hardware, sino el cliente que lo llama: el agente.

Un harness es el programa que arma el prompt y hace la llamada al modelo: un agente de código como OpenCode, un plugin del editor, un SDK o una app propia. Para un founder que paga por tokens o por GPU-hora, ese detalle de implementación es factura, latencia y huella energética. El análisis lo firma Chad Gibson, co-fundador y CEO de Neuralwatt, que pasó más de 20 años en Microsoft antes de invertir en startups y co-fundar la compañía en 2024.

¿Por qué el agente que llama al modelo decide tu consumo de energía?

Casi todo el tráfico de Neuralwatt es agéntico, con muchísimo más input que output. Un turno típico de un agente de código envía 100.000 tokens o más de conversación y recibe unos pocos cientos de vuelta. La mayor parte de ese input es el prompt del turno anterior con un poco de texto nuevo al final.

Si el texto anterior no cambió, el servidor ya tiene su caché de key-value (KV) y solo procesa la parte nueva. Eso es el prompt caching, la mayor fuente de eficiencia de la inferencia actual: servir un token cacheado es mucho más barato que recalcularlo.

El problema es que la caché exige un prefijo exacto. Cuando el harness modifica algo que ya había enviado, se produce una ruptura de caché y el servidor recalcula todo desde la primera diferencia. Un cambio cerca del inicio —aunque sea una marca de tiempo— obliga a releer casi todo el prompt. Un cambio al final cuesta poco. Y el harness controla cómo se construye el prompt.

¿Cuánta energía desperdicia un fallo de caché?

En los 30 días entre el 8 de septiembre y el 7 de octubre de 2026, Neuralwatt vio cientos de clientes distintos. La proporción de input que no pudo servirse desde caché fue de 1,6% a 11,1% según el cliente. Parece poco, pero la aritmética engaña: un cliente con 97% cacheado envía tres tokens sin cachear por cada cien; uno con 92% envía ocho. Eso es 2,7 veces más trabajo de prefill para la misma conversación.

En energía medida, una petición mayormente sin caché consume el doble que una cacheada del mismo tamaño, y en GLM-5.3 se acerca a 2,5 veces. La latencia hasta el primer token también se resiente, y el prefill compite por las mismas GPU que la generación, así que el desperdicio frena las respuestas de todos los demás en ese servidor.

El costo se dispara en sesiones profundas. Pasados los 128.000 tokens de contexto, cerca de 3 de cada 1.000 turnos releen más de la mitad del prompt desde cero. Son pocos, pero concentran el 75% de los tokens releídos a esa profundidad: cada uno relee unos 230.000 tokens en promedio, mientras un turno normal a esa profundidad agrega una mediana de unos 370 tokens nuevos. Un solo turno así cuesta tanto prefill como unos 600 turnos ordinarios.

¿Qué rompe la caché de prompts?

Neuralwatt corrió cuatro agentes open source —OpenCode, Pi, omp y Kilo Code— contra DeepSeek V4.1 Flash y GLM-5.3 en un proxy que registraba cada token. De 539 peticiones que seguían a otra en la misma conversación, el 88% eran adiciones puras: el prompt anterior era un prefijo exacto del nuevo. Las otras 65 rompieron la caché, y todas las rupturas vinieron del harness editando algo que ya había enviado. Ninguna salió de las plantillas de chat, y ni el tiempo de inactividad, ni reiniciar el agente, ni usar sub-agentes provocaron rupturas.

Los culpables más caros:

• Recordatorio del modo plan. OpenCode 1.x adjuntaba un aviso de cambio de modo a cada mensaje nuevo y lo borraba al turno siguiente, forzando la relectura del turno completo: entre 330 y 2.340 tokens por turno. La versión 2.x lo guarda en su propio mensaje y ya no rompe la caché.
• Poda de archivos releídos. omp reemplaza una lectura anterior por un marcador de texto. En la prueba, esa edición cayó al 62% del prompt y obligó a releer 5.846 de 15.520 tokens.
• Cambiar el esfuerzo de razonamiento. Ambas plantillas escriben el nivel en los primeros tokens del prompt: la primera diferencia apareció en el token 8. Un cambio reescribe todo.
• Conectar o desconectar un servidor MCP. OpenCode 1.x inserta herramientas nuevas en orden alfabético, en medio de la lista: en GLM-5.3 el cambio cae a unos 1.300 tokens del inicio.
• Agregar una skill. La primera diferencia apareció entre el token 461 y el 2.948 según el modelo.
• El cambio de fecha. OpenCode 1.x y Kilo Code escriben la fecha del día en el system prompt, a unos 2.000 tokens del inicio. Cruzar la medianoche local implica releer casi todo una vez.
• La compactación. Con la misma ventana de 40.000 tokens, OpenCode 2.x compactó tres veces y releyó 67.850 tokens; la 1.x compactó una vez y releyó 29.776.

En producción el patrón se repite: cambiar la lista de herramientas o el nivel de esfuerzo hace que una ruptura de caché sea más de 20 veces más probable y cuesta, en promedio, cerca del 40% del prompt anterior. Esos cambios ocurren en apenas el 0,5% de los turnos, pero explican el 19% de todos los tokens releídos.

¿Qué hace distinto a deepseek-harness?

En la captura de laboratorio, todas las peticiones de seguimiento de deepseek-harness fueron adiciones puras al final, incluso después de reiniciar el proceso. Sus prácticas: reconstruir las peticiones desde un log de sesión de solo adición, mantener un system prompt fijo y mínimo (sin fecha, sin estado de git, sin sistema operativo), agregar los cambios de estado después del historial, dejar la lista de herramientas estable y ordenada, y compactar tarde reutilizando el prefijo existente. Cada paquete del repositorio incluye una sección sobre su efecto en la caché KV.

¿Qué significa esto para tu startup?

Si construyes o configuras un agente, hay decisiones de arquitectura que se traducen directo en costo:

• Mantén idéntico el inicio del prompt en cada turno. Agrega mensajes nuevos y resultados de herramientas al final, y describe los cambios de configuración ahí también.
• Saca la fecha, el estado de git y cualquier dato cambiante del system prompt. Es el error más caro y el más fácil de evitar.
• Compacta tarde y haz que la llamada del resumidor reutilice el prefijo exacto de la conversación.
• Envía un identificador de sesión estable. En Neuralwatt, el header X-NW-Conversation-ID permite que la sesión siga en el servidor que ya tiene su caché, incluso tras una compactación.

Si solo usas agentes de terceros, el margen de acción es menor pero real: elige el nivel de esfuerzo de razonamiento por sesión en lugar de cambiarlo a mitad de camino, y en omp prueba compaction.supersedeReads: false. Deja configurados el esfuerzo, los servidores MCP y las skills antes de que la sesión se haga larga: ahí es cuando una ruptura duele de verdad.

Vale la pena medirlo. Neuralwatt expone en su dashboard, por sesión y turno, cuánto del prompt vino de caché, cuánto se computó en frío, el tiempo hasta el primer token y la energía medida, sin mostrar el texto de los prompts. Y el problema no es exclusivo de esta nube: el 14 de octubre de 2026, Tensormesh —creadora de LMCache— anunció una plataforma de gestión de caché KV para empresas, con la promesa de reutilizar contexto en cualquier punto del prompt y no solo al inicio. Su CEO, Junchen Jiang, lo dijo sin rodeos en el comunicado: los workloads de LLM "recalculan el mismo contexto sin fin", y eso desperdicia tiempo de GPU e infla el tiempo hasta el primer token.

El interés no es nuevo. Cuando AWS llevó prompt caching a Bedrock en diciembre de 2024, TechCrunch reportó que la compañía estimaba reducciones de costo de hasta 90% y de latencia de hasta 85%, y que Adobe había medido una caída del 72% en tiempo de respuesta en algunas de sus aplicaciones. Un repaso técnico de Geeky Gadgets cifra el ahorro del KV caching entre 41% y 80% según el caso de uso. La diferencia es que ahora el foco está puesto en el cliente, no solo en el modelo o el hardware.

Conclusión

Una ruptura de caché no aparece como error: la respuesta llega, solo que más tarde y con más energía gastada. Ese es el motivo por el que casi nadie la mide, y por el que se acumula sin que nadie la vea. La buena noticia es que la mayor parte del desperdicio se corrige con una configuración o un cambio pequeño en cómo el agente arma su prompt.

Para un founder, la lectura práctica es simple: antes de cambiar de modelo o de GPU para bajar costos, revisa cómo tu agente construye el prompt. Es la palanca más barata que tienes sobre la mesa, y no requiere reescribir nada del producto.

Fuentes

• Why harnesses matter for energy (and token) efficiency (fuente original)
• Tensormesh Launches Tensormesh Platform to Cut LLM Inference Costs by Reusing KV Cache at Enterprise Scale
• AWS brings prompt routing and caching to its Bedrock LLM service
• Why Prompt Caching is the Secret to Slashing Your AI Costs By 90%