Una discusión reciente en r/LocalLLaMA reúne consejos prácticos para ejecutar bien modelos LLaMA en local, especialmente para flujos de trabajo de agentes siempre activos.

En rendimiento, la comunidad recomienda cachés KV persistentes o checkpoints en SSD para no reevaluar contexto repetido — se menciona que CachyLLama añadió checkpoints KV persistentes en SSD y una caché de prompt de sistema. La decodificación especulativa destaca como gran ventaja: una prueba de los métodos de llama.cpp en Qwen 3.6 27B midió unas 2,7x con MTP, 3,7x con DFlash y cerca de 6x con una pila n-gram en tareas reales de programación. Se prefiere Linux frente a Windows; una comparación mostró 5:25 frente a 12:57 de tiempo total.

En hardware, hay que ajustar el VRAM al quant y al contexto, ya que desbordar a la RAM del sistema ralentiza todo. Para multi-GPU entre máquinas, 10GbE ayuda en cargas en frío y RDMA da las mayores ganancias en configuraciones grandes; un usuario reportó unos 2000-2800 tokens/s de procesamiento de prompt y 88 tokens/s de generación vía RPC all-GPU agrupado — decodificación triplicada, porque mantener cada experto en VRAM supera la penalización de red. Más de cuatro tarjetas por chasis de consumo es poco realista.

Para la elección de modelo y runtime se sugieren quants que quepan en VRAM (p. ej. Qwen3.6-27B-MTP en Q4_K_XL con VS Code Copilot), cachés KV q8_0, offload de mmproj y --cache-ram (48 GB bastaron a un usuario para Qwen3.6 27B). Opciones como --flash-attn, --cache-type-k q8_0 y --model-draft se pierden cuando LM Studio fija un build antiguo de llama.cpp.

En lo operativo, el hilo aconseja empezar pequeño con las integraciones de agentes — el verdadero cuello de botella suele ser la integración de API (p. ej. G-suite), no el LLM. El alojamiento local se plantea como un compromiso por privacidad, control o coste — un usuario reportó unos 80 dólares extra al mes de electricidad por dos viejas tarjetas Tesla funcionando 24/7 — y no como sustituto directo de los modelos cloud de frontera.