El benchmark de QEngine RTX 5090 registra 504 tok/s, con una ventaja marcada por la caché

El benchmark de QEngine RTX 5090 registra 504 tokens por segundo para Qwen3.8-Flash-Next, pero ese pico presenta condiciones que cambian el panorama competitivo. Un usuario de LocalLLaMA probó QEngine 1.3.1 con dos tarjetas RTX 5090 e informó de una ventaja considerable en decodificación de flujo único, es decir, la velocidad de generación de una conversación. La misma comparación sitúa a QEngine aproximadamente al nivel de Strata en una prueba de latencia de prompts para agentes, mientras que Strata procesa más rápido el prompt más largo del benchmark.

El evaluador, que publica como Relative-Ant-9249, atribuye el mérito al desarrollador bpx03 y afirma explícitamente que QEngine es el proyecto de otra persona. Su benchmark de inferencia local compara varios motores en la misma estación de trabajo. Esto hace que el informe sea útil, aunque sigue siendo una comparación realizada por un usuario sin réplica independiente.

La principal disyuntiva ya es visible: el flujo de salida más rápido no produce automáticamente la espera más corta durante toda una conversación. Los prompts repetidos favorecen la caché adaptativa de QEngine, las entradas largas favorecen a Strata en la prueba reportada y conservar conversaciones inactivas vuelve a modificar la latencia. Los desarrolladores que elijan entre estos motores deben identificar qué demora interrumpe realmente su trabajo.

Qué midió realmente el benchmark de QEngine RTX 5090

El resultado de 504 tok/s corresponde a una carga de trabajo, una configuración de memoria y una versión de software concretas. No es ni un promedio de toda la comparación ni una garantía para cada respuesta.

La estación de trabajo contiene dos tarjetas RTX 5090, cada una con 32 GB de memoria de vídeo, junto a un procesador Threadripper PRO 3975WX. El evaluador informa de 251 GB de RAM del sistema y un contexto configurado de aproximadamente 262.000 tokens. Los tokens son las unidades de texto que un modelo procesa y genera, no un recuento directo de palabras.

QEngine utilizó su compilación INT4 AutoRound de Flash-Next, una representación comprimida del modelo que usa pesos enteros de cuatro bits. El evaluador dice que cambió el objetivo de compilación CUDA de la arquitectura 86 a 120, usando nvcc 13.3 y g++-13. Informa de que no realizó otros cambios en el código fuente y de un intervalo de 53 segundos entre el inicio y la atención de solicitudes.

Es un informe alentador sobre portabilidad, aunque una compilación exitosa no demuestra compatibilidad general con el hardware. Demuestra que este usuario logró ejecutar esta compilación en esta máquina. No demuestra un comportamiento equivalente en distintas placas base, controladores, disposiciones de memoria o entornos operativos.

La prueba separa la salida narrativa de la salida de código, y esa distinción importa en todos los resultados. Con la configuración predeterminada, QEngine habría generado texto narrativo a 370 tok/s y código a 439 tok/s. Tras mover su caché de conversaciones a la RAM del sistema, esas mediciones subieron a 406 y 504 tok/s, respectivamente.

La configuración ISTA IQ3_S de Strata habría alcanzado 214 tok/s para salida narrativa y 293 tok/s para código. Su configuración UD-IQ4_XS arrojó 180 y 239 tok/s. Se trata de compilaciones comprimidas distintas del modelo, lo que impide tratar la comparación como una medición pura de la implementación del motor.

La configuración ajustada de bucko vLLM arrojó 135 tok/s para salida narrativa y 141 tok/s para código. Su configuración distribuida midió 120 y 118 tok/s. El evaluador también enumera una configuración de Infernix de 14–18 tok/s, sin una medición correspondiente de procesamiento de prompts.

Estas cifras establecen una diferencia considerable reportada en esta estación de trabajo. También establecen los límites del titular: 504 tok/s es el mayor resultado listado para generación de código. El resultado narrativo del mismo motor es menor, y su configuración de memoria predeterminada es más lenta que su configuración con RAM.

El informe afirma que todos los motores utilizaron el mismo script de benchmark y los mismos prompts. Las recetas comunitarias de serving enlazadas aportan contexto sobre el ecosistema de pruebas, aunque enlazar un proyecto de benchmark no valida de forma independiente un resultado enviado.

Por tanto, la descripción más defendible es específica. QEngine 1.3.1 lideró las configuraciones que este usuario probó para la generación de flujo único, y su mayor tasa reportada se produjo con código. Las afirmaciones más amplias sobre el motor disponible más rápido requieren un campo de comparación más completo y ejecuciones independientes repetibles.

Los prompts repetidos dificultan generalizar la ventaja de generación

La ventaja reportada de QEngine es relevante, pero el benchmark también recompensa un comportamiento que el tráfico habitual podría no reproducir. El evaluador identifica directamente esta limitación, lo que la convierte en un elemento central para interpretar el resultado.

Según la publicación, la caché de expertos de QEngine se adapta al uso reciente. Una caché de expertos conserva las partes de un modelo que se necesitan con frecuencia para que el motor pueda acceder a ellas sin recuperarlas repetidamente de otro lugar. Repetir los mismos prompts ofrece a ese mecanismo una carga de trabajo favorable.

Esto importa porque el benchmark repite sus prompts entre ejecuciones. El uso reciente se convierte entonces en un predictor útil de la demanda futura, lo que puede reducir el movimiento de datos del modelo. La tasa de generación resultante describe una condición operativa favorable, no todas las conversaciones posibles.

El evaluador contrasta esto con la caché de Strata, que, según afirma, ya retiene aproximadamente el 99,5 % de la masa de expertos enrutados. En su relato, repetir un prompt aporta por tanto menos beneficio adicional a Strata. Esa explicación procede del evaluador y no se ha establecido de forma independiente aquí.

La publicación también aporta una observación anterior con tráfico variado: aproximadamente 300–400 tok/s para un único flujo. Las solicitudes mediante la carga de trabajo de agentes del evaluador habrían oscilado entre 330–470 tok/s. Estas cifras siguen siendo rápidas, pero hacen que el titular de 504 tok/s parezca más un caso favorable que una expectativa típica.

El título describe una ventaja aproximada de 1,5–1,9 veces sobre el siguiente mejor motor probado. El cuerpo utiliza una estimación algo más amplia de aproximadamente 1,4–1,9 veces frente a Strata después de considerar las diferencias de carga de trabajo. Ninguno de estos rangos debe convertirse en un multiplicador universal aplicado a hardware o prompts no relacionados.

Aquí es donde QEngine vs Strata se convierte en una cuestión de carga de trabajo. Un desarrollador que genera código similar repetidamente podría beneficiarse de un patrón de caché distinto al de alguien que alterna entre documentos no relacionados. La fuente no establece cuánto tiempo debe persistir cada patrón antes de que cambie la ventaja medida.

Una comparación independiente útil preservaría ambas condiciones. Los prompts repetidos revelan lo que el motor puede hacer cuando la actividad reciente predice la demanda futura. Los prompts variados revelan qué tan bien maneja una secuencia de solicitudes menos cooperativa.

Ninguna condición merece preferencia automática en todas las evaluaciones. La repetición puede representar una aplicación real con instrucciones compartidas y tareas recurrentes. La diversidad puede representar un asistente personal que alterna entre programación, investigación, revisión de documentos y proyectos desconocidos.

El problema práctico surge cuando una condición favorable desaparece del titular. Un lector que solo vea 504 tok/s podría esperar esa tasa inmediatamente después de cambiar de tarea. La evidencia disponible no respalda esa expectativa.

Por tanto, el benchmark de QEngine RTX 5090 presiona a los motores competidores para que expliquen su comportamiento bajo condiciones de caché comparables. También presiona a los autores de benchmarks para que expongan esas condiciones con claridad. Sin esa divulgación, una clasificación de rendimiento puede ocultar la razón por la que existe.

Para compradores y desarrolladores, la pregunta relevante es con qué frecuencia su trabajo real se parece al benchmark repetido. Esa respuesta determina cuánto peso dar al pico. Una tasa ligeramente menor con un comportamiento consistente podría servir mejor a algunos flujos de trabajo que una tasa mayor con oscilaciones más amplias.

Strata se mantiene competitivo antes de que empiece la respuesta

La ventaja de generación de QEngine no se traduce en una ventaja clara en toda la solicitud. Los resultados reportados de procesamiento de prompts otorgan a Strata una posición más sólida a medida que las entradas se alargan.

Prefill significa procesar la entrada antes de que el modelo comience a generar su respuesta. Con aproximadamente 10.000 tokens de entrada, la configuración predeterminada de QEngine habría procesado cerca de 5.700 tok/s. Su configuración de caché en RAM alcanzó aproximadamente 6.200 tok/s con esa longitud de entrada.

La configuración ISTA IQ3_S de Strata habría procesado aproximadamente 5.100 tok/s con la entrada más corta. Sin embargo, con aproximadamente 90.000 tokens, alcanzó cerca de 10.000 tok/s. La configuración predeterminada de QEngine midió aproximadamente 7.300 tok/s con esa entrada más larga.

La publicación no proporciona una cifra equivalente de prefill con 90.000 tokens para la configuración de RAM de QEngine. Ese resultado ausente debe seguir ausente, en lugar de inferirse a partir de su rendimiento con entradas más cortas. Las mediciones disponibles respaldan un resultado dividido, con QEngine por delante en el prompt más corto y Strata por delante en el más largo.

Esta distinción tiene una aplicación directa en los asistentes de programación. Un asistente que trabaja con un intercambio reciente reducido dedica una proporción del tiempo a leer distinta de la de otro que revisa el contexto de un repositorio grande. Una generación más rápida ayuda a ambos, pero no elimina el tiempo dedicado a procesar sus entradas.

La prueba de agentes añade otro límite importante. Cubre una secuencia de 12 turnos de uso de herramientas con un contexto que crece hasta aproximadamente 35.000 tokens. Con el almacenamiento en caché de prefijos funcionando, QEngine 1.3.1 habría leído el prompt del turno final en 1,75 segundos.

El almacenamiento en caché de prefijos significa reutilizar el cálculo correspondiente al comienzo inalterado de un prompt. El resultado correspondiente de Strata fue de 1,7–1,9 segundos, lo que sitúa a QEngine dentro de ese rango reportado. El evaluador describe adecuadamente ambos motores como equivalentes en esta medición.

La configuración ajustada de bucko tardó 4,36 segundos en la misma comparación reportada. Esto establece una diferencia entre esas configuraciones probadas, pero no un resultado para cada despliegue de vLLM. La configuración, la representación del modelo y la carga de trabajo siguen siendo parte de la comparación.

También importa que el número reportado mide una fase de lectura del prompt. No mide el tiempo completo necesario para ejecutar herramientas, inspeccionar resultados, generar instrucciones posteriores y finalizar una tarea. Una fase rápida puede mejorar un agente sin determinar el tiempo total de finalización del agente.

Por tanto, QEngine vs Strata no tiene un único ganador en las mediciones divulgadas. QEngine lidera la generación, mientras que Strata se mantiene competitivo en prompts de agentes almacenados en caché y es más fuerte en la prueba reportada de prefill con entradas largas. Esa es una conclusión más útil que reducirlo todo a tokens de salida por segundo.

Para los equipos que mantienen asistentes locales, la presión es operativa. Deben establecer si los usuarios esperan principalmente el procesamiento de entrada, la generación de respuestas o las herramientas externas. Un cambio de motor solo aborda las partes de ese tiempo de espera que el motor realmente controla.

El resultado también cuestiona cómo se presentan las demostraciones de inferencia local. Un flujo de código que aparece rápidamente es fácil de mostrar y de entender. La demora más silenciosa antes de que comience ese flujo puede importar igual de mucho durante interacciones repetidas con herramientas.

Mantener conversaciones inactivas en RAM cambia otro tipo de espera

El resultado más práctico podría ser la recuperación de conversaciones antiguas, más que la mayor tasa de generación. La configuración de RAM de QEngine habría preservado un estado útil pese al tráfico intermedio.

Una caché KV almacena claves y valores relacionados con la atención, lo que permite a un modelo reutilizar cálculos de tokens anteriores. En esta prueba, QEngine pudo mantener esa caché en RAM del sistema fijada, es decir, memoria del host reservada para transferencias predecibles. El evaluador informa de un pool de 13,5 GB que representa aproximadamente un millón de tokens de capacidad de caché agregada.

El tamaño de ese pool es distinto del límite de contexto configurado para una conversación individual. La capacidad agregada describe cuánto estado conversacional puede retener el pool entre sesiones. No significa que el benchmark probara una sola conversación de un millón de tokens.

El experimento de sesiones inactivas comenzó con ocho conversaciones de aproximadamente 58.000 tokens cada una. A continuación, el evaluador envió aproximadamente 400.000 tokens de otro tráfico antes de volver a las conversaciones originales. Esta secuencia examina si el trabajo previo sigue listo después de que la máquina atiende otra cosa.

Con la caché en RAM, las ocho conversaciones supuestamente volvieron en caliente, lo que significa que su estado retenido seguía siendo reutilizable. El tiempo hasta la primera respuesta osciló entre 1,56 y 2,01 segundos. Esto mide una demora que los usuarios encuentran al reabrir trabajo, en lugar de la velocidad final del flujo de salida.

Con la caché en memoria de vídeo, supuestamente solo dos conversaciones permanecieron en caliente. Las otras seis requirieron procesar de nuevo la entrada, tardando entre 8,7 y 9,4 segundos. El evaluador informa de una referencia de arranque en frío de 8,85 segundos, lo que facilita ver la consecuencia práctica.

Un desarrollador que alterna entre proyectos en curso reconocería este patrón. Una conversación contiene una investigación de depuración, otra una revisión de implementación y otra realiza el seguimiento de una función distinta. El beneficio relevante es conservar el trabajo ya procesado mientras la atención se desplaza a otro lugar.

La misma distinción importa en una base de conocimiento consultable. Encontrar el material adecuado y reanudar el cálculo anterior de un modelo son problemas distintos, aunque ambos afectan a la rapidez con que alguien vuelve a un trabajo útil.

La fuente informa de que las respuestas siguieron siendo correctas cuando la configuración de memoria de vídeo tuvo que procesar de nuevo la entrada anterior. La penalización observada fue la latencia, en lugar de una pérdida documentada de corrección en las respuestas. Esta distinción evita tratar cada fallo de caché como un fallo de razonamiento.

También existe una compensación en la concurrencia, donde concurrencia significa atender varios flujos a la vez. Con ocho flujos simultáneos en contextos de 64.000 tokens, la configuración de RAM produjo supuestamente 124 tok/s por flujo. La configuración de memoria de vídeo alcanzó 139 tok/s por flujo.

El evaluador resume esto como aproximadamente un 10% más lento bajo esta carga de trabajo concurrente, pese a una mejora de aproximadamente un 10% en un único flujo. También revela un arranque por modo y una pasada. Es suficiente para identificar una compensación que merece examinarse, pero insuficiente para establecer su distribución completa.

La cuestión técnica más amplia se extiende más allá de este motor. La documentación de caché híbrida describe un manejo específico de Flash-Next y limita su validación declarada a la generación de texto. La compatibilidad de modelos, la retención de estado y la cobertura de cargas de trabajo requieren atención explícita, en vez de suposiciones basadas en el nombre de un producto.

Para un asistente individual, preservar el trabajo inactivo podría compensar una menor velocidad de salida concurrente. Para un servicio compartido, el equilibrio podría invertirse. Los resultados comunicados hacen que ambas posibilidades merezcan evaluación sin establecer ninguna como opción predeterminada.

Las comprobaciones de calidad y los motores competidores limitan la afirmación de victoria

El informe justifica realizar más pruebas de QEngine, no declarar que produce mejores respuestas o supera a todas las alternativas. Sus propias comprobaciones de calidad y el hilo de discusión establecen esos límites.

La prueba de asistente supuestamente devolvió 44 tareas correctas de 44 en QEngine 1.3.1. Las ejecuciones anteriores de la versión 1.3 devolvieron 42 de 44 con bajo esfuerzo. El evaluador trata la pequeña diferencia con cautela, en lugar de presentarla como una mejora de calidad ya establecida.

La comparación de programación exige una atribución de versión aún más cuidadosa. Una compilación candidata a lanzamiento devolvió 26 tareas correctas de 30 en el conjunto de programación del evaluador. Las configuraciones de Strata devolvieron 24 y 25, mientras que los resultados repetidos de una configuración oscilaron entre 24 y 26.

El evaluador afirma explícitamente que la comprobación de programación no se había vuelto a ejecutar en la versión 1.3.1. Por tanto, no puede servir como certificación directa de calidad para la versión exacta detrás del titular. Aporta contexto sobre una compilación anterior y la variabilidad observada en la comparación.

La conclusión razonable es que estas comprobaciones limitadas no revelaron una desventaja evidente de programación para el modelo comprimido de QEngine. No establecen una calidad equivalente en todas las tareas. Tampoco muestran que una mejora de la velocidad de generación conserve todos los comportamientos que necesita una aplicación de producción.

La cuantización, la compresión de los pesos numéricos del modelo, complica aún más la comparación de motores. Diferentes compilaciones comprimidas pueden alterar tanto el rendimiento como las salidas. Un benchmark que compara configuraciones completas de despliegue responde a una pregunta práctica, pero no aísla todas las causas que contribuyen.

El campo competitivo también está incompleto. En la discusión, el desarrollador de Basalt sugiere probar un motor diseñado específicamente para hardware NVIDIA Blackwell. El desarrollador informa de rendimiento en otra máquina y con otro benchmark, por lo que esas cifras no pueden incorporarse a la clasificación original.

Aun así, la existencia de compatibilidad de inferencia con Blackwell importa al interpretar la expresión «motor más rápido». QEngine lideró las configuraciones que midió quien publicó el informe. Una alternativa no probada sigue sin estar probada, independientemente de que su desarrollador comunique cifras prometedoras en otro lugar.

El hilo fuente también contiene reacciones entusiastas de usuarios y solicitudes de ayuda de configuración. Esas respuestas indican interés, pero ni el entusiasmo ni una anécdota reproducen el benchmark de forma independiente. Una segunda estación de trabajo necesita una prueba documentada antes de que la experiencia de su propietario pueda respaldar la misma afirmación de rendimiento.

La deriva de versiones crea otro problema de verificación. En el momento de comprobarlo, el repositorio de código fuente de QEngine describe la versión 1.3.2 y funcionalidad adicional de Flash-Next. Esas descripciones actuales no deberían atribuirse retroactivamente a la compilación 1.3.1 probada.

El repositorio denomina al proyecto source-available y documenta un enfoque en hardware RTX 3090. Sus notas de compilación siguen identificando la arquitectura 86 y describen otros modelos de GPU como no probados. Esto convierte la compilación del autor en una 5090 en evidencia útil de un resultado individual, en lugar de un compromiso general de compatibilidad.

Por tanto, una reproducción independiente debería preservar la revisión real del software, los archivos del modelo, las opciones del compilador y la configuración de lanzamiento. Actualizarlo todo a la versión más reciente podría producir un resultado interesante, pero respondería a una pregunta distinta. La reproducibilidad depende de conservar lo que se midió.

La presión sobre QEngine consiste ahora en convertir un prometedor informe de usuario en un patrón operativo fiable. La presión sobre los competidores consiste en responder con cargas de trabajo comparables y configuraciones transparentes. Ninguna de las dos tareas se satisface publicando un número mayor obtenido con hardware no relacionado.

Tres resultados harían más útil la próxima comparación

La próxima evidencia útil es una comparación más reproducible entre cargas de trabajo, en lugar de otro pico aislado. Tres señales específicas reforzarían o debilitarían la interpretación de este informe.

Primero, observe una reproducción independiente en otra estación de trabajo con dos RTX 5090. Un resultado útil identificaría la revisión exacta de QEngine y la compilación del modelo, y luego informaría tanto de prompts repetidos como variados. Reproducir una ventaja material de generación en ambas condiciones reforzaría la idea de que la ventaja va más allá de la máquina original.

Una ventaja menor con prompts variados acotaría esa idea sin hacer insignificante la medición original. Mostraría que el historial reciente de la carga de trabajo explica una mayor parte del resultado observado. Esa información ayudaría a los usuarios a elegir un motor según su propio tráfico.

Las pruebas independientes también deberían preservar la distinción entre salida narrativa y salida de código. Combinarlas en un único promedio ocultaría una diferencia que el informe original ya expone. Informar de sus resultados por separado ofrece a los lectores una mejor oportunidad de vincular el benchmark con su aplicación.

Segundo, observe una comparación en la misma máquina que incluya una alternativa centrada en Blackwell como Basalt. El resultado del autor original no establece dónde se sitúa ese motor en la clasificación. Probarlo en las mismas condiciones resolvería una carencia concreta planteada en la discusión.

Una comparación creíble revelaría las diferencias en las compilaciones de modelos comprimidos y los ajustes de calidad. También debería incluir la latencia de procesamiento de prompts y el comportamiento de reanudación de sesiones junto con la velocidad de generación. De lo contrario, un nuevo ganador heredaría la misma ambigüedad que el antiguo titular.

Si QEngine conserva su ventaja en ese campo ampliado, la afirmación competitiva se fortalece. Si otro motor iguala la generación y mejora la latencia de entradas largas o de sesiones reanudadas, la elección dependerá más del comportamiento de la aplicación. Cualquiera de los dos resultados sería más informativo que comparar capturas de pantalla incompatibles.

Tercero, observe pruebas repetidas de carga de trabajo mixta sobre retención de sesiones inactivas y generación concurrente. El resultado comunicado para RAM resulta atractivo porque aborda la interrupción entre sesiones de trabajo. Su ralentización concurrente muestra por qué ese beneficio necesita evaluación bajo un uso sostenido.

Las ejecuciones repetidas revelarían si la recuperación de sesiones en caliente se mantiene consistente a medida que se acumulan conversaciones y cambia la actividad. También mostrarían con qué frecuencia el motor procesa de nuevo la entrada antigua, encuentra fallos o reduce la velocidad por flujo. Esas mediciones pondrían a prueba el valor práctico detrás de la configuración de memoria.

Una recuperación consistente con rendimiento concurrente aceptable reforzaría el argumento a favor del estado conversacional respaldado por RAM. Una variabilidad frecuente o una ralentización mayor limitaría su atractivo a cargas de trabajo más ligeras. Ninguno de los dos resultados exige fingir que todos los asistentes locales atienden el mismo patrón de solicitudes.

Para los desarrolladores que consideran un cambio, el benchmark de QEngine en RTX 5090 ofrece una razón creíble para investigar, junto con limitaciones inusualmente explícitas. Su mayor contribución es mostrar que la velocidad de generación, la latencia de prompts y la recuperación de conversaciones pueden moverse en direcciones distintas.

Antes de sustituir un motor existente, compare las esperas que experimentan realmente sus usuarios. Conserve una conversación larga representativa, introduzca tráfico no relacionado y mida qué ocurre cuando se reanuda el trabajo original. Incluya tareas variadas junto con prompts repetidos y mantenga comprobaciones de calidad que reflejen el trabajo que necesita completar. Registre la versión y configuración probadas para que futuras actualizaciones no borren el significado de la comparación. El benchmark de QEngine en RTX 5090 presenta un caso convincente para realizar esa evaluación, mientras deja la elección final supeditada a la evidencia de su carga de trabajo. ¿Su asistente pasa más tiempo generando una respuesta, leyendo un prompt cada vez más largo o recuperando una conversación que esperaba que recordara?