Lightreason, el repo que acelera Qwen en una RTX 4090

¿Qué es Lightreason y qué mide exactamente?

El repositorio de Lightreason documenta un salto de 63,0 a 139,6 tokens por segundo en Qwen2.5-3B-Instruct corriendo sobre una sola RTX 4090, medido a lo largo de seis prompts. Es la cifra que cualquier fundador que haya intentado servir un modelo local mira primero: el mismo hardware, el mismo checkpoint original en BF16, el doble de velocidad.

Lightreason se presenta como un laboratorio de inferencia local y un Studio interactivo para correr Qwen más rápido en una única GPU de consumo. El proyecto no es un paper: es un checkout de GitHub con código, manifiestos de descarga fijados y evidencia de benchmarks. Los experimentos usan los pesos originales en BF16 de Qwen2.5-3B-Instruct (3,09B parámetros) y del modelo de texto de Qwen3.6-35B-A3B (34,66B parámetros). Nada de cuantizaciones agresivas: el objetivo declarado es acelerar sin tocar el modelo que decide el token final.

Los números: de 63 a 139,6 tok/s en el modelo de 3B

El bloque de rendimiento del repo separa lo que se midió con el checkpoint público de lo que requiere piezas adicionales. Estas son las cifras tal como aparecen:

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

3B, Standard vs Exact: de 63,0 a 139,6 tok/s en seis prompts. Las configuraciones de CUDA graphs y KV compacto de Lightreason coincidieron con las 30 corridas de timing de Hugging Face.
Calidad de salida en el 3B: las respuestas completas de Python, JavaScript y SQL coincidieron en 9 de 9 pares nuevos frente a la referencia.
Runner PARD2 (experimental, separado): de 58,3 a 525,2 tok/s en una respuesta meteorológica que coincidió por completo, y de 63,6 a 724,4 tok/s en el mejor corte de 128 tokens de una secuencia de Fibonacci.
35B: de 7,93 a 51,08 tok/s en el prompt de Python con tope de tokens. La comparación de 6,44× usa la misma entrada entre sesiones.

La diferencia entre esos rangos importa. El 6,44× del modelo grande y el salto del 3B son mediciones de configuración principal. Los picos de 525,2 y 724,4 tok/s vienen de un runner PARD2 distinto y, según el propio repo, son mediciones de investigación archivadas. Mezclar ambas cosas en un solo titular sería engañoso: aquí las separamos.

El 35B: el cuello de botella está en la memoria, no en la GPU

El modelo pequeño cabe entero en la tarjeta. Ahí la estrategia es reutilizar trabajo de GPU ya preparado y verificar varios tokens a la vez. El modelo grande es otro problema: sus pesos de texto ocupan 64,56 GiB, muy por encima de lo que entra en una GPU de consumo.

La solución que describe Lightreason es un ejecutor híbrido CPU/GPU: el runner del 35B mantiene la mayor parte de los pesos de expertos en RAM del sistema y mueve solo los que Qwen realmente usa en cada paso. Cuando un borrador predice varios tokens, el modelo objetivo los revisa en conjunto y puede reutilizar pesos entre esas verificaciones. El punto clave de calidad: el objetivo original en BF16 toma cada decisión de token final, no el modelo borrador.

Para un MoE esto tiene sentido arquitectónico. El repositorio de QwenLM confirma que la familia Qwen3 combina modelos densos y de mezcla de expertos, con variantes como 30B-A3B y 235B-A22B, y que el modelo alterna entre modo de razonamiento y modo directo según cómo se le pida. En un MoE solo se activa una fracción de los parámetros por token, pero los pesos siguen ocupando disco y RAM: ahí es donde se gana o se pierde la latencia real.

Qué técnicas reutiliza Lightreason y qué añade

El repo etiqueta sus configuraciones como construidas y medidas por el propio proyecto, apoyadas en técnicas existentes. Los créditos son explícitos: NVIDIA CUDA Graphs, AMD PARD2, Inco AI DFlash2 y FreeToken de FlashML. El historial de experimentos detalla los cambios propios y, algo poco habitual, también registra qué pruebas fueron más lentas o alteraron la salida.

En el 3B, Lightreason Exact graba y reproduce trabajo de GPU, mantiene una caché de atención compacta, combina proyecciones BF16 y filtra candidatos de vocabulario antes de puntuar los supervivientes con los pesos de salida originales. En el 35B, FreeToken y DFlash2 aportan el ejecutor híbrido y el borrador paralelo, y Lightreason suma prefill de filas seleccionadas, reutilización AVX2 entre rutas de expertos repetidas, desempaquetado nativo en CUDA, bancos de host empaquetados en 34 capas y un nivel de réplica en GPU sin pérdida. El detalle final: reconstruye los bits BF16 originales antes de la matemática de expertos.

La letra pequeña: qué puedes reproducir hoy y qué no

Aquí está el matiz que separa un benchmark de un producto. El checkout contiene código, manifiestos y evidencia, pero cero pesos de checkpoint o adaptadores: los modelos se descargan aparte en la máquina con GPU.

Los resultados 3B de solo objetivo usan únicamente la descarga pública de Qwen. Esos son los 139,6 tok/s que puedes intentar replicar.
Los picos del PARD2 público requieren el adaptador entrenado que el laboratorio suministra por separado. Sin ese adaptador no reproduces los 724,4 tok/s.
El runner asistido por borrador fue 1,062× más rápido que el runner asistido anterior en 36 comparaciones reservadas, con las mismas salidas, pero coincidió con Hugging Face en 12 de 36. Es decir: esa ruta concreta no es bit a bit idéntica al original en todos los casos.
En el 35B, la salida de la configuración empaquetada difiere por primera vez de la configuración Scheduled en el token 116, y coincidió en los 20 pares contra su control fijo de ocho posiciones.

La lectura honesta: la ruta de objetivo original es la que sostiene la promesa de calidad, y las rutas especulativas ganan velocidad a cambio de divergencias medibles. Si tu producto depende de reproducibilidad exacta, esa tabla es tu punto de partida.

¿Cómo lo pruebas en tu propia máquina?

El quickstart público del Studio 3B asume Linux, una RTX 4090 y un driver compatible con CUDA 12.8. El navegador puede vivir en otra máquina. Para saltarte las fuentes del 35B y los archivos de benchmarks, el repo propone un clon disperso con git clone --depth 1 --filter=blob:none --sparse y sparse-checkout set demo_chat results3b.

El setup del 35B pide Python 3.12 con venv y headers, más un compilador de C para Triton; en Ubuntu 24.04 eso se resuelve con build-essential python3.12-venv python3.12-dev. La descarga ronda los 6,2 GB y el descargador necesita otros 2 GiB libres. El entorno fija PyTorch 2.9.1 con CUDA 12.8 y Transformers 4.57.1, y download_3b.py valida los objetos oficiales contra el plan de descarga fijado.

Con el servidor levantado en http://127.0.0.1:8765/ puedes comprobar el estado en el endpoint /api/status buscando ready: true. Para un test sin interfaz, los dos motores se comparan con el mismo prompt y el mismo tope de tokens:

python run_model_3b.py --model-path model-3b --engine original --tokens 128 --json --prompt ...
python run_model_3b.py --model-path model-3b --engine bucketed --tokens 128 --json --prompt ...

El repo es claro con la licencia: el código y la documentación originales de Lightreason usan 0BSD, mientras que los parches de FreeToken y los checkpoints de Qwen tienen términos upstream separados. QwenLM indica en su repositorio que sus modelos de pesos abiertos se publican bajo Apache 2.0. Antes de empaquetar esto en un producto, revisa ambas capas.

¿Qué significa esto para tu startup?

Para un equipo que evalúa servir LLM en local, la señal no es el número más alto sino la metodología. Lightreason publica tiempos de preparación separados de los de generación, repite prompts para medir rendimiento en caliente y compara secuencias completas de tokens, no solo promedios. Eso es exactamente lo que un fundador debería exigir a cualquier proveedor de inferencia que le prometa un multiplicador.

También deja una lección de arquitectura: en modelos grandes, el trabajo de ingeniería rentable está en el movimiento de pesos y en la gestión de memoria, no en exprimir más la GPU. Y una segunda: el ahorro llega con costo de complejidad. Un stack híbrido CPU/GPU con offload de expertos necesita RAM dimensionada, un compilador en la máquina y disciplina para medir cada cambio.

Acciones concretas que puedes ejecutar esta semana:

Mide tu baseline sin tocar nada. Es la primera instrucción de la guía de portabilidad del repo: corre el modelo sin modificar en tu hardware antes de optimizar. Sin esa línea base, cualquier ganancia es una ilusión.
Separa preparación de generación en tus propias métricas. Si tu dashboard mezcla el tiempo de compilación de gráficos con el de generación, vas a reportar mejoras que desaparecen en la segunda llamada.
Repite el prompt antes de creer el número. El Studio insiste en correr el mismo prompt dos veces para ver rendimiento en caliente. La primera ejecución de un LLM local casi nunca representa el costo real de operación.
Valida la salida, no solo la velocidad. Compara secuencias completas de tokens entre la versión estándar y la optimizada. Los 12 de 36 del runner asistido por borrador muestran que acelerar puede cambiar la respuesta.

Conclusión

Lightreason no inventa una técnica nueva: ordena, mide y publica lo que ya existe, con las cifras separadas por configuración y las limitaciones a la vista. Ese es su valor real para el ecosistema hispanohablante, donde sobran tutoriales de inferencia local y faltan benchmarks reproducibles con evidencia en el repo.

El mensaje para un founder es sobrio. Duplicar los tokens por segundo de un modelo de 3B en una RTX 4090 es plausible y está documentado. Multiplicar por once requiere piezas que el propio autor no incluye en la entrega pública. Saber distinguir ambas cosas antes de firmar un proveedor o de prometer una latencia a un cliente es, quizá, el aprendizaje más caro de este tipo de proyectos.