-
Inferencia local: llama.cpp sumó soporte de Nemotron 3 Puzzle y un 2,71x en modelos cuantizados a IQ3_S, pero conviene quedarse en la build b11199 (27/09)
El relevamiento diario de infraestructura marca regresiones reportadas en los backends ROCm, SYCL y CUDA en las builds posteriores, así que el salto de rendimiento y la estabilidad todavía no viajan juntos. En vLLM entraron GLM-5.3-Flash-DFlash2 y MiniCPM-V 4.7, y hay un problema abierto que vale mirar antes de subir a producción: deadlock del motor V1 bajo carga concurrente cuando se combina decodificación especulativa con cuantización FP8. LiteLLM optimizó la capa de proxy con operaciones Redis en lote y sumó soporte de batch de Mistral. La recomendación del informe es directa: fijar builds estables y evitar por ahora la inferencia gestionada de Ollama Cloud Pro, que muestra 95% de fallas. AI Infrastructure Digest
-
El motor de inferencia colibri explotó en GitHub con más de 3.100 estrellas en un día (13/09)
El repo no es nuevo, pero el salto de tracción de hoy lo pone arriba de la lista de tendencias y vale mirarlo por lo que propone: correr modelos MoE de frontera —de 744.000 millones a 2,8 billones de parámetros— en hardware de consumo, en C puro y sin dependencias, tratando almacenamiento, RAM y VRAM como una sola jerarquía de inferencia. La idea central es hacer streaming de los expertos desde disco en lugar de tenerlos todos en RAM, así que un NVMe rápido pasa a ser el factor que más determina los tokens por segundo. Hoy soporta ocho familias, entre ellas GLM-5.2, GLM-5.3-Flash, Kimi K3, DeepSeek V4 Flash, Qwen3.8-Flash-Next, Qwen3.6 y OLMoE, con la jerarquía de memoria manejada por LRU más un conjunto de pines aprendido. Conviene tomarlo como lo que es —un proyecto en movimiento, con trabajo abierto en formatos, compresión, placement, scheduling, kernels y KV—, no como un reemplazo de producción de vLLM o llama.cpp. GitHub · Colibri
-
Un benchmark de cuantizaciones de Qwen3.8 27B llegó al frente de Hacker News y da una respuesta concreta a "cuánta VRAM necesito de verdad" (08/09)
El post es de Piotr Migdał, publicado el 26 de agosto y explotado ahora en HN. Midió los GGUF de Unsloth con llama.cpp sobre GPQA Diamond, IFBench y Terminal-Bench 2.1, y el resultado práctico es que el Q4_K_M de 17 GB iguala al BF16 de 55 GB en el benchmark agéntico de código, y entra en una placa de 24 GB dejando lugar para unos 64k de contexto. El daño de la cuantización es no lineal: hasta 4 bits no se mide nada, el 2 bits (10,7 GB) cae un poco pero se sostiene, y el 1 bit se derrumba al nivel del azar en GPQA —peor todavía con más razonamiento, porque el modelo piensa hasta quedarse sin presupuesto de tokens y devuelve vacío—. El otro detalle que importa es que el nivel de esfuerzo de razonamiento mueve el score mucho más que la cuantización. Costó unos 3.000 dólares de GPU en Modal. Quesma · Hacker News
-
Reasignar precisión tensor por tensor devuelve el 96,7% del razonamiento de Gemma 4 E4B en un GGUF de 3,3 GB (15/08)
Un cuantizado IQ2_XXS armado con lo que su autor llama asignación a nivel de tensor: construye la imatrix desde un corpus orientado a categorías, mide el daño por capacidad y redistribuye la precisión tensor por tensor bajo un presupuesto de bytes fijo. Los números contra el baseline imatrix del mismo tamaño: razonamiento pasa de 28,9 a 69,5, con el BF16 original en 71,875 — o sea recupera el 96,74% del razonamiento del BF16 con alrededor del 24% de su tamaño, y mejora 10 de 11 categorías. Las limitaciones están declaradas y son serias: structured output queda en 55,81%, coding en 58,49% y math en 60,61%, así que sirve para chat y razonamiento pero no para agentes que emiten JSON o código. No hay post-training, LoRA ni pruning: todo sale de cómo se reparte la precisión. El GGUF está publicado con licencia Apache 2.0 y corre con llama.cpp. Hugging Face · r/LocalLLaMA
-
Meta lanza Muse Glimmer, modelo agéntico open-weight de 30B que corre en una laptop
Es una destilación de Muse Spark 1.2 bajo licencia Apache 2.0, pensada para agentes locales "always-on": coding, function calling y razonamiento multi-paso sin depender de la nube. Meta reporta mejoras de velocidad de decodificación de 3,1× en una RTX 5090 y 1,8× en M5 Max; ya está en Hugging Face con soporte para llama.cpp y Ollama. Zuckerberg acompañó el release con una defensa del open source y de la destilación como motor de progreso. Meta AI Research · CNBC · HN (157 comentarios)
Meta AI Research CNBC HN (157 comentarios) Meta Hugging Face
-
Guía práctica: tooling de inferencia local comparado (llama.cpp, Ollama, vLLM, SGLang)
Repaso actualizado a julio de cuándo conviene cada motor para servir modelos localmente — referencia útil para decidir stack de serving según throughput vs. simplicidad. DEV Community
-
Correr Kimi K3 localmente: MXFP4 y llama.cpp
Con los pesos abiertos de Kimi K3 ya publicados (~1,4 TB en MXFP4), la comunidad está armando guías para self-hosting. La ruta práctica: GGUF + llama.cpp (sin paso extra de conversión/cuantización, se apunta el server al archivo) o vLLM/SGLang para serving. El Hub de Hugging Face (org ggml-org) concentra las conversiones oficiales. Accionable para quien quiera evaluar un frontier open-weight sin depender de API. explainx · dev.to — guía inference tools
explainx dev.to — guía inference tools Hugging Face Kimi vLLM
-
Hugging Face transformers v5.13.0 se alinea con la última vLLM
El release trae fixes de generación, attention, cache, cuantización y serving orientados a habilitar transformers con la versión más reciente de vLLM. Útil si servís modelos y venías peleando compatibilidades entre ambas libs. Nota de ecosistema: TGI está en modo mantenimiento y redirige a vLLM, SGLang, llama.cpp y MLX. Releasebot — Hugging Face