Qwen 3.5 en MacBook Pro: Comparación de ocho servidores locales para trabajo en equipo

La ejecución local de modelos grandes en Mac dejó de ser un juguete para entusiastas hace mucho tiempo, pero la historia con Qwen 3.5 35B demuestra que existe una gran distancia entre "funciona" y "sirve como API para equipos." El autor tomó un MacBook Pro M2 Max con 64 GB de RAM y probó no el modelo en sí, sino la infraestructura a su alrededor: cuál servidor MLX aguanta carga de trabajo real, no solo produce números bonitos en los logs y no se desmorona cuando dos usuarios llegan simultáneamente.

Para la prueba, construyeron un arnés Python separado y ejecutaron ocho servidores locales posicionados como forma rápida de levantar una API sobre modelos MLX en macOS. La validación no se basó en una sola pregunta conveniente, sino en un conjunto de ocho prompts de diferentes tipos y longitudes, incluyendo tareas de nivel AIME e inputs largos de hasta 52 mil tokens. Cada escenario se ejecutó cinco veces para eliminar picos aleatorios y obtener un cuadro más honesto de latencia, velocidad de generación y comportamiento general bajo carga.

Se hizo especial énfasis en evaluar no la velocidad pico de laboratorio, sino el comportamiento del sistema en condiciones cercanas al trabajo real: con respuestas en streaming, sobrecarga de red y condiciones de medición repetibles.

En modo single-user, había poco misterio: los tres primeros mostraron resultados similares, y en sesiones cortas la diferencia entre ellos parecía más bien cosmética. Es precisamente por eso que las promesas de marketing en los READMEs engañan fácilmente. Si solo miras una solicitud única, parece que casi cualquier servidor MLX moderno ya es lo suficientemente bueno para el trabajo diario. Pero esta conclusión se desmorona de inmediato una vez que el modelo local se transforma de herramienta personal en servicio para equipo, donde las solicitudes comienzan a solaparse en tiempo.

La etapa más reveladora de la prueba—carga paralela de dos solicitudes. Aquí es donde emergió una brecha real entre soluciones. Cuatro frameworks de seis esencialmente cayeron en cola y manejaron solicitudes casi secuencialmente, aunque seguían pareciendo multihilo en la superficie. Otro servidor mantuvo paralelismo solo formalmente y se desplomó a un coeficiente de 0,85x, lo que significa que la segunda solicitud obstaculizaba en lugar de ayudar a utilizar el hardware. Solo un participante de la prueba mostró aceleración honesta de 2,17x, lo que ya parece comportamiento adecuado para una API local de equipo, donde importa no solo responder rápidamente a un usuario, sino manejar múltiples solicitudes sin degradación dramática.

En el camino, surgieron problemas que importan más que números secos en una tabla. En un lugar, el autor se topó con atención cuadrática, que en 2026 aún puede degradar severamente el comportamiento en contextos largos. En otro—phantom 14.000 tokens/seg que apareció no por optimización mágica, sino por una única línea en un parser SSE que distorsionó la medición. Por separado vale la pena mencionar un proceso zombi que dejó aproximadamente 20 GB de RAM ocupada, aunque los READMEs prefieren guardar silencio sobre tal riesgo.

Para quienes planean producción local, estos no son detalles menores: tales bugs impactan la previsibilidad del servicio, monitoreo y costos de soporte mucho más que diferencias de algunos puntos porcentuales en velocidad bruta.

El valor práctico de este trabajo reside en desplazar el enfoque de promesas bonitas hacia casos de uso reales. Si un modelo es necesario por un desarrollador para solicitudes ocasionales, se puede considerar la simplicidad de despliegue y velocidad básica. Pero si se trata de una API de equipo con paralelismo, contextos largos y necesidad de recuperarse rápidamente de fallos, elegir servidor basado en README ya es peligroso.

Este benchmark muestra algo simple: la stack local para Qwen 3.5 debe evaluarse como infraestructura, no como demo. De lo contrario, puedes terminar con un sistema que se ve "rápido" en pruebas unitarias pero en uso real transforma un MacBook poderoso en una cola cara de solicitudes.