Con 500.000 llamadas reales, reduje la espera diaria de red de 3 horas a 3 minutos

2026-09-08

Fuente de los datos: del 2026-07-16 al 2026-09-08, 513.336 llamadas en producción

I. La conclusión, de entrada

Si no tienes tiempo para leerlo entero, esta es la idea principal:

Basándome en los datos de 500.000 llamadas reales a la API, reduje el tiempo diario de espera por transmisión de red de aproximadamente 3 horas a 3 minutos.

¿Cómo lo hice? — Separando la inferencia de la ejecución de herramientas, de modo que el tráfico pesado circulase por la red interna y el tráfico ligero atravesase la red internacional.

A continuación se detallan el proceso y los datos reales.

II. Contexto: por qué la arquitectura antigua era lenta

Al principio, mi equipo principal estaba desplegado en China continental y ejecutaba CodeX. CodeX es un framework completo para el desarrollo de aplicaciones de IA: se encarga de llamar a la API de OpenAI, gestionar el contexto de las conversaciones, ejecutar llamadas a herramientas… Todo se hacía en una sola máquina.

La topología de red era la siguiente:

flowchart LR
    A[Equipo principal CN<br>CodeX] -->|Solicitud pública<br>VPN + Cloudflare| B[API de OpenAI]
    B -->|Respuesta de inferencia<br>~794 KB / llamada| A

Cada solicitud de inferencia tenía que salir de China, atravesar la VPN y Cloudflare, cruzar el Pacífico hasta llegar a OpenAI y devolver después el resultado. Las características de esta conexión eran muy desfavorables:

• Ancho de banda: 10 Mbps (rendimiento efectivo real de aproximadamente 0,75 MB/s)
• Latencia: RTT de unos 300 ms, con fluctuaciones frecuentes
• Estabilidad: pérdidas de paquetes y retransmisiones ocasionales

Con esta arquitectura, 10.000 llamadas diarias implicaban que solo esperar a la transmisión de los datos por la red costaba aproximadamente 3 horas.

Durante esas 3 horas, CodeX no hacía nada: solo esperaba a la red.

III. Los datos hablan por sí solos

Para entender en qué se empleaban exactamente esas «3 horas», descargué todos los registros de acceso de la arquitectura antigua entre el 16 de julio y el 8 de septiembre de 2026: un total de 513.336 llamadas válidas. El tamaño de la muestra era suficiente para dejar claro el problema.

Analicé la composición del tráfico de cada llamada:

Los dos grupos difieren en un factor de 58 veces. El tráfico de inferencia representa el 98,3 % del tráfico total, mientras que las señales de control de las herramientas solo suponen el 1,7 %.

Después calculé el tiempo invertido:

Tráfico de inferencia atravesando la red internacional:

7.94 GB = 7.940 MB ÷ 0,75 MB/s ≈ 10.587 segundos ≈ 2,94 horas

Tráfico de control de las herramientas atravesando la red internacional (si se transmitiera por separado):

0.14 GB = 140 MB ÷ 0,75 MB/s ≈ 187 segundos ≈ 3 minutos

El problema estaba localizado: cada día se empleaban casi 3 horas en transmitir el tráfico de inferencia, aunque esos datos no deberían circular por una conexión internacional.

IV. Solución: de un «todo en uno» a una arquitectura separada

Si el problema era que «todo se ejecutaba en el equipo principal de CN y todo el tráfico tenía que cruzar la red internacional», la solución consistía en separar las responsabilidades.

Nueva arquitectura: la inferencia permanece en AWS y las herramientas, en CN

Separé la capacidad de inferencia de CodeX y la desplegué en AWS US:

flowchart LR
    subgraph CN["🇨🇳 Equipo principal CN"]
        T[Entorno de ejecución de herramientas]
        C[Cliente HTTP/2]
    end

    subgraph AWS["☁️ AWS US"]
        R[Dispositivo de inferencia<br>Rust + SQLite]
        O[API de OpenAI]
    end

    C -->|Parámetros de herramientas<br>591.59 Bytes| R
    C -->|Resultados de herramientas<br>13.387,34 Bytes| R
    R <-->|Tráfico de inferencia<br>7.94 GB/día dentro de la red interna| O

Los cambios fundamentales de esta nueva arquitectura son los siguientes:

1. El dispositivo de inferencia —un servidor ligero en Rust + SQLite— está desplegado en AWS US, en la misma región que OpenAI.
2. El dispositivo de inferencia y OpenAI se comunican a través de la red troncal interna de AWS: latencia inferior a 10 ms y ancho de banda de nivel Gbps.
3. El equipo principal de CN ya no llama directamente a OpenAI y solo se encarga de dos tareas:
   • Recibir los parámetros de llamada a herramientas enviados por el dispositivo de inferencia (591.59 Bytes).
   • Tras ejecutar las herramientas, devolver los resultados (13.387,34 Bytes) al dispositivo de inferencia.
4. SQLite mantiene el contexto de la conversación en el dispositivo de inferencia, mientras que el equipo principal de CN no conserva estado.

Comparación del tráfico internacional entre la arquitectura antigua y la nueva:

V. Resultados finales