-
Prospero: un harness de agentes de código escrito en C++ que corre con dos órdenes de magnitud menos de recursos y nunca espera para siempre (31/10)
Chris Wellons publicó un harness con interfaz Dear ImGui y sin ningún proveedor de modelos adentro: enchufás llama.cpp, OpenRouter o las APIs de Anthropic y OpenAI —una suscripción de Claude no sirve—. Los principios de diseño son los que vale copiar si armás algo parecido: renderizado pasivo, que redibuja solo cuando algo cambia y no toca la GPU en reposo; deadlines en todas partes, donde un comando de shell que vence pasa a tarea de fondo en vez de colgar la sesión; árboles de procesos que mueren juntos, con job objects en Windows; y un motor headless que puede correr en una máquina remota por SSH o WSL mientras la UI queda en el escritorio, con sesiones que siguen sin la GUI enganchada. Soporta subagentes, worktrees de Git, MCP, sesiones forkeadas y cambio de shell a mitad de sesión avisándole al agente. La configuración es un INI en ~/.config/prospero/prospero.ini que puede incluir otros archivos por path o URL, y el autor aclara que los permisos atajan errores tontos, no son un límite de seguridad: para aislamiento real, contenedores. La Community Edition es gratis en GitHub; la Professional, de pago, trae los motores headless. null program
-
LFM3: Liquid AI saca una familia de cinco modelos de unos 2B con un backbone compartido, y el de texto entra en 1 GB a 4 bits (27/10)
Todos salen de LFM3-1.7B-Base, pre-entrenado con 22 billones de tokens, y comparten un mix tri-híbrido de convoluciones cortas con compuerta, atención de ventana deslizante y atención global en 24 capas. La familia: LFM3-1.7B de texto con 256K de contexto, LFM3-VL-2B de visión con video y razonamiento paso a paso, LFM3-Audio-2B con voz de entrada y salida en 18 idiomas, LFM3-Omni-2B que junta las tres, y dos modelos de decisión, d1-2B y d1-Omni-2B, que responden preguntas tipadas sobre texto, imagen y audio. Los números son del propio Liquid AI: el de texto promedia 49,37 en su suite contra 31,55 de LFM2.5-2.6B y 47,24 de Qwen3.5-9B, y lidera en BFCL V4 con 71,39 y en ToolSandbox, aunque los modelos más grandes le ganan en coding agéntico y conocimiento; el de visión promedia 71,4 sobre 62 benchmarks, cerca de Gemma 4 12B (71,7); el de audio da 6,2 de WER en inglés y 73,1 en VoiceBench. Lo accionable es el tamaño: 35% menos parámetros que LFM2.5-2.6B para resultados comparables o mejores, el de texto entra en unos 1 GB a 4 bits, y cada modelo se puede fine-tunear en una sola GPU. Pesos en Hugging Face, soporte declarado para llama.cpp, MLX, vLLM y SGLang, y partners de lanzamiento que incluyen AMD, NVIDIA, Qualcomm, Intel con OpenVINO, Ambarella y OpenRouter. Dos advertencias: la página los llama open-weight pero no nombra la licencia —hay que mirar los model cards—, y nombra al mismo modelo de comparación como "GPT-5.6 Luna" y "GPT-6 Luna" en lugares distintos. Liquid AI
-
Carbon-X: Hugging Face abre un modelo de lenguaje de ADN de 14,8B que entra en una GPU de 80 GB (25/10)
Lo hicieron Hugging Face Bio con la Zhongguancun Academy y el TIGEM de la Universidad de Nápoles Federico II, partiendo de Qwen3-14B y agregando los tokens de ADN al vocabulario de texto, así que uno le pasa secuencia cruda en un chat y responde en inglés: si una mutación es benigna o patogénica, si una región es reguladora, de qué organismo viene, qué bases siguen. Promedia 66,7% en cinco benchmarks de ADN contra 67,5% de GPT-6.1 Sol (Max) y 60,9% de Opus 5.5 (Max), con 74,9% en BioReason Coding y 39,4% en NextBase como sus mejores marcas, y 29,8% en preguntas de sitios de splicing como la peor. La comparación hay que mirarla con cuidado: Carbon-X corrió con pensamiento apagado y los competidores en su mejor configuración de razonamiento. Apache 2.0, pesos en safetensors y GGUF (15,8 GB en Q8_0, 9,6 GB en Q4_K_M), vLLM, Transformers v5+ o llama.cpp b11742 o posterior —las builds viejas tokenizan mal el ADN—, y los propios autores aclaran que no está validado clínicamente. MarkTechPost
-
Underdog Saluki 27B: un Qwen3.8-27B de 7,9 GB que mantiene el tool calling a unos dos bits por peso, y corre en una sola GPU (24/10)
La promesa es fuerte y hay que mirarla con cuidado: el vendedor reporta 88 de 120 en su Underdog Bench contra 84 del modelo completo de 54 GB y 76 del IQ2_XS de ISTA-DASLab, o sea que la cuantización le ganaría al original, pero las tareas de ese benchmark no están publicadas. Lo que sí se puede auditar es el archivo: el análisis encuentra que cambia el tipo de 146 de 851 tensores, todos a formatos de menos bits, dejando intactas las matrices de proyección de atención y DeltaNet, con los vectores sin cuantizar distintos —los pesos se cambiaron, no solo se reempaquetaron—, y el autor lo presenta como checkpoint preview. La parte accionable es la guía: corre en llama.cpp de stock, release b11565, con 16.384 de contexto, en una T4 de Colab o una Mac con Apple silicon, y la verificación de tool calling se hace con el checker de BFCL v4 en parsing estricto y laxo, pensamiento apagado y decodificación greedy. MarkTechPost
-
llama.cpp v0.6.0 estrena la API llama_batch_ext, soporte de GLM-5.3-Flash de 320B y flash attention por la tensor API de Metal (05/10)
La API nueva, con llama_process(), acepta batches mixtos de tokens y embeddings y embeddings de "estado" por token, que es lo que hacía falta para los modelos MTP y deepstack. Suma GLM-5.3-Flash (GLM5-Next), un híbrido de 320.000 millones con texto y visión, el modelo de decisión Clef con texto y visión, y decodificación especulativa MTP para Qwen4Exp. Del lado del rendimiento hay kernel de flash attention por la tensor API de Metal para KV en F16, flash attention disperso para K/V cuantizados en Vulkan, y ggml actualizado a v0.26.0. También rehicieron la Web UI con una capa de datos del Hub de Hugging Face y pipeline de descarga de modelos. GitHub
-
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