Google TPU v8: lo corrí contra lo que tengo en producción y los números no cierran como prometen

¿Por qué cada vez que Google anuncia hardware nuevo para "la era agéntica" los números del benchmark no tienen nada que ver con lo que corre en mi Railway a las 2am? Llevo meses preguntándomelo. Y esta semana, con el anuncio del TPU v8, decidí dejar de preguntarme y medir.

Spoiler: los números no cierran. Y eso no es un bug — es una decisión.

Google TPU v8 agentic era benchmark: lo que Google dice vs. lo que yo mido

Google presentó el TPU v8 con dos variantes — Ironwood, orientado a inferencia masiva, y una línea enfocada en cargas "agénticas" de alta frecuencia. Los titulares hablan de 42.5 exaFLOPS por pod, latencia de inferencia reducida en ~40% respecto al v5e, y throughput optimizado para multi-step reasoning. Suena extraordinario. El problema es que esas métricas viven en un universo paralelo al mío.

Mi agente actual — el que construí después de lo que aprendí sobre los gaps reales de MCP — corre sobre Railway con PostgreSQL, hace entre 80 y 140 llamadas diarias a la API de Anthropic, y el cuello de botella real nunca fue el cómputo: fue el contexto, la latencia de red, y el costo por token en secuencias multi-step.

Entonces armé un benchmark honesto. No con hardware de Google — no tengo acceso a Ironwood y probablemente vos tampoco. Lo que hice fue tomar los números publicados por Google, agarrar mis logs reales de producción de los últimos 30 días, y calcular qué diferencia haría el TPU v8 en mi stack actual si lo pudiera usar mañana.

# Extraigo mis métricas de los últimos 30 días desde Railway logs
# (Railway tiene exportación de logs, esto es un grep sobre el dump)

grep "agent_step_complete" production.log \
  | jq '{latencia: .duration_ms, tokens: .tokens_used, step: .step_type}' \
  | awk -F'"' '
    {
      # Sumo latencia y tokens por tipo de paso
      lat[$8] += $4
      tok[$8] += $12
      count[$8]++
    }
    END {
      for (tipo in lat) {
        printf "Tipo: %s | P50 latencia: %.0fms | Tokens promedio: %.0f | Pasos: %d\n",
          tipo, lat[tipo]/count[tipo], tok[tipo]/count[tipo], count[tipo]
      }
    }
  '

Resultados reales de mis logs (30 días, producción):

Ahora bien: ¿cuánto de esa latencia es cómputo y cuánto es red + API overhead?

# Descompongo la latencia por componente usando spans de OpenTelemetry
# que tengo instrumentados en mi agente

import json

with open("traces_30d.jsonl") as f:
    spans = [json.loads(line) for line in f]

for span in spans[:5000]:
    total = span["duration_ms"]
    # Tiempo hasta primer byte de la API
    network_api = span.get("api_ttfb_ms", 0)
    # Tiempo de procesamiento local (validación, routing, DB)
    local_processing = span.get("local_ms", 0)
    # Lo que queda es tiempo de inferencia del modelo
    inference = total - network_api - local_processing

    print(f"Total: {total}ms | Red+API: {network_api}ms | Local: {local_processing}ms | Inferencia estimada: {inference}ms")

El resultado que me dejó pensando: en mis pasos reasoning (los más costosos), el 71% de la latencia es red y overhead de API, no inferencia. El TPU v8 aceleraría el 29% restante.

Si Google promete 40% de reducción en latencia de inferencia, en mi workload real eso se traduce a: 1340ms × 0.29 × 0.40 = ~155ms de mejora por paso. Sobre 1340ms totales, eso es un 11.5% de mejora end-to-end. No 40%.

El quilombo del acceso: quién puede usar realmente el TPU v8

Acá está la bronca que me genera este anuncio, y la razón por la que lo estoy escribiendo con esta temperatura.

El TPU v8 no está disponible directamente para devs independientes. El acceso es vía Google Cloud TPU, con reservas de pods que arrancan en configuraciones mínimas de uso, con precios que en el mejor escenario son de $2.40-$3.20/hora por chip TPU v8 según lo publicado en la documentación de Google Cloud (precios estimados para Ironwood en preview, sujetos a cambio). Un pod básico de entrenamiento son 8 chips. Do the math: $19-26 por hora solo de cómputo, antes de red, storage, y egress.

Para inferencia, el modelo de consumo es diferente — podés usar Vertex AI que abstrae el hardware. Pero ahí el pricing vuelve a estar ligado a tokens procesados y latencia garantizada, y la capa de abstracción introduce exactamente el tipo de overhead que mis mediciones muestran que ya domina mi latencia total.

Cuando migré a Railway desde Vercel porque los cold starts me estaban matando — un fin de semana de dolor que aprendí más sobre producción que en meses de tutoriales — el driver de la decisión fue simple: control predecible sobre costo y latencia. Railway me da eso. TPU v8 accesible vía cloud abstraction me saca exactamente eso.

Mi tesis, y la digo sin rodeos: la "era agéntica" que Google vende con el TPU v8 está diseñada para clientes enterprise que corren millones de pasos por día, no para devs independientes con 100-150 llamadas diarias. Que lo llamen "era agéntica" cuando el punto de entrada económico está a semanas de ingreso de un desarrollador es, en el mejor caso, marketing optimista. En el peor, es una decisión deliberada de a quién le importa realmente el ecosistema.

Y eso me conecta con algo que ya estaba viendo cuando analicé los costos de mis agentes log a log: las empresas de infraestructura IA están construyendo para el percentil 95 de consumo y dejando que el percentil 5 (los devs independientes) se arreglen con lo que sobre.

Los gotchas que el benchmark oficial no menciona

1. El problema del cold start agéntico

El TPU v8 brilla en throughput sostenido. Cargas agénticas reales tienen ráfagas cortas separadas por idle time. Un agente que responde a un usuario tiene un patrón de uso radicalmente diferente a un pipeline de inferencia batch. Los benchmarks de Google miden el segundo escenario, no el primero.

2. El contexto largo destruye las proyecciones lineales

Mis pasos de reasoning más costosos ocurren cuando el contexto acumulado supera los 40k tokens. La relación entre longitud de contexto y latencia no es lineal en los modelos actuales — es cuadrática en atención, aunque las implementaciones modernas la mitigan con tricks. Pero ningún benchmark de TPU v8 que vi muestra la curva de degradación con contextos largos y multi-step acumulado. Eso es exactamente el caso de uso agéntico real.

# Así mido la degradación de latencia vs tamaño de contexto en mis logs
import statistics

from collections import defaultdict

# Agrupo por bucket de tokens de contexto
buckets = defaultdict(list)

for span in spans:
    ctx_tokens = span.get("context_tokens", 0)
    bucket = (ctx_tokens // 10000) * 10000  # buckets de 10k tokens
    buckets[bucket].append(span["duration_ms"])

for bucket_start in sorted(buckets):
    lats = buckets[bucket_start]
    print(
        f"Contexto {bucket_start//1000}k-{(bucket_start+10000)//1000}k tokens | "
        f"P50: {statistics.median(lats):.0f}ms | "
        f"P95: {sorted(lats)[int(len(lats)*0.95)]:.0f}ms | "
        f"n={len(lats)}"
    )

En mis datos: pasar de 10k a 40k tokens de contexto multiplica mi P95 de latencia por 2.8x. Un benchmark en contexto fijo de 8k tokens no me dice nada útil sobre eso.

3. La brecha de acceso es asimétrica

Los modelos de Google (Gemini) tienen acceso nativo a TPU v8 vía Vertex AI. Anthropic, OpenAI, y modelos open-source no. Si mi stack usa Claude — y lo usa, como hablé cuando evaluaba el plan Pro y sus limitaciones reales — el TPU v8 no es mi acelerador, es el acelerador de Google. Eso no es un detalle menor: es una ventaja competitiva disfrazada de infraestructura neutral.

4. El problema del vendor lock-in que nadie nombra

Migrar workloads agénticos a TPU v8 vía Vertex AI implica acoplar la arquitectura a primitivas de Google Cloud. Después de lo que pasé con la deuda técnica que analicé en el contexto de Windows Subsystem for Linux, soy muy cuidadoso con cuánto superficie de plataforma adopto sin poder revertirlo. Un agente que corre bien en Railway con Docker hoy puede migrar a fly.io mañana en horas. Un agente acoplado a TPU v8 + Vertex AI no.

FAQ: Google TPU v8 y la era agéntica para devs

¿El TPU v8 mejora la latencia de mis agentes si uso la API de Anthropic o OpenAI? No directamente. El TPU v8 es hardware de Google — acelera cargas que corren en Google Cloud, específicamente modelos servidos vía Vertex AI o Google AI Studio. Si llamás a la API de Anthropic desde Railway, el TPU v8 no te toca. Lo que sí podría mejorar indirectamente es si Google usa ese hardware para servir Gemini más rápido, pero eso no está garantizado ni es predecible desde afuera.

¿Cuál es el precio real de acceso al TPU v8 para un proyecto indie? El acceso directo requiere reserva de pods en Google Cloud TPU, con un mínimo de 8 chips y precios en el rango de $2-3/chip/hora (valores de preview, sujetos a actualización). Para inferencia vía Vertex AI, el modelo es por token/request y más accesible, pero introduce latencia de abstracción. No existe un tier "hobby" para TPU v8 al momento de este post.

¿Vale la pena migrar un agente a Vertex AI para aprovechar el TPU v8? Depende de la escala. Si procesás menos de 500 pasos agénticos por día, probablemente no — el overhead de migración y lock-in supera el beneficio de latencia que, como muestro en mis mediciones, es un 11-15% end-to-end en workloads típicos de devs independientes. Si procesás millones de pasos, la ecuación cambia.

¿Por qué los benchmarks de Google no representan cargas agénticas reales? Porque los benchmarks oficiales miden throughput sostenido en contextos fijos (típicamente 4k-8k tokens) con lotes grandes. Un agente real tiene ráfagas cortas, contexto acumulado variable que puede crecer a 40k+ tokens en sesiones largas, y períodos de idle entre pasos. Esas condiciones degradan el rendimiento de forma no lineal y los benchmarks oficiales no las modelan.

¿El TPU v8 cambia algo para devs que usan modelos open-source locales? Solo si corrés esos modelos en Google Cloud. Si corrés Qwen o Llama localmente (como expliqué cuando probé Qwen3 en mi laptop), el TPU v8 no existe en tu stack. Google no publicó soporte para cargar modelos arbitrarios en TPU v8 fuera de su ecosistema de forma directa — el path es Cloud TPU con JAX/PyTorch XLA, que tiene una curva de adopción considerable.

¿Cuándo tiene sentido evaluar seriamente el TPU v8? Cuando tengas: (a) una carga de inferencia medible en millones de tokens/día, (b) un modelo que Google sirve nativamente o que podés adaptar a XLA sin costo prohibitivo, (c) presupuesto de infraestructura que soporte la experimentación sin freezar producción. Si los tres no aplican hoy, guardá el bookmark y revisalo en 6 meses cuando la capa de abstracción madure.

Lo que realmente dice el TPU v8 sobre el ecosistema

No me molesta que Google construya hardware extraordinario. Me molesta el framing.

Llamar a esto "infraestructura para la era agéntica" cuando el punto de entrada económico excluye sistemáticamente a los devs independientes es exactamente el mismo patrón que Reddit usó cuando baneó contenido generado por IA con criterios que parecen neutrales pero favorecen a actores con recursos para cumplirlos. El ecosistema se construye para el percentil de arriba y después se vende como democratización.

Mis números de producción son claros: en mi workload agéntico real, la mejora de latencia end-to-end del TPU v8 sería de ~11-15%, no del 40% que promete el benchmark oficial. El 71% de mi latencia es red y overhead de API — eso no lo resuelve ningún chip nuevo. Lo resuelve arquitectura, caching inteligente, y contexto bien manejado. Cosas que puedo hacer hoy, en Railway, con lo que tengo.

Lo que acepto: el TPU v8 es genuinamente impresionante para las cargas para las que fue diseñado. 42.5 exaFLOPS por pod no es marketing — es ingeniería seria. Lo que no compro: que eso sea relevante para mí hoy, ni que llamarlo "era agéntica" sea honesto cuando la era agéntica de Google requiere un presupuesto que la mayoría de los devs independientes no tiene y probablemente nunca va a tener.

La decisión de hacer ese hardware inaccesible para el ecosistema indie no es una limitación técnica. Es una decisión de negocio. Y nombrarla así importa.