Inferencia de AI distribuida: reduce la latencia 75% sin cambiar tu modelo

Todo equipo que intenta optimizar los costos de inferencia de AI termina chocando contra la misma pared: el modelo se vuelve más barato, pero la factura sigue igual.

En los últimos seis meses, Hacker News estuvo lleno de proyectos haciendo cosas extraordinarias con hardware mínimo: AirLLM corriendo modelos de 70B parámetros en una sola GPU de 4GB, Kimi K3 sirviendo tokens a $0.50/tok desde 29GB de RAM, DeepSeek V4 Flash redefiniendo los benchmarks de precio-desempeño para workloads en producción. El hilo común es ingenieros descubriendo que el mayor driver de costo en inferencia no es el cómputo.

Es la distancia.

TL;DR: La inferencia centralizada agrega 100–180ms de latencia de round-trip por solicitud y obliga al over-provisioning para mantener el p95. Una capa de preprocesamiento distribuido — corriendo auth, semantic caching y response streaming cerca de los usuarios — reduce la carga en el origen de inferencia en 40–60% y la latencia global p50 en 75%. Esto no requiere cambiar tu proveedor de inferencia. Requiere insertar la capa correcta frente a lo que ya tienes.

Por qué la inferencia centralizada de LLM es estructuralmente cara

El deploy estándar funciona así: el modelo corre en una región (us-east-1, o donde sea que viva tu cluster de GPU), las solicitudes llegan de todas partes, las respuestas regresan. Simple de configurar, familiar de operar, y cada vez más difícil de justificar a escala.

El costo por token sigue bajando. Todo lo que lo rodea no.

La latencia de red se acumula. Un usuario en Ciudad de México haciendo solicitudes a un endpoint de inferencia en Virginia agrega 100–180ms de overhead de round-trip antes de que se genere un solo token. Para respuestas en streaming, eso es una pausa muerta antes de que aparezca algo en pantalla. Para agent loops haciendo docenas de llamadas secuenciales, se apila en segundos.

Las fallas regionales tienen blast radius global. Cuando tu endpoint de inferencia está en una región y esa región tiene un camino de red degradado (o un evento de energía como el shutdown de la planta nuclear que Hungría experimentó este verano cuando la sequía bajó el nivel del Danubio a mínimos históricos), todos los usuarios globalmente se ven afectados.

El over-provisioning es el ítem oculto de la factura. Para manejar picos de tráfico sin que los cold starts destruyan el p95, los equipos mantienen capacidad warm corriendo todo el tiempo. Con infraestructura centralizada, pagas por esa capacidad ociosa independientemente de si está sirviendo solicitudes o no. En volumen, a través de múltiples geografías, este costo supera el gasto en inferencia en sí.

La división en tres capas: dónde la inferencia distribuida realmente ayuda

Los workloads modernos de inferencia tienen tres capas distintas con diferentes perfiles de cómputo:

1. Manejo y preprocesamiento de solicitudes: auth, rate limiting, ensamblado de prompt, inyección de contexto
2. Generación de tokens: el paso que necesita GPU o hardware acelerado
3. Response streaming y posprocesamiento: formateo, filtrado, caching, logging

El error que la mayoría de los equipos comete es tratar las tres como una unidad y hacer el deploy juntas en una región centralizada. Por eso pagas costos de latencia en operaciones que no tienen nada que ver con la generación de tokens.

El principio del preprocesamiento distribuido: Las capas 1 y 3 (manejo de solicitudes y procesamiento de respuestas) pueden correr en una arquitectura distribuida sin cold starts, a menos de 10ms de los usuarios, por una fracción del costo de mantener esa lógica en un servicio centralizado. Solo la capa 2, el cómputo del modelo, necesita quedarse donde está el hardware.

Separa el stack en esa frontera y obtienes:

• Preprocesamiento por debajo de 10ms para auth, inyección de contexto y ensamblado de prompt antes de que la solicitud llegue al modelo
• Response streaming desde el punto de presencia más cercano, entregando tokens sin un round-trip extra al origen
• Semantic caching distribuido: patrones comunes de completion manejados en la capa de red, sin llamada al modelo
• Failover regional sin re-arquitectura: enruta alrededor de regiones de inferencia degradadas de forma transparente

Una implementación concreta

Así se ve esto en la práctica usando Azion Functions con un proveedor de inferencia upstream o modelo self-hosted:

// Function: auth, rate limiting, cache lookup, proxy al origen de inferencia

export default async function handler(request) {
  const authResult = await validateRequest(request);
  if (!authResult.ok) return new Response("Unauthorized", { status: 401 });

  const cacheKey = await buildSemanticCacheKey(request);
  const cached = await azion.cache.get(cacheKey);
  if (cached) return streamFromCache(cached);

  // Solo llega al origen de inferencia en caso de cache miss
  const inferenciaResponse = await fetch(inferencia_ORIGIN, {
    method: "POST",
    body: await request.arrayBuffer(),
    headers: buildinferenciaHeaders(authResult.token),
  });

  // Hace streaming de tokens al usuario mientras escribe en caché
  return streamWithCacheWrite(inferenciaResponse, cacheKey);
}

Esta function corre en 300+ puntos de presencia globales sin cold starts. Auth, rate limiting y consultas al caché ocurren en la misma ubicación que el usuario. El origen de inferencia solo ve las solicitudes que necesitan generación de tokens. Todo lo demás se maneja antes de llegar ahí.

El impacto en el throughput es real. Los equipos que usan este patrón reportan reducciones de 40–60% en las solicitudes que llegan al origen de inferencia, porque el semantic caching absorbe queries repetidas o casi idénticas. Para la mayoría de las features de AI en producción (soporte al cliente, búsqueda, generación de contenido), las distribuciones de queries se agrupan alrededor de intenciones comunes mucho más de lo que parecen.

Los números que importan

Una feature de AI en producción sirviendo 10 millones de solicitudes por mes para una base de usuarios global:

El modelo de preprocesamiento distribuido, alcanzable hoy sin cambiar tu proveedor de inferencia, reduce la latencia global p50 en 75% y la carga en el origen de inferencia hasta un 60%. Eso es una clase diferente de experiencia de usuario.

El ahorro de costos viene de dos lugares: menos solicitudes llegando a endpoints de inferencia pagos (los cache hits son baratos), e infraestructura de origen dimensionada correctamente porque ya no estás haciendo over-provisioning para compensar la latencia.

Por qué los workloads de agentes hacen esto urgente

La inferencia de disparo único (el usuario pregunta, el modelo responde) es el caso fácil. Los agentes son más difíciles, y el problema de distancia se apila.

Un agente haciendo 15 tool calls secuenciales, cada uno con 150ms de overhead de red hacia un endpoint centralizado, acumula 2.25 segundos de latencia de red pura por agent loop. Antes de cualquier cómputo del modelo. Para agentes corriendo múltiples loops, estás en 10–20 segundos de overhead solo de red.

El preprocesamiento distribuido resuelve el loop externo: la lógica de orquestración, el enrutamiento de tool calls, la gestión de contexto y el caching entre pasos pueden correr cerca del usuario. Las llamadas al modelo siguen yendo a donde está el hardware, pero el overhead del agent loop cae drásticamente.

Los equipos construyendo agentes en producción enfocados en responsividad ya están dividiendo sus stacks de esta forma. Los que no lo están están chocando contra un techo donde la experiencia del usuario se degrada más rápido de lo que las mejoras del modelo compensan.

Por qué los modelos más baratos amplían la brecha de arquitectura

A medida que los modelos se vuelven más pequeños y eficientes (Qwen3.8B, DeepSeek Flash, Kimi K3), el caso para la arquitectura distribuida se vuelve más urgente.

Los modelos más pequeños reducen el costo por token. Lo que significa que el overhead de red y el costo de preprocesamiento se vuelven una porción más grande de tu estructura de costo total. Un modelo de $0.001/1K tokens corriendo detrás de 180ms de latencia de red evitable tiene un perfil de costo efectivo peor que un modelo de $0.003/1K tokens corriendo con 20ms de overhead, porque la latencia aparece como churn de usuarios y over-provisioning en lugar de aparecer como una línea en tu factura de inferencia.

Las mejoras en eficiencia del modelo no corrigen la ineficiencia arquitectural. Las dos curvas son independientes, e ignorar la curva de infraestructura mientras se celebra la curva del modelo es cómo los equipos terminan con modelos rápidos entregando productos lentos.

Cómo empezar sin reemplazar tu configuración de inferencia

La migración no requiere tocar tu proveedor de inferencia. Requiere insertar una capa distribuida frente a él.

Tres cambios para empezar:

1. Mueve auth y rate limiting a la capa distribuida. Cada solicitud de inferencia que llega a tu origen para hacer auth paga latencia innecesaria. Azion Functions manejan esto en menos de 1ms, globalmente, sin cold starts.

2. Agrega semantic caching en la capa de red. No necesitas un modelo de similitud sofisticado. Normalizar y hacer hash de los prompts captura 20–40% de cache hit rates en la mayoría de los workloads en producción.

3. Enruta por geografía. Si tienes capacidad de inferencia en múltiples regiones, enrutar solicitudes a la región más cercana en lugar de hacer round-robin a un solo origen es un cambio de una línea con impacto medible en la latencia.

Ninguno de estos cambios requiere modificar tu modelo, tu proveedor de inferencia o el código de tu aplicación. Requieren poner la capa correcta frente a lo que ya tienes.

La conversación sobre costos de AI inferencia está mayormente enfocada en la capa del modelo: modelos más pequeños, cuantización, kernels eficientes. Ese trabajo importa. Pero los ingenieros que ponen features de AI en producción a escala siguen llegando al mismo descubrimiento: la capa del modelo es solo la mitad del problema.

La otra mitad es todo lo que hay entre el modelo y el usuario. Esa mitad ya está resuelta, si construyes la arquitectura para aprovecharlo.

Azion Web Platform corre ejecución distribuida sin cold starts en 300+ puntos de presencia globales. Azion Functions manejan el preprocesamiento de solicitudes, caching y response streaming sin tocar tu infraestructura de inferencia. Ver la documentación →

Preguntas frecuentes

¿Por qué la inferencia de LLM sigue siendo cara incluso con modelos más baratos? Los modelos más baratos reducen el costo por token, pero la latencia de round-trip de red y el over-provisioning se mantienen constantes independientemente del precio del modelo. Un usuario en Ciudad de México llamando a un endpoint de inferencia en Virginia agrega 100–180ms antes de que se genere un solo token. Para compensar, los equipos hacen over-provision de capacidad warm, pagando por cómputo ocioso todo el tiempo. Estos costos de infraestructura no aparecen en tu factura de inferencia pero pueden superarla a escala.

¿Qué es la inferencia de AI distribuida? La inferencia de AI distribuida separa el manejo de solicitudes y el response streaming de la generación de tokens. Auth, rate limiting, ensamblado de prompt y semantic caching corren en puntos de presencia globales cerca de los usuarios, agregando menos de 10ms de overhead. Solo las solicitudes que fallan el caché llegan al origen de inferencia para la generación de tokens. Esto reduce la carga del origen en 40–60% y la latencia global p50 hasta un 75% sin cambiar el modelo ni el proveedor de inferencia.

¿Cuánto reduce el semantic caching los costos de inferencia de LLM? El semantic caching en la capa de red captura 20–40% de cache hit rates en la mayoría de los workloads de AI en producción. Las aplicaciones de soporte al cliente, búsqueda y generación de contenido ven tasas más altas porque las distribuciones de queries se agrupan alrededor de intenciones comunes. Cada cache hit elimina una llamada de inferencia por completo, reduciendo la generación de tokens pagos proporcionalmente.

¿Por qué la latencia de inferencia se acumula dentro de los pipelines de agentes de AI? Los agentes de AI encadenan múltiples llamadas de función por tarea. Una cadena de cuatro tool calls donde cada función agrega 150ms de overhead de round-trip de red acumula 600ms de latencia de red pura por agent loop, antes de que corra cualquier cómputo del modelo. Para agentes corriendo múltiples loops, esto se convierte en segundos. El manejo distribuido de solicitudes elimina la mayor parte de este overhead al correr la lógica de orquestación cerca del usuario.

¿Cuál es la diferencia de costo de infraestructura entre inferencia centralizada y distribuida? Para una feature de AI en producción sirviendo 10 millones de solicitudes por mes desde una base de usuarios global, la inferencia centralizada en una sola región cuesta un estimado de $12,000–18,000/mes incluyendo over-provisioning para p95. Agregar una capa de preprocesamiento distribuido lo reduce a $5,000–8,000/mes mientras reduce la latencia global p50 de ~340ms a ~85ms.

¿La inferencia distribuida requiere cambiar mi proveedor de inferencia? No. La capa distribuida se ubica frente a tu endpoint de inferencia existente. Auth, rate limiting, semantic caching y response streaming corren en puntos de presencia globales. El origen de inferencia se mantiene sin cambios. Solo recibe menos solicitudes porque el caché absorbe las queries repetidas antes de que lleguen ahí.

¿Cómo afecta el tamaño más pequeño del modelo el caso para la inferencia distribuida? A medida que el costo por token baja con modelos más pequeños, el overhead de red y el over-provisioning se vuelven una porción más grande del costo total de inferencia. Un modelo de $0.001/1K tokens corriendo detrás de 180ms de latencia de red evitable tiene un perfil de costo efectivo peor que un modelo de $0.003/1K tokens con 20ms de overhead, porque la latencia aparece como churn de usuarios y over-provisioning en lugar de aparecer como una línea en la factura de inferencia. Las mejoras en eficiencia del modelo aceleran el argumento para corregir la ineficiencia de infraestructura.