dasllama: A Game-Scripting-Language Inference Engine Claims 5x Faster Speech-to-Text Than llama.cpp on CPU

A new open-source inference engine called dasllama says it runs speech-to-text up to roughly 5 to 7 times faster than llama.cpp-family runtimes on CPU, and it is written not in C++ but in a game scripting language. The claim comes from the authors' own write-up, The need for speed, and every figure in it is self-measured. This post lays out what is claimed, where the authors admit losses, and how you can check it on your own machine.

We cover it because local speech and small-model inference is where laptops and servers without a big GPU actually get used, and because the post is unusually candid about where it does not win. For other recent local-runtime stories, see our coverage of DwarfStar and antirez's DS4 local inference and the Cactus Whistle 16.9 MB speech-to-text model.

TL;DR

What is dasllama and what is daslang?

According to the project site, dasllama is "local inference, written in daslang". Daslang is a statically typed scripting language from Gaijin Entertainment, the studio behind War Thunder, built for embedding in game engines. It is JIT-compiled, and the project lives inside the daScript repository on GitHub under modules/dasLLAMA. The article says the whole engine, including the compute kernels, is written in daslang with no separate C++ and no hand-written shader code.

The engine loads stock GGUF files, the same format used by llama.cpp, so you do not need a special conversion step. The features page lists Llama, Qwen, Gemma, Phi and gpt-oss text models, plus speech-to-text (Whisper, Parakeet, Qwen3-ASR, and GigaAM v3 for Russian), text-to-speech (KittenTTS, Kokoro-82M, Pocket TTS), and translation (Bergamot int8 models and translation LLMs such as MiLMMT-46). GigaAM and the translation families are marked as in master, ahead of the next release.

What speedups does it claim?

The authors publish a "ladder" of comparisons against reference runtimes. Version 0.6.6 numbers from the article:

CPU

GPU

The pattern is that the biggest wins are on small speech models on CPU, where per-call overhead and kernel choice matter more than raw matrix-multiply throughput. For a large mixture-of-experts LLM on a GPU the numbers are modest, and on one high-end GPU the result is a tie or slightly worse.

Where does it lose?

The article lists its own losses, which is what makes the benchmarks more credible than a bare headline:

• Qwen3-ASR on Granite Rapids: about half the speed of the reference.
• Qwen3.6 prefill on Granite Rapids: 0.91x.
• Kitten TTS nano on x86 servers: 0.7x to 0.85x.
• Kokoro on x86: roughly even.
• A 4-stream decode test on the RTX 5060 Ti: 0.88x.

Also noted: the CUDA emitter is finished but the article publishes no CUDA benchmarks, and some CPU and GPU shape combinations, including the x86 int8 path, are not yet implemented or tuned. In short, this is a fast-moving 0.6.x project, not a drop-in replacement for llama.cpp across the board.

How does it get its speed?

Two techniques stand out in the write-up.

Auto-tuning on first launch. A [tune] macro races permutations of a kernel on the machine it runs on and saves the winners to a JSON sidecar file. Pre-tuned sidecars ship for several CPU classes, and tuning on an unfamiliar machine can take around 20 minutes the first time. That explains why results vary so much between CPUs: on hardware that matches a shipped sidecar you get tuned kernels, otherwise you pay a one-time cost or run with defaults.

Expert caching on Vulkan. For mixture-of-experts models that do not fit in VRAM, the engine keeps the hot experts cached on the GPU while the CPU handles the rest. This is the source of the 2.0x decode and 5.3x prefill result on the 16 GB RTX 5060 Ti, a consumer card where the model otherwise would not fit.

These are design claims from the authors. We did not read the kernels, and we have not reproduced the numbers.

Claimed versus verified

We found no third-party benchmark of dasllama at the time of writing. Treat the table as a list of claims worth testing, not settled results.

How to try it and check the numbers yourself

Per the project site:

1. Install with pip install dasllama (any platform), brew install borisbat/daslang/dasllama (macOS or Linux), or Scoop on Windows after adding the borisbat/scoop-daslang bucket. Debian, Ubuntu and Fedora packages exist for amd64, arm64, x86_64 and aarch64.
2. Each install provides dasllama-server, dasllama-cli, dasllama-bench and dasllama-watchdog.
3. Run dasllama-bench on the same model file and the same audio clip you use with llama.cpp or whisper.cpp, on the same machine, and compare wall-clock time. Warm up first, and let the tuner finish before you time anything.
4. Compare output quality too: speed is meaningless if the transcript differs. Run both engines on the same clip and diff the text.

If you are choosing a runtime for a voice agent or a local transcription tool, the question is not whether 5.5x holds on an M5 Max, it is whether you see a gain on the machine you will deploy to. Our guides to on-device speech models like Gradium Phonon and IBM Granite Speech 5.0 cover the models you might run on top of such an engine.

Why a game scripting language for inference?

Game studios have long needed fast, hot-reloadable, safely sandboxed code that can be compiled at runtime for whatever hardware the player has. That is close to what an inference engine needs: kernels specialised to the CPU or GPU in front of it. The dasllama pitch is that a single high-level language with a JIT can generate specialised kernels for CPU, Metal and Vulkan without maintaining separate C++ and shader code bases.

The trade-off is maturity. llama.cpp has years of community testing across thousands of hardware configurations. A new engine with auto-tuned kernels may beat it on the configurations its authors tested and trail it on others, which is exactly what the published ladder shows. The practical takeaway is that engine choice is increasingly hardware-specific, a theme we also saw in Apple's MLX RDMA work for local inference and in extreme quantisation projects such as Underdog Saluki 27B.

Which workloads benefit most?

Reading the ladder as a buyer would, three groups of users might care:

• Voice and transcription apps on CPU-only servers or laptops. The speech results are the headline. If you transcribe meetings on an ARM cloud instance such as Graviton4 or run Qwen3-ASR on a MacBook, a multi-x gain would cut latency or cost. Check your own clips.
• People running big mixture-of-experts models on a single consumer GPU. The 16 GB RTX 5060 Ti result suggests expert caching can help when the model overflows VRAM. It is one card, so test before you rely on it.
• Anyone on Intel server CPUs such as Granite Rapids. The authors' own numbers show losses there, so llama.cpp may remain the better choice until tuning improves.

For developers building apps with local speech, a related tool is the AnySpeechRecognizer Swift package for Apple platforms, which wraps Parakeet and Qwen3-ASR.

What to watch next

• Independent benchmarks from people outside the project, especially on Intel and AMD desktop CPUs.
• CUDA numbers, now that the backend is announced in the 0.6.7 news item.
• Whether the tuned-sidecar approach scales to many hardware types without a 20-minute first-run cost.
• Whether the project closes the x86 int8 and TTS gaps the authors list.

Related reading

• DwarfStar DS4: antirez's local inference engine
• Cactus Whistle: a 16.9 MB speech-to-text model on CPU
• Gradium Phonon: open on-device TTS
• IBM Granite Speech 5.0
• Underdog Saluki 27B 2-bit GGUF

Figures are from the dasllama authors' article of October 28, 2026 and project site as read on October 31, 2026, and have not been independently reproduced by explainx.ai.