Del creador de Redis; ejecuta LLM localmente con ds4

Artículo original ↗ Discusión en Hacker News ↗

Un nuevo motor de inferencia de LLM basado en C, ds4 (“DwarfStar”), se centra en un conjunto reducido de grandes modelos MoE como DeepSeek V4 Flash y Qwen 3.8 sobre hardware de consumo de gama alta, especialmente Macs Apple Silicon de 96–128 GB y GPUs x090. Los comentaristas destacan sus valores predeterminados sólidos, optimizaciones agresivas de rendimiento, soporte de contexto largo y streaming desde SSD como ventajas frente a ejecutores más genéricos como llama.cpp y Ollama, mientras que otros señalan herramientas del ecosistema como ds4go y proyectos más pequeños inspirados en él. También hay debate sobre su sitio web llamativo, la elección de C frente a Rust y mucho código generado con IA, y si este enfoque señala un cambio más amplio hacia modelos potentes, totalmente locales y “casi de frontera” para trabajo serio de desarrollo.

Enfoque del proyecto y filosofía de diseño

  • ds4 es un motor de inferencia pequeño y nativo centrado en unos pocos modelos grandes MoE (DeepSeek V4/4.1 Flash, GLM 5.x, Qwen3.8 Flash Next), optimizado en profundidad para ellos en lugar de intentar soportarlo todo.
  • El énfasis está en modelos locales “casi de frontera”, contexto largo (hasta ~1M con trucos) y buen soporte para herramientas/agentes, más que en una cobertura amplia de modelos.
  • El proyecto se plantea explícitamente como una “plantilla funcional” para grandes casos de uso que otros puedan bifurcar y especializar.

Objetivos de hardware y rendimiento

  • El enfoque principal es hardware de consumo de gama alta: Apple Silicon con 96–128 GB de RAM, DGX Spark y GPUs nuevas de gama alta.
  • Se usa streaming desde SSD para encajar modelos muy grandes o ejecutar en máquinas de 64 GB/96 GB, pero algunos dicen que en realidad se necesitan 128 GB para Qwen3.8 Flash Next.
  • Los usuarios informan de un gran rendimiento en M5 Max 128 GB (tokens rápidos, contexto largo) y entusiasmo por los próximos sistemas M5U.
  • Esfuerzo aparte: un motor Gemma-4 MoE para iGPU Intel Xe-LP con unos ~22 tokens/s reportados en un portátil Intel Ultra 7.

Comparación con otros ejecutores

  • Algunos ven ds4 como un clon “vibe-coded” de llama.cpp; otros sostienen que su valor está en los valores predeterminados validados y en un soporte estrecho y muy afinado, más que en una enorme matriz de configuración.
  • Se lo contrapone con herramientas generales (llama.cpp, Ollama) que pueden igualar el rendimiento pero a menudo requieren un ajuste intensivo.
  • Hay discusión sobre el benchmark automático específico por hardware como un enfoque mejor que la configuración manual.

Ecosistema y herramientas

  • Un fork expone ds4 como bibliotecas compartidas con bindings de Go, además de una TUI y herramientas (workspace, scratchpad, API estilo OpenAI, configuraciones MCP/tool-calling).
  • Otro proyecto apunta a GPUs Intel más antiguas; algunos comentaristas desean soporte de primera clase para Intel y mejor soporte para AMD. Hay cierta actividad experimental con ROCm.

Elección del lenguaje y desarrollo asistido por IA

  • El núcleo está escrito en C. Las razones citadas: familiaridad del autor, simplicidad, rendimiento y que los LLM actuales generan C mejor que Rust.
  • Otros argumentan que Rust encaja bien con código de alto rendimiento, de bajo nivel y multihilo, y que puede superar a C en algunos dominios.
  • Hay debate sobre si la semántica más estricta de Rust ayuda o dificulta los flujos de trabajo asistidos por IA.

Críticas, escepticismo y UX

  • Algunos critican la landing page con mucho marketing como “slop” y prefieren el README mínimo de GitHub.
  • Las opiniones mixtas sobre el trabajo previo del autor (por ejemplo, Redis y debates sobre sistemas distribuidos) hacen que algunos traten esa asociación como una señal de alerta.
  • A pesar de las críticas, muchos están entusiasmados con ds4 como una señal de que ingenieros serios están impulsando hacia delante la inferencia local.