Optimización del rendimiento de Agno: de 2 segundos a 200ms

Agno ya es rápido. El equipo afirma 70x más rápido que LangChain, y en nuestros benchmarks, no es marketing—es real.

Pero "rápido" es relativo.

Cuando desplegamos por primera vez nuestro sistema de resolución de disputas, las respuestas del agente promediaban 2,1 segundos. Para un chatbot, está bien. Para mediación en tiempo real donde los usuarios esperan respuestas casi instantáneas, no lo está.

Necesitábamos sub-200ms.

Llegar ahí requirió patrones específicos—algunos obvios, algunos contraintuitivos. Este post desglosa exactamente qué hicimos, con ejemplos de código que puedes aplicar a tus propios despliegues de Agno.

Por qué importan los 200ms

Primero, hablemos de por qué nos preocupaba específicamente 200ms.

Para nuestro sistema de resolución de disputas, los usuarios están en situaciones emocionales. Están frustrados. Quieren respuestas. Cada segundo de latencia amplifica esa frustración.

Pero no es solo UX. A escala, la latencia se acumula:

Son 71 horas de tiempo de usuario ahorradas. Por año. Para un solo sistema.

El punto de partida: 2,1 segundos

Empecemos con lo que teníamos. Aquí es donde se iba el tiempo:

GPT-4 era la mayor parte, pero no podíamos simplemente "hacer GPT-4 más rápido". Necesitábamos optimizar todo lo que controlábamos.

Patrón #1: Ejecución paralela de herramientas

La primera mejora fue obvia una vez que la miramos. Nuestro agente llamaba cuatro herramientas secuencialmente:

Pero estas herramientas no dependen entre sí. Pueden correr en paralelo.

agent = DisputeAnalysisAgent(
    tool_execution_mode="parallel"  # Enable parallel tools
)
# Total: 180ms (longest tool)

Patrón #2: Enrutamiento de modelos

Aquí va el contraintuitivo: no toda tarea necesita GPT-4.

Nuestro análisis de disputas tenía múltiples subtareas:

• • Clasificación de casos (simple)
• • Extracción de entidades (media)
• • Razonamiento legal (complejo)
• • Cálculo de confianza (simple)

GPT-4 es excesivo para clasificación. Un modelo pequeño fine-tuned es más rápido Y más barato.

model = ModelRouter({
    "classification": "gpt-3.5-turbo",     # Fast, cheap
    "extraction": "claude-3-haiku",         # Good at structure
    "reasoning": "gpt-4",                   # Complex tasks only
    "scoring": "gpt-3.5-turbo",            # Fast, cheap
})

Patrón #3: Optimización de contexto

Estábamos pasando demasiado contexto. Para un caso complejo, podía ser 15,000+ tokens de contexto.

Problema: Más tokens = más latencia. El time-to-first-token de GPT-4 escala con el tamaño del input.

def build_optimized_context(case: Case, task: str) -> str:
    # Always include core identifiers
    base = f"Case: {case.id} | Type: {case.dispute_type}"

    if task == "classification":
        return base + f"\nDescription: {case.description[:500]}"

    elif task == "reasoning":
        # Only for complex reasoning do we include more
        relevant_docs = retrieve_relevant_chunks(case, top_k=3)
        return base + f"\nRelevant Sections: {relevant_docs}"

    return base

# Before: 10,000+ tokens
# After: 200-800 tokens depending on task

Patrón #4: Streaming de respuesta con salida temprana

Para muchas tareas, no necesitamos la respuesta completa. Podemos empezar a procesar en cuanto tenemos suficiente.

async def get_classification(case: Case) -> str:
    async for chunk in agent.stream(prompt):
        # Check if we have enough to classify
        if classification := try_parse_classification(chunk):
            return classification  # Exit early

    # Fallback: parse complete response
    return parse_classification(chunk)

Para tareas de clasificación, típicamente salimos después de que se genera el 30-40% de la respuesta.

Patrón #5: Caché inteligente

Muchos inputs se repiten o son similares. El caché evita cómputo redundante.

Patrón #6: Connection pooling y keep-alive

Este es aburrido pero impactante. Una conexión nueva = 100-200ms de overhead.

http_client = httpx.Client(
    http2=True,
    limits=httpx.Limits(
        max_connections=100,
        max_keepalive_connections=20,
        keepalive_expiry=30
    )
)

agno.configure(
    http_client=http_client,
    connection_pool_size=100
)

Patrón #7: Async de punta a punta

Si estás haciendo algo síncrono en tu pipeline de agentes, estás dejando rendimiento sobre la mesa.

async def process_case(case: Case) -> Result:
    # Independent steps run in parallel
    classification, entities = await asyncio.gather(
        classify(case),
        extract_entities(case)
    )

    # Dependent step runs after
    analysis = await analyze(case, classification, entities)

    return Result(classification, entities, analysis)

El resultado combinado

Espera—eso son 455ms, no 200ms. Correcto. Para el caso promedio.

La prioridad de optimización

Si estás optimizando el rendimiento de Agno, este es el orden de prioridad:

No necesitas todas estas. Implementa 1-3 y verás una mejora dramática.

Cuándo NO optimizar

Una palabra de precaución: la optimización prematura sigue siendo una cosa.

No optimices si:

• • Tu latencia ya es aceptable para tu caso de uso
• • Aún estás iterando en el comportamiento del agente
• • Aún no tienes tráfico en producción
• • El costo de complejidad supera el beneficio de latencia

Primero haz que funcione. Luego haz que sea correcto. Después hazlo rápido.

Reflexión final

Agno es rápido. Pero "rápido" es un punto de partida, no un destino.

Los patrones aquí—enrutamiento de modelos, ejecución en paralelo, caché, optimización de contexto—no son específicos de Agno. Son principios generales para construir sistemas de IA performantes.

De 2 segundos a 200ms no es magia. Es metodología.