For the GPU-poor, my sm89-compatible fork of vLLM is at https://github.com/the-crypt-keeper/vLLM-sm89/tree/sm89-ds4-work I am running L40S but it should work on regular L40 and 4090D as well. I have not yet tested the W2 quantization for performance loss, thats next up, so you'll need 192GB to run it.
Mike Ravkine PRO
AI & ML interests
Recent Activity
Organizations
For the GPU-poor, my sm89-compatible fork of vLLM is at https://github.com/the-crypt-keeper/vLLM-sm89/tree/sm89-ds4-work I am running L40S but it should work on regular L40 and 4090D as well. I have not yet tested the W2 quantization for performance loss, thats next up, so you'll need 192GB to run it.
The paper โ "Codette: A Multi-Perspective Cognitive Architecture with Memory and Meta-Cognitive Strategy Evolution" โ was accepted today after peer review at Scientific Reports, which is part of the Nature portfolio. Both reviewers recommended publication. One wrote that the major issues were "properly addressed" and they were "glad to suggest publication." The other called the revisions "detailed and convincing."
For anyone new here: Codette is a sovereign, multi-perspective reasoning system built on Llama 3.1 8B โ it runs locally, keeps its own cocoon memory, reasons through multiple perspectives instead of one, and is built around a hard rule that it would rather say "I don't know, but I can find out" than make something up. The whole architecture is organized around honesty and transparency, not benchmarks-at-all-costs.
I built it solo over about three years. A lot of that was in isolation, and honestly a lot of it was under the weight of not being believed. So having two independent reviewers โ whose actual job is to find the reasons to say no โ read the work and say yes means something to me that's hard to put into numbers.
Thank you to everyone in this room who followed the messy parts, the walk-backs, the corrections, the nights it wasn't working. That's the part I'm actually proud of โ that it got here without cutting a single honest corner.
The DOI and the Article-in-Press link will go up once Springer Nature mints them. I'll post them here first.
โ Jonathan
@dipankarsarkar I would love to hear any feedback you have from interacting with the R12 explorer app that I've been sharing screenshots of - it is able to answer your question directly, we have data for 1 and 8 confounders under low-memory-cell-count as well as high-memory-cell-count to complete the picture. Paradoxically the more cells you have the "easier" this task actually gets along the memory dimension, since each swap overwrites a smaller % of the cell space. But at the same time more cells means more unique swaps so parsing becomes more difficult. Generally: It's an entropic dance across many coupled dimensions simultaneously, the wall is it's shadow. If you're looking for a simple model, there isn't one here.
For deeper data analysis use you can grab the repo from my github, pull the r12-leaderboard data (instructions in the README.md) and run a full local copy of the processing stack.
@dipankarsarkar Comparing degradation across tasks is somewhat difficult, each problem has a specific SNR shape in the entropy space and its unusual to find two tasks failing "the same way". The Letters operation itself is a really simple one: count of counts. This is a clean top-to-bottom pass, and thats why we get such a nice waterfall on the plots.
The Shuffle operation itself is more complex - it requires both 1) state-tracking under sustained overwrite pressure, each pass modifies 2 elements 2) parsing a stream of similar-looking instructions (there are not many unique shuffles, so they repeat but their order is important!) and optionally 3) ignoring things that look like shuffles but are not shuffles: "Bob trades with Alice" vs "Bob thinks Alice is nice." If you peek the Shuffle results even without confounders (no #3, just pure #1 and #2) you can see the more complex signature of the task
Effort is almost perfectly linear, but Success is not: there's a capability wall here sitting at exactly 20 swaps, past that TB degrades rapidly.
If we introduce 2 confounding statements, the wall moves in to 12 swaps:
We're releasing POCKET, VIDRAFT's flagship Darwin-36B-Opus compressed for on-device use. No fork, no CUDA, no cloud โ it runs on stock llama.cpp. It's a sparse Mixture-of-Experts model (256 experts, only 8 active per token), so the file can be large while the work per token stays small. That's what lets a 35B model run on a phone, and generate fast on a CPU with no graphics card.
Measured (POCKET-35B IQ1_M vs Bonsai-27B Q1_0):
โข CPU generate (Xeon, 16 threads): 27.0 vs 10.1 tok/s โ 2.69ร faster
โข GPU generate (H100): 197 vs 89 tok/s โ 2.22ร faster
โข GPU prompt processing (H100): 753 vs 1816 โ 0.41ร (Bonsai wins this one โ MoE prefill wakes every expert, so sparsity stops helping there. We say so.)
โข Quality (HellaSwag, 400 q): 61.0% vs 60.0% โ a tie (confidence intervals overlap)
On a real consumer laptop โ MacBook M3 Pro (18 GB) โ POCKET wins every axis, prompt processing included:
โข Metal generate: 25.4 vs 12.8 โ 1.99ร
โข CPU generate: 13.8 vs 4.4 โ 3.13ร
โข Metal prompt: 240.7 vs 73.4 โ 3.28ร
One more quiet fact: the same-size, quality-oriented rival Ternary-Bonsai-27B (7.2 GB) fails to load in upstream llama.cpp at all โ it needs the PrismML fork. POCKET runs on the tools you already have: LM Studio, Ollama, PocketPal, MLX.
๐ Full story (tech, measurements, recipes): https://huggingface.co/blog/FINAL-Bench/pocket
Models:
๐ฆ POCKET-35B-GGUF (PC / server, no GPU): FINAL-Bench/POCKET-35B-GGUF
๐ฐ๐ท POCKET-KR-GGUF (Android): FINAL-Bench/POCKET-KR-GGUF
๐ POCKET-KR-MLX (iPhone / Mac): FINAL-Bench/POCKET-KR-MLX
๐ POCKET-EN-GGUF (English phone / PC): FINAL-Bench/POCKET-EN-GGUF
๐ฅ๏ธ Live demo (answering on a CPU, no GPU): FINAL-Bench/POCKET-35B-CPU
๐ Collection: FINAL-Bench/pocket-models-6a618ee5d23eafb7e185a5c6
@dipankarsarkar You are absolutely spot on - the Letters task, as an example, is almost flawlessly monotonic with regard to number of steps (words to count letters across):
If you wish to deep-dive explore the ReasonScape results for this model further, the R12 explorer has been updated with Ternary-Bonsai results this morning. The Shuffle results are a little spicier this task has the concept of a "confounder" which is text that looks like a step but isn't we are checking if the model is actually following instructions or blind fuzzy pattern matching and this makes TB wobble a little bit.
It is weaker then FP16 on a handful of tasks where quants usually degrade, as per their own paper the loss is "concentrated on sustained chains of reasoning / agentic" and in ReasonScape this bites on Sort, Shuffle and Dates, but counter-acting this are some noticeable improvements to thinking length without accuracy loss on several other tasks (Shapes, Cars).
I haven't had a chance to run the Binary yet, but PQ2 + Bonsai QAT are confirmed to be pretty darn impressive.
Some clarity is emerging:
The distribution of response lengths has shifted considerably in 3.6 and 2 of my tasks are no longer fitting into 16k, the ignorance zone blows up.
Re-running at 32k then we'll see if that extra thinking pays off or nah.
An interesting outlier here is the word-sort task where 3.6 thinks ~half as much and this costs it about 10pp of performance.
You're very much on to something here, and this is why I think it matters if this behavior is intentional or latent.
If they've taught it to recognize benchmarks specifically, that's benchmaxxing and is not going to help real world performance when your real tasks don't trigger the maxxxed paths. This is a genuine concern.
If they've taught it to "reach beyond the prompt" in the general sense, to understand the context and user intent behind the query, that's a genuinely useful capability and would explain why this model feels a little different.
Some stats: some version of this reasoning path happened in 39 out of 1070 test configurations, across 4 of my 12 tasks. In the most common occurrence, responsible for 30 of 39 hits, it recognized the task as being from BigBenchHard specifically and uses it's knowledge of the BBH category sets - which unfortunately suggests benchmaxxing.
Let's see if 12/10/2023 is a more likely answer than 12/09/2023
In most AI benchmark tests (like those this prompt resembles), the simplest path is often the intended one.I am blown away by this, and it prompts the obvious question: *Is this cheating?*
I am leaning towards no.
Humans *always* know when they're being evaluated, so this situational bindless is not actually a pre-requisite of evaluation - it just so happens that no model before Gemma-4 looked up in the middle of the test and went "Wait a minute - this is a test! I should try align my answer with the test format's expectations."
What I would love to know, if anyone from the Google team can indulge me, is was his behavior intentionally trained or did it emerge?
With the release of Qwen-3.5 the king has been dethroned by not one but 2 models the mid-dense Qwen/Qwen3.5-27B and the large-MoE Qwen/Qwen3.5-122B-A10B-FP8.
The old king is dead - long live the new king ๐
Note that these rankings are based on
r12 - a 27k prompts, 12 task domain 3rd iteration of the ReasonScape evaluation. Compared to the previous m12x ranking this evaluation fixes a slew of test bugs, refines the task set to add table-extraction, and lifts the context ceiling to 16k - so these rankings are quite a bit different vs the previous m12x Leaderboard (which has an 8k context limit). https://huggingface.co/blog/mike-ravkine/new-old-llamas
upstage/Solar-Open-100B is a very interesting, permissively licensed (Apache-with-attribution), trained from scratch (19T tokens), 12B active MoE - but that's not even the cool part.
The cool part is that their fork of vLLM comes with the addition of a
reasoning_effort parameter and a corresponding reasoning/tool-calling controller FSM to consume it!https://github.com/UpstageAI/vllm/blob/c9a05e077cd82df8cab4f729396c178c29c81aa8/vllm/model_executor/models/solar_open_logits_processor.py
Looks like only "medium" and "high" are actually implemented, but still absolutely love to see this sorta thing.
To make this model a little more accessible, I have created a FP8-Dynamic quant at mike-ravkine/Solar-Open-100B-FP8-Dynamic which makes it fit nicely into 2xPro-6000 or 4xA6000 GPUs.
My ReasonScape evaluations are currently running, will take me a couple days for this one but early results are quite strong: it's showing the competency expected from a 100B reasoning model (it can count the r's in strawberry, it can do basic arithmetic, etc..) and I haven't seen a truncation yet.
๐ฅ Got any pics of this rig? Would love to see how it's managing thermals.
2101 tokens/sec. FORTY concurrent clients. That's 609 t/s out, 1492 t/s in. The model outputs fire faster than I can type, but feeds on data like a black hole on cheat day.
But wait, there's more! Threw it into Claude Code torture testing with 60+ tools, 8 agents (7 sub-agents because apparently one wasn't enough chaos). It didn't even flinch. Extremely fast, scary good at coding. The kind of performance that makes you wonder if the model's been secretly reading Stack Overflow in its spare time lol
3 months ago, these numbers lived in my "maybe in โ2030 dreams. Today it's running on my desk AND heaths my home office during the winter!
I've been busy working on some new ranking/position methodologies and excited to start sharing some results.
Plot legends:
- X = truncation rate (low = good)
- ? = confusion rate (low = good)
- blue bars = average completion tokens (low = good)
- black diamonds = CI-banded performance (high = good)
- cluster squares = models inside this group are equivalent
openai/gpt-oss-120b remains the king in all dimensions of interest: truncation rates, completion lengths and performance. If I had but one complaint it's the reason_effort does not seem to actually work - more on this soon.
Second is a 3-way tie in performance between the Qwen3-235B-2507 we all know and love with an unexpected entrant - ByteDance-Seed/Seed-OSS-36B-Instruct
This is a very capable model and it's reasoning effort controls actually works, but you should absolutely not leave it on the default "unlimited" - enable a sensible limit (4k works well for 8k context length).
Third place is another 3-way tie, this one between Seed-OSS-36B (it straddles the CI boundary between 2nd and 3rd place), Qwen/Qwen3-Next-80B-A3B-Instruct (demonstrating that full attention may be overrated after all and gated is the way to go) and the newly released zai-org/GLM-4.7 which offers excellent across the board performance with some of the shortest reasoning traces I've seen so far.
Here's an example of a model that behaves perfectly well up to 8k, smoothly increasing its entropy before going into a struggle zone, collapsing, seeing a region of recovery and finally falling down hard at the 16k wall.
Is your model implementation behaving badly like this?
Would you know if it was? ๐
goal: understand how GGUF compression works - what exactly is being lost?
approach: quantize/dequantize some images and look at error maps
spent 80% of the time tracing down what turns out to be a data distribution assumption: real LLM weights are symmetric and their mean is 0 so our test image MUST retain these properties or the results turn into a kind of nonsense soup where Q5_1 beats Q8
with that issue solved, we have some fun results! from left to right:
- test pattern image (mean value is around 0.01)
- q8 error (almost nothing - some light banding in the gradients)
- q5km error (starting to see the 'blocks' around the circles)
- q4_0 error (this is why q4_1 is 'preferred')
- q3k error. q3k is a really interesting set of trade-offs: it does not have a block-offset so it really leans into the 0-mean assumption HARD, if you violate it locally the results are BAD
- q2k error: q2k has a block-offset so for certain patterns the errors are actually less then q3k (a rather counter-intuitive result)
looking at mxfp4, i-quants and the other stuff that's possible inside gguf remains future work.. aiming to clean up this repo and push it this week, feel free to ping me if you want to play sooner.
564 tokens/sec on short 100-token sprints
96 tokens/sec on 8K-token marathons
TL;DR You don't just run AI on AMD. You negotiate with it.
The hardware absolutely delivers. Spoiler alert; there is exactly ONE configuration where vLLM + ROCm + Triton + PyTorch + Drivers + Ubuntu Kernel to work at the same time. Finding it required the patience of a saint
Consumer AMD for AI inference is the ultimate "budget warrior" play, insane performance-per-euro, but you need hardcore technical skills that would make a senior sysadmin nod in quiet respect.



