Por qué tu LLM local se siente más tonto de lo que es
Muchos usuarios descubren que los modelos de lenguaje grandes que se ejecutan en su propio hardware se sienten más débiles que los sistemas basados en la nube, no porque los modelos sean inherentemente peores, sino por trampas de configuración como plantillas de chat incorrectas, cuantización agresiva, ventanas de contexto pequeñas y ajustes de muestreo subóptimos. Los participantes comparan herramientas como llama.cpp, Ollama, vLLM y varios esquemas de cuantización, y señalan que los valores predeterminados en ejecutores populares pueden degradar silenciosamente el razonamiento, el uso de herramientas y el rendimiento en contextos largos. El hilo también sopesa las ventajas y desventajas de ejecutar modelos potentes localmente —a menudo con calor, ruido y lentitud en hardware de consumo— frente a descargar el trabajo a GPU en la nube, con el tema recurrente de que una configuración cuidadosa y benchmarks específicos para cada tarea importan más que el tamaño nominal del modelo.
Hardware, térmicas y velocidad
- Hay muchos informes de Qwen 3.8 27B y Gemma 4 ejecutándose de forma impresionante en Macs y GPUs recientes, pero con mucho calor, ventiladores ruidosos y alto consumo de batería.
- Los MacBook Pro (M1–M5, 32–128 GB de RAM) alcanzan ~12–60 tok/s en modelos de 27B; los modelos densos suelen ser “usables pero lentos”, especialmente con contexto grande.
- Los usuarios mitigan el calor con modo de ahorro de energía, herramientas de control de ventiladores, bases de refrigeración para portátiles o descargando la carga a un servidor doméstico.
- Algunos prefieren instancias GPU en la nube (Vast.ai, DO, Linode) a ~$2/h para trabajo serio, usando scripts y túneles para levantarlas bajo demanda.
Por qué los LLM locales se sienten “tontos”
- Un punto recurrente: las malas plantillas de chat y los valores predeterminados de muestreo no proporcionados por el proveedor pueden degradar drásticamente la calidad, incluso si la cuantización está bien.
- Algunos ejecutores retroceden silenciosamente a plantillas genéricas (p. ej., ChatML), haciendo que los modelos actúen como si fueran menos capaces.
- El nivel de cuantización y la compresión de la caché KV afectan fuertemente al razonamiento, especialmente en contextos largos; se señalan cuantizaciones de baja calidad (p. ej., algunas W4A16/NVFP4).
- Varios recomiendan ceñirse a cuantizaciones de mayor calidad (Q8, buenos esquemas GGUF) y evitar la cuantización de la caché KV si importa la precisión.
Ollama vs llama.cpp vs vLLM/otros
- Críticas a Ollama: características retrasadas frente a llama.cpp/vLLM/SGLang, valores predeterminados cuestionables (contexto pequeño, cuantización opaca, menor rendimiento), confusión en el registro y pocos controles de ajuste.
- Otros dicen que Ollama está bien para facilitar el uso, pero oculta detalles importantes, llevando a los usuarios a juzgar mal la calidad del modelo.
- llama.cpp (y variantes) recibe elogios por su fiabilidad, rendimiento y control detallado, aunque la configuración puede no ser trivial sin buena guía.
Casos de uso y valor frente a modelos en la nube
- Experiencias positivas: modelos locales para revisión de código, comprobación de tono, trabajo con herramientas/agentes, retos de CTF/reversing y flujos de trabajo privados.
- Experiencias negativas: los modelos locales suelen ser demasiado lentos o menos capaces que los modelos cloud de frontera (Claude, GPT, Gemini), especialmente para programación y razonamiento complejo.
- Algunos argumentan que los modelos BF16 sin cuantizar que encajan por completo en VRAM son los únicos que realmente merecen la pena; otros se conforman con cuantizaciones de 4 bits bien elegidas.
Meta: benchmarking y adaptación
- Se enfatiza mucho construir benchmarks y harnesses específicos para cada tarea en lugar de depender de puntuaciones llamativas.
- Surgen ideas sobre postentrenamiento o ajuste fino estilo RL con código y tickets propios de una empresa, aunque se debate el esfuerzo frente al beneficio.