A 48GB M4 Pro MacBook Pro reportedly runs Qwen3.6-35B-A3B at 154 tokens/sec with a new inference engine called Kapitsa. For comparison, llama.cpp with MTP reaches 69 tokens/sec in the same reported benchmark. That puts Kapitsa at roughly 2.2× the decode speed of llama.cpp in this test. Here is how the reported results compare on a 2024 M4 Pro MacBook Pro with 48GB of unified memory, running a 4-bit Qwen3.6-35B-A3B model: Kapitsa + DFlash2: 154 tokens/sec oMLX + DFlash2: 127 tokens/sec Ollama + MTP: 89 tokens/sec LM Studio: 86 tokens/sec MTPLX: 80 tokens/sec llama.cpp + MTP: 69 tokens/sec These are developer-reported results, so independent testing is still needed to establish how consistently the differences hold up. Why build another inference engine for Mac? Kapitsa takes a more specialized approach than runtimes designed to support a broad range of models. Instead of optimizing one general-purpose engine for everything, it focuses on specific model architectures running on Apple Silicon, particularly Qwen and NVIDIA Nemotron. That allows its developers to tailor the execution path to the models they support. The reported optimization strategy combines several techniques: 1. Metal kernel optimization Apple Silicon uses Apple’s Metal framework for GPU computation. Hand-optimized kernels can reduce the overhead of operations that dominate inference, provided the implementation matches the model’s architecture and hardware. 2. DFlash2 speculative decoding Speculative decoding uses a draft mechanism to propose tokens that the main model verifies. When multiple proposed tokens are accepted together, the system can generate more output per verification step. The resulting speedup depends on acceptance rates, verification costs and the implementation. It is not a guaranteed multiplier for every prompt. 3. Model-aware caching Caching strategies tailored to a particular model can reduce repeated work and unnecessary memory movement. Their effectiveness depends on the workload and the data being reused. 4. Optimized mixture-of-experts execution Qwen3.6-35B-A3B is a mixture-of-experts model. Instead of activating every expert for each token, the model selects a subset. Efficiently executing those expert operations and managing memory movement can have a substantial effect on inference speed. 5. Concurrent request batching Processing multiple requests together can improve hardware utilization. However, higher aggregate throughput does not automatically mean lower latency for each individual user. The combination of these techniques is what makes architecture-specific runtimes worth watching. The reported numbers extend beyond the M4 Pro On an M5 Max Mac with 128GB of unified memory, the developers also report: Qwen3.6-35B: 281 tokens/sec Nemotron 3.5 Super-VL 120B: 85 tokens/sec These figures show the range of workloads Kapitsa is targeting, from a smaller active-compute MoE model to a much larger vision-language model. However, the two results should not be compared directly without more information about quantization, context length, decoding method, workload and benchmark procedure. What this means for local AI The local inference ecosystem is becoming more specialized. A general-purpose runtime offers broad compatibility, while a dedicated engine can focus its engineering effort on a narrower set of architectures and hardware configurations. That specialization can produce meaningful speed gains, but it also creates trade-offs. Model coverage, compatibility, stability, output quality and maintenance all matter alongside raw tokens per second. For now, Kapitsa’s reported results are promising, particularly the 154 tokens/sec figure on a 48GB M4 Pro. The next step is independent testing with matching model files, quantization, context lengths and decoding settings across all the runtimes. That would help establish how much of the performance gap comes from Kapitsa itself and how much comes from