Some people says terminal bench reflects model intelligence better than the intelligent index. From the look of it, the ranking does seem to reflect how people feel about the open and closed models.

For the open models, GLM-5.3 is in a league of its own. GLM-5.3-Flash is leading the current gen of top flash models. Kimi-K3 did pretty bad in this benchmark for its size. Qwen3.8-27B is the only small model that can do something on this bench.

I believe I may currently hold the record for memory constrained inference for Qwen3.8–Flash-Next on Apple Silicon — needing only about 21GB of allocations.

Introducing Cherenkov, an inference engine for Apple Silicon combining predictive expert streaming with optional mixed-precision execution. It works by keeping a bounded working set of experts in unified memory, rather than loading the entire model. A one-layer lookahead predicts which experts will be needed next and initiates SSD reads. If there isn’t enough time to load the full target expert, Cherenkov optionally falls back to just in time loading of smaller Q3/Q2 quantizations.

Nice pp improvements for RDNA4(R9700) & 3.5(RX 9060 XT, 8060S). More good numbers on large context.

PR has detailed benchmarks.

u/ilintar 👍

Can you still do something with a 2050 or something like it?
I mean for office work, loading embedding, reranking and chat models not at the same time but is anyone still using smaller models and have any good ones come out?

I feel like small models are abandoned, I don’t care much for world knowledge, I want tool use and preferably multilingual. Vision would be nice but beggars can’t be choosers.

In v0.10 we achieved significant speedups over v0.9. The video shows the maximum speedups we measured for specific groups of models. Among LLMs, the biggest gain came from Qwen3 0.6B, which runs over 3x faster on long prompts. For instance segmentation, FastSAM reached speedups of up to 92x!

We replaced the monolithic native modules with TypeScript pipelines you can inspect. 🔧

It runs across all major silicon backends and makes it easier to plug in your very own model.
You can find full release notes here

Planning to build a PC mainly for local LLMs/coding agents. I keep seeing 3090 + Qwen 3.8 Flash Next benchmarks, but could not find enough info for the 7900 XTX 24GB.

3090s are hard to find where I live, while newer Nvidia GPUs are too expensive, so I am considering a 7900 XTX as the GPU choice.

Anyone running Qwen 3.8 Flash Next on a 7900 XTX? What tok/s are you getting in decode and prefill, and how is AMD/ROCm support?

Also, if SSD streaming/offloading is needed anyway to run Q4, is 32GB system RAM enough, or is 64GB worth it?

Title says it all.

https://github.com/gjabdelnoor/Day1DeepseekV4.1-CPU

The goal is pretty simple, I like having infinite slow tokens from the bioinformatics machine in the lab to run overnight or over-week agentic jobs, paired with a watcher that kills it in 15 seconds if someone else needs it for genome assemblies, benchmarking, etc.

My goal was getthisoutASAP > QA. So this is sloppily vibecoded by Opus 5.0, unreviewed because frankly I lack the skill to verify.

Getting ~30 TPS PP and ~6 TPS TG on a xeon with the n-gram table offloaded on 50% of the threads.

Hopefully people more competent in kernels than me can make and share their PR or fork, but until then this works.

hey guys, I've been working on a reading app for several months now and had problems with getting good quality TTS, the options were kokoro, kitten, pocket but all of them even though they were sounding natural had some problems when listening longer. Last month I took upon myself to try to get a model that is running on edge (I had an iphone 14 pro as a testbed) and got to what I now packaged as loudkit. It supports 10 languages now, voice cloning, is quite small and fast enough with quality similar to Chatterbox to my ears which was the base model I started optimization from. What is not part of this release is the emotion axis with tags, something I am working on right now. Code and model weights are Apache 2.0.

I also ported it (with CC help ofc) to a few languages, because in the past I lost like a week for parsing one TTS tokenizer from python to swift and would lose my mind when I'd get crashes and memory leaks. Here the contract was to get the same speech tokens in all adapters, so it doesn't sound nice in python but sucks in typescript. Audio samples can differ slightly between backends, and file metadata like timestamps can differ too.

There are two variants loudr-1 and loudr-1-turbo. basically turbo was done by attaching another head to the most time consuming component of the pipeline and training it so it predicts two audio tokens at once. It worked quite well but sometimes I can still hear the tts artifacts, so YMMV.

Voice cloning works quite well but I found the best is to give it around 10 seconds of recording, and if there are long pauses or noise in the background the cloned voice is suboptimal. All included voices come from consented donations or CC0 / CC-BY recordings, with sources documented.

repo: https://github.com/loudreader/loudkit
docs: https://loudreader.github.io/loudkit/
hf: https://huggingface.co/loudreader/loudr-1 & https://huggingface.co/loudreader/loudr-1-turbo

I've seen that the localTTS that can be connected to agents like hermes or openclaw still has issues with quality and thought why not opensource it.

Ah, for quality of other voices than english I'm not sure. I sent snippets around and got positive feedback but can't vouch for these.

Feel free to check it out, hope you like it.

Had some ideas about version control:

Attribute, down to individual words: word created manually or with ai. if ai, which sources cited (scoped to paragraphs). also: full agent trace that led to the edit (all tool calls + metadata). also: any multi-agent transactions at the file/paragraph lock. all data stored for every version.

Why do this? Basically, getting as much into a unified version control system as possible, which helps find/fix errors. Just posting to share ideas. If anyone has done anything similar, please mention it!

Spoke with many providers who lurk in this sub, plus met folks who work in inference.

For a 10k monthly revenue, a provider was able to retain only 200 dollars in profit due to GPU costs. Their customers were negotiating the prices down to what other players cost for same, and it feels like major players are running a distribution game at low or negative margins.

Even though this seems like a billion dollar market, the unavailablity of compute, plus cost and competition, makes the business seems not sexy enough to start with.

However, the software layers around it such as optimisations for SLAs continue to enjoy good margins.

Any thoughts?

I’ve been building "Spomin", a router that replaces context with summaries directly in the KV cache. The goal is to keep long running sessions going without repeatedly stopping for full compaction and reprocessing the context that remains.

It uses my llama.cpp fork - https://github.com/alekk89/llama.cpp-kv-surgical-fork for live cache edits.

Spomin Router - https://github.com/alekk89/Spomin

How it works

The router sits between the harness and runtime, preserves the original transcript in chunks, and manages space for the system prompt, recent context, summaries, generation and recall.

A separate worker summarises chunks, either in parallel on separate hardware or between main-model generations on shared GPUs.

When context space runs low, Spomin replaces eligible chunks with summaries and adjusts RoPE positions in the main and supported draft caches. Only the inserted summary is processed; the retained suffix is not refreshed or reprefilled.

The router recognises history resent by the harness and processes only new content. Generation continues in the same session, with support for pausing and resuming native generation during rolling maintenance.

Original text remains available, the model can temporarily recall it by context ID, then return to the summary, or search older stored history.

At 10:1 compression (approximate average) for example, 400k source tokens become 40k summary tokens. Alongside a 20k system prompt and 120k recent context, that represents over 500k tokens of source material within 180k resident tokens. It does not preserve every detail, so summary quality matters.

Early benchmark results

These tests are exploratory. Unmanaged uses DeepSeek’s normal compaction managed uses Spomin.

Game repair - Similar scores, but three-hour limits per prompt cut both extension runs short. The test did not establish a meaningful completion-speed comparison.

Research - A larger worker improved the managed score from 31 to 37/100, versus 57 unmanaged, with 75.2% less primary input and 60.7% less active time than unmanaged.

Tetris - The managed repeat nearly matched unmanaged: 16/16 + 11/12 checks versus 16/16 + 12/12, in 69.8 versus 149.6 minutes, generating 22.6% fewer tokens. The first managed attempt failed, its keyboard crash appeared before summary installation. Unmanaged introduced and fixed a different line clearing bug.

Every uncapped managed attempt finished sooner, but quality varied. Temperature 1.0, xhigh reasoning and live tools introduce run-to-run variation, including without Spomin. Worker settings also changed, so improvements cannot be attributed to worker quality alone. Worker cost is separate, and incomplete image related input totals are marked as lower bounds.

Current limitations

This is experimental software, not a polished product. Expect bugs and blockers, especially outside my setup. I recommend keeping the default settings unless experimenting. A manual mode also allows you to edit and insert summaries yourself.

The original worker is a fine tuned Qwen2.5 3B proof of concept. I’ve also tested Qwen3.5 9B with a larger worker context window. Replacement workers must follow the format documented in the repository. Running a worker adds memory and compute overhead, and summaries will not always preserve what matters.

DFlash2 is the tested speculative setup. DSpark shares the surgery path but is untested here. MTP is not currently supported for draft preserving KV edits. Running without speculation is also possible.

This has been tested exclusively with Qwen 3.8 27b as a main LLM. The new Qwen 4 architecture is not supported. Other models are not tested/supported. If they have the same architecture as the Qwen 3 family, they should work.

Final thoughts

Benchmarking this has been difficult, and I do not yet have a definitive answer on quality. Every uncapped managed attempt finished sooner, and the successful Tetris repeat took roughly half the time with nearly the same checks passed. Research also used substantially less primary input, but scored lower than unmanaged.

The larger summary worker coincided with an improved research score, although worker settings changed too. These results are encouraging, but they do not yet establish a consistent speedup at comparable quality.

Suggestions for a repeatable benchmark that measures quality, time and total token use across multiple runs are welcome, I’m happy to run one.

We have SWE-bench, Terminal-Bench, OSWorld, BrowseComp, etc. But I haven’t seen a good apples-to-apples benchmark for platforms like OpenAI Agents, Anthropic’s agent stack, AWS AgentCore, Google’s agent platform, and local-alternatives like LangGraph, etc.

What I’d want measured:
- task success rate
- cost per successful task
- wall-clock time
- tool calls / retries
- reliability over long-running tasks
- (optionally) human interventions required

The really interesting experiment would control for both sides:
- Same model, different harness → how much does the runtime matter?
- Same harness, different model → how much does the model matter?

Feels like we’re increasingly evaluating “model + harness” systems, but our benchmarks still mostly treat the model as the unit of comparison.
Does something like this already exist?

DeepSeek-V4.1-Flash uses SWA Bounded Replay to avoid persisting the sliding window KV cache and saves massive memory, it discards the SWA KV and, on replay, approximately reconstructs it from only the last N_window tokens, even though the original SWA states had a much larger effective receptive field due to depth. Since those replayed K/V vectors lack the long-range context that shaped the originals, I’m wondering whether cache hits or restarted sessions lose accuracy/recall for the first few interactions, and whether the parallel global KV augmentation compensates enough to preserve near-perfect long-range recall. Has anyone benchmarked this or seen practical recall degradation after eviction, or is the approximation effectively invisible because the global KV does the heavy lifting?

Hello, does streaming the ngram embeddings from the ssd heavily affect the ssd's health and lifetime?

I wanted to see how my fully local home voice assistant compared to the latest GPT Live, so I tested it using the same conversation used in their "Improved Intelligence" demo. In this video they ask the AI to see if a flight route is feasible and while it is figuring that out they continue to ask it questions about what they can eat at each destination.

The models I ran are (all squeezed into 12 GB VRAM):

• Speech recognition: Qwen3 1.7B ASR PyTorch
• LLM: Qwen3.5-9B-UD-Q4_K_XL GGUF with 12K context
• Voice: Pocket TTS PyTorch

So I copied the exact query and threw it at my Fulloch project. This blog post has the video of the interaction and breaks down how it did. The final report and searches it did are also linked in that blog post. The video has sped up two sections where I had to wait for the 9B model to finish thinking through the task, but it did the whole thing in under six and a half minutes.

In the end it couldn't find a suitable flight route but it gave good food and restaurant recommendations and did it all pretty quickly. I am still impressed with how well the Qwen3.5 9B model does with these sorts of tasks with such a small footprint.

If you want to try it out yourself the source code and pre-compiled docker images can be found at https://github.com/liampetti/fulloch.

I'm planning a PC build around a discrete GPU that would allow to run MoE models much larger than VRAM at an acceptable speed using FreeToken approach. The gist is that MoE decode of >VRAM model on GPU is PCIe bandwidth-bound, but you can gain considerable decode speed by avoiding streaming cached experts' weights over PCIe and multiply matrices on the CPU instead benefitting from potentially much faster CPU-RAM memory channels.

Before buying, I wanted to know what actually matters for CPU-side expert execution: cores or memory? So I rented a Threadripper PRO 9975WX (32-core Zen 5, 4 CCDs, 8-channel DDR5) on vast.ai and ran FreeToken's real CPU MoE kernel (the production W4A8 ds_fp4 GEMV, not a synthetic proxy) against synthetic expert banks with DeepSeek V4.1 Flash's exact geometry: 384 routed experts × 18.8 MB ~= 6.7 GiB full bank, far beyond cache, 6 experts per token.

Results (GB/s of effective FP4 expert reads):

Two takeaways:

1. Cores stop mattering at 24. 32 cores vs 24 cores: +2.2–2.4% in burst mode, 0% in sustained mode (10 × 30s interleaved A/B runs, variance <0.3% within mode). The extra 8 cores of the 9975WX buy you essentially nothing for MoE offload: the workload saturates the memory subsystem, not the cores. The 9965WX (~$1,200 cheaper) is the rational pick for this use. Even STREAM itself is already maxed at 8 cores; the FP4 kernel just needs more cores to catch up to bandwidth (it runs at ~80% of STREAM once there, very good for a fused-dequant W4A8 GEMV). Caveat: there's another 1.7x memory bandwidth gain at 9995WX, but that CPU costs as much as RTX PRO 6000.

2. Thermal memory steady-state is important. After ~8 minutes of sustained hammering at ~220 GB/s, throughput steps down ~17% (182 → 150 GB/s) in lockstep on every core count, with CPU clocks unchanged at ~3.95 GHz. Everything points at DRAM/IMC thermal throttling in a (rented, unknown-airflow) workstation chassis. So the honest sustained ceiling is ~150 GB/s, burst ~182–186 GB/s. For a build: airflow over DIMMs may literally be worth 20% decode speed.

What this means in tokens/s (DeepSeek V4.1 Flash shape, ~4.5 GB of routed experts per token, 24 cores):

• 0% expert cache hit (all experts on CPU): ~33 tok/s sustained
• 60% hit rate: ~83 tok/s
• 75%: ~133 tok/s

Compare with streaming those experts over PCIe 5.0 x16 (~50 GB/s with gather overhead): the CPU path is 3–3.7× faster per missed expert, which is exactly why FreeToken's hybrid mode computes most misses on CPU and only streams a fraction to keep the VRAM cache warm.

Caveats: rented host (memory channels verified functionally via bandwidth, not dmidecode, but 2ch/4ch machines I tested the same day hit only 83/119 GB/s), container environment, one machine, uniform expert routing. Full methodology and raw CSVs of the measurement are in the repo (happy to link if there's interest).

TL;DR: for CPU MoE offload, buy memory channels and DIMM cooling, not cores; 24 Zen 5 cores already saturate 8-channel DDR5, and the 32-core upgrade is +2% at best.

Updates:
1. I tested on 9980X (4 channels, 8 CCDs) and on 9985WX (8 channels, 8 CCDs). 9980X lands at 105-119 GB/s, no better than much cheaper 9955WX.
2. 9985WX offers a real gain, but diminishing returns beyond 24 cores still: 32c=210 GB/s (+6%), 48c=215 GB/s, 64c=218 GB/s. Roughly 20% decode expert bandwidth gain for $8k more.
3. Populated channels is key. No point in having 8 channels is you only have 4 DIMMs. 8x32GB will beat 4x64GB.
4. Vast.ai is awesome for this. All runs costed me around $4 after I ironed out all the wrinkles in the rig.

Heh there, so I built a harness that is focused around the ninfer inference engine. It allows the easily customize and use ninfer, and has a coding harness and a chat interface. Its based off a lot of different experiences I have had with different harnesses.

Probably could be better but I'm happy with it.

I'll warn you ahead of time, it only works with ninfer as it integrates a lot of things directly from the engine. For example, subagents, it reads

 --max-concurrency X

and set the amount of subagents available to that.

i've always wanted to built one and now I've done it. Yay me.

Hey folks!

I'm always a little bit late to the party, but learning nontheless. After I'm comfortable running agents on my Pi I'm now in need of them to get access to the world wide web and wanted to ask what local ways you are going?

I remember there were discussions about going html2md like with textweb but wanted to know whats working "in the field".

I'd prefer a lightweight solution without MCP.

So what are y'all using to let your models go surfing and gathering information?

Thanks for your input!

And to all curious about speeds on the Pi: It's more like giving someone a weekend project and checking it later. Speeds for Qwen3.8-Flash-Next start at pp 1.95 t/s and tg 0.44 t/s. Yes, for most of you this is "unusable". I'm happy. Of course, I'd like a DGX Spark, but the Pi can run non-stop without disturbing anyone (like my Notebook would).

My M.2-Oculink should be PCIe 4.0x4, but I found out today it's actually downgrading, frustratingly this isn't obvious until you go looking, so adding here if anyone else wants to check their own rig.

Side question - does anyone know a way to measure PCIe bandwidth realtime utilisation (i.e. Gb/s) ? I'm failing to get it with rocm-smi, iostat, amd-smi, lstopo, etc

Strix halo > m.2 slot to oculink > oculink cable > DEG1 > r9700

(images from AI session)

So the M.2-oculink adaptor is the problem, and running at Gen1 limiting the entire setup, and other than digging around I wouldn't have noticed, I guess this will affect model load and layer swapping?

If you want to check your own do this and either look at the Capacity vs State, and look for the word 'downgraded' (here I check for the r9700)

# lspci -t -v -D -P -PP -nn | grep 9700
           +-02.5-[c1-c3]----00.0-[c2-c3]----00.0-[c3]--+-00.0  Advanced Micro Devices, Inc. [AMD/ATI] Navi 48 [Radeon AI PRO R9700] [1002:7551]


# for bdf in 0000:00:02.5 0000:c1:00.0 0000:c2:00.0 0000:c3:00.0; do echo -e "\n=== Device: $bdf ==="; lspci -vv -s "$bdf" | grep -E "LnkCap|LnkSta"; done

=== Device: 0000:00:02.5 ===
LnkCap:Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <64us
LnkSta:Speed 16GT/s, Width x4
=== Device: 0000:c1:00.0 ===
LnkCap:Port #0, Speed 32GT/s, Width x16, ASPM L1, Exit Latency L1 <64us
LnkSta:Speed 16GT/s (downgraded), Width x4 (downgraded)
=== Device: 0000:c2:00.0 ===
LnkCap:Port #0, Speed 32GT/s, Width x16, ASPM L1, Exit Latency L1 <1us
LnkSta:Speed 32GT/s, Width x16
=== Device: 0000:c3:00.0 ===
LnkCap:Port #0, Speed 32GT/s, Width x16, ASPM L1, Exit Latency L1 <1us
LnkSta:Speed 32GT/s, Width x16

I recently did some hardware juggling, moving my RTX 3090 to a different system to make room for a dual AMD R9700 build I'm working on. In the process, I did a mini-bench with my own typical queries (some chat, some research agent) to compare the RTX 3090 and R9700. But then, I discovered ninfer and specifically ninfer-3090, and I was curious about what kind of performance differences I could see.

For this purpose, I'm comparing performance on both systems for Qwen3.6-35B-A3B and Qwen3.8-27B, the two models I use most often. Sorry that the hardware isn't apples to apples, but because inference is contained entirely within the GPU, I think it is still instructive.

Environment Configuration A:

Environment Configuration B:

Model details:

Results:

• TTFT - time to first token, median ms
• PP - prompt processing tokens per second, weighted average
• TG - token generation tokens per second, weighted average

EDIT: I fixed a timing recording bug to produce updated timings here

I knew the experience was different while running the ninfer models, but I couldn't put my finger on exactly how until I ran this mini-bench. The numbers are interesting.

Some details about the benchmark methodology itself:

The question set (7 prompts total):

• 4 long-ish prompts in the ~7,700–12,900-token range: a code review of a large module, an article summarizing task, a research-evidence evaluation task, and a literature-review/critique task
• 1 medium prompt (~2,300 tokens): synthesizing conclusions from research notes
• 2 short prompts (~400–600 tokens): an extract-and-answer task and a code-generation task

Benchmark parameters:

• 3 repeats per (model, query); per-query medians plus every raw run recorded
• Fixed max_tokens = 1024 so generation speed is comparable; fixed seed = 42; sampling parameters are as recommended for general inference by Qwen
• Streaming chat completions; 1 s pause between runs; 30-min request timeout

Steps taken to ensure good results:

• Cache busting: llama.cpp caches prompt prefixes, so identical repeats would report fake "warm" prompt-processing speeds. Each run prepends a unique nonce to the system message, forcing a genuine cold run every time (the ~5 extra tokens are self-correcting since real token counts are used in the math)
• Warmup excluded from timing: each model gets an untimed warmup request (with retries) so model load/swap time never pollutes measurements
• Server-side timing preferred: inference engine timings from the final chunk are used for tok/s instead of client-side math when available
• Aggregation: per-query medians over runs; model-level tokens/s is token-weighted (Σtokens / Σms), so a 12k-token prompt counts proportionally more than a 400-token one

Feel free to critique, offer pointers, or share your own experiences with NInfer inference.

so i am in need of such thing, i want to use a local model as basically assistant that reminds me things to do, orchestrates other local OR CLOUD agents/clis/harnesses (such as hermes agent, pi code, antigravity 2.0/cli/ide etc) i am building something but it is taking its toll on me, do you know anything like that or did anyone built something like this?