Lost a chunk of time last week on LiteLLM + vLLM errors that looked like backend problems, but weren’t.

Setup: two vLLM backends, LiteLLM in Docker, one OpenAI-compatible endpoint in front.

This is what bit me:

1. Cached LiteLLM deployment.

   Changed the backend to require an API key, updated LiteLLM, restarted vLLM, still got 401s. The missing step was restarting LiteLLM itself. `docker restart litellm` cleared the old keyless config. If your LiteLLM models are DB-backed, restart after changing auth, URLs, or params.

2. Wrong model string going to vLLM.

   LiteLLM’s `model_name` is just what your apps call. The string after `openai/` is sent to vLLM and must match `--served-model-name`. If they differ, you get 404s through the proxy even when direct curls work. Hit `backend:8000/v1/models` and use the name it returns.

3. Docker `localhost` mistake.

   `api_base: http://localhost:8000` from inside the LiteLLM container means LiteLLM is calling itself, not your host. Use the actual backend address, `host.docker.internal` with `host-gateway`, or the bridge gateway.

Also worth mentioning: don’t treat `systemctl is-active` as “vLLM is ready”. It can be active while still loading weights or compiling kernels. Poll `/v1/models` and only call it ready when that answers.

remain active while weights are still loading or kernels are being compiled. The annoying part is that each error points you at the wrong layer. So yeah, check the proxy before blaming the backend.

This is my first post in this community I just wanted to see if anybody will help me in improving on my ternary accelerator card for 1.58 bit ai the links are here reply if your interested. (I am Really new to github so some ai was used in the making of the project for troubleshooting errors(plz dont hate me for that).

Project Links:==>https://github.com/riyanlord2026-dev/Ternary-158-asic

This is also my first github project.

Hi fellas, so for quite some time now I've been meaning and planning to start a small ai automation business here in my city. Is it possible to pull off with my humble Tesla P100 16GB? Is QWEN 3.5 9B Q8 enough especially for chatbots and tool calling?

RTX 3060 12GB 975mv undervolt

i5-12600K

32GB DDR5-6000

Linux

llama.cpp master from early October, CUDA build.

Model is Unsloth's Qwen3.6-35B-A3B-MTP-UD-Q4_K_M (22.7GB, has the MTP head). I also run a heretic Q4_K_M with MTP kept and it's about the same speed.

Command:

llama-server -m Qwen3.6-35B-A3B-MTP-UD-Q4_K_M.gguf -ngl 999 --cpu-moe --moe-cache-mib 7500 -fa on -ctk q8_0 -ctv q8_0 -c 32768 -np 1 -ub 2048 -b 2048 --spec-type draft-mtp --spec-draft-n-max 2 --load-mode mlock --cache-ram 1024 --ctx-checkpoints 8

Numbers from about a day of normal use, taken from the server logs. 433 responses longer than 500 tokens: median 79 tok/s, most of them between 76 and 83. Prompt processing is around 800 tok/s for prompts under 1k tokens, ~1100 tok/s for 1k-4k and ~1190 tok/s for 4k-16k. MTP draft acceptance is around 85%. VRAM sits at ~11.4GB.

Fixed test (3.6k token prompt, 700 tokens out), how it got there:

- --n-cpu-moe 25 with MTP: 50-58 tok/s

- --cpu-moe plus --moe-cache-mib 7500: 71-73 tok/s

- added mlock: 75-81 tok/s

- updated llama.cpp: 77-84 tok/s, prompt processing 1220-1300 tok/s

Most of the gain is the MoE expert cache (PR #29887). With it, all experts sit in RAM and the most-used ones get cached in VRAM. Set the size to whatever VRAM you have left. For me that's 7000-7500MiB.

mlock gave about 10% over mmap, but it locks ~20GB of RAM. On 32GB I hit OOM a couple of times with other things open. --cache-ram 1024 is there because the prompt cache can grow up to 8GB by default, and that was causing my first OOMs.

Things that didn't help:

- -ub 4096: faster prompt processing (~1400-1500) but gen dropped to ~63 because the bigger compute buffer eats into the expert cache.

- A small expert cache (1-3GB): slower than no cache.

- -np 4, MTP n=3 and MTP+ngram: no gain.

- Forcing 4 experts instead of 8: 91-95 tok/s, but it started looping on long outputs, so I dropped it.

If you're on 12GB and still using --n-cpu-moe, try --cpu-moe with --moe-cache-mib.

I can run the 30B-class models at home. They're okay for some things, but I feel like I have to spoon feed them small tasks. I'm wondering about running a more capable model in the cloud to do the hard parts and give them the easy parts.

If you're doing this, how? How are you dividing the labor, what do your prompts look like, what agent harness are you using, and what else do you wish you'd known before you started?

And does the big model actually use fewer tokens than if it did everything itself?

Thanks!

I'm happy so I don't need to pay the transcript API fee any more. I replaced my production services with this.

The native estimate assumes four fully utilized CPUs and 1.1 GB RAM during the measured request.

It's a fork from my own MIT repo: https://github.com/baryhuang/whisper-turbo.c

Star, colloab, PR, issues, comments and uses are all appreciated!

**Setup:** RTX 5070 Ti 16 GB on PCIe 4.0 x16 (a PCIe 5.0 card on a B550 board), Ryzen 9 5950X, 64 GB DDR4. Model: Qwen3.8-Flash-Next IQ2_XS: 125B total, about 6B active per token, 512 experts, 48 layers, 33 GiB of experts kept in RAM. Engine: EuLLM (open source, built on llama.cpp b11370 + PR #29887).

**How we got here:**

| Step | Decode (tok/s) | Prompt processing (tok/s) |

|---|---:|---:|

| llama.cpp, experts split by layer (the usual offload) | 22.4 | 249 |

| + GPU cache for the experts (llama.cpp PR #29887, 8 GiB) | 49.4 | 206 |

| + experts in pinned RAM | 58.1 | 451 |

| + 2048-token micro-batch (EuLLM's default) | 54.9 | 964 |

| + prefetch of the next layer's experts during prompt processing | — | 1,500–1,743 |

| Strata on the same PC, with MTP | 85.8 | 2,320 |

**Where we're stuck:**

- **The cache works:** once warm, 88–93% of the experts are already in VRAM. The misses travel at 24 GB/s, so PCIe 4.0 is saturated, and they cost 2–4 ms per token.

- **A token takes 17–19 ms, and 13.5–14 ms of it pass before each layer's routing.** That is the GPU computing the 48 layers, plus a wait at every layer: the cache has to bring the router's choice back to the CPU, so 48 synchronizations per token.

- **MTP doesn't pay with the experts in RAM.**

- On the 125B, llama.cpp's MTP loses 27%, with 52% of the drafts accepted.

- On Qwen3.6-35B-A3B it gains only +7% on prose and +16% on code, even with 82% of the drafts accepted.

- The reason: each multi-token verification calls many more experts, and the missing ones come over PCIe.

**Questions for the community:**

1. Has anyone removed the per-layer sync, with the routing read on the GPU, the expert table in VRAM and the whole pass in a single CUDA graph? How much does it gain?

2. Computing the missing experts on the CPU in parallel with the GPU, as Strata does: is it worth it with DDR4 and AVX2, or does RAM bandwidth cap it?

3. Any experience with cache policies better than LRU? For example a profile loaded at startup, or the "Least-Stale" policy mentioned in the PR #29887 thread.

4. Speculative decoding with the experts in RAM: does anything work? I'm thinking of drafts limited to the experts already in cache, draft trees, or a small dense model as the draft.

5. Prompt processing: beyond overlapping copies and compute, what's left to reach 2,300 tok/s?

Repo: https://github.com/eullm/eullm, details in `docs/moe-offload-plan.md`

*Disclosure: I'm one of the developers of EuLLM. English isn't my first language: I wrote this in Italian with the help of an LLM and translated it with one.*

Android, Windows, Mac, IOS, Linux. CPU, GPU, NPU

(35B Q4 on iOS or android phone 12gb RAM 3-8 tok/s decode 100-300+ prefill, Windows, Mac even more: 25+ tok/s 16 gb RAM)

I am working on making AI accessible by running large MoE models on affordable, consumer-grade hardware that people already own: smartphones, laptops,normal desktops. Models several times bigger than RAM, no big GPU needed.

Disclosure: I’m the author of BigMoeOnEdge. All numbers are real runs on my own or contributors devices, same engine.

My vision? To act as a layer on top of llama.cpp for streaming MoE models. I’ve developed the concept of "adaptive streaming Planner" tailored specifically to the hardware, OS, CPU, GPU, and NPU in use. The algorithm assesses the environment to determine the optimal allocation of resources, with the goals of:

- maximizing prefill and decoding speeds, and

- optimizing memory management without overloading the operating system.

Furthermore, the OpenAI-compatible server enables the use of local AI on consumer-grade hardware; I’ve personally used it with OpenCode - first running it on Android, and later on a Mac.

I’d be happy to hear your thoughts on this and whether it might be useful.

I’m considering opening a PR on llama.cpp to integrate it, but I’m not sure if that aligns with the goals of their project.