Do criador do Redis; rode LLM localmente com ds4
Um novo mecanismo de inferência para LLM baseado em C, o ds4 (“DwarfStar”), mira um conjunto restrito de grandes modelos MoE como DeepSeek V4 Flash e Qwen 3.8 em hardware de consumo de ponta, especialmente Macs Apple Silicon com 96–128 GB e GPUs x090. Comentaristas destacam seus padrões fortes, otimizações agressivas de desempenho, suporte a contexto longo e streaming via SSD como vantagens sobre executores mais genéricos como llama.cpp e Ollama, enquanto outros apontam para ferramentas do ecossistema como ds4go e projetos menores inspirados por ele. Também há debate sobre seu site de marketing chamativo, a escolha de C em vez de Rust e código pesado gerado por IA, e se essa abordagem sinaliza uma mudança mais ampla para modelos “quase de fronteira” poderosos e totalmente locais para trabalho sério de desenvolvimento.
Foco do projeto e filosofia de design
- ds4 é um pequeno mecanismo de inferência nativo focado em alguns poucos grandes modelos MoE (DeepSeek V4/4.1 Flash, GLM 5.x, Qwen3.8 Flash Next), otimizado profundamente para eles em vez de tentar suportar tudo.
- A ênfase está em modelos locais “quase de fronteira”, contexto longo (até ~1M com truques) e bom suporte a ferramentas/agentes, em vez de ampla cobertura de modelos.
- O projeto é explicitamente apresentado como um “modelo de trabalho” para grandes casos de uso que outros podem fazer fork e especializar.
Alvos de hardware e desempenho
- O foco principal é hardware de consumo de ponta: Apple Silicon com 96–128GB de RAM, DGX Spark e GPUs novas de alto desempenho.
- O streaming de SSD é usado para acomodar modelos muito grandes ou rodar em máquinas de 64GB/96GB, mas alguns dizem que 128GB é realisticamente necessário para o Qwen3.8 Flash Next.
- Usuários relatam forte desempenho em M5 Max 128GB (tokens rápidos, contexto longo) e entusiasmo com os próximos sistemas M5U.
- Esforço separado: um mecanismo Gemma-4 MoE para iGPUs Intel Xe-LP com cerca de 22 tokens/s relatados em um laptop Intel Ultra 7.
Comparação com outros executores
- Alguns veem o ds4 como um clone codificado por vibe de llama.cpp; outros argumentam que seu valor são padrões validados e suporte estreito e altamente ajustado, em vez de uma enorme matriz de configuração.
- Ele é comparado com ferramentas gerais (llama.cpp, Ollama) que podem igualar o desempenho, mas muitas vezes exigem ajuste intenso.
- Há discussão sobre benchmarking automático específico por hardware como uma abordagem melhor do que configuração manual.
Ecossistema e ferramentas
- Um fork expõe o ds4 como bibliotecas compartilhadas com bindings Go, além de uma TUI e ferramentas (workspace, scratchpad, API semelhante à da OpenAI, configurações de MCP/tool-calling).
- Outro projeto mira GPUs Intel mais antigas; comentaristas gostariam de suporte de primeira classe para Intel e melhor suporte a AMD. Há alguma atividade experimental em ROCm.
Escolha de linguagem e desenvolvimento assistido por IA
- O núcleo é escrito em C. As razões citadas: familiaridade do autor, simplicidade, desempenho e os LLMs atuais serem melhores em gerar C do que Rust.
- Outros argumentam que Rust é bem adequado para código de alto desempenho, de baixo nível e multithread, e pode superar C em alguns domínios.
- Há debate sobre se a semântica mais rígida do Rust ajuda ou atrapalha fluxos de trabalho assistidos por IA.
Críticas, ceticismo e UX
- Alguns criticam a landing page carregada de marketing como “slop” e preferem o README mínimo do GitHub.
- Visões mistas sobre o trabalho passado do autor (por exemplo, Redis e debates sobre sistemas distribuídos) levam alguns a tratar a associação como um sinal de alerta.
- Apesar das críticas, muitos estão entusiasmados com o ds4 como sinal de que engenheiros sérios estão levando a inferência local adiante.