Métricas de evaluación de LLM: cómo comparar modelos en tus propias tareas

La forma más fiable de comparar el rendimiento de los LLM es probar los modelos con el trabajo que realmente realiza su aplicación. Las pruebas de rendimiento públicas pueden ayudarle a crear una lista preliminar, pero no pueden indicarle qué modelo seguirá sus instrucciones, gestionará sus casos límite, cumplirá su objetivo de latencia o proporcionará el menor coste por tarea completada correctamente.

Una evaluación útil combina métricas específicas de la aplicación, casos de prueba representativos, pruebas repetidas, comprobaciones automatizadas, revisión humana calibrada y mediciones de coste y latencia relevantes para producción. El objetivo no es identificar un único modelo universalmente «mejor». Consiste en encontrar el modelo y la configuración de despliegue que cumplan sus requisitos con una coherencia y un coste operativo aceptables.

Elija métricas de evaluación que se adapten a su aplicación

Empiece por definir qué significa el éxito para su producto. Un asistente de atención al cliente, un pipeline de extracción, un agente de generación de código y una herramienta de resumen no deben evaluarse con las mismas métricas.

Una buena métrica cambia una decisión real. Si mejorar la métrica no hace que la aplicación sea más útil, más segura, más rápida o menos costosa, probablemente no debería ser una métrica de lanzamiento.

Para tareas deterministas, calcule la tasa de ejecuciones aceptadas como:

Tasa de ejecuciones aceptadas = Número de ejecuciones aceptadas ÷ Número total de ejecuciones intentadas

No excluya respuestas mal formadas, tiempos de espera agotados o fallos de herramientas simplemente porque sean incómodos de calificar. Si los usuarios percibirían el evento como una tarea fallida, normalmente pertenece al denominador.

Las tareas abiertas necesitan una rúbrica de puntuación. En lugar de preguntar si una respuesta es «buena», defina dimensiones independientes como:

• Corrección

• Completitud

• Relevancia

• Cumplimiento de instrucciones

• Fundamentación

• Tono o estilo

• Seguridad

Asigne a cada dimensión condiciones claras de aprobación o pautas de puntuación. «Puntuar la veracidad de 1 a 5» es demasiado vago. Una mejor rúbrica explica qué evidencia separa un 3 de un 4 e identifica cualquier error que cause un suspenso automático.

En los flujos de trabajo con agentes, inspeccione tanto la traza de ejecución como el resultado final. Un agente puede afirmar que ha emitido un reembolso, actualizado un archivo o completado una reserva incluso cuando el estado subyacente no haya cambiado. Por lo tanto, las comprobaciones de resultados deben inspeccionar la base de datos, el sistema de archivos, el estado de la aplicación u otro entorno relevante siempre que sea posible.

Las pruebas repetidas revelan otra distinción importante:

• pass@k mide si al menos uno de kk intentos tiene éxito.

• pass^k mide si cada uno de los kk intentos tiene éxito.

Utilice pass@k cuando varios intentos sean aceptables y un resultado exitoso sea suficiente. Utilice pass^k o una tasa de éxito por intento cuando los usuarios esperen que el flujo de trabajo funcione de forma fiable siempre.

Cree un conjunto de pruebas a partir de tareas reales y fallos conocidos

Un conjunto de datos de evaluación de LLM eficaz debe parecerse al tráfico de producción sin convertirse en una muestra aleatoria de todo lo que los usuarios han enviado alguna vez.

Comience con cuatro fuentes:

1. Tareas comunes de producción con un volumen de uso significativo

2. Flujos de trabajo de alto impacto vinculados a ingresos, confianza o seguridad

3. Casos límite que involucren formatos inusuales, contexto faltante o instrucciones contradictorias

4. Fallos conocidos procedentes de incidencias de soporte, registros, informes de errores y pruebas manuales

Cada caso de prueba debe contener suficiente información para reproducir y calificar la tarea:

{
  "id": "support_refund_014",
  "category": "refund_policy",
  "input": "Can I return an opened item after 35 days?",
  "context": "Refunds are allowed within 30 days with a receipt.",
  "expected_behavior": "Explain that the request falls outside the stated window.",
  "acceptance_criteria": [
    "Does not claim that the return is automatically eligible",
    "States the 30-day limit",
    "Does not invent an exception"
  ],
  "severity": "high",
  "source": "known_failure"
}

{
  "id": "support_refund_014",
  "category": "refund_policy",
  "input": "Can I return an opened item after 35 days?",
  "context": "Refunds are allowed within 30 days with a receipt.",
  "expected_behavior": "Explain that the request falls outside the stated window.",
  "acceptance_criteria": [
    "Does not claim that the return is automatically eligible",
    "States the 30-day limit",
    "Does not invent an exception"
  ],
  "severity": "high",
  "source": "known_failure"
}

{
  "id": "support_refund_014",
  "category": "refund_policy",
  "input": "Can I return an opened item after 35 days?",
  "context": "Refunds are allowed within 30 days with a receipt.",
  "expected_behavior": "Explain that the request falls outside the stated window.",
  "acceptance_criteria": [
    "Does not claim that the return is automatically eligible",
    "States the 30-day limit",
    "Does not invent an exception"
  ],
  "severity": "high",
  "source": "known_failure"
}

No todas las tareas necesitan una única respuesta de referencia. Las respuestas de referencia funcionan bien para la clasificación, la extracción y las preguntas con un solo resultado verificable. Para tareas abiertas, el comportamiento esperado y unos criterios de aceptación explícitos suelen ser más fiables que exigir una frase concreta.

Su conjunto de datos también debe incluir casos emparejados que prueben ambos lados de un comportamiento. Si un agente debe escalar una actividad sospechosa, incluya casos en los que la derivación sea obligatoria y casos en los que sea innecesaria. De lo contrario, el modelo puede parecer exitoso simplemente escalándolo todo.

Mantenga separados los conjuntos de desarrollo y de validación final (holdout). Utilice el conjunto de desarrollo al modificar prompts, herramientas o lógica de enrutamiento. Reserve el conjunto de validación para las comparaciones finales, de modo que el ajuste repetido no convierta la evaluación en un ejercicio de memorización.

Lleve el control de versiones del conjunto de datos y registre de dónde procede cada caso. Cuando aparezca un fallo en producción, añada una reproducción minimizada a la suite de regresión. Esto transforma los fallos reales en comprobaciones permanentes en lugar de parches puntuales.

Combine comprobaciones automatizadas, revisión humana y jueces LLM

Ningún método de calificación sirve para todos los output. Utilice el método fiable más económico para cada criterio y, a continuación, añada una revisión más subjetiva solo donde sea necesario.

Ejecute primero las comprobaciones deterministas. No hay razón para pagar a un juez LLM para que revise un output que es un JSON no válido o que no superó una prueba unitaria obligatoria.

Utilice jueces LLM para criterios estrechamente definidos en lugar de pedir una única impresión general. Proporcione al juez la tarea, el contexto relevante, el output candidato, la rúbrica y las etiquetas permitidas. Permita un resultado desconocido o de evidencia insuficiente cuando el juez no pueda decidir con confianza.

Las comparaciones por pares pueden ser más sencillas que la puntuación absoluta, pero el orden de las respuestas debe controlarse. Los jueces LLM pueden preferir una respuesta debido a su ubicación más que a su calidad, una forma documentada de sesgo de posición. Ejecute las comparaciones por pares importantes en ambos órdenes e investigue los resultados que se inviertan al cambiar las posiciones.

Los revisores humanos deben calibrar el sistema automatizado. Haga que revisores cualificados califiquen de forma independiente una muestra, resuelvan discrepancias y comparen sus decisiones con las del juez LLM. Continúe tomando muestras después del lanzamiento, especialmente para nuevas categorías de fallos y tareas de alto impacto.

Defina criterios de evaluación específicos para la tarea antes de ejecutar la comparación. Cambiar la rúbrica tras ver qué modelo gana introduce sesgos y hace que el resultado informado sea difícil de reproducir.

Realice una comparación justa entre modelos

Una comparación justa cambia el modelo mientras mantiene controlado el resto de la evaluación.

Mantenga estos elementos constantes a menos que el experimento los esté probando específicamente:

• Prompts de sistema y de usuario

• Contexto proporcionado

• Definiciones de herramientas

• Resultados de recuperación

• Límite máximo de output

• Política de tiempo de espera

• Política de reintentos

• Orden de los casos de prueba

• Lógica de calificación

• Número de intentos

• Condiciones de concurrencia

Utilice el identificador exacto de modelo para cada despliegue. Los nombres de modelo, los parámetros admitidos y las versiones disponibles pueden variar entre un desarrollador upstream, SiliconFlow, otro proveedor de API y un despliegue autohospedado. Rellene su configuración de evaluación con los identificadores devueltos por el endpoint de lista de modelos de SiliconFlow.

No obligue a cada modelo a utilizar un parámetro no compatible simplemente para que los cuerpos de las peticiones sean idénticos. Mantenga constantes los ajustes admitidos y documente cualquier diferencia obligatoria específica del modelo. La comparación debe reflejar una configuración válida para cada candidato.

Ejecute varios intentos porque los output de los LLM son no deterministas. Intercale los modelos en lugar de ejecutar todos los intentos de un modelo antes de pasar al siguiente. Esto reduce la posibilidad de que una carga temporal, las condiciones de la red u otro factor dependiente del tiempo favorezcan a un candidato.

Oculte la identidad del modelo a los revisores humanos y a los jueces LLM. Para la evaluación por pares, aleatorice el orden mostrado y repita las comparaciones importantes con el orden invertido.

Los reintentos también necesitan un tratamiento explícito. Los reintentos automáticos a nivel de SDK pueden ocultar múltiples peticiones físicas tras un único resultado registrado. Desactívelos durante las pruebas controladas o registre cada intento por separado. De lo contrario, la latencia, la tasa de errores y el coste pueden verse subestimados.

El siguiente ejemplo en Python ejecuta pruebas repetidas a través de la API compatible con OpenAI de SiliconFlow. Registra el output, la latencia de extremo a extremo, el uso de tokens, los fallos de la API y un resultado de aceptación automatizado simple.

Las comprobaciones de cadenas son intencionadamente básicas. Sustitúyalas por calificadores que se ajusten a su aplicación.

import json
import os
import time
from pathlib import Path

from openai import APIConnectionError, APIStatusError, OpenAI

api_key = os.environ["SILICONFLOW_API_KEY"]
models = [
    model.strip()
    for model in os.environ["EVAL_MODELS"].split(",")
    if model.strip()
]
trials = int(os.getenv("EVAL_TRIALS", "3"))

client = OpenAI(
    api_key=api_key,
    base_url="https://api.siliconflow.com/v1",
    timeout=60.0,
    max_retries=0,
)

tasks = [
    {
        "id": "refund_policy",
        "system": "Answer using only the supplied policy.",
        "prompt": (
            "Policy: Refunds are allowed within 30 days with a receipt. "
            "Question: What does a customer need to request a refund?"
        ),
        "required_terms": ["30 days", "receipt"],
    },
    {
        "id": "support_escalation",
        "system": "Answer using only the supplied policy.",
        "prompt": (
            "Policy: Escalate suspected account takeover to the security team. "
            "Question: Where should this case be sent?"
        ),
        "required_terms": ["security team"],
    },
]


def accepted(output, required_terms):
    normalized = output.casefold()
    return all(
        term.casefold() in normalized
        for term in required_terms
    )


def run_trial(model, task, trial):
    started = time.perf_counter()

    try:
        response = client.chat.completions.create(
            model=model,
            messages=[
                {"role": "system", "content": task["system"]},
                {"role": "user", "content": task["prompt"]},
            ],
        )

        latency_seconds = time.perf_counter() - started
        output = response.choices[0].message.content or ""
        usage = response.usage

        return {
            "model": model,
            "task_id": task["id"],
            "trial": trial,
            "accepted": accepted(
                output,
                task["required_terms"],
            ),
            "latency_seconds": round(latency_seconds, 3),
            "input_tokens": getattr(
                usage,
                "prompt_tokens",
                None,
            ),
            "output_tokens": getattr(
                usage,
                "completion_tokens",
                None,
            ),
            "output": output,
            "error": None,
        }

    except APIStatusError as exc:
        return {
            "model": model,
            "task_id": task["id"],
            "trial": trial,
            "accepted": False,
            "latency_seconds": round(
                time.perf_counter() - started,
                3,
            ),
            "status_code": exc.status_code,
            "error": type(exc).__name__,
        }

    except APIConnectionError as exc:
        return {
            "model": model,
            "task_id": task["id"],
            "trial": trial,
            "accepted": False,
            "latency_seconds": round(
                time.perf_counter() - started,
                3,
            ),
            "error": type(exc).__name__,
        }


results = [
    run_trial(model, task, trial)
    for model in models
    for task in tasks
    for trial in range(1, trials + 1)
]

Path("eval_results.json").write_text(
    json.dumps(
        results,
        indent=2,
        ensure_ascii=False,
    ),
    encoding="utf-8",
)

import json
import os
import time
from pathlib import Path

from openai import APIConnectionError, APIStatusError, OpenAI

api_key = os.environ["SILICONFLOW_API_KEY"]
models = [
    model.strip()
    for model in os.environ["EVAL_MODELS"].split(",")
    if model.strip()
]
trials = int(os.getenv("EVAL_TRIALS", "3"))

client = OpenAI(
    api_key=api_key,
    base_url="https://api.siliconflow.com/v1",
    timeout=60.0,
    max_retries=0,
)

tasks = [
    {
        "id": "refund_policy",
        "system": "Answer using only the supplied policy.",
        "prompt": (
            "Policy: Refunds are allowed within 30 days with a receipt. "
            "Question: What does a customer need to request a refund?"
        ),
        "required_terms": ["30 days", "receipt"],
    },
    {
        "id": "support_escalation",
        "system": "Answer using only the supplied policy.",
        "prompt": (
            "Policy: Escalate suspected account takeover to the security team. "
            "Question: Where should this case be sent?"
        ),
        "required_terms": ["security team"],
    },
]


def accepted(output, required_terms):
    normalized = output.casefold()
    return all(
        term.casefold() in normalized
        for term in required_terms
    )


def run_trial(model, task, trial):
    started = time.perf_counter()

    try:
        response = client.chat.completions.create(
            model=model,
            messages=[
                {"role": "system", "content": task["system"]},
                {"role": "user", "content": task["prompt"]},
            ],
        )

        latency_seconds = time.perf_counter() - started
        output = response.choices[0].message.content or ""
        usage = response.usage

        return {
            "model": model,
            "task_id": task["id"],
            "trial": trial,
            "accepted": accepted(
                output,
                task["required_terms"],
            ),
            "latency_seconds": round(latency_seconds, 3),
            "input_tokens": getattr(
                usage,
                "prompt_tokens",
                None,
            ),
            "output_tokens": getattr(
                usage,
                "completion_tokens",
                None,
            ),
            "output": output,
            "error": None,
        }

    except APIStatusError as exc:
        return {
            "model": model,
            "task_id": task["id"],
            "trial": trial,
            "accepted": False,
            "latency_seconds": round(
                time.perf_counter() - started,
                3,
            ),
            "status_code": exc.status_code,
            "error": type(exc).__name__,
        }

    except APIConnectionError as exc:
        return {
            "model": model,
            "task_id": task["id"],
            "trial": trial,
            "accepted": False,
            "latency_seconds": round(
                time.perf_counter() - started,
                3,
            ),
            "error": type(exc).__name__,
        }


results = [
    run_trial(model, task, trial)
    for model in models
    for task in tasks
    for trial in range(1, trials + 1)
]

Path("eval_results.json").write_text(
    json.dumps(
        results,
        indent=2,
        ensure_ascii=False,
    ),
    encoding="utf-8",
)

import json
import os
import time
from pathlib import Path

from openai import APIConnectionError, APIStatusError, OpenAI

api_key = os.environ["SILICONFLOW_API_KEY"]
models = [
    model.strip()
    for model in os.environ["EVAL_MODELS"].split(",")
    if model.strip()
]
trials = int(os.getenv("EVAL_TRIALS", "3"))

client = OpenAI(
    api_key=api_key,
    base_url="https://api.siliconflow.com/v1",
    timeout=60.0,
    max_retries=0,
)

tasks = [
    {
        "id": "refund_policy",
        "system": "Answer using only the supplied policy.",
        "prompt": (
            "Policy: Refunds are allowed within 30 days with a receipt. "
            "Question: What does a customer need to request a refund?"
        ),
        "required_terms": ["30 days", "receipt"],
    },
    {
        "id": "support_escalation",
        "system": "Answer using only the supplied policy.",
        "prompt": (
            "Policy: Escalate suspected account takeover to the security team. "
            "Question: Where should this case be sent?"
        ),
        "required_terms": ["security team"],
    },
]


def accepted(output, required_terms):
    normalized = output.casefold()
    return all(
        term.casefold() in normalized
        for term in required_terms
    )


def run_trial(model, task, trial):
    started = time.perf_counter()

    try:
        response = client.chat.completions.create(
            model=model,
            messages=[
                {"role": "system", "content": task["system"]},
                {"role": "user", "content": task["prompt"]},
            ],
        )

        latency_seconds = time.perf_counter() - started
        output = response.choices[0].message.content or ""
        usage = response.usage

        return {
            "model": model,
            "task_id": task["id"],
            "trial": trial,
            "accepted": accepted(
                output,
                task["required_terms"],
            ),
            "latency_seconds": round(latency_seconds, 3),
            "input_tokens": getattr(
                usage,
                "prompt_tokens",
                None,
            ),
            "output_tokens": getattr(
                usage,
                "completion_tokens",
                None,
            ),
            "output": output,
            "error": None,
        }

    except APIStatusError as exc:
        return {
            "model": model,
            "task_id": task["id"],
            "trial": trial,
            "accepted": False,
            "latency_seconds": round(
                time.perf_counter() - started,
                3,
            ),
            "status_code": exc.status_code,
            "error": type(exc).__name__,
        }

    except APIConnectionError as exc:
        return {
            "model": model,
            "task_id": task["id"],
            "trial": trial,
            "accepted": False,
            "latency_seconds": round(
                time.perf_counter() - started,
                3,
            ),
            "error": type(exc).__name__,
        }


results = [
    run_trial(model, task, trial)
    for model in models
    for task in tasks
    for trial in range(1, trials + 1)
]

Path("eval_results.json").write_text(
    json.dumps(
        results,
        indent=2,
        ensure_ascii=False,
    ),
    encoding="utf-8",
)

Los campos documentados de uso de Chat Completions proporcionan recuentos de tokens de prompt, de completado y totales. Almacene los registros de resultados brutos antes de agregarlos para que pueda inspeccionar los fallos individuales y recalcular las métricas más adelante.

Mida la latencia y el coste por tarea completada correctamente

Un modelo que produce respuestas sólidas pero que con frecuencia agota el tiempo de espera, necesita varios reintentos o consume muchos más tokens puede no ser la mejor opción para producción.

Mida la latencia desde la perspectiva del usuario:

• Tiempo hasta el primer token: útil para interfaces de transmisión en streaming

• Tiempo hasta el último token: tiempo total de generación

• Latencia de extremo a extremo: incluye la recuperación, las herramientas, la validación y otro trabajo de la aplicación

• Latencia de tarea aceptada: tiempo necesario para generar un resultado que cumpla los criterios de aceptación

Informe de las distribuciones de latencia en lugar de solo los promedios. La latencia mediana describe una petición típica, mientras que p95 o p99 revelan el comportamiento en la cola lenta. Los percentiles requieren suficientes pruebas para ser significativos, así que incluya recuentos brutos cuando el conjunto de pruebas sea pequeño.

Para las evaluaciones de agentes, registre tanto el tiempo total de la tarea como el tiempo empleado en cada llamada a modelo o herramienta. Esto ayuda a distinguir el razonamiento lento de la recuperación lenta, las API externas, las acciones del navegador o los intentos repetidos de recuperación.

Para modelos con precio por millón de tokens, calcule el coste de la petición como:

Coste de la petición = (Tokens de Input ÷ 1.000.000 × Precio de Input por millón de tokens) + (Tokens de Output ÷ 1.000.000 × Precio de Output por millón de tokens)

Si el input almacenado en caché tiene una tarifa independiente, añádalo como otro término utilizando el mismo cálculo. Utilice los precios del despliegue exacto de SiliconFlow que se esté probando en lugar de las tarifas publicadas por el desarrollador del modelo upstream u otro proveedor.

Para pruebas repetidas, utilice:

Coste por ejecución de tarea aceptada = Coste total de todas las ejecuciones intentadas ÷ Número de ejecuciones aceptadas

El «coste total» debe incluir los intentos fallidos, los reintentos, los output no válidos, las llamadas al evaluador, la recuperación y el uso de herramientas de pago cuando esos gastos formen parte del flujo de trabajo de producción. El denominador debe contener únicamente las ejecuciones que cumplan los criterios de aceptación predefinidos.

Si no se acepta ninguna ejecución, el coste por tarea aceptada queda indefinido en lugar de ser cero. Indique el gasto total y cero ejecuciones aceptadas en lugar de generar una cifra de coste engañosa.

Esta métrica a menudo cambia la clasificación. Un modelo más económico puede costar más por tarea aceptada si necesita reintentos frecuentes o falla en flujos de trabajo costosos. Un modelo de precio más alto puede ser más económico cuando completa la tarea de forma fiable al primer intento.

Establezca umbrales de lanzamiento y vuelva a ejecutar las evaluaciones tras los cambios

Los resultados de la evaluación solo se vuelven operativos cuando afectan a las decisiones de lanzamiento. Defina los umbrales antes de revisar la comparación final de modelos.

Una barrera de lanzamiento práctica puede incluir:

Evite ocultar una regresión grave dentro de una única puntuación ponderada. Un modelo no debería compensar un comportamiento inseguro con las herramientas ofreciendo un rendimiento ligeramente mejor en el estilo de redacción.

Compare los resultados por tarea además de forma agregada. Un modelo puede mejorar el promedio general mientras empeora en una categoría pequeña pero comercialmente importante. Informe sobre el número de victorias, derrotas, empates, fallos y casos sin calificar para cada grupo principal de tareas.

En conjuntos de datos pequeños, no sobreinterprete diferencias porcentuales menores. Revise las discrepancias individuales y utilice intervalos de confianza o remuestreo emparejado cuando la decisión sea reñida.

Vuelva a ejecutar la evaluación tras realizar cambios en:

• El modelo o despliegue

• El prompt de sistema

• La plantilla del prompt de usuario

• Los ajustes de muestreo o razonamiento

• El pipeline de recuperación

• Las definiciones de herramientas

• El esquema de output

• Las barandillas de seguridad (guardrails)

• El código de orquestación o SDK

• La lógica de reintento, tiempo de espera o enrutamiento

Mantenga suites de capacidades y de regresión separadas. La suite de capacidades debe contener tareas difíciles que revelen en qué aspectos puede mejorar el sistema. La suite de regresión debe proteger el comportamiento que ya funciona y normalmente debe tener un umbral de lanzamiento mucho más estricto.

La decisión final del modelo debe tener en cuenta conjuntamente la calidad, la coherencia, la latencia y el coste. Conserve los resultados brutos y la configuración de la evaluación para poder volver a ejecutar la comparación cuando cambien los modelos, los precios, los prompts o los requisitos de producción.

Preguntas frecuentes

¿Qué tamaño debe tener un conjunto de datos de evaluación de LLM?

No existe un mínimo universal. Comience con tareas comunes representativas, casos de alto impacto y fallos conocidos. Amplíe el conjunto de datos a medida que aparezcan nuevos fallos en producción. Un conjunto más pequeño y bien definido es más útil que una gran colección de prompts ambiguos.

¿Deben usarse las pruebas de rendimiento públicas para comparar el rendimiento de los LLM?

Sí, pero solo para un filtrado inicial. Las pruebas de rendimiento públicas miden capacidades predefinidas bajo condiciones específicas. Su decisión final debe proceder de un conjunto de datos de evaluación de LLM que refleje sus prompts, contexto, herramientas, criterios de aceptación, requisitos de latencia y presupuesto.

¿Puede un solo juez LLM calificar todos los modelos candidatos?

Puede hacerlo, pero los resultados no deben aceptarse sin calibración. Compare al juez con revisores humanos cualificados, compruebe la sensibilidad al orden, permita resultados inciertos y utilice comprobaciones deterministas siempre que el output pueda verificarse directamente.

¿Cómo deben contabilizarse los fallos de infraestructura en las evaluaciones de agentes?

Impute los fallos específicos del despliegue a la configuración probada. Etiquete por separado los fallos de infraestructura de evaluación compartida cuando afecten a todos los candidatos por igual. Conserve ambas categorías para no confundir un entorno de prueba defectuoso con un rendimiento deficiente del modelo.

¿Se pueden comparar modelos de API y modelos autohospedados en la misma evaluación?

Sí, si cada candidato recibe tareas equivalentes y se mide su despliegue completo. Registre el hardware, la cuantización, la configuración de servicio, los reintentos, la concurrencia y el comportamiento específico del proveedor, ya que la evaluación compara sistemas operativos, no pesos del modelo de forma aislada.