This branch adds an experimental, block-granular KV cache streaming path to the CUDA llama-server. It is intended for running long contexts when model weights leave too little VRAM for the complete KV cache. With --kv-stream-stage-mib N, the authoritative KV tensors are stored in pinned host memory while a bounded CUDA pool is shared by resident KV pages and a transfer ring. The runtime adapts that split as the context grows: it keeps as many pages resident as the budget allows, reclaims resident space for staging when more streaming is required, and prefetches later layers while the current layer computes. This avoids relying on uncontrolled Unified Memory page thrashing and preserves exact attention over the full context.

(Not my project) I just built and tested the above llama.cpp fork and I can attest that it really works. My previous "best Qwen 3.8 27B" on my 5060Ti 16GB and host DDR5 RAM was UD-IQ4_XS beellama with KVarN KV cache 5/4 where I got 112000 in context at usable speeds (~900 PP, ~25 TG). With this fork I'm now running the same model, KV cache 8.0/4.0 at 131072 context size at the same speed.

Gemma 4 12B QAT + faster Qwen 3 TTS fits perfectly fine in 12GB VRAM and can be used to create a fully local voice assistant with ... reconizeable traits ;) The project is fully open source and published here: https://git.sync.wtf/starfleet I see Youtubers trying to do similar things every now and then but for some reason their latencies always seem a lot higher than I would expect so if the one I've conjured up (based on Huggingface's Speech-to-Speech project initially) is special somehow then maybe it's of interest to others.

The 5090Ti owners are living a life of luxury with an inference engine (NInfern) that maximizes CUDA 120a performance when running Qwen models. Purely for my own curiosity's sake I've worked with an LLM to make a fork of this project but with my 5060Ti (16GB) as target instead. The upstream author is not interested in taking on us VRAM-poor thus the name change. My main interest lies in trying to get Qwen 3.8 27B even the slightest bit faster than possible with llama.cpp, but I have no idea if I will succeed. Where I'm currently at is that the ffn layer offloading (the main trick from Stainless-Bacon that makes 27B possible to run at Q4 quant at all) has been implemented, as well as attention rotation for the KV cache quants and FP6 as the first of the new <8 bit KV cache quant implementations to come. Looking at adding KVarN now. With Qwen 3.8 27B, MTP and 96000 context size at FP6 KV cache I'm currently seeing around 500 tps PP and 8-10 tps TG. This is slightly below the numbers I have in llama.cpp, although there I'm also using ngram-mod and a 5.0/4.1 KV cache quant so it's not apples to apples. Posting about it here in case anyone else is as curious as I.

This has been my dream since I was a teen - and now the tech is real. This is a fork of an existing speech-to-speech project by Huggingface, with a lot of additions to add the right chimes, the voice* and the overall wakeword architecture. I've had it running for a day and ... I like it. I'll most likely wire up a version of this throughout the house so the whole family can live the trekkie life :) *) Cloning Barrett's voice ... I know. It's just little old me showing that we now have the tech, not some commercial venture. It's done with the utmost of respect for her craft throughout all those years!

We have a Bazzite box that different family members often use for streaming to their own laptops/computers from. It's cumbersome having to walk to the room it's in to wake it from sleep or log in their user into Steam on so that a Remote Play session can be started. Created a little utility that runs a web service on the Bazzite box that can switch the logged in Steam user (guardrailed so that no switching can be done if someone is currently playing). Additionally the binary (Windows, macOS and Linux) can run as a cli to do the switching, as well as sending a Wake-on-Lan packet and perform Steam Link connect PIN pairing. Note: This is very early, only tested on our own system at the moment. It might also work on plain SteamOS with very little adaptions, that is completely untested though since I don't have such a machine. Source repo for building (no ready binaries until I know it works for others too): https://git.sync.wtf/troed/bazinga

I've been back'n'forth for a while whether to invest in a second 5060Ti to be able to go dual GPU on my main workstation. The target has always been to be able to run Qwen 3.6 27B at a usable model quant, kv-cache quant and context size. Today I tried out llama.cpp with the rpc option. I sort of knew at the back of my head that there were projects doing cross-computer inference but I didn't know it was built into llama.cpp. Sure, this requires that you have another machine on your local network (latency matters) with a GPU - but in my case I actually have two. One server that has a 12GB A2000 and one Bazzite box with an AMD something also with 12GB VRAM. I just compiled the latest llama.cpp HEAD with the rpc option enabled on my headless server and launched my main llama-server pointing to it. With the 12GB of the A2000 in the mix I'm now able to comfortably run the 27B model Q4_K_M, Q8_0 kv-cache and 140000 context size, and I've still not maxed out the available VRAM. PP at ~400 (a bit low, will see if that can be tuned*) and TG at 25 (MTP and ngram enabled) makes this perfectly usable. That's the token/second during inference I would've expected from a dual GPU setup in the workstation anyway. So, if you also happen to have another machine on your network with spare VRAM - try out llama rpc. I have no idea why it took this long for me to do. *) This is literally my first run with random defaults - tuning starts now

Not my settings! All credits to "Stainless-Bacon". I did however replicate the setup just now and I think it's worthy of spreading. The trick is in a targeted offloading of only a specific kind of layers to CPU making it possible to run a higher quant that otherwise would be too slow to be usable. Remember to compile llama.cpp with GGML_CUDA_FA_ALL_QUANTS=ON Original settings below. Since I'm using the iGPU for the system I'm slightly tweaking them to use even more VRAM. On my 5060Ti I'm getting prefill 500-600tps (ub at 2048) and tg at ~10tps. export GGML_CUDA_DISABLE_GRAPHS=1 llama-server
--model Qwen3.6-27B-Q4_K_M_MTP.gguf
--chat-template-file froggeric_fix.jinja
--chat-template-kwargs '{"preserve_thinking": true}'
--jinja
--spec-type draft-mtp
--spec-draft-n-max 2
--fit off
--n-gpu-layers 99
--override-tensor 'blk.(2[0-9]|3[0-9]|4[0-3]).ffn_.*=CPU'
--ctx-size 96000
--batch-size 512
--ubatch-size 512
--cache-type-k q5_0
--cache-type-v q4_1
--parallel 1
--temp 0.60
--top-p 0.95
--top-k 20
--min-p 0.0
--presence-penalty 0.0
--repeat-penalty 1.0
--flash-attn on
--no-mmap
--host 0.0.0.0

I regularly recompile llama.cpp but after having done so today my existing setup stopped working. llama-server started throwing an error 400 on the chat template in the Ornith 1.0 35B model I'm mostly using. Couldn't find anything (except a closed stale issue on llama.cpp that seemed slightly similar) so I followed the advice from another posted there and installed the linked "fixed" Qwen chat templates. That worked, so, just posting this here in case it might help someone else too.

I have an HP Z2 G9 where I've replaced the original A2000 GPU with a 5060Ti. I'm pondering getting another 5060Ti to be able to go up to dense models instead of MoE, but the PCIe options on this motherboard aren't the best. I will need to use a PCIe extender no matter what I opt for since there's physically no room for another GPU (the 5060 I have is 2.5 slot sized) and so I'm wondering whether I would even gain something from using an M2 slot adapter instead.

Any insight welcome.

(1) PCI Express Gen5 slot x16 mechanical/ x16 electrical (full height, full length)
(1) PCI Express Gen3 slot x4 mechanical/ x1 electrical (full height, full length, open-ended)
(1) PCI Express Gen3 slot x16 mechanical/ x4 electrical (full height, full length)
(1) PCI Express Gen3 slot x4 mechanical/ x4 electrical (full height, full length, open-ended)
(1) M.2 2280 Storage (PCIe Gen4 x4)
(1) M.2 2280 Storage (PCIe Gen4 x4)
(1) M.2 2280 Storage (PCIe Gen4 x4)

I've just published an Opencode plugin I made since I couldn't find one that fulfilled the exact use case I had myself. Publishing and posting in case it's useful for someone else too. When working with local models I have the need to know why there's suddenly nothing happening (besides the blue cylon-bar) but the plugins I found only showed token generation data when something was passed into Opencode. That meant that during >1 minute prefills there was no output at all. This plugin uses the /slots endpoint (enabled by default) in llama-server to deduce whether it's currently generating tokens or doing prompt processing, and also the current tps for that activity. Now I can just run llama-server as a daemon and I no longer feel the need to go inspect its output just to see what's up. It's likely only useful in a single-user scenario, but it has been tested with both single and multiple parallel slots. Installation: opencode plugin @troed/oc-ls-stats@latest --global

Since I like having more than one local LLM to switch between when analysing tricky development issues I decided to try out this new MoE model today. It's a 30B A3B which means it's basically a drop-in replacement for Qwen 3.6 35B A3B with suitable llama.cpp parameters the same. On their own published benchmark metrics it's supposed to be slightly worse than Qwen, but so far it's not something I've noticed. It's tuned to work well in Opencode which is how I'm running it as well. Try it out, see how it works for you. I know that there are those who would rather use a Canadian than Chinese model in today's political climate and it does seem to perform better than Gemma 4 at least for me. Just don't forget to use the PR linked from unsloth's description until it has been merged into main.

Maybe it was just me, but in case others have done the same this post might help someone else too. I have a workstation with plenty of CPU and system RAM, but I'm "GPU poor" in that I only have a 5060Ti with its 16GB of VRAM. Additionally, I need to use the GPU for regular system activities too which means I only have around ~14GB of VRAM available for the LLM. I'm exclusively using this setup for development and system management tasks, and I've found Qwen 3.6 35B A3B to excel compared to other models. I don't have the VRAM to run the 27GB dense model, so I've spent time on getting the best usage out of the MoE. Or so I thought. Since "everyone" says to use Unsloth UD-Q4_K_XL that's the quant I've been using, and I've gone a bit back'n'forth with MTP/no MTP, UB increase, mmproj since I've also started using a browser MCP etc. Today I took another look at their quant chart and thought that since it's MoE maybe I could run Q5_K_S which would be a step up? Well. Now I'm using Q6_K because it turns out I could run that with the exact same settings as I've optimized my Q4_K_XL setup for which means there are no drawbacks - just a better performing model. I've already noticed how it's able to get out of loops while before I had to interrupt it sometimes. This is my setup. I get >1000 t/s prefill and >20 t/s inference. I'm not chasing faster inference since I actively read the thought process when working the LLM - but I've increased ub to get faster prefill since that's just waiting time otherwise. ./llama-server -hf unsloth/Qwen3.6-35B-A3B-GGUF:UD-Q6_K
-c 160000
-n 32768
-fa on
-ub 2048
-ctk q8_0
-ctv q8_0
--no-mmap
--mlock
--no-warmup
--chat-template-kwargs '{"preserve_thinking": true}'
--temp 0.6
--top-p 0.95
--top-k 20
--min-p 0.0
--presence-penalty 0.0
--repeat-penalty 1.0
--host 0.0.0.0

I also use Opencode with the DCP and Superpowers plugins, which make a tremendous difference both to context handling as well as planning. I have no need for a larger context - I even compact early quite often since the tasks get done before reaching the limit.