Metodología de benchmarking de rendimiento de APIs de modelos de lenguaje de Artificial Analysis

Resumen

Medir el rendimiento de un LLM requiere enviarle un prompt y medir las características de su salida. Medimos el rendimiento en varias cargas de prueba.

Tipos de carga

Tipo de carga	Descripción
Entrada de 1k tokens	Una sola solicitud de aproximadamente 1,000 tokens de entrada
Entrada de 10k tokens	Una sola solicitud de aproximadamente 10,000 tokens de entrada
Entrada de 100k tokens	Una sola solicitud de aproximadamente 100,000 tokens de entrada
Agéntica multiturno	Una tarea agéntica de varios turnos de nuestras evaluaciones de programación, trabajo del conocimiento y automatización

Carga

Medimos todas las cargas de trabajo bajo carga concurrente, para representar mejor cómo rinden los endpoints en producción.

Frecuencia de prueba

Ejecutamos el benchmark cada 6 horas en una variedad de cargas de trabajo
Medimos los endpoints de modelos obsoletos cada 18 horas

Generación de prompts

Cada ejecución toma sus prompts y tareas de un conjunto amplio y diverso, y envía los mismos a cada endpoint de esa ejecución, de modo que todos los endpoints se comparan con el mismo trabajo.

Los prompts de solicitud única combinan contenido de entrada largo con una variedad de tareas y llenan la longitud de entrada objetivo de cada carga de trabajo.

La diversidad de prompts es importante para el benchmarking de rendimiento porque técnicas como speculative decoding hacen que las velocidades de salida varíen según el tipo de salida.

Las cargas de trabajo multiturno usan tareas agénticas de nuestras evaluaciones de programación, trabajo del conocimiento y automatización, elegidas al azar en cada ejecución, por lo que la tarea varía de una ejecución a otra.

Representación de las mediciones

En cada ejecución, tomamos la mediana de las muestras de cada carga de trabajo: sus solicitudes o, en una carga multiturno, su sesión. El valor de un endpoint para una carga de trabajo es el promedio de las medianas de sus ejecuciones en los últimos 5 días.

Las cifras principales de un endpoint (velocidad de salida, tiempo hasta el primer token de respuesta y tiempo hasta el primer token) son el promedio de sus cargas de trabajo. Cada carga de trabajo cuenta por igual. Cuando no tenemos mediciones de una carga de trabajo para un endpoint, como un prompt más largo que su ventana de contexto o una carga con llamadas a herramientas en un endpoint sin llamadas a funciones, el promedio abarca las cargas que medimos.

Las cifras de velocidad y latencia de un modelo provienen de su endpoint representativo, normalmente la API propia del creador del modelo, que también usamos para su precio. Si un modelo no tiene endpoint representativo, o no tenemos mediciones de ese endpoint en los últimos 5 días, usamos la mediana entre los endpoints medidos del modelo.

Definiciones clave

Tiempo hasta el primer token de respuesta: El tiempo en segundos entre enviar una solicitud al servicio o sistema y recibir el primer token de respuesta. Para modelos de razonamiento, incluye el tiempo de razonamiento, por lo que, a diferencia del tiempo hasta el primer token, mide la espera de una respuesta de la misma forma para modelos con y sin razonamiento. En las cargas de trabajo multiturno, lo promediamos entre los turnos de una sesión.
Tiempo hasta el primer token: El tiempo en segundos entre enviar una solicitud al servicio o sistema y recibir el primer token de la respuesta. Para modelos de razonamiento que devuelven tokens de razonamiento, este será el primer token de razonamiento. En las cargas de trabajo multiturno, lo promediamos entre los turnos de una sesión.
Velocidad de salida (tokens de salida por segundo): El número de tokens de salida, incluidos los tokens de razonamiento, recibidos por segundo durante toda la duración de una solicitud, desde que se envía hasta que se recibe el último token, por lo que incluye el tiempo hasta el primer token. En una sesión multiturno, dividimos sus tokens de salida entre el tiempo que el endpoint tardó en responder sus solicitudes, sin contar el tiempo que las herramientas tardan en ejecutarse entre ellas.
Tiempo de extremo a extremo: El tiempo en segundos entre enviar una solicitud y recibir el último token, medido en cada solicitud. En una sesión multiturno, es el total de las solicitudes de la sesión, sin contar el tiempo que las herramientas tardan en ejecutarse entre ellas.
Tasa de errores del endpoint: La proporción de solicitudes de un endpoint en los últimos 5 días que fallaron por parte del endpoint. Una sesión multiturno cuenta como una solicitud, que falla si falla cualquiera de sus solicitudes. Excluimos las fallas que no atribuimos al endpoint, como una clave de API no válida, créditos agotados o la cuota de nuestra cuenta, una solicitud rechazada por no válida o por exceder la ventana de contexto, una respuesta que nuestro límite de max_tokens corta antes de que responda, un bloqueo de seguridad o un error del sandbox. Cuentan los errores por parte del endpoint, incluidos sus límites de tasa, los tiempos de espera agotados y las solicitudes que siguen en curso al cumplirse el plazo del benchmark. Entre cargas de trabajo, agrupamos las solicitudes antes de dividir.
Tasa de aciertos de caché: La proporción de tokens de entrada almacenables en caché que se sirven desde la caché de prompts del proveedor, según lo informa la API del proveedor durante sesiones agénticas de varios turnos. Reportamos una tasa de aciertos de caché representativa para cada endpoint con base en sus mediciones recientes.

Detalles técnicos

Ubicación del servidor: Ejecutamos el benchmark en Google Cloud Run, en la región us-central1.

Cuentas de prueba: Realizamos pruebas usando una combinación de cuentas anónimas, cuentas con créditos y claves de API proporcionadas explícitamente para benchmarking. Cuando nuestro benchmarking principal no usa una cuenta anónima, registramos una cuenta anónima separada y validamos que el rendimiento no esté siendo manipulado.

Librerías de API: Para todos los proveedores que afirman compatibilidad con la API de OpenAI, usamos la librería oficial de Python de OpenAI para garantizar consistencia entre pruebas. Para proveedores sin compatibilidad con OpenAI, usamos sus librerías cliente recomendadas.

Medición de la tasa de aciertos de caché: La tasa de aciertos de caché es la proporción de tokens de entrada almacenables en caché que se leen de la caché. La medimos en nuestras cargas de trabajo multiturno.

Parámetros de API: Usamos los siguientes parámetros de API:

temperature: 0.6 para modelos de razonamiento y temperature: 0 para modelos sin razonamiento, salvo que el creador del modelo especifique lo contrario.
top_p: 1 para las cargas de solicitud única, salvo que el creador del modelo especifique lo contrario
max_tokens de hasta el límite de tokens de salida del endpoint, con un máximo de 65,536, o 128,000 para endpoints que suelen razonar más tiempo

Medición de tokens: Contamos los tokens de salida según los reporta la API de cada proveedor cuando están disponibles, incluidos los tokens de razonamiento, la API devuelva o no su texto. Cuando un proveedor no reporta ninguno, los contamos a partir del texto de la respuesta. Las evaluaciones del Artificial Analysis Intelligence Index también usan los recuentos de tokens reportados por la API de cada proveedor (incluidos los tokens de entrada en caché, de razonamiento y de salida), que nos permiten informar con mayor precisión el costo de ejecutar el Intelligence Index. Al informar las tasas de aciertos de caché y el costo, combinamos estos recuentos con mediciones en vivo de la tasa de aciertos de caché típica de cada modelo, en lugar de basarnos en la medición puntual del momento en que se ejecutó la evaluación.

Manejo de fallas: Una solicitud que falla por parte del endpoint, como un error del servidor, un límite de tasa (429) o un tiempo de espera agotado, cuenta como una velocidad de salida de 0. Una sesión multiturno que falla o no termina dentro de su ejecución programada cuenta solo las solicitudes que respondió el endpoint, o 0 si no respondió ninguna. Excluimos las fallas por nuestra parte, como una clave de API no válida, créditos agotados o la cuota de nuestra cuenta, o un error del sandbox.

Limitaciones conocidas

Cuantización: Algunos modelos usan cuantización para reducir requisitos computacionales y aumentar la velocidad. Sin embargo, la cuantización también puede afectar la calidad del modelo. Estamos avanzando hacia la divulgación completa de los métodos de cuantización usados por los modelos que evaluamos. Para medir cómo afectan a la calidad decisiones de servicio como la cuantización, también ejecutamos el Endpoint Accuracy Index en un conjunto seleccionado de los modelos de pesos abiertos más relevantes que ofrecen muchos proveedores.

Ubicación del servidor y latencia: El tiempo hasta el primer token de respuesta y el tiempo hasta el primer token incluyen latencia de red, por lo que son sensibles a la ubicación del servidor. Ejecutamos nuestros benchmarks en la región us-central1 de Google Cloud, lo que puede favorecer o perjudicar a determinados proveedores según la ubicación de sus servidores. Estamos considerando ubicaciones de prueba adicionales para mitigar este efecto.

Historial de versiones

Versión 3.0.0

3 de noviembre de 2026

Cargas de trabajo: agregamos cargas de trabajo agénticas multiturno con llamadas a herramientas, de nuestras evaluaciones de programación y trabajo del conocimiento, a las cargas de solicitud única, y medimos todas con la misma carga sostenida. Estas reemplazan la carga de trabajo de visión y los escenarios de carga de prompt único y prompts en paralelo.
Velocidad de salida principal: nuestra velocidad de salida principal ahora promedia las cargas de trabajo que medimos en los últimos 5 días (antes, la mediana de la carga de 10k tokens de entrada en las últimas 72 horas).
Velocidad de salida de extremo a extremo: la velocidad de salida ahora abarca toda la duración de cada solicitud, incluido el tiempo hasta el primer token, y excluye el tiempo que tardan en ejecutarse las herramientas en las sesiones multiturno.
Latencia: ahora medimos el tiempo hasta el primer token de respuesta y el tiempo de extremo a extremo en cada solicitud (antes se estimaban a partir del promedio de tokens de razonamiento y la velocidad de salida).
Conteo de tokens: contamos los tokens de salida según los reporta la API de cada proveedor (antes, tiktoken o200k_base).
Tasa de errores del endpoint: ahora reportamos la proporción de solicitudes de cada endpoint que fallan por parte del endpoint.
Fallas: las fallas por parte del endpoint ahora cuentan como una velocidad de salida de 0, y las fallas por nuestra parte se excluyen.
Frecuencia: ejecutamos el benchmark cada 6 horas (antes, cada 3 horas).
Opciones de prompt: eliminamos las páginas de Opciones de prompt. Los gráficos por carga de trabajo muestran los resultados de cada carga.

Versión 2.2.0

2 de marzo de 2026

Prompts actualizados: hemos introducido un nuevo conjunto de prompts con contenido más amplio y variado y una mayor variedad de tipos de tarea. La diversidad de prompts es importante porque técnicas como speculative decoding hacen que las velocidades de salida varíen según el tipo de salida.
Cambio de carga por defecto: la velocidad por defecto en nuestro sitio ahora refleja resultados de prompts con 10k tokens de entrada (antes 1k) y hemos dejado obsoletas las mediciones de rendimiento para cargas de 100 tokens de entrada. Todas las cargas de 1k, 10k y 100k tokens de entrada siguen visibles en todas las páginas seleccionando el desplegable Opciones de prompt. La forma más sencilla de comparar velocidades de salida para diferentes formas de carga es usar el gráfico Velocidad de salida por cantidad de tokens de entrada.

Integrity Terms

Background

Artificial Analysis is an independent AI benchmarking and insights provider. Our benchmarks are consulted by millions of users and organizations.

We strive to ensure that all data published on Artificial Analysis is fair, transparent, and representative of the typical experience of developers and organizations using the models and endpoints we cover. Our inference benchmarking data is widely used as a reference standard for comparing inference providers across dimensions such as speed, latency, and quality. The value of these measurements depends on them reflecting the experience of an ordinary developer using a provider's standard, publicly available endpoint.

These terms formalize the approach Artificial Analysis has taken since we began benchmarking inference performance. They apply equally to all inference providers and platforms (together, "providers") that publish serverless endpoint data on Artificial Analysis, and they ensure every provider is measured on the same fair basis.

Provider Requirements

Traffic from Artificial Analysis must be served on the same publicly available configuration that any ordinary developer would receive when using the endpoint. In particular, providers must not:

Detect, fingerprint, or otherwise identify Artificial Analysis traffic (whether by account, API key, IP address, request headers, payloads, or traffic patterns) and serve it differently from ordinary traffic.
Route Artificial Analysis traffic to dedicated, reserved, or non-public resources, including separate hardware, capacity pools, priority queues, or geographic regions that are not generally available.
Serve Artificial Analysis a model, quantization, context length, or endpoint configuration that differs from what is publicly advertised and generally available under the same name.
Serve Artificial Analysis traffic at a batch size, concurrency, or load configuration that is not representative of what ordinary traffic on the same endpoint receives (for example, running benchmark requests at reduced batch sizes to increase per-request speed).

On request, providers must confirm the model version, precision or quantization, and context length serving Artificial Analysis traffic, and confirm that this matches the standard public offering. Providers must ensure that every employee, contractor, advisor, or affiliate who is aware that an endpoint is being measured by Artificial Analysis complies with this policy.

Performance features that are part of the standard public offering and available to all developers on equivalent terms (for example, autoscaling, generally available caching, or published tiering that any customer can access) are not a violation, provided they are not applied selectively to Artificial Analysis traffic.

Compliance Process

Artificial Analysis lists endpoints and providers at its sole discretion. We reserve the right to delist any endpoint or provider that does not comply with these terms, and to decline, withhold, or remove any listing for any reason.

We conduct frequent consistency checks on every endpoint we measure. As standard practice, we measure from our primary Artificial Analysis account alongside independent test accounts, each created and used in the same way an ordinary developer would. Where these return materially different results on identical payloads and the same endpoint, we investigate before drawing conclusions.

If we detect or reasonably suspect that Artificial Analysis traffic is being served differently from the standard public offering, we may:

Withhold, remove, or delay publication of affected measurements.
Re-measure on a standard, publicly created account and publish those results.
Remove the endpoint or provider from performance leaderboards and listings.
Suspend the provider across all leaderboards.
Publicly disclose that a provider has served non-representative performance to Artificial Analysis.

By submitting endpoints to Artificial Analysis, providers acknowledge these terms and our shared commitment to maintaining benchmark integrity. Artificial Analysis may update this policy at any time.

We appreciate your cooperation. If you have questions or concerns, please contact our team.