Local Qwen no es un Opus peor, es una herramienta distinta

Modelos locales vs. modelos de frontera

• Qwen local y modelos similares se presentan como herramientas distintas, no como sustitutos directos de los mejores modelos alojados.
• Fortalezas citadas: privacidad, control de los datos, comportamiento predecible para tareas repetitivas, capacidad de ejecutarse en entornos aislados o empresariales estrictos, y menor coste marginal para un uso personal intensivo.
• Debilidades: dificultades con tareas largas o complejas, de varios pasos; tendencia a entrar en bucles, perder el foco o “rendirse”; menor capacidad bruta que Opus/GPT en razonamiento difícil y conocimiento amplio.

Rendimiento, hardware y coste

• Muchos ejecutan Qwen 27B/35B en 3090/4090/RTX 6000 o GPUs Intel Arc con cuantización; se reportan velocidades desde ~18–60 tok/s en tarjetas de consumo hasta 130–200 tok/s en hardware de gama alta.
• El consumo eléctrico es una preocupación: generaciones largas a cientos de vatios hacen que algunas configuraciones locales sean más costosas por token que las APIs en la nube.
• Los modelos Mixture-of-Experts destacan por mejor tokens/s y ajuste a la VRAM, pero a veces con menor calidad que modelos densos comparables.
• vLLM frente a llama.cpp: vLLM es elogiado por el batching multiusuario y la atención en producción; llama.cpp por el arranque rápido, la flexibilidad y los flujos de trabajo de usuario único. Algunos informan que vLLM es significativamente mejor para la estabilidad y los bucles; otros lo encuentran más lento y menos flexible para uso prosumer.

Arneses, agentes y uso de herramientas

• Un tema recurrente: el diseño del harness (agentes, llamada a herramientas, memoria, enrutamiento) importa tanto como el modelo subyacente.
• La gente ejecuta varios modelos (pequeños/rápidos frente a grandes/lentos) y enruta tareas según la latencia y la dificultad.
• Hay interés en los modelos locales como “asistentes” que hagan el 80% del trabajo, escalando los casos difíciles a un “gran modelo” en la nube, pero construir enrutamiento fiable y autoconocimiento se describe como algo no trivial.

Estilos de prompting, “vibes” y benchmarks

• Distintos modelos responden mejor a distintos estilos de prompting: algunos recompensan la subespecificación y la creatividad, otros necesitan instrucciones muy precisas, y a algunos les gustan formatos estructurados (XML/JSON).
• Los usuarios informan de una gran variabilidad entre ejecuciones y sensibilidad a cambios mínimos en la redacción; las “palabras mágicas” y el tono emocional a veces cambian los resultados.
• Los benchmarks se ven ampliamente como proxies débiles: fáciles de manipular, a menudo desalineados con flujos de trabajo reales e ignorando la UX del harness. Se pide más evaluaciones específicas por tarea y valoradas por humanos.

Privacidad, soberanía y escepticismo

• Fuerte deseo de ecosistemas locales/de pesos abiertos para datos de salud, hogares inteligentes e IP corporativa, para evitar la dependencia del proveedor y políticas opacas en la nube.
• Los escépticos cuestionan el ROI, la inestabilidad de las pilas de hardware/software y el bombo del artículo; otros argumentan que la capacidad local mejora tan rápido que los límites de hoy quizá no duren mucho.