Qwen 3.5 en un MacBook Pro: comparativa de ocho servidores locales para trabajo en equipo

Ejecutar modelos grandes en local en un Mac hace tiempo que dejó de ser un juguete para entusiastas, pero el caso de Qwen 3.5 35B demuestra que entre «arranca» y «sirve para una API de equipo» hay una gran distancia. El autor tomó un MacBook Pro M2 Max con 64 GB de memoria y no evaluó el modelo en sí, sino la infraestructura que lo rodea: qué servidor MLX aguanta una carga de trabajo real, no presume de cifras bonitas en los logs y no se desmorona en cuanto llegan dos usuarios a la vez.

Para la prueba se montó un arnés propio en Python y se pasaron por él ocho servidores locales que se presentan como una forma rápida de levantar una API sobre modelos MLX en macOS.

La prueba no se basó en una sola pregunta cómoda. Se usó un conjunto de ocho prompts de distinto tipo y longitud, con tareas de nivel AIME y entradas largas de hasta 52 mil tokens. Cada escenario se ejecutó cinco veces para eliminar picos aleatorios y obtener una imagen más honesta de la latencia, la velocidad de generación y el comportamiento general bajo carga. El énfasis estuvo en medir no la velocidad máxima de laboratorio, sino el comportamiento en un régimen cercano al de trabajo: con respuesta en streaming, capa de red y condiciones de medición repetibles.

Con un único usuario apenas hubo emoción: los tres primeros mostraron resultados parecidos y, en sesiones cortas, la diferencia entre ellos parece más cosmética que real. Por eso las promesas de marketing de los README inducen tan fácilmente a error. Si solo se mira una petición aislada, parece que casi cualquier servidor MLX actual basta para el trabajo diario. Pero esa conclusión se rompe en cuanto el modelo local pasa de herramienta personal a servicio de equipo, donde las peticiones empiezan a solaparse en el tiempo.

La fase más reveladora fue la carga paralela de dos peticiones. Ahí apareció la brecha real entre soluciones. Cuatro de seis frameworks acababan en cola y atendían las peticiones casi en secuencia, aunque por fuera parecían multihilo. Otro servidor mantenía el paralelismo solo en apariencia y caía a un coeficiente de 0,85x, es decir, la segunda petición estorbaba más de lo que ayudaba a aprovechar el hardware. Solo un participante logró una aceleración real de 2,17x, lo que ya se parece a un comportamiento válido para una API local de equipo, donde importa no solo responder rápido a un usuario, sino sostener varias peticiones sin una caída dramática.

Por el camino surgieron problemas más importantes que las cifras secas de una tabla. En un caso, el autor se topó con un attention cuadrático que, en 2026, todavía puede degradar con fuerza el comportamiento con contextos largos. En otro, con unos fantasmales 14 000 tokens/sec que no se debían a ninguna optimización mágica, sino a una línea del parser SSE que distorsionaba la medición.

Aparte se menciona un proceso zombi que dejaba unos 20 GB de RAM ocupados, un riesgo sobre el que los README prefieren callar. Para quien planee un despliegue local en producción, no son menudencias: esos fallos afectan a la previsibilidad del servicio, a la monitorización y al coste de mantenimiento más que una diferencia de unos pocos puntos porcentuales en velocidad bruta.

El valor práctico del trabajo está en que desplaza el foco de las promesas atractivas a los escenarios de uso. Si un desarrollador necesita el modelo para consultas ocasionales, puede fijarse en la facilidad de arranque y la velocidad básica. Pero si se trata de una API de equipo, con paralelismo, contextos largos y necesidad de recuperarse rápido de fallos, elegir un servidor por su README ya es peligroso.

Este benchmark deja clara una idea simple: la pila local para Qwen 3.5 hay que evaluarla como infraestructura, no como demo. De lo contrario, se puede acabar con un sistema que parece «rápido» en pruebas individuales y que, en el trabajo real, convierte un potente MacBook en una cara cola de peticiones.