IA Informer.

Kapitsa publica nuevos *benchmarks* de inferencia en un MacBook Pro con M5 Max y suma Clover 35B a su motor para Apple Silicon

Kapitsa ha publicado una nueva tanda de pruebas en un MacBook Pro de 16 pulgadas con chip M5 Max y 128 GB de memoria unificada. La actualización 0.2.26 del proyecto incluye mejoras de rendimiento para Qwen Flash-Next 180B, añade Clover 35B al catálogo y sitúa a su motor de inferencia para Apple Silicon por delante de otros motores locales en varias comparativas, siempre dentro de los modelos y condiciones medidos.

Ilustración editorial sobre Kapitsa publica nuevos *benchmarks* de inferencia en un MacBook Pro con M5 Max y suma Clover 35B a su motor para Apple Silicon
Imagen editorial generada para IA Informer.

Qué ha medido Kapitsa

Kapitsa se presenta como un motor de inferencia de código abierto optimizado para Apple Silicon, con kernels Metal escritos a medida para distintos chips y modelos. En esta tanda, sus autores dicen haber comparado seis modelos en un MacBook Pro 2026 con M5 Max frente al siguiente motor más rápido para cada uno en el mismo equipo, con contextos de 1.000 a 32.000 tokens. La propia publicación recuerda que se trata de resultados de *benchmark* y no de una garantía de rendimiento en cualquier uso real.

En la tabla principal, Qwen3.6 35B-A3B encabeza la decodificación con 346 tokens por segundo, seguido de Clover 35B-A3B con 304, Flint 40B con 265, Nemotron Bolt 74B con 154, Qwen3.8 27B con 143 y Qwen Flash-Next 180B con 108. En *prefill*, la ventaja es más clara para los modelos más pequeños: Qwen3.6 35B-A3B marca 6.036 tokens por segundo y Clover 35B-A3B 5.981, por delante de Bolt 74B, Qwen3.8 27B y Flash-Next 180B.

Qué cambia con la versión 0.2.26

La novedad más relevante frente a la versión anterior del motor es que Flash-Next 180B lee los *prompts* un 46% más rápido y Qwen 27B escribe un 8% más rápido, siempre según el relato del propio proyecto. Además, Kapitsa incorpora Clover 35B al catálogo y afirma que puede ejecutar Qwen Flash-Next 180B con *SSD offloading*, es decir, descargando parte del modelo al SSD cuando no cabe por completo en memoria. En su ejemplo, dice que ese modelo puede funcionar en un MacBook Pro de 48 GB a 61 tokens por segundo.

Ese punto importa porque toca uno de los límites más prácticos de la inferencia local: la memoria. Si un modelo no cabe en RAM unificada, apoyarse en el SSD puede abrir la puerta a ejecutar pesos más grandes en equipos que de otro modo quedarían fuera de juego. La contrapartida es que el rendimiento deja de depender solo del chip o de la cuantización y pasa a estar condicionado también por el acceso al almacenamiento y por el equilibrio entre velocidad y latencia.

Cómo explica Kapitsa su ventaja

Kapitsa atribuye la mejora a KFlash, su mecanismo de *speculative decoding*. Según la descripción técnica que acompaña a la prueba, otros motores verifican las hipótesis del *drafter* como una cadena lineal y se detienen cuando encuentran el primer error. KFlash, en cambio, comprueba un árbol de mejores hipótesis en una sola pasada, de modo que sobreviven más tokens por iteración. Los autores sostienen que, en Apple GPUs, ese enfoque encaja bien porque el hardware trabaja en bloques de 8 filas y el coste de una pasada corta ya se paga de todos modos.

Conviene leer esa explicación como una afirmación del propio proyecto y no como una validación independiente. El *benchmark* publicado muestra ventaja frente a otros motores concretos —Splash, oMLX, rec y mlx-serve, según el modelo—, pero no basta por sí solo para concluir que Kapitsa sea mejor en cualquier escenario. Aun así, sí deja una señal clara: en este nicho, la optimización de *kernels* y la elección del método de decodificación siguen moviendo mucho la aguja en Apple Silicon.

Qué puede hacer un usuario interesado

El proyecto invita a probar Kapitsa en cualquier Mac con Apple Silicon mediante Homebrew, con comandos para servir modelos localmente, integrarlos con APIs de estilo OpenAI o Anthropic en localhost y lanzar su propio *benchmark*. También anima a enviar resultados de la comunidad, y dice que el proceso puede tardar entre 3 y 15 minutos. La publicación aclara además que el envío automático remite alrededor de 2 KB con el modelo del Mac, el chip, la RAM, la versión de macOS y las cifras, sin número de serie, nombre de usuario ni rutas de archivo.

Hay, sin embargo, una nota de cautela que el propio autor incluye al final: se trata de una base de código nueva y pueden aparecer errores extraños de *prefill* o decodificación. Esa advertencia rebaja el entusiasmo automático y recuerda que una gráfica llamativa no sustituye a una batería de pruebas más amplia, sobre todo cuando se habla de contextos largos y cargas de trabajo agentivas.

La siguiente comprobación útil será ver si la comunidad reproduce estos números en otros Mac con M3 o M4, o si la mejora se mantiene cuando el contexto crece por encima de 32.000 tokens.