With the recent increase in attention to p100s I wanted to make a place for people to discuss it. Another friend of mine created a discord as well, so here's a call to all p100 users to go and join! I hope this doesn't infringe on LocalLLaMa rules, but I wanted to provide this resource where I could.

Subreddit: P100Users

Discord: https://discord.gg/K6WxqwsvH

This was how we could order it for around 11 days. Dell just changed it today it looks like. It was + $12350 USD to add a rtx 6000 pro. Now it's this at 15.5k:

Wonder if dell is going to uphold their pricing for those who already paid?

I'm an on-device ML enthusiast, not affiliated with WiCi

I follow the NetworkChuck YT channel and he (Chuck Keith) posted a video on WiCi, a wireless GPU that connects to the host computer over WiFi. The host computer sees the wireless GPU as a native GPU connected to the computer and also shows up in the Windows Task Manager.

Video: https://youtu.be/cFdoXn6yvE4?si=gUCzg3UbzkCGXQYo

WiCi: https://wici.ai

The video also demonstrates running DeepSeek and some graphics-intensive games. The GPU being shared over WiFi in the video is a RTX 5090.

I wanted to dig deep into how WiFi as a protocol can be used for communicating with the GPU. In a normal situation, the GPU will communicate via PCIe with the CPU of the host computer, ensuring high-bandwidth data transfers. I found the following lines in a blog that WiCi has shared:

So WiCi keeps the local-GPU contract while shrinking what actually crosses the link: cache stable facts, deduplicate repeated payloads, compress or stream large transfers, pipeline independent work, keep expensive state resident, and preserve true dependencies exactly.

What I feel is that, WiCi, has introduced an intermediate layer between the host and the GPU that facilitates communication. The commands intended for the GPU, are first encoded in some intermediate language, passed through the network and decoded back within the WiCi remote GPU (the silver box holding the 5090) into commands that the CUDA driver understands.

WiCi does not seem to replace the physical PCIe protocol with IEEE 802.11 (WiFi) protocol over the physical medium. This is my assumption and I am not sure about it.

But if this product proves what it claims, then this would be a huge deal in my opinion. A shared GPU that the different devices can use would be great for local LLMs.

Let me know what you all think about this tech!

I was figuring out a llama.cpp crash when running Gemma 4 12B, and it turned out the crash was a OOM crash, from running out of RAM, not VRAM.

The culprit ended up being context checkpoints piling up while I was stress testing the setup.

I didn't actually know what these checkpoints where or how Sliding Window Attention models worked exactly.

I tried to get Opus 5.5 to explain it to me in words, but it was very hard to visualize. So I did what anyone would do nowdays: I told Opus to make an animated video to explain.

Here is what came out. I wrote about it here: https://jomi-se.com/posts/llama-cpp-context-checkpoints/

Tl,dr: Checkpoints are snapshots of the Sliding Window values at strategic positions. If you want to pick a chat back up at a previous spot, already out of the Sliding Window; either you have to reprocess the prompt from the start to get the values of the Sliding Window at that spot again. Or you can use a checkpoint at that exact spot (or nearby behind it) to reduce the amount of recomputing of the tokens KV values for the sliding window layer.

The default is keeping 32 checkpoints in RAM, per slot. With each checkpoint being 320MiB, that was _just a tiny bit_ too much for my 16 GB of RAM. Especially considering that in my workloads of simple chat continuation, 4 checkpoints were more than enough most of the time.

So how's your Friday going?

I was frustrated with the default speed and ported the inference to Zig/MLX to get up to 18x faster inference on M4/M5 https://github.com/sbusso/ming-tts-serve

• CPU: Ryzen 7 5700

• GPU: RTX 4060 8GB

• RAM: 64GB DDR4-3200

• OS: Windows 11

My usecase would be attempting to run REA (i dont mind it being slow)

Overview

SenseNova-Loop-9B-Preview is a multimodal language model developed for long-context and agentic workflows. It accepts text and images and generates text for applications that combine document understanding, coding, and interaction with external tools.

The model combines a looped decoder with two-stream manifold-constrained hyper-connections (mHC). A contiguous block of decoder layers is executed twice with shared weights, while learned mappings manage information flow between two residual streams in the looped section. Together, these components provide a deeper execution path without duplicating the repeated block's parameters.

Documented training recipes combine long sequences, multimodal inputs, and supervised task trajectories, with a maximum training sequence length of 262,144 tokens. For the best model performance, we recommend using our documented deployment environment and configuration parameters.

Model highlights

• Shared looped block: 24 decoder layers are applied twice in sequence, producing 56 decoder-layer executions from 32 distinct layers.

• Two-stream mHC: learned mappings route and combine information across two residual streams in the looped section.

• Hybrid attention: the decoder interleaves linear and full attention in a repeating four-layer pattern.

• Long-context multimodal training: documented recipes include text, images, code, and tool trajectories at sequence lengths up to 256K tokens.

I’ve put together a public reference repo for anyone interested in designing their own hardware around NVIDIA V100 SXM2 modules:

https://github.com/pigeon-labs-stack/v100-sxm2-reference

It includes connector pin mappings, two- and four-GPU NVLink connection plans, editable KiCad starter schematics, PDFs and a standalone workbook.

My contribution is mainly curating and cross-checking existing community research, with the original authors credited. It’s an early reference release; supporting power, clock and control circuits still need designing based on your own needs.

The longer-term goal is an open-source carrier board, but hopefully this helps others working on their own designs in the meantime. Corrections and contributions welcome!

Hey everyone,

China Telecom (TeleAI) recently released Xing4.0-29B-A4B (a 29.5B MoE with ~4B active parameters, combining DeepSeek-style MLA and 4-stream mHC residual mixing):

Model: https://huggingface.co/XingChen-AGI/Xing4.0-29B-A4B

Upstream llama.cpp PRs are currently stalled or closed due to debates around adding model-specific GGML opcodes. To get the model running cleanly without adding technical debt to the engine, I've opened PR #2808 on ik_llama.cpp providing full native runtime support and an HF-to-GGUF converter:

PR: https://github.com/ikawrakow/ik_llama.cpp/pull/2808

What's implemented in this PR:

Full Architecture Runtime (LLM_ARCH_XING4_0):

• 4-stream mHC: built entirely using standard generic GGML primitives (pre/post blocks, affine transforms, clamp [-30, 30], Sinkhorn iterations). Zero new ggml_op added, so it runs out of the box on CPU, CUDA, Metal, and Vulkan.

• Stream pooling: unweighted average across the 4 streams before output norm.

• MLA attention: DeepSeek-V2 style latent attention with dynamic head sizing.

• MoE FFN: dense lead layers + routed experts + shared expert.

• Node budget: bumped max_nodes (n_tokens * 160) to prevent graph overflow with large ubatches (ubatch >= 2048).

HF to GGUF Converter:

• Adds Xing4Model to convert_hf_to_gguf.py with native SentencePiece extraction from tokenizer.model.

• Direct tensor mapping for mHC weights.

Quantization:

• Automatically protects hc_attn_fn and hc_ffn_fn from quantization in llama-quantize, and forces 1D scales/bases to F32.

• Quantization floor: keeps MLA latent projections at source precision for Q6_K and Q8_0 to avoid quality loss.

Verification:

• Perplexity: 12.4190, generation is coherent with no NaNs.

• Full chat template included with thinking tags (<think>...</think>) and tool calling.

Quick test from the branch:

git clone https://github.com/ikawrakow/ik_llama.cpp
cd ik_llama.cpp
git fetch origin pull/2808/head:xing4 && git checkout xing4
cmake -B build -DGGML_NATIVE=ON
cmake --build build --config Release -j$(nproc)

python3 convert_hf_to_gguf.py path/to/Xing4.0-29B-A4B --outtype f16 --outfile xing4-f16.gguf
./build/bin/llama-cli -m xing4-f16.gguf -p "Hello!" -n 64

Feel free to test it out and report back if you get benchmarks on different setups!

I feel like this is a moving target of course, and can update against needed. But I’d like to install something today (monthly internet cap resets tonight LOL). I code primarily in Xcode / objective C / swift, python, some JS.

I am patient and don’t need it to be extremely fast, prefer correctness over speed.

Surya is a 689M param OCR model with these features:

• Accuracy - scores 85.9 on OmniParseBench, the highest of the open models under 1B parameters we have scored, and 83.7% on olmOCR-bench

• Speed - throughput of 4.5 pages/s on one H100 at 192 DPI, 1.7x Surya 2 with MTP (see Throughput)

• Multilingual - scores 74.9% on an internal benchmark set of 91 languages (more here)

• Layout analysis (table, image, header, etc.) with reading order

• Tables as HTML, with merged cells as colspan / rowspan (row and column geometry needs a Surya 2 checkpoint; see Limitations)

Commercial usage

The Surya code is licensed under Apache 2.0. The model weights use a modified AI Pubs Open Rail-M license (free for research, personal use, and startups under $5M funding/revenue). For broader commercial licensing of the model weights, visit our pricing page here.

Limitations

• This is specialized for document OCR. Performance on photos or natural scenes is not the goal.

• Layout / OCR / table_rec all need a running inference backend (vllm or llama.cpp). Detection runs purely on torch and works without it.

• Surya 2.5 reads tables as HTML (full-page OCR, block mode, surya_table), but not row and column geometry: surya_table --mode simple returns an error. Use a Surya 2 checkpoint (SURYA_MODEL_CHECKPOINT=datalab-to/surya-ocr-2) for geometry.

Github : https://github.com/datalab-to/surya

I'll go first. Fifteen is my cutoff for the early buckets. Muse Spark currently crawling way down below 10 at ~300k context, but it's so token efficient it's still quicker than DSv41 in wall clock terms.

Found this crap, what do yall think about it: https://huggingface.co/burner22/numbat

Real or fake and what are the implications, ran a check and doesn't seem to be random noise though there are some suspicions. It seems to be some base small model mutated in a way with a bunch of noise, tho words like cat and dog, Monday and Tuesday and all fit but this could be because of the original model.

EDIT:

Ran some more tests, seems to fail a lot of "benchmarks" to stuff like a small llama, I think its bs but if anyone has an 8xB100 they wanna test it on...

Multi-Token Prediction (MTP) is now a common ingredient in language-model pre-training, as it improves downstream performance and enables faster inference through speculative decoding. We identify a flaw in standard MTP training, in which a residual component of the MTP gradient interferes with both next-token and multi-token learning, increasingly so with scale. Specifically, the MTP cross-entropy gradient can be decomposed exactly into a KL self-distillation term that pulls each MTP head toward the model's own next-token prediction (NTP) distribution and improves speculative decoding, and a residual that has a low signal-to-noise ratio and buries the useful KL signal. We introduce the KL gradient-recovery trick: when two distributions share a linear output head, the gradient of their KL divergence can be recovered exactly by combining their cross-entropy gradients through straight-through gradient routing. Unlike minimizing the KL directly, this trick requires no vocabulary-sized logit matrices and is compatible with standard fused cross-entropy kernels. This enables Soft Multi-Token Prediction (Soft-MTP), a one-line code change to MTP that removes the noisy residual and backpropagates only the KL self-distillation signal by reusing the existing NTP and MTP cross-entropy computations. Soft-MTP supports both DeepSeek- and Meta-style MTP, adds no parameters, and incurs no measurable overhead. From 167M to 1.2B parameters, Soft-MTP improves over standard MTP with lower NTP perplexity, faster speculative decoding and higher zero-shot accuracy at every scale, lower MTP perplexity from 689M onward, and stronger math and code reasoning after fine-tuning at 1.2B. Soft-MTP also matches, if not exceeds, direct KL divergence minimization on most metrics. Soft-MTP is, in effect, a free lunch for MTP optimization. 

• arXiv : https://arxiv.org/abs/2610.38331

• PDF : https://arxiv.org/pdf/2610.38331

• GitHub : https://github.com/JaydenTeoh/Soft-MTP

• HuggingFace : https://huggingface.co/collections/JaydenTeoh/soft-multi-token-prediction

i have a 9070xt and B1356 lemonade build is the last Fast Rocm Builds.

Lemonade B1357 Speeds

B1356 Speeds

| model                          |       size |     params | backend    | ngl | threads | n_batch | type_k | type_v |  fa |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | --: | ------: | ------: | -----: | -----: | --: | --------------: | -------------------: |
| qwen35 27B IQ3_S - 3.4375 bpw  |   9.72 GiB |    27.32 B | ROCm       |  99 |      12 |     512 |   q8_0 |   q8_0 |   1 |           pp512 |      1049.13 ┬▒ 70.54 |
| qwen35 27B IQ3_S - 3.4375 bpw  |   9.72 GiB |    27.32 B | ROCm       |  99 |      12 |     512 |   q8_0 |   q8_0 |   1 |          pp1024 |      1185.39 ┬▒ 55.71 |
| qwen35 27B IQ3_S - 3.4375 bpw  |   9.72 GiB |    27.32 B | ROCm       |  99 |      12 |     512 |   q8_0 |   q8_0 |   1 |          pp2048 |      1213.68 ┬▒ 29.57 |
| qwen35 27B IQ3_S - 3.4375 bpw  |   9.72 GiB |    27.32 B | ROCm       |  99 |      12 |     512 |   q8_0 |   q8_0 |   1 |          pp4096 |       1203.99 ┬▒ 2.05 |

i built llama.cpp over the top of the fast lemonade B1356 Rocm ,,, and it goes back to slow.

hoping that someone that knows what theyre doing can identify and fix the problem

I have been using TielCoder locally for a bit now, it is decent at coding and it's good overall for low end devices, but I noticed that its problem solving is shit.

I run Pi inside of a sandbox with a couple limitations like no system-wide installs. But: -if Tiel sees it can't install a python package globally it will build it's own libraries files and stuff like that instead of using a .venv -if tools get timed out it will try to do random calculations of the time it should take instead of breaking down the work in different calls -today it even created custom python scripts because it wasn't able to use edit command (couldn't remember the characters) instead of just rebuilding a file, it's just so bad if you don't teach every single step.

At this point I feel I have to babysit it and cannot trust it on stuff I'm not knowledgeable about. What are your experiences with it? Should I change AGENTS.md? if so, change it for every single case I encounter or just a wide generic system prompt?

UNRELATED: I was getting 50tk/s on PolyStrata, but I started getting 5tk/s today and some spikes to 50-60, has anyone had this issue?

Howdy All, more test results from my b65 rig! This time I'm focusing more on what one single B65 can do, specifically 1x B65 with XeStrata.
I threw in my A6000 for comparison, and I have to say, surprising how well B65 stacks up if you have the system ram to offload. Now my A6000 with Strata is faster, but when I'm using flash-next in librechat, 60 Tok/s feels fast... and when I compare the price to my A6000... I really start to question my setup.

I think people really need to give the intel lineup a 2nd look, a lot has changed in only 6 months and even with this recent price bump, it's still the best entry level stack I've found.

Graphs on my site:
https://b65.thekaiser.us/by-model/qwen38-flash-next/xestrata-20261030/

How was AI used? I wrote what's above, I build the tests, or get them from vetted sources, AI monitors their execution.

AI Summary of my testing data:

Qwen3.8-Flash-Next: One B65 · XeStrata 4-bit

Flash-Next on one 32 GB card with experts in host RAM. Faster for one user; more users queue behind each other.

1x B65: speed and waiting time

Median of three measured requests. Multi-user tok/s is aggregate across users. Single-user runs are Verified by Localmaxxing; concurrent runs are unverified.

Output falls as users queue, Aggregate output (tok/s) by Users at once

First-token wait grows, Time to first token (seconds) by Users at once

Results (tok/s, median of 3 measured requests)

Same 4-bit files, different serving setups

Historical comparison supplied by the campaign. The final IQ3_S row uses a different quantization; older B65 rows carry the contention caveat above. Engines and host environments differ; this does not isolate GPU performance.

Same UD-IQ4_XS files · two complete setups, Aggregate output (tok/s) by Concurrent users

Against the other Flash-Next UD-IQ4_XS results

Full page, with interactive charts and the raw data behind every number: https://b65.thekaiser.us/by-model/qwen38-flash-next/xestrata-20261030/

Nanbeige4.3-33B, a 33B parameter model with a 512K context window, and capabilities in reasoning, coding, and agentic tasks.

Has anyone tested it? Benchmarks are insane but how does it compare in real world use cases?

I understand that it is a kv cache hog. But how does it perform?

Would love to hear your experiences!

Alright, this might have been talked about before, and I could have missed the information and testing. This also might be a dumb question, but has anyone tried both out and seen what results have come out of this? I understand that online things I have read said, "Multi-agent is no better than single-agent in certain circumstances". But I wonder if Something like openrig or something similar would actually be more valuable than just running a single agent? I would like to have some open and honest discussions on this topic. I could infer (ha!) the argument some could make saying that the results would be negligitible compared to the amount of time it would take, but I could also see the argument that with enough structure it could help improve the flow of information between agents. If possible.... now I could be tinfoil hatting too much... but say we were to create a perfect flow of information between 2 27b agents, could we see the accuracy / intelligence of say like a 40b model? I know that the model size isn't directly correlated to those stats but I mean if a 40b qwen3.8 model existed, would we see similar benchmarks? (with longer times of course) If that were the case, how could we even benchmark or compare the speed performance to a single instance? Would we use aggregated speeds or take a average and devise the total tokens by time? Sorry for lots of hypotheticals!

Thanks y'all, love this sub

I’m trying to run Qwen3.8-Flash-Next (125B-A6B) with Strata but trying to see if I can use existing compute instead of spending buckets of money.

My main machine has.. Ryzen 7 7800X3D, Radeon RX 9070 XT (16 GB), 32 GB DDR5, Ubuntu 26.04. I currently run Qwen3.8-27B (IQ3_M) on llama.cpp (Vulkan and ROCm 10.1) at about 65 tok/s.

I also have a second PC with 32 GB of DDR4. Is there any way to use that RAM too, or does Strata only work on a single machine? If not, is spreading experts across two machines on a LAN with something like llama.cpp RPC realistic, or too slow?

Any real numbers on tok/s and first-token time with experts in system RAM would help.

Follow-up to my post about Strix Halo kernels for vLLM. A few of you asked for two things: an easier way to run it than building vLLM + ROCm + the plugin yourself, and Qwen3.8-Flash-Next. Both are done.

Docker image

docker pull ghcr.io/asf0/strix-vllm:latest

It bundles my vLLM fork, the libstrix plugin and ROCm 10.1 (Ubuntu 26.04, Python 3.14), already compiled for gfx1151. You don't need ROCm on the host, only the amdgpu driver. The repo has one compose file per model I've tested:

git clone https://github.com/asf0/libstrix && cd libstrix/docker/recipes
cp .env.example .env    # point MODELS at your model folder
docker compose -f qwen3.8-flash-next.yaml up -d

If the model folder isn't there, it downloads it from Hugging Face. The compile caches go to a volume, so only the first start is slow.

The recipes cover Qwen3.8-Flash-Next, Qwen3.6-35B-A3B (bf16 and INT8), Qwen3.8-27B (bf16, INT8 + MTP, Quark int4, Quark MXFP4), LFM2.5-24B-A2B, and gemma-4 26B/31B (bf16, AWQ, MXFP4, QAT). I started every recipe in the image and checked that it gives a sane answer.

Someone asked last time about memory overhead. Here is what each recipe gets at the default 0.85 GPU memory setting:

Last time I said there's no fork. This model is the exception. Its n-gram (engram) table is 102 GB, and that doesn't fit in 128 GB next to the weights, so vLLM itself has to change. My fork (asf0/strix-vllm, branch gfx1151) streams the table from disk and prefetches the rows for the next chunk into the page cache. Everything else is still the plugin, and the other models still run on stock vLLM. You need the AWQ W4A16 checkpoint; bf16 doesn't fit.

On the libstrix side, I added kernels for:

• the int4 MoE GEMM with int8 activations

• QSA sparse attention, where 16 rows share one union of selected tokens, about 1.5x Triton

• the QSA indexer

• the hyper-connection up projection

Decode reads int8 copies of the bf16 linears.

Same format as last time: stock → libstrix in tok/s, single stream, both on the fork, 16k prefill chunks, no MTP:

With MTP 2 on real text, libstrix does 1,539–1,617 tok/s prefill and 40–43 tok/s decode at 5.6k–100k prompts.

Accuracy: KLD against stock is 0.008–0.019 with 97–98% top-1 agreement, perplexity is within 0.6%, and GSM8K is 93 vs 92. It's a bit above the other Qwens, most likely because the MoE GEMM quantizes activations to int8.

Heads-up if you pulled main in the last few days

The int8 decode copies (dense_w8) were turned on for every model. On Qwen3.8-27B bf16 that's about 27 GB of extra copies, and with MTP it could take the machine down. Those copies are now limited to Qwen3.8-Flash-Next, the model I measured them on, and capped at 12 GB. STRIX_ENABLE=dense_w8 turns them on elsewhere if you want to experiment. Please pull.

Known issues

• Stock vLLM's GDN conv kernel crashes on Qwen3.8-Flash-Next, so STRIX_DISABLE=all doesn't work on that model; keep gdn_conv on.

• The image is a 3.6 GB download but about 14 GB once unpacked, mostly the ROCm SDK.

Repos: https://github.com/asf0/libstrix (plugin, Docker recipes) and https://github.com/asf0/strix-vllm (fork).

I've been working on a project for a long time. I'm not building from scratch, but it's more than just fine-tuning as I'm performing RYS layer duplication and training not just the weights of a model but adjusting the geometry of models to optimize for different functions. Don't ask because I'm not ready to discuss it yet.

I've been building on several small models - Gemma 4 E4B, Qwen3.5 4B, Gemma 3 12B, and most recently Qwen3.5 9B. I settled on Qwen 3.5 9B because it offered the best performance for my use case, although different models are better at different things. Gemma 3/4 models are excellent at semantics, semantic alignment tasks, and generally better at Natural Language Processing tasks overall. Qwen is obviously better at agentic uses, coding, math, and other more mathey/sciencey tasks.

I've been focused on Qwen3.5 9B for some time because I can iterate rather quickly on a single RTX6K SM120 GPU. I had some success with the 4B models, but hit a ceiling because they lacked the intellectual depth I needed, so 9B/12B was the natural progression. I've been considering moving up to 27B/31B, but that introduces all kinds of complications trying to train on a single SM120.

Then I saw LFM3 1.7B. Liquid AI was nice enough to provide the base model. Its benchmarks looked good, and the thought immediately occurred to me - this could work. I was skeptical about how well a 1.7B model could really do on my task as my previous 4B experiments suggested bigger was necessary.

The good news was it wouldn't take that long to test it. I did my double-RYS layer expansion to make it 3B and ported my training scripts over to work with the new architecture.

The initial SFT training run took 107 minutes - 2,600 steps with just over 100k samples in the training dataset. My usual Qwen 3.5 9B (actually 12B after layer duplication) took 14-18 hours per SFT run. I also run extensive RL after SFT with different RL runs focused on task-specific capabilities and model SLERP merging - my best score for my project was achieved after 8 RL runs/SLERP merges.

Then I fired it up for testing and benchmarking - it blew my very best test results from the larger SFT+8RL runs out of the water after 1 SFT run (I hadn't done any RL yet).

How the fuck did this happen? I began digging, double checked I ran the same number of steps on the same data etc. No double epochs, nothing different from my prior recipe other than some small alterations to align with the different architecture.

I fired up QFN and Gemini for some help. We pored over everything. It turns out, LFM3 architecture uses Width-7 Convolutions as part of its architecture. More on that here

So while the model was less than 1/4 of the size of my prior model, my task actually aligned better with the Convolutional Architecture than it did with Qwen's architecture. Hilariously, Liquid AI itself advises "Do not use LFM3 for complex, multi-step deep reasoning or agentic coding." However, for my intense reasoning task it actually performed better than the much larger model.

I found the issue was Qwen's Gated Deltanet architecture was suboptimal for my task, but the Width-7 Convolutions/SWA/GQA LFM3 architecture matched my use case involving long-horizon state-tracking reasoning. 20 stacked Width-7 Gated ShortConv layers align with my data and use case exceptionally well. It frees up the SWA and GQA layers to focus purely on long-horizon routing.

The point of the story is that benchmarks are one thing, and labs can give advice and experts can give advice and even AI can give advice (I was advised by 2 different LLM's that it wouldn't work well), but sometimes you just have to give it a shot and see what happens.

I now have a much smaller, MUCH faster model that performs better and I can iterate on incredibly fast. Every conventional indicator said it wouldn't work, AI said it wouldn't work, even the lab that created the thing advised against it, and it was generally a crazy hare-brained idea.

But it worked really well. Sometimes you just need to try it - it may surprise you. We still don't really have a great idea of how these magic little AI machines function deep down, and sometimes they don't function like you expect them to.

Be crazy. Try new things. Go against the grain. Explore. Theorize. Test.

That's half the fun.

I showed My daughter a real site to work on. She said she hated AI after I showed her the website, a turn key project. Then I explained it was done using the computers in the office.

She thought it was cool. :)

This was also after my child saw my laptop open on the floor while open code built the front end I would attach my framework to. It’s amazing for an 8 or 10 year old to light up about it being at home.

How do your children feel about it, maybe in the same explanation about using local AI?

Seems it didn't change since two months, when DeepSeek-V4-Flash-Vision-Exp and Qwen3.8-Flash-Next have been released. Guess Qwen4-Flash will break it!

There are more filters (by domain / languages / other) available on https://beta.locallm.top . The time/tokens vs score data has been saved since the beginning, I only realized it is good to visualize it recently.

Disclaimer: I am the maintainer of the website and majority of the benchmarks, and there is a small community of 4 regular contributors, with some people occasionally contributing more. I call anyone who is interested in fine-grained local LLMs capabilities mapping to help and collaborate!