LocalAI sostiene que la mayoría de los backends de inferencia locales deberían limitarse a envolver motores ya existentes —llama.cpp, vLLM, whisper.cpp, stable-diffusion o MLX—, y precisamente por eso dieciocho de sus backends no envuelven nada: son puertos propios en C o C++ que la empresa escribe desde cero cuando el envoltorio obligaría a distribuir un entorno virtual de Python de varios gigabytes, una pila CUDA no portable o un modelo que carece de implementación en C++. El artículo mide qué se gana y qué se paga con esa decisión.
El ejemplo más claro es vllm.cpp, un puerto en C++20 de la arquitectura V1 de vLLM. Instalar vLLM produce un entorno virtual de 9,1 GiB; instalar vllm.cpp produce un binario de 66 MiB. Ofrece las mismas funciones —caché KV paginada, batching continuo, caché de prefijo, planificador y muestreador— sin Python, PyTorch ni ggml en inferencia. En un NVIDIA GB10 con Qwen3.6-27B en NVFP4, el rendimiento se sitúa entre 1,007 y 1,045 veces el de vLLM —empate dentro del ruido excepto en flujo único, un 4,5 %— y el uso máximo de memoria cae de 28,18 a 24,88 GiB. En CPU, el prefill corre 1,18 veces más rápido que llama.cpp sobre el mismo GGUF.
A veces el puerto gana en velocidad. depth-anything.cpp, puerto de Depth Anything 3 de ByteDance, corre la cuantización q8_0 a 1,31 veces la velocidad de PyTorch con un 27 % de la memoria y carga en 40 ms frente a 749 ms. La ganancia procede de memorizar dos embeddings posicionales que la implementación de referencia recomputaba en cada pasada. En biometría, face-detect.cpp y voice-detect.cpp igualan bit a bit al insightface original —coseno 1,000000 en el embedding— sacrificando velocidad en CPU a cambio de un binario autónomo y despliegues sin Python. La metodología es siempre la misma: convertir primero los pesos a un GGUF único, portar después el grafo validándolo componente a componente contra tensores de referencia y optimizar solo cuando la paridad está garantizada.