Edge AI Inference: Ejecutando modelos en la capa CDN
La llamada de inferencia más rápida es la que nunca cruza un océano. Edge AI traslada modelos cuantizados a la capa CDN -- Cloudflare Workers AI, Deno, Vercel -- colocando inteligencia en el mismo nivel que tus activos estáticos. Esta es una guía de producción sobre cuándo funciona, cuándo falla y cuánto cuesta realmente.
Tabla de Contenidos
La llamada de inferencia más rápida es la que nunca cruza un océano.
Durante dos décadas, los CDN existieron para cachear bytes: imágenes, scripts, fragmentos HTML. El contrato era simple. Colocar contenido estático cerca del usuario. Reducir el tiempo de ida y vuelta. Facturar por gigabyte.
Ese contrato acaba de cambiar. La capa CDN ahora ejecuta modelos. No demos de juguete. Clasificadores en producción, generadores de embeddings, detectores de PII, moderadores de contenido. Modelos pequeños, cuantizados agresivamente, ejecutándose en el mismo nivel de red donde vive tu CSS.
No se trata de un cambio teórico. Cloudflare Workers AI sirve inferencia desde más de 300 centros de datos. Deno Deploy ejecuta modelos ONNX en el edge. Vercel distribuye helpers del AI SDK que frontan funciones desplegadas en el edge. La infraestructura es real. La pregunta ya no es «¿podemos?» sino «¿cuándo debemos hacerlo, y a qué renunciamos?»
Hemos estado ejecutando edge inference en producción para cargas de clasificación y embeddings. Este artículo es lo que aprendimos: la arquitectura, el modelo de costos, las concesiones de cuantización y los patrones operacionales que sobreviven al contacto con tráfico real.
I. El argumento de la latencia
La latencia no es un número. Es una experiencia de usuario.
Un clúster GPU centralizado en us-east-1 entrega una latencia de primer token de 200-800ms para una llamada LLM típica. Sumemos el tránsito de red para un usuario en Oslo, y estamos ante 300-1000ms antes de que llegue el primer byte de inteligencia. Para un usuario en São Paulo, el doble.
Edge inference cambia la aritmética:
Centralizado (us-east-1):
Usuario (Oslo) -> CDN edge (Oslo) -> Origen (Virginia) -> Clúster GPU -> vuelta
RTT de red: ~120ms * 2 = ~240ms
Inferencia: ~200-600ms
TTFT total: ~440-840ms
Edge inference:
Usuario (Oslo) -> CDN edge (Oslo) -> modelo local -> vuelta
RTT de red: ~5ms * 2 = ~10ms
Inferencia: ~50-300ms (cuantizado, modelo pequeño)
TTFT total: ~60-310ms
Para tareas de clasificación -- «¿es tóxico este comentario?», «¿en qué idioma está esto?», «¿contiene PII?» -- la ruta edge es 3-8x más rápida. No porque el modelo sea más rápido. Porque la red desapareció.
La latencia de primer token importa más en flujos interactivos: autocompletado, moderación en línea, clasificación en tiempo real, generación de embeddings para búsqueda mientras se escribe. Estas son las tareas donde 400ms se siente roto y 60ms se siente instantáneo. El umbral de percepción humana para lo «instantáneo» es aproximadamente 100ms. Edge inference te sitúa por debajo de ese umbral para las cargas de trabajo adecuadas.
Para generación de texto largo -- resúmenes de múltiples párrafos, completado de código, razonamiento de cadena de pensamiento -- la historia del edge es más débil. Se necesitan modelos más grandes, ventanas de contexto más largas y más memoria de la que los nodos edge suelen ofrecer. La ventaja de latencia existe, pero queda eclipsada por el tiempo de generación.
Conoce la forma de tu carga de trabajo antes de elegir la topología.
II. Qué significa realmente «edge» en 2026
La palabra «edge» está sobrecargada hasta el punto de la inutilidad. Seamos precisos.
Los nodos edge CDN son instancias de cómputo ligeras que se ejecutan en Puntos de Presencia (PoPs) -- los mismos centros de datos que sirven tus activos cacheados. Tienen memoria restringida (128MB-512MB por isolate), tiempo de ejecución limitado (típicamente presupuestos de 30s-50ms de tiempo CPU), y carecen de GPU persistente. La inferencia se ejecuta en CPUs o, cada vez más, en aceleradores de propósito específico co-ubicados con la infraestructura CDN.
El edge regional es diferente. Son regiones de cómputo completas más cercanas a los usuarios que una única nube centralizada, pero no tan distribuidas como los PoPs CDN. Piensa en máquinas de Fly.io, regiones de Railway o AWS Local Zones.
On-device es el edge definitivo: el navegador o teléfono del usuario. Inferencia WebGPU, Core ML, ONNX Runtime Web.
Este artículo se centra principalmente en el edge de capa CDN -- el nivel más restringido y más ampliamente distribuido. Los patrones se aplican, con modificaciones, al edge regional y on-device.
Distribución vs. Capacidad:
CDN Edge (300+ PoPs) | Menor latencia, modelos más pequeños
Edge Regional (20-50) | Más memoria, modelos medianos
Nube Centralizada (3-8) | GPU completa, modelos más grandes
─────────────────────────┼─────────────────────────────────────
Más ubicaciones | Más capacidad
III. Cuantización de modelos: el arte de la degradación controlada
No se puede ejecutar un modelo de 7B parámetros en float32 en el edge CDN. Las matemáticas son implacables: 7B parámetros * 4 bytes = 28GB. Un Cloudflare Worker recibe 128MB.
La cuantización es el puente. Reducir precisión, reducir tamaño, aceptar cierta pérdida de calidad. La pregunta es siempre: ¿cuánta calidad sacrificas, y puede tu aplicación tolerarlo?
El panorama de la cuantización
INT8 -- cuantización a enteros de 8 bits. Reduce el tamaño del modelo en ~4x frente a float32. La pérdida de calidad es típicamente del 1-3% en benchmarks estándar. Es la opción conservadora. La mayoría de los modelos sobreviven INT8 sin degradación significativa para tareas de clasificación, embeddings y generación corta.
INT4 -- cuantización a 4 bits. Reduce el tamaño en ~8x. La pérdida de calidad es del 3-8% dependiendo del modelo y la tarea. Viable para clasificación y embeddings. Arriesgado para generación con matices.
GPTQ (Post-Training Quantization) -- Un método basado en calibración que encuentra parámetros de cuantización óptimos usando un pequeño dataset de calibración. Produce modelos INT4 de alta calidad. El estándar para cuantización offline de modelos de lenguaje grandes.
AWQ (Activation-Aware Weight Quantization) -- Protege el 1% de los pesos «salientes» que más importan para la calidad del modelo, cuantizando todo lo demás agresivamente. Frecuentemente supera a GPTQ con el mismo ancho de bits. Nuestra opción predeterminada para despliegue en el edge.
# Cuantizando un modelo con AWQ para despliegue en el edge
from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer
model_path = "mistralai/Mistral-7B-Instruct-v0.3"
quant_path = "mistral-7b-awq-int4"
model = AutoAWQForCausalLM.from_pretrained(model_path)
tokenizer = AutoTokenizer.from_pretrained(model_path)
quant_config = {
"zero_point": True,
"q_group_size": 128,
"w_bit": 4,
"version": "GEMM"
}
model.quantize(tokenizer, quant_config=quant_config)
model.save_quantized(quant_path)
tokenizer.save_pretrained(quant_path)
Orientación práctica
Para edge inference, nuestra regla de dimensionamiento:
- Menos de 500M parámetros, INT8: Se ejecuta cómodamente en la mayoría de los entornos edge. Modelos de embeddings (BGE, E5, GTE), clasificadores pequeños, detectores de idioma.
- 500M-3B parámetros, INT4/AWQ: Cabe en entornos restringidos con gestión de memoria cuidadosa. Phi-3 Mini, Gemma 2B, TinyLlama.
- 3B-7B parámetros, INT4/AWQ: Requiere edge regional o presupuestos de memoria generosos. Factible en Cloudflare Workers AI (que gestiona la ubicación de modelos), ajustado en otros entornos.
- Por encima de 7B: Centralizado. No lo fuerces.
Mide la calidad en tu distribución de tareas real, no en benchmarks académicos. Un modelo que puntúa un 2% menos en MMLU podría puntuar un 15% menos en tu corpus específico de detección de PII. Construye evaluaciones específicas por tarea y ejecútalas contra cada variante de cuantización.
IV. Cloudflare Workers AI: arquitectura y realidad
Workers AI de Cloudflare es la plataforma de inferencia de capa CDN más madura. Comprender su arquitectura revela tanto el potencial como las restricciones del AI en el edge.
Cómo funciona
Workers AI no ejecuta modelos en tu isolate de Worker. Tu Worker realiza una llamada API a modelos con espacio de nombres @cf/. Cloudflare enruta esa llamada al PoP más cercano que tenga el modelo cargado. El modelo se ejecuta en el hardware de inferencia de Cloudflare -- una combinación de GPUs y aceleradores de propósito específico distribuidos a través de su red.
// Cloudflare Workers AI -- clasificación de texto
export default {
async fetch(request: Request, env: Env): Promise<Response> {
const { text } = await request.json<{ text: string }>();
// Clasificación en el edge
const result = await env.AI.run(
"@cf/huggingface/distilbert-sst-2",
{ text }
);
return Response.json({
label: result[0].label,
confidence: result[0].score,
served_from: request.cf?.colo // qué PoP procesó esto
});
}
};
// Generación de embeddings -- misma ruta edge
export default {
async fetch(request: Request, env: Env): Promise<Response> {
const { texts } = await request.json<{ texts: string[] }>();
const embeddings = await env.AI.run(
"@cf/baai/bge-base-en-v1.5",
{ text: texts }
);
// Almacenar en Vectorize o devolver directamente
return Response.json({ embeddings: embeddings.data });
}
};
El catálogo de modelos
A principios de 2026, Workers AI ofrece ~30 modelos en distintas categorías: generación de texto (Llama, Mistral, Phi), clasificación de texto, embeddings (BGE, GTE), traducción, clasificación de imágenes, speech-to-text (Whisper) y generación de imágenes (variantes de Stable Diffusion). El catálogo crece trimestralmente.
Los modelos vienen pre-cuantizados. No se elige el método de cuantización. Cloudflare optimiza para su perfil de hardware. Esto es una concesión: se pierde control sobre los parámetros de cuantización, pero se gana distribución automática y optimización consciente del hardware.
Limitaciones con las que te encontrarás
Arranque en frío. La primera solicitud a un modelo en un PoP dado incurre en tiempo de carga del modelo -- 1-5 segundos dependiendo del tamaño del modelo. Las solicitudes subsiguientes son rápidas. Para uso en producción sensible a la latencia, se necesitan estrategias de mantenimiento en caliente: health checks sintéticos, tasas mínimas de solicitudes, o aceptación de penalizaciones ocasionales por arranque en frío.
Selección de modelos. Se ejecuta lo que Cloudflare ofrece. Sin modelos personalizados (aún). Sin variantes fine-tuned de modelos del catálogo. Si se necesita un modelo especializado, Workers AI no es la vía.
Ventanas de contexto. Más pequeñas que en despliegues centralizados. Los modelos Llama en Workers AI típicamente soportan 2048-4096 tokens, no los 32K-128K que se obtienen de una instancia dedicada de vLLM.
Límites de tasa y precios. Nivel gratuito generoso (10.000 neuronas/día), pero las cargas de producción necesitan el nivel de pago. El precio es por neurona (una unidad específica de Cloudflare aproximadamente proporcional al cómputo), lo que hace que la predicción de costos sea menos intuitiva que el precio por token.
Sin streaming para todos los modelos. La generación de texto soporta streaming; las llamadas de clasificación y embeddings son solo respuesta por lotes.
Configuración de Wrangler
# wrangler.toml
name = "edge-inference-service"
main = "src/index.ts"
compatibility_date = "2026-01-01"
[ai]
binding = "AI"
Simple. La complejidad reside en saber qué modelos usar y cuándo recurrir al fallback.
V. ONNX Runtime Web y WebGPU: el navegador como motor de inferencia
El edge CDN no es el único edge. El navegador también lo es.
ONNX Runtime Web ejecuta modelos ONNX en el navegador usando WebAssembly (CPU) o WebGPU (aceleración GPU). Esto es verdadera inferencia on-device -- sin llamada al servidor en absoluto. El modelo se descarga una vez, se cachea en el navegador y se ejecuta enteramente del lado del cliente.
// Inferencia del lado del navegador con ONNX Runtime Web
import * as ort from 'onnxruntime-web';
// Configurar backend WebGPU (fallback a WASM)
ort.env.wasm.numThreads = 4;
async function classifyText(text: string): Promise<string> {
const session = await ort.InferenceSession.create(
'/models/distilbert-classification.onnx',
{ executionProviders: ['webgpu', 'wasm'] }
);
// Tokenizar (usando un tokenizador ligero)
const encoded = tokenizer.encode(text);
const inputIds = new ort.Tensor('int64',
BigInt64Array.from(encoded.map(BigInt)),
[1, encoded.length]
);
const results = await session.run({ input_ids: inputIds });
const logits = results.logits.data as Float32Array;
return logits[0] > logits[1] ? 'positive' : 'negative';
}
Cuándo la inferencia en el navegador gana
- Flujos de trabajo con privacidad absoluta. Análisis de documentos legales donde el texto nunca debe abandonar el dispositivo. Pre-screening médico. Categorización de finanzas personales.
- Capacidad offline. PWAs que clasifican, generan embeddings o moderan sin conectividad.
- Eliminación de costos. Si se sirven 10M de solicitudes de clasificación/mes, trasladarlas al navegador ahorra la factura de inferencia completa. El dispositivo del usuario paga el costo de cómputo.
Cuándo no
- Tamaño del modelo. Una descarga de un modelo ONNX de 500MB en la primera visita es inviable para la mayoría de las aplicaciones web. Límite práctico: 50-150MB para una UX aceptable.
- Varianza de dispositivos. Un MacBook Pro 2024 con WebGPU ejecutará la inferencia 20x más rápido que un teléfono Android económico de 2020 con fallback a WASM. Se debe diseñar para el piso, no para el techo.
- Disponibilidad de WebGPU. Soportado en Chrome, Edge y Firefox (detrás de flags). El soporte en Safari es incompleto a principios de 2026. El fallback a WASM debe ser transparente.
Construye para mejora progresiva: intenta WebGPU, recurre a WASM, recurre a la API edge, recurre a centralizado. Cada nivel es una capacidad, no un requisito.
VI. Casos de uso prácticos: dónde edge inference justifica su existencia
No toda tarea de ML pertenece al edge. Aquí es donde desplegamos edge inference en producción, y por qué.
Clasificación
Detección de idioma, análisis de sentimiento, enrutamiento de intención. Estas son las tareas canónicas de edge inference. Los modelos son pequeños (50-200M parámetros), la latencia importa, y la salida es una etiqueta -- no texto generado. Un clasificador distilbert en el edge devuelve una etiqueta en 15-40ms. La misma llamada a una API centralizada toma 150-400ms incluyendo la red.
Generación de embeddings
Búsqueda mientras se escribe, similitud semántica, recomendación. Los modelos de embeddings (BGE-base, E5-small) tienen 100-400M parámetros y producen vectores de longitud fija. Genera embeddings en el edge, consulta tu base de datos vectorial desde la región más cercana. El paso de embedding es la parte sensible a la latencia; la búsqueda vectorial puede tolerar un salto regional.
El usuario escribe la consulta
|
v
Edge: generar embedding (BGE-base, ~30ms)
|
v
Regional: búsqueda vectorial (Pinecone/Qdrant, ~20ms)
|
v
Edge: formatear y devolver resultados (~5ms)
Total: ~55ms vs ~250ms centralizado
Detección de PII
Escaneo previo de datos antes de que abandonen el edge. Ejecuta un modelo NER pequeño en el edge para detectar nombres, correos electrónicos, números de teléfono, direcciones. Marca o redacta antes de que la solicitud llegue a tu servidor de aplicaciones. Esto no es solo una jugada de latencia -- es una jugada de gobernanza de datos. Los PII que nunca abandonan el PoP edge nunca entran en tus logs centralizados.
Moderación de contenido
Puntuación de toxicidad, detección de NSFW, clasificación de spam. Estas son funciones de filtro: se ejecutan antes de que el contenido entre en tu sistema. La ubicación en el edge significa que las decisiones de moderación ocurren a velocidad de admisión, no a velocidad de procesamiento de cola. Para plataformas de contenido generado por usuarios, esto reduce la ventana de exposición de segundos a milisegundos.
Dónde edge inference no pertenece
- Conversación multi-turno. Requiere estado, ventanas de contexto y tamaños de modelo que exceden los presupuestos del edge.
- Generación de texto largo. La generación token por token en el edge es más lenta que un único viaje de ida y vuelta a una GPU centralizada para cualquier cosa más allá de una oración.
- RAG con corpus grandes. La generación aumentada por recuperación necesita almacenes vectoriales, fragmentos de documentos y modelos de síntesis que no caben en las restricciones del edge.
- Modelos de dominio fine-tuned. Si tu modelo es entrenado a medida, Workers AI no puede servirlo. Necesitas tu propia infraestructura.
VII. El modelo de costos: edge vs. GPU centralizada
Las comparaciones de costos en inferencia son traicioneras. Las unidades difieren. Los modelos de precios difieren. Pero la economía direccional es clara.
GPU centralizada
Una instancia A100 dedicada (AWS p4d.24xlarge) cuesta ~$32/hora. A utilización completa con batching, sirve aproximadamente 500-2000 solicitudes/segundo para un modelo de 7B, dependiendo de la longitud de secuencia. Eso son $0.016-$0.064 por cada 1000 solicitudes a carga completa. Pero se paga por la instancia esté ocupada o inactiva. Una utilización por debajo del 60% duplica tu costo efectivo.
Edge inference (Cloudflare Workers AI)
El precio de Workers AI es por neurona, con el nivel gratuito cubriendo 10.000 neuronas/día. En el plan de pago, los costos escalan con el uso. Para tareas de clasificación y embeddings, el costo típico es $0.01-$0.05 por cada 1000 solicitudes. Sin costo por inactividad. Sin reserva de GPU.
El punto de equilibrio
Comparación de costos (clasificación, 1M solicitudes/día):
GPU centralizada (reservada):
Instancia: $32/hr * 24 = $768/día
A 1M sol/día: $0.77 por cada 1000 solicitudes
(asumiendo modelo único, batching modesto)
GPU centralizada (serverless, ej., Replicate):
~$0.10-$0.30 por cada 1000 solicitudes
Edge (Workers AI):
~$0.01-$0.05 por cada 1000 solicitudes
Edge (navegador/ONNX):
$0.00 (dispositivo del usuario)
Edge gana decisivamente para cargas de trabajo intermitentes y con alta clasificación. Centralizado gana para generación sostenida de alto rendimiento. El punto de cruce depende de tu patrón de tráfico, la complejidad del modelo y si puedes mantener las GPUs activas.
Para la mayoría de las aplicaciones, la respuesta es ambas: edge para la ruta rápida, centralizado para la ruta pesada. La arquitectura no es una u otra. Es una decisión de enrutamiento.
VIII. Patrones de arquitectura que sobreviven en producción
Patrón 1: Edge-first con fallback a la nube
El patrón por defecto. Enruta todas las solicitudes elegibles para inferencia al edge. Si el modelo edge no puede manejar la solicitud (demasiado compleja, contexto demasiado largo, modelo no disponible), recurre al centralizado.
Solicitud
|
v
+----------------+
| Edge Router |
| (estimador de |
| complejidad) |
+-------+--------+
|
+--------+--------+
| |
Simple/Rápido Complejo/Largo
| |
v v
+----------+ +---------------+
| Edge AI | | Centralizado |
| (Workers | | Clúster GPU |
| AI, 30ms| | (vLLM, 400ms)|
+----------+ +---------------+
| |
+--------+--------+
|
v
Respuesta// Enrutamiento edge-first en un Cloudflare Worker
async function handleInference(
request: Request,
env: Env
): Promise<Response> {
const { text, task } = await request.json<InferenceRequest>();
// Ruta rápida: clasificación y embeddings en el edge
if (task === 'classify' || task === 'embed') {
try {
const result = await env.AI.run(
EDGE_MODELS[task],
{ text }
);
return Response.json({ result, tier: 'edge' });
} catch (e) {
// Caer al centralizado
}
}
// Ruta lenta: generación y tareas complejas centralizadas
const response = await fetch(env.CENTRAL_INFERENCE_URL, {
method: 'POST',
headers: {
'Authorization': Bearer ${env.INFERENCE_API_KEY},
'Content-Type': 'application/json'
},
body: JSON.stringify({ text, task })
});
const result = await response.json();
return Response.json({ ...result, tier: 'centralized' });
}
Patrón 2: Inferencia dividida
Ejecuta la primera etapa de un pipeline en el edge, envía resultados intermedios al centralizado para la etapa costosa. Común para búsqueda: generar embedding en el edge, recuperar y re-rankear centralmente.
Edge PoP (Oslo) Región (eu-west-1)
+-----------------+ +-------------------+
| Embed consulta | vector | Búsqueda vectorial|
| (BGE, 30ms) |--------->| Re-rank (cross- |
| | | encoder, 80ms) |
+-----------------+ | Generar snippet |
| (LLM, 200ms) |
+-------------------+Patrón 3: Decodificación especulativa en el edge
Un patrón de frontera tomado prestado de la decodificación especulativa en LLMs. Un modelo pequeño en el edge genera un borrador de respuesta. Un modelo centralizado verifica y corrige. Si el borrador del edge es suficientemente bueno (y para consultas simples, frecuentemente lo es), el usuario ve latencia sub-100ms. Si no, la corrección del modelo centralizado llega dentro de la ventana de latencia normal.
Esto funciona para consultas predecibles: respuestas de FAQ, respuestas con plantilla, completados simples. No funciona para tareas creativas o de razonamiento intensivo donde los borradores del modelo pequeño son consistentemente erróneos.
Patrón 4: Preprocesamiento en el edge, razonamiento central
El patrón más conservador. El edge se encarga de la tokenización, detección de PII, validación de entrada y formateo. El clúster central maneja toda la inferencia. El edge añade 5-15ms de preprocesamiento pero elimina solicitudes basura, reduce el conteo de tokens y aplica gobernanza de datos antes de que la solicitud alcance una GPU.
IX. La realidad operacional: monitorizando edge inference a escala
Edge inference introduce desafíos de monitorización que los despliegues centralizados no tienen.
El problema de la observabilidad
Tu modelo se ejecuta en más de 300 ubicaciones. El comportamiento de arranque en frío difiere por PoP. El hardware varía. Las condiciones de red varían. Una degradación de calidad en Asia-Pacífico podría no aparecer en tus métricas agregadas.
Se necesita monitorización por PoP. No es opcional.
// Logging estructurado para observabilidad de edge inference
interface InferenceMetric {
timestamp: number;
colo: string; // Identificador de PoP de Cloudflare
model: string;
task: 'classify' | 'embed' | 'generate';
latency_ms: number;
tokens_in: number;
tokens_out: number;
cold_start: boolean;
fallback: boolean;
confidence: number; // puntuación de confianza del modelo
error?: string;
}
async function instrumentedInference(
env: Env,
request: Request,
task: string,
input: unknown
): Promise<{ result: unknown; metric: InferenceMetric }> {
const start = performance.now();
const colo = request.cf?.colo ?? 'unknown';
try {
const result = await env.AI.run(MODEL_MAP[task], input);
const metric: InferenceMetric = {
timestamp: Date.now(),
colo,
model: MODEL_MAP[task],
task: task as InferenceMetric['task'],
latency_ms: performance.now() - start,
tokens_in: estimateTokens(input),
tokens_out: estimateTokens(result),
cold_start: (performance.now() - start) > COLD_START_THRESHOLD,
fallback: false,
confidence: extractConfidence(result)
};
// Enviar a analytics (no bloqueante)
env.ANALYTICS.writeDataPoint(metric);
return { result, metric };
} catch (error) {
// ... rastreo de errores con contexto de PoP
}
}
Sobre qué alertar
- Latencia P99 por PoP que exceda 3x la línea base P50. Los arranques en frío causan picos; una elevación sostenida significa que algo está mal.
- Tasa de fallback por encima del umbral. Si más del 5% de las solicitudes edge recurren al centralizado, hay que investigar. Fallos en la carga del modelo, presión de memoria, o patrones de solicitud que exceden la capacidad del edge.
- Deriva de confianza. Si la confianza promedio del modelo para una tarea dada cae con el tiempo, la distribución de tus inputs ha cambiado. El modelo podría necesitar reentrenamiento o el umbral de enrutamiento edge/central necesita ajuste.
- Frecuencia de arranque en frío. Rastrea con qué frecuencia cada PoP sirve una solicitud de arranque en frío. Si un PoP está ciclando constantemente, tu tráfico es demasiado escaso allí para que edge inference valga la pena. Enruta ese PoP al centralizado y ahorra la penalización de arranque en frío.
El dashboard que realmente necesitas
Olvida las métricas de vanidad. Tu dashboard de edge inference tiene tres paneles:
- Mapa de calor de latencia por PoP. Mapa mundial con código de colores mostrando la latencia P50 de inferencia en cada ubicación. Rojo significa «investigar o redirigir».
- Cascada de fallback. Para cada solicitud que cayó del edge al centralizado: por qué, desde dónde y cuánta latencia añadió.
- Costo por inferencia útil. No costo por solicitud -- costo por solicitud que devolvió un resultado que la aplicación realmente utilizó. Una clasificación con confianza de 0.51 que se re-verifica centralmente no es una inferencia edge útil; es una desperdiciada.
X. Limitaciones: la lista honesta
Edge inference no es magia. Esto es lo que te morderá.
Techo de tamaño de modelo. El modelo más grande que se puede ejecutar prácticamente en el edge CDN es de 3-7B parámetros, cuantizado a INT4. Eso descarta los modelos en los que la mayoría de la gente piensa cuando dice «AI» -- clase GPT-4, clase Claude, Llama 70B. Edge AI es AI de modelos pequeños.
Sin fine-tuning en el edge. No se pueden desplegar modelos fine-tuned personalizados en Workers AI o plataformas similares (a principios de 2026). Si tu caso de uso requiere modelos específicos de dominio, necesitas tu propia infraestructura de serving, lo que significa edge regional en el mejor de los casos.
Presión de memoria. Los isolates edge tienen límites de memoria estrictos. Un modelo que cabe en memoria podría aún causar OOM si el batching de solicitudes es demasiado agresivo o si el runtime tiene fragmentación de memoria. Prueba bajo carga concurrente realista, no benchmarks de solicitud única.
El arranque en frío es real. La carga del modelo toma 1-5 segundos. Para despliegues de bajo tráfico, cada solicitud podría ser un arranque en frío. El mantenimiento en caliente añade costo y complejidad.
Varianza de calidad entre cuantizaciones. Un modelo cuantizado para el edge puede producir resultados sutilmente diferentes al mismo modelo en precisión completa. Para clasificación, esto normalmente no importa. Para generación o extracción, puede importar enormemente. Siempre evalúa al nivel de cuantización que despliegas.
Dependencia del proveedor. Los modelos de Workers AI son llamadas API específicas de Cloudflare. ONNX Runtime Web es portable pero requiere que gestiones la distribución del modelo. No existe una API universal de edge inference. Planifica tu capa de abstracción temprano.
XI. Por qué esto importa para la arquitectura edge-first
Construimos sobre Cloudflare Workers. Pensamos en términos edge-first. Esto no es lealtad tribal; es una apuesta sobre hacia dónde se dirige la curva de capacidad.
La trayectoria es clara: los modelos se hacen más pequeños y mejores. La cuantización se vuelve menos destructiva. El hardware edge se vuelve más capaz. WebGPU madura. El conjunto de tareas que se pueden ejecutar en la capa CDN se expande cada trimestre.
Hace tres años, «AI en el edge» significaba feature flags y lógica de tests A/B. Hace dos años, significaba clasificación básica de texto. Hoy, significa generación de embeddings, NER multilingüe, moderación de contenido y modelos generativos pequeños. El próximo año, significará más.
La arquitectura que gana es la que puede absorber esta expansión sin rediseño. Edge-first con fallback a la nube es esa arquitectura. Comienza conservadora -- clasificar y generar embeddings en el edge, generar centralmente -- y absorbe naturalmente nueva capacidad a medida que los modelos se reducen y el hardware edge crece.
La migración de capacidad a lo largo del tiempo:
2024: Clasificación, detección de idioma
2025: Embeddings, NER, moderación de contenido
2026: Generación pequeña, detección de PII, decodificación especulativa
2027: Clasificación multi-modal, traducción en tiempo real (proyectado)
2028: Inferencia colaborativa on-device + edge (proyectado)
──────────────────────────────────────────────>
Más tareas migran de centralizado a edge
Para los clientes de Gothar, esto se traduce en valor concreto: menor latencia para inteligencia orientada al usuario, menor exposición de datos a través de procesamiento local en el edge, y costos de infraestructura que escalan con el uso en lugar de con reservas. Los clientes que adopten patrones de edge inference ahora tendrán una ventaja estructural a medida que la frontera de capacidad se mueva hacia afuera.
Referencias
- Cloudflare Workers AI Documentation. https://developers.cloudflare.com/workers-ai/
- ONNX Runtime Web. https://onnxruntime.ai/docs/tutorials/web/
- WebGPU W3C Specification. https://www.w3.org/TR/webgpu/
- Deng, T. et al. "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration." MLSys 2024. https://arxiv.org/abs/2306.00978
- Frantar, E. et al. "GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers." ICLR 2023. https://arxiv.org/abs/2210.17323
- Cloudflare AI Gateway and Model Routing. https://developers.cloudflare.com/ai-gateway/
- Vercel AI SDK Documentation. https://sdk.vercel.ai/docs
- Deno Deploy and Edge Functions. https://deno.com/deploy
- Leviathan, Y. et al. "Fast Inference from Transformers via Speculative Decoding." ICML 2023. https://arxiv.org/abs/2211.17192
- vLLM: Easy, Fast, and Cheap LLM Serving. https://github.com/vllm-project/vllm
- Cloudflare Network Map and PoP Locations. https://www.cloudflare.com/network/
- ONNX Model Zoo. https://github.com/onnx/models
Hay algo apropiado en la inteligencia en el edge. Durante siglos, las decisiones estuvieron centralizadas -- en cortes, en capitales, en mainframes. El arco de los sistemas distribuidos se inclina hacia la subsidiariedad: manejar las cosas en el nivel más bajo que pueda manejarlas competentemente. Un nodo CDN que puede clasificar un comentario no necesita pedir permiso a Virginia. Un navegador que puede generar el embedding de una consulta no necesita cruzar un océano. Esto no es solo eficiencia de ingeniería. Es un argumento silencioso sobre dónde debería vivir la inteligencia: no en una catedral, sino en la parroquia. Cerca del suelo. Cerca de la necesidad. Cerca del humano que hizo la pregunta y merece una respuesta antes de terminar de parpadear.
