llama.cpp

Artículo original ↗ Discusión en Hacker News ↗

Llama.cpp, un popular runtime open-source en C/C++ para ejecutar modelos de lenguaje grandes localmente, está recibiendo atención renovada con su nuevo sitio web llama.app y un instalador basado en curl, lo que provoca tanto entusiasmo como preocupaciones de seguridad en torno a la facilidad de instalación frente a los riesgos de “curl | sh”. En general, los comentaristas elogian el rendimiento de llama.cpp, el soporte de hardware (NVIDIA, AMD, Intel, Vulkan, SYCL, ROCm) y su flexibilidad, especialmente para configuraciones multimodelo y flujos de trabajo de codificación con agentes, aunque señalan asperezas, regresiones en algunas GPUs y una curva de aprendizaje para no expertos. Sigue habiendo comparación con herramientas de mayor nivel como Ollama y LM Studio: muchos las ven como envoltorios más amigables que ayudaron a popularizar los LLM locales, pero sostienen que llama.cpp termina ofreciendo mejor control, un ecosistema GGUF más rico y menos complicaciones de proveedor si los usuarios están dispuestos a gestionar por sí mismos compilaciones y configuración.

Legitimidad y nuevo sitio web

  • Algunos inicialmente desconfiaron de llama.app, pero está enlazado desde el repositorio oficial de llama.cpp y tiene su propio repositorio público del sitio.
  • El sitio se percibe como “vibe-coded” y muy orientado al marketing; a algunos les gusta la presentación más amigable, mientras que otros lo consideran amateur o engañoso por no indicar de forma destacada sus orígenes o que no es de Meta.
  • Un comentarista teme posibles problemas de marca registrada con LLaMA de Meta; otros señalan que llama.cpp existe desde hace años sin conflicto aparente.

Instalación y debate sobre curl|bash

  • El nuevo one-liner curl https://llama.app/install.sh | sh es un gran tema de discusión.
  • A muchos no les gusta curl|sh por razones de seguridad y transparencia, y prefieren git clone + cmake, paquetes del sistema (Homebrew, Arch, etc.) o binarios precompilados.
  • Contraargumentos: instalar desde una fuente HTTPS de confianza no es fundamentalmente distinto de otras instalaciones de software; la facilidad de instalación es crucial para la adopción.
  • Algunos destacan las ventajas de los gestores de paquetes (atestación criptográfica, desinstalación predecible) y el aislamiento mediante contenedores/VMs para agentes y herramientas.

Backends, hardware y rendimiento

  • Las experiencias con Intel Arc, NVIDIA, AMD/ROCm y Vulkan son mixtas:
    • Compilar con OpenVINO/SYCL puede ser complicado para algunos usuarios de Intel Arc.
    • En AMD, el soporte de ROCm es frágil; varios recomiendan simplemente usar Vulkan, o motores alternativos como Hipfire o envoltorios como Lemonade-server y “toolboxes” del proveedor.
  • Se informa que el llama.cpp sin modificaciones deja rendimiento sobre la mesa, pero otros muestran mejoras significativas mediante un ajuste cuidadoso de parámetros de arranque y decoding especulativo.
  • En Apple Silicon, el rendimiento de MLX frente a llama.cpp ahora es parecido; el ecosistema GGUF y el comportamiento de caché son factores importantes.

llama.cpp frente a Ollama y otros runtimes

  • llama.app se percibe como un competidor directo de Ollama (CLI llama serve, instalación de un solo comando, branding).
  • Hay fuerte desacuerdo sobre si Ollama “usa” llama.cpp o solo ggml y sus propios kernels; algunos critican a Ollama por su comportamiento pasado al atribuir crédito.
  • Varios dicen que Ollama es más fácil y popular, pero que llama.cpp es más flexible, más rápido en su hardware y más cercano a la “verdadera” solución.
  • LM Studio y Kobold se señalan como GUIs/envoltorios que internamente dependen de llama.cpp.

Usabilidad, estabilidad y dirección del proyecto

  • Algunos elogian llama.cpp como el “ffmpeg de la IA”: rápido para adoptar nuevos modelos, ampliamente compatible y de alta calidad.
  • Otros se quejan de regresiones (especialmente en ROCm) y del aire de “moverse rápido y romper cosas” en master; el consejo es fijar commits que funcionen.
  • Se critica que históricamente el proyecto no haya sido tan amigable para “hacer clic y ejecutar” como Ollama; sus defensores argumentan que es software de servidor y que las GUIs deberían encargarse de la UX.

Modelos, casos de uso y agentes locales

  • Los usuarios ejecutan una variedad de modelos (Qwen 3.x, Gemma 3, Llama 3.2, DeepSeek V4 Flash, etc.) en GGUF, a menudo fuertemente cuantizados.
  • Algunos encuentran que los modelos pequeños (p. ej., ~4–12B) son limitados para programación o razonamiento serios, especialmente con ventanas de contexto cortas; otros reportan éxito con un prompt bien afinado.
  • Discusión sobre la configuración local de agentes de codificación más barata viable: se sugieren RTX 3090 de segunda mano o equipos Intel Arc eficientes energéticamente; los compromisos giran en torno a VRAM, ancho de banda de memoria y consumo eléctrico.

Enrutamiento multimodelo y herramientas

  • llama-server ahora admite carga y enrutamiento multimodelo, con un “router mode” en evolución; soluciones anteriores como llama-swap siguen ofreciendo enrutamiento y UIs más ricas, pero añaden complejidad.
  • La gestión del KV-cache, el decoding especulativo y el batching son clave para el rendimiento; algunos automatizan el ajuste de configuración usando un LLM en sí mismo.
  • Se menciona harnesses construidos sobre llama-cpp-python y agentes mínimos directamente sobre llama.cpp (p. ej., DLLM en D) para flujos de trabajo locales de codificación eficientes.