llama.cpp 0.8.0: nuevos modelos, voz en tiempo real y funciones de IA local

llama.cpp v0.8.0 es una actualización importante para la IA local, especialmente para la inferencia multimodal. Lanzada el 28 de octubre de 2026, añade compatibilidad con la familia LFM3 de Liquid AI, nuevas arquitecturas de modelos, incluida DeepSeek V4.1 Flash, y capacidades experimentales de audio en tiempo real mediante /v1/realtime, así como conversión de texto a voz mediante POST /tts. También mejora la gestión de modelos, las herramientas del servidor y varias rutas de memoria. Esto no significa que todas las arquitecturas recién incluidas ni los flujos de trabajo de audio estén listos para producción en cualquier dispositivo.

Para un servidor doméstico, la medida inicial más útil es fijar la versión, ejecutar un modelo GGUF conocido, registrar el pico de memoria y la latencia, y mantener la API en privado. Solo entonces hay que probar la visión o el audio. Un nuevo endpoint de servidor no sustituye a un modelo de voz compatible, una interfaz multimedia, una canalización de micrófono, controles de acceso ni capacidad suficiente de GPU/CPU.

¿Qué novedades trae realmente llama.cpp 0.8.0?

Las notas oficiales de la versión v0.8.0 agrupan los cambios en compatibilidad con modelos, multimodalidad, actualizaciones de la API y el servidor, gestión de memoria central y optimizaciones del backend. La mejor forma de entender esta versión es distinguir las funciones que un usuario local puede usar de inmediato de las funciones avanzadas que requieren hardware específico o nuevo código de integración.

El explicador de la actualización de DeepSeek V4.1 Flash es útil para distinguir entre una actualización del modelo y la capacidad de un entorno de ejecución para cargar un modelo. Que una nota de lanzamiento indique que algo es «compatible» no garantiza una cuantización específica, una configuración de GPU ni una experiencia de usuario en tiempo real determinadas.

¿Cómo funcionan la voz en tiempo real y la conversión de texto a voz en esta versión?

Antes, muchos asistentes de voz alojados en casa combinaban componentes separados: captura del micrófono, conversión de voz a texto, una solicitud a un LLM y síntesis de voz. La versión 0.8.0 introduce una ruta experimental de transmisión de audio entrante en la interfaz multimodal (mtmd) y expone un punto de conexión de servidor en tiempo real que utiliza un protocolo de tiempo real al estilo de OpenAI. El servidor también cuenta con un punto de conexión independiente POST /tts para modelos compatibles.

Se trata de capacidades distintas. /v1/realtime es el punto de entrada para flujos de trabajo de conversación o transcripción con transmisión de audio; /tts genera voz a partir de texto mediante un modelo de voz compatible. Ninguno crea por sí solo un asistente que esté siempre escuchando, y ninguno garantiza un idioma, una latencia de ida y vuelta, un formato de audio de salida o una integración con una plataforma específicos sin probar el punto de control real.

Para una prueba de audio práctica, confirma los permisos del micrófono, la frecuencia de muestreo, la conversión de códecs, el comportamiento ante tramas parciales, la detección del final del turno, la cancelación y el manejo de tiempos de espera de la red. Mantén todas las grabaciones de audio y transcripciones sujetas a una política de retención explícita. Si la aplicación que usa el usuario está en otra máquina, el hecho de que la inferencia se ejecute en un NAS no significa que el audio nunca atraviese una red.

¿Por qué son importantes los cambios en la memoria y MoE?

La versión v0.8.0 incorpora una caché SLRU (LRU segmentada) 50/50 para los pesos de mezcla de expertos almacenados en la memoria del equipo anfitrión. El objetivo es gestionar mejor los expertos con distintos patrones de reutilización; el beneficio real varía según el enrutamiento de expertos, la distribución de prompts y la residencia en memoria. En los modelos densos pequeños habituales, este cambio puede tener poco efecto o ninguno.

También se ha refactorizado el procesamiento de atención dispersa, y la versión incluye un manejo más limpio de no_alloc, nuevas operaciones de ggml y optimizaciones de backend. Estos cambios pueden influir en la asignación de memoria o el rendimiento, pero no eliminan la fórmula básica para servir modelos: huella de los pesos + búferes de ejecución + estado de KV/contexto + tensores multimodales + concurrencia + margen operativo.

Un modelo de clase 2B de 4 bits puede caber con facilidad donde no cabe un checkpoint más grande. Aun así, atender prompts más largos y varios clientes puede sobrecargar un NAS pequeño. Nuestra guía de enrutamiento según la memoria que ocupan los modelos explica por qué la memoria máxima total, y no solo el tamaño de descarga del GGUF, debe incluirse en la planificación de capacidad. El análisis de los límites de implementación de Kimi K3 muestra el caso opuesto: las funciones en tiempo de ejecución no pueden hacer que un checkpoint de un billón de parámetros quepa en la memoria de un equipo de consumo.

¿Qué modelos nuevos puedes probar realmente de forma local?

Si quieres hacer una prueba local rápida y medirla, LFM3-1.7B GGUF es un mejor punto de partida que un checkpoint multimodal grande sin probar. Su ficha oficial de GGUF documenta su uso compatible con llama.cpp. Pasa a LFM3-VL-2B cuando necesites imágenes o vídeo, y prueba el proyector y el preprocesamiento adecuados. El audio y el modo omni requieren integraciones específicas para cada modelo.

Para comparar mejor los tamaños de los modelos locales y la cuantización, consulta nuestra guía de modelos de IA para hardware de consumo. Si usas la tienda de aplicaciones de ZimaOS, los requisitos de hardware de Ollama ofrecen otra opción de implementación; el empaquetado de Ollama y las funciones del proyecto original llama.cpp no son garantías intercambiables.

¿Cómo puedes instalar y verificar llama.cpp v0.8.0 en Linux?

Lo siguiente es una guía de verificación de compilación desde el código fuente, no una afirmación sin fundamento de que v0.8.0 ya esté disponible en la tienda de aplicaciones de ZimaOS. Compila un servidor compatible con CPU, fija la etiqueta para garantizar la reproducibilidad, usa un modelo LFM3 GGUF documentado y se vincula solo a la interfaz loopback:

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
git checkout v0.8.0
cmake -S . -B build
cmake --build build --config Release -j --target llama-server
./build/bin/llama-server \
  -hf LiquidAI/LFM3-1.7B-GGUF:Q4_K_M \
  -c 4096 --host 127.0.0.1 --port 8080

En una segunda terminal del mismo host, comprueba que el servidor haya cargado un modelo:

curl -s http://127.0.0.1:8080/v1/models
curl -s http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"local","messages":[{"role":"user","content":"Nombra dos ventajas de un modelo GGUF local."}],"max_tokens":128}'

Si es necesario, sustituye "local" por el ID exacto del modelo devuelto por /v1/models. La versión requiere explícitamente un argumento de modelo (--model o -hf) en el uso actual de la CLI, por lo que un script de inicio antiguo sin ninguno de los dos puede dejar de funcionar. Consulta las instrucciones de compilación del proyecto original para ver las opciones de CUDA, Vulkan, Metal y otros backends compatibles. No expongas públicamente el puerto 8080 hasta que estén configurados la autenticación, TLS, los límites y los perímetros de clientes de confianza.

En un servidor doméstico basado en contenedores, también necesitas almacenamiento persistente para modelos, límites de recursos, capacidades de CPU/GPU compatibles y una asignación de montaje verificada. La siguiente referencia más útil es implementar un LLM local sin interrumpir las aplicaciones NAS; síguela antes de mover las descargas de modelos a una unidad de arranque compartida.

¿Qué deberías probar antes de actualizar un servidor de IA existente?

Una versión de upstream con muchas funciones puede cambiar el comportamiento aunque el servidor se inicie sin problemas. Conserva el binario o la imagen del contenedor actuales, el hash del modelo, las marcas anteriores y al menos una respuesta aceptada como referencia para revertir los cambios. Después, ejecuta una pequeña matriz de regresión:

1. Compatibilidad: registra la etiqueta, el nombre del archivo GGUF, la suma de verificación, el backend y la plantilla de chat; comprueba si aparecen advertencias al iniciar.
2. Latencia: ejecuta las mismas indicaciones cortas y largas en ambas versiones y registra el tiempo de precarga, la velocidad de decodificación y la latencia del percentil 95, sin cambiar el modelo ni el contexto.
3. Memoria: registra el pico de RAM del sistema anfitrión, la VRAM, el comportamiento al descargar modelos de la memoria, las solicitudes simultáneas y si las demás aplicaciones del NAS siguen respondiendo con normalidad.
4. Audio: valida por separado el ciclo de vida de la conexión en tiempo real, las transcripciones, la salida de TTS, la cancelación y la reconexión si esas funciones son relevantes.
5. Seguridad y recuperación: verifica el enlace de red, los permisos de archivos, las rutas persistentes, el comportamiento al reiniciar y la reversión al binario anterior.

Usa nuestra lista de verificación para comprobar las rutas de los archivos de modelo y la explicación sobre cómo separar el estado del entorno de ejecución de los pesos. Esto es especialmente importante cuando un explorador de modelos facilita las descargas: descargarlos fácilmente no sustituye a comprobar dónde se guardaron varios gigabytes de datos.

Preguntas frecuentes

¿llama.cpp v0.8.0 es lo mismo que LFM3?

No. llama.cpp es un entorno de ejecución para inferencias. LFM3 es una familia de puntos de control de modelos de Liquid AI. v0.8.0 añade compatibilidad con nuevas integraciones de LFM3, pero los archivos de modelo aún deben elegirse y obtenerse por separado.

¿v0.8.0 me permite hablar en tiempo real con cualquier modelo GGUF?

No. Las nuevas rutas de audio son experimentales y dependen del modelo. Un modelo solo de texto no adquiere entrada ni salida de voz simplemente porque el servidor exponga /v1/realtime o /tts.

¿Es /v1/realtime una API de voz lista para producción?

Al momento del lanzamiento, considéralo experimental. Prueba el modelo elegido, la codificación de audio, la compatibilidad con el cliente, el comportamiento ante interrupciones y la estabilidad durante las sesiones previstas antes de usarlo como servicio desatendido.

¿La actualización reducirá la VRAM necesaria para todos mis modelos?

No necesariamente. Algunos cambios en la memoria y el backend pueden mejorar cargas de trabajo específicas, pero la VRAM y la RAM necesarias dependen de los pesos, el contexto, la cuantización, el backend del dispositivo y la cantidad de solicitudes. Compara el rendimiento de tu configuración exacta en lugar de hacer suposiciones a partir de las notas de la versión.

¿Necesito una GPU NVIDIA para ejecutar llama.cpp?

No. Admite la inferencia por CPU y varios backends de GPU. El rendimiento usando solo la CPU puede ser suficiente para modelos pequeños, pero mucho más lento que con una aceleración adecuada. Primero compruebe la RAM disponible y el tamaño del modelo; después, elija un backend.

¿Puedo instalar v0.8.0 directamente desde la App Store de ZimaOS?

Este artículo no verifica la versión del paquete de la App Store de ZimaOS ni ofrece una instalación oficial con un solo clic. La guía explica cómo compilar desde el código fuente upstream de Linux fijando una versión e incluye comprobaciones que puede adaptar a su hardware o entorno de contenedores.

¿Seguirá funcionando sin cambios mi antiguo comando llama-server?

Compruebe las opciones y los modelos. Las notas de v0.8.0 indican que los comandos actuales de la CLI requieren --model o -hf. Fije la versión, revise los registros de inicio, pruebe las respuestas de la API y conserve los archivos para volver a la versión anterior antes de modificar un servicio en funcionamiento.

Conclusión

llama.cpp v0.8.0 resulta especialmente útil para ampliar la compatibilidad con modelos y ofrecer un servidor local más capaz; la voz en tiempo real es la novedad más emocionante, pero sigue siendo experimental. Un GGUF pequeño de LFM3 en una API privada de loopback es un objetivo inicial de verificación razonable. Registre el uso real de memoria y la calidad de los resultados antes de añadir entradas de imagen, flujos de audio o usuarios simultáneos.

Para quienes tienen un NAS, la arquitectura más eficaz sigue siendo disciplinada: almacenamiento de modelos en un volumen conocido, un entorno de inferencia dimensionado según la RAM/VRAM realmente disponible y aplicaciones protegidas que consuman su API. ZimaCube 2 puede servir como plataforma privada de almacenamiento y aplicaciones; no lo promocione como un nodo de inferencia multimodal de alta velocidad garantizada sin una configuración de hardware y backend probada. Si está evaluando la nueva familia de modelos compatible, consulte nuestra guía de modelos LFM3 locales y hardware junto con las notas de la versión del entorno de ejecución.

Fuentes y alcance

Documentación oficial consultada el 29 de octubre de 2026: notas de llama.cpp v0.8.0, guía de compilación del proyecto upstream, GGUF oficial de LFM3-1.7B, GGUF oficial de LFM3-VL y explicación del lanzamiento de Liquid AI. La compatibilidad de funciones se basa en las notas de la versión del proyecto upstream; ZimaSpace no ha evaluado de forma independiente esta versión ni la ha certificado para una versión específica de ZimaOS.

Imagen de portada: ggml-org/llama.cpp, tarjeta oficial de la versión v0.8.0 en GitHub.