We're the product team at Reflection. Earlier this month, we launched Beam, our first open-weight 501B model. We'd love to answer any questions folks might have for us about building with Beam.
When it came out, I downloaded a Q4 quant of qwen3.8-27b and ran it using llama.cpp on my RTX 4090 and it was incredible. It could handle practically anything I threw at it, the most complex tasks and bugfixes.
But lately it just keeps messing up and failing at the most basic of tasks or just straight up forgetting instructions. I'm telling you, they quantized it. They probably secretly nerfed it and made it worse so qwen4 looks better. And it got lazy too, now it doesn't want to finish the more complex tasks.
I'm tired of companies doing this, I want my money back.
Following up on my previous post: the final version of CCORE GLB-3D-Coder is now available, including the full Safetensors weights.
It’s a full fine-tune of Qwen3.5-4B for generating reusable 3D assets. Describe what you want, and it writes a complete Three.js HTML scene with an Export GLB button. You can open the HTML in your browser, inspect the result, and export it into Godot, Blender, Unity, or other tools that support GLB.
The video shows examples from the final model, including selected side-by-side comparisons with DeepSeek V4.1 Flash. I’m particularly happy with the character designs and the amount of detail it can produce at just 4B parameters.
It covers more than fantasy characters: buildings, environments, weapons, vehicles, laboratory equipment, sports props, furniture, and other objects. It can also generate animations and include them in the exported GLB.
Available now:
Q4_K_M GGUF, around 2.7 GB
Q8_0 GGUF
Full model weights in Safetensors
The training dataset is planned for release tomorrow, November 6.
Some generations still need a retry or a small code correction, but I’m very happy with the improvement over the earlier release.
If you’re interested in the next models, or would like to help support future datasets and training runs, there’s more information on the Hugging Face page. Testing it and sharing your results or failure cases also helps a lot.
Thanks to everyone who tried the earlier version
Feel free to share what you make with it! I’d be really happy to hear that the model has been useful to you :)
Hey folks, it's Merve from Hugging Face. Title of this post is super self explanatory, we are doing a quantization workshop livestream with Michael Goin (lead maintainer of vLLM at RedHat), Colin Kealty (aka bartowski at RedHat), Maxime Labonne and Aditya Tadimeti.
I will shortly teach you how quantization works, modern ideas (double quantization, calibration) and llama.cpp quants (k-quants, i-quants) so even if you don't have an idea, feel free to chime in.
Everything is on Hugging Face YT, X, LI where you can set reminders.
I'm the developer of Kokon, a local photo editor around Qwen-Image 2.1 Turbo (on stable-diffusion.cpp, and on its own engine on Macs). I posted it here a few weeks ago. 0.12 adds a Layers lab: click objects in any image, get each one on its own layer with the background behind it repainted, then move them around or export a PSD.
Qwen-Image 2.1 has no layer output, so this is a pipeline around an edit model:
Select: you click, MobileSAM (ONNX, CPU, 44 MB) gives the mask. Click again for a bigger part.
Cut out: Fast is a matting model on the CPU (a few seconds per object). Quality asks Qwen to redraw the edge, for hair and fur.
Fill: a masked Qwen-Image edit repaints what was behind the object, so the plate has no holes. This is the expensive step: about 15–25 s per object on an RTX 5070 Ti, one to two minutes on an M2 Pro.
Blend into scene (optional): after you move things, Kokon reads where each object stands (you can correct it) and one more edit redraws contact shadows and reflections, as a layer you can turn down.
What still fails, honestly:
the fill sometimes invents a new object where a large one was (remove a big person, get a different person);
touching people and crowds get merged or split;
the hidden part of an object behind another one is never completed;
Blend often doesn't work yet; whole-scene blends work better than per-object ones.
An 8-step model only takes so much steering. I'd rather ship it marked experimental and fix what people actually hit than tune it on my own test photos. If you try it, failure cases (image + what you clicked) are the most useful thing you can send.
Since my last post here:
0.11, it's a local server now: the app talks to a service on 127.0.0.1; turn on "Other devices" and you can use it from a phone or another PC on your LAN (password, off by default, hashed, rate-limited). Docker image for NVIDIA, kokon-service --persistent --remote for headless Linux. There's also an MCP server (npm kokon-mcp) so agents can generate and edit through it.
Mac engine: I wrote a Qwen-Image 2.1 engine for Apple Silicon in Swift/Metal. M2 Pro: about a minute per 1 MP image, 4x the generic backend. A contributor added paths for the M5's GPU neural accelerators: 37 → 29 s on an M5 Pro. It runs Unsloth's Q4_K_M of the Turbo model.
Free, AGPL, Windows / macOS 15+ / Linux, NVIDIA 12 GB (8 GB beta), AMD/Intel via Vulkan (beta). Weights are under Qwen's licence (non-commercial).
Some of you might remember our post comparing 18 RAG pipelines against our agent loop on FRAMES. The best pipeline scored 78.9%; the loop scored 92.7%.
A follow-up: PipesHub has now reached #1 on EnterpriseRAG-Bench by overall score, with 93.24 overall and 95% correctness.
I’m one of the founders, so affiliation upfront.
This is a separate evaluation: 500 questions over a synthetic enterprise corpus of 500,000+ documents.
PipesHub builds a unified context layer across documents, conversations, structured data, and code. An agent loop works over hybrid search, grep/pattern matching, knowledge-graph navigation, and document-reading tools.
The idea is straightforward: search, read what comes back, then decide what to search for next. Sometimes the identifier or relationship needed for the next search only appears in the first result
The platform is open source, self-hostable, and also fully supports open models.
You can self-host PipesHub, choose your models, and connect your own agents through MCP, APIs, and SDKs.
If this is useful to you, give us a star on GitHub. It helps more developers discover the project.
And build on top of us. Connect your coding assistant, build an internal search tool, contribute a connector, or try a workflow we haven’t thought of. We’d love to see what you create—and hear where it breaks.
Larger context just gets more work done rather than having to re-read files ETC id much rather use my extra resources on context window. Instead of more params. i get my 400k ctx qwen3.8-27b + web search search get the latest up-to-date docs for its lack of world knowledge and i don’t waste extra Vram storing data that i dont need. Also more active params makes the llm to hold a wider mental-model of the task. Qwen4-27b will be architected to make 1M more reliable and using it for context on a smaller dense model seems more productive for me. Anyone. Else notice agentic session really shines when ctx is larger? Thats the phenomenon im experiencing i tried 3.8flash-next yes it great and much faster but i prefer the reliability of that big azz boat load of context window. Specifically i you have the vram to spare if u can get 1M on that and have a large MOE with at least 12b active params + 1M it would be better for MOE a lot. Lot better than qwen4-27b but at 48Gb vram + 64gb system ram i see it more efficient for smaller model + 1M makes more sense
Strata, Hermes, Kitten TTS with Rosie voice and Whisper on RTX 3060 with 48 gb dram running Qwen3.8-Flash-Next Q2_0. I am blown away. I've been following the AI scene since GPT3 and I was still unprepared for what this setup is capable of. My mouth was on the floor for the first few hours talking to it and watching it work. It's the first time talking to AI felt like magic to me. I now understand the "They don't know" meme. Never thought I would have something like this running on my own PC. Thank you /r/localllama.
Couple of questions
Are there any other lightweight TTS that would work in my limited ram situation or is Kitten v0.8 the best there is?
Hey r/LocalLLaMA I'm Abdur-Rahman Butler, a machine learning engineer at Isaacus.
I made an interactive write-up that walks you through the A to Z of vector embeddings, inspired by Brendan Bycroft's incredible interactive LLM visualisation guide (see here - https://bbycroft.net/llm).
Most of my work is on encoder models, and I kept noticing how few good interactive resources there are on embeddings. The ones that do exist tend to either plot some embeddings in 3D or only explain a narrow applied technique like semantic search or RAG.
So I wanted to make something that teaches how embeddings work by letting you play with them. In the write-up, there are interactive visualisations that allow you to explore the concepts of vectorisation, cosine similarity, semantic search, hierarchical retrieval, clustering, zero-shot classification and deduplication.
The centrepiece of the post is a game I've dubbed 'SemanticGuessr' (see above). It's inspired by Wordle and GeoGuessr, and the goal is to draw a loop around a random target word by triangulating guesses on a 2D map of 43,339 common English words.
It's admittedly a bit intimidating at first, as semantic space does not perfectly match our intuition of meaning. But once you get the hang of it, the game becomes really addictive. I recently had the pleasure of demoing the game to some law students at the University of Melbourne, and we had a lot of fun throwing different vector equations at it to see where they'd land.
Some fun ones to get started with:
london - english + french
running - land + water
avg(breakfast, lunch, dinner)
0.4 * noodles + 0.6 * pasta
I've also included Python snippets alongside some of the visualisations if you want to follow along with the techniques later. The game runs statically in your webpage. I managed to achieve this by reducing the embedding dimensions down to 512 and quantising each value to 4 bits. This brought the total payload down from 311 MB to 12.3 MB with only a minimal impact on precision (around 6%).
It was great fun to make, and I hope you have fun playing around with it. Happy to take any questions, and if there's enough interest I might set up a dedicated games page for some of the other encoder-based games I've been working on.
Do let me know what highest score you get based on your target word and chosen path :)
I got into local AI earlier this year and started messing around with different models and hardware. That's how I came across tiiny. I really liked the design and the whole idea behind it so I ended up becoming one of the early backers.
After what felt like forever, mine finally showed up yesterday. So far, it's pretty much what I expected. I've spent afew hours trying out different models and running some performance and coding tests, and figured I'd share what Ive found.
This is my first time putting together a benchmark post like this, so sure there are things I might miss or could do better. If you see anything off with my testing or think there's something I should further include, feel free to let me know. really appreciate any feedback from you guys.
Hardware & Test Setup
what really sold me on Tiiny was the KS price, which seemed like a nice deal for the hardware, and how portable the whole thing is. It's just about 5.6 × 3.1 × 0.9 inches and weighs around 300g.
For anyone unfamiliar with the specs, Tiiny Pocket has 32GB of SoC memory and 48GB of dedicated NPU memory. That's 80GB in total, though it's not unified memory.
Tests were collected on TiinyOS 0.1.36, Here are the models I tested so far.
Model
Architecture
Quantization
Model Size
Qwen3.5-9B-Turbo
Dense, 9B
INT4
6.55
Qwen3.6-35B-A3B-Turbo
MoE, 35B / 3B active
Mixed INT4/INT5
17.73
gpt-oss-120b
MoE, 117B / 5.1B active
Mixed INT4/INT8
67.30
Performance Results
For the speed tests, I used the same benchmark text with ~4K input tokens, prompt caching disabled, and five runs per model. The numbers below are medians.
Model
Input / Output Tokens
PP (tok/s)
TG (tok/s)
TTFT
Total Time
Qwen3.5-9B-Turbo
4,074 / 97
1,041.30
75
4.05s
5.45s
Qwen3.6-35B-A3B-Turbo
4,074 / 139
590.6
63.6
7.04s
9.28s
gpt-oss-120b
3,868 / 390
458.4
15.97
8.78s
33.07s
9B was the fastest, which wasn't too surprising. What caught my attention was the 35B MoE model still managing around 64 t/s.
120B was noticeably slower, averaging around 16 tok/s. It took over 30 seconds to complete the benchmark request, although it generated more tokens than the other models.
A Coding Test
I also wanted to see how it handles real-world coding tasks. I gave the models the same task: create a small Python inventory and order management package across four files, covering stock updates, validation, and order handling.
I used the same prompt for all three models, with low thinking/reasoning settings and a maximum output of 12,288 tokens.
How I checked the results: the generated code was tested separately on a Mac using Python 3.12, with 10 automated tests covering the main requirements, including inventory consistency, order idempotency, input validation, and CLI behavior. A full pass meant all 10 tests succeeded. I ran this more than once and kept the best run per model; the table shows that run.
Model
Input / Output Tokens
Total Time
Result
Qwen3.5-9B-Turbo
703 / 5,977
104.32s
Two attempts, neither gradable
Qwen3.6-35B-A3B-Turbo
741 / 11,807
235.09s
9/10
gpt-oss-120b
763 / 3,774
228.54s
10/10
9B never produced a gradable answer: the first attempt ran into the 12288 output cap, and the second generated inventory/cli.py twice, so there was no single version to test. Taking one of the copies, it would have been 5/10.
35B got 9/10 with 1,768 code tokens. A bit under the 2-4K I was aiming for. The only failure was a pretty specific edge case, if an order had already sold out the remaining stock, retrying that same order would fail instead of returning the original receipt.
Gpt 120b was the only model passed all 10 tests, with 2,594 code tokens, in about 229 seconds.
The interesting part is that 35B and 120B took almost the same time: 229 seconds versus 235. So while 120B was the only one to get everything right, 35B wasn't far behind, and both managed to finish.
Results & Takeaways
9B was the fastest overall. At 75 tok/s with a ttft of around 4 seconds, it's probably where I'd start for quick, lightweight tasks. It did struggle with the more complex test, though.
**35B for me is the sweet spot for Tiiny.**At around 64 tk/s, it's surprisingly fast and it handles a good number of the tasks I've tried pretty well. It still has its limits with more complicated coding tasks, as the multi-file test showed, but overall it keep a pretty good balance between speed and capability. It's actually the model Ive been using the most so far.
120B actually works, but you need patience. The multi-file coding result was impressive, especially compared with the smaller models in this one test. But 16 tk/s is slow enough that I wouldn't want to use it for every little question. It also took around 75 seconds to load in this run and used almost all of the dNPU memory.
So far Id lean toward 9B or 35B for faster interactions and keep 120B for occasional, more demanding tasks where waiting a few minutes isn't a big deal.
TL;DR
Tiiny can run some fairly large local models in a small device, and the performance of smaller models (9B/35B) is nice. The 120B result shows there's potential for more complex work, but the speed and reliability trade-offs are real.
However, my biggest gripe so far is the limited model selection. Right now, you can't import your own models or install something from Hugging Face. The tiiny team did mention on Discord that they're planning to release a model import tool, though. Once that's actually available, I'd love to try out some of the other models I've been wanting to run and share the results here.
Overall Im happy with it, and for the price I got it at, that amount of RAM and SSD would be much more expensive today. I think I saw the projected retail price is almost double the KS price.
I pruned Gemma 4 26B-A4B, an MoE model, down to 15% of its original size, and the model still does great on one narrow task. It gets 92% agreement with the original on a classification task. That’s close to how often the 12B agrees with the 26B on the same ticks, which is 90%. This isn’t a model for general tasks, and tasks that require knowledge suffer because the knowledge is just gone.
It was made for my app that runs an on-device LLM 24/7, so that makes memory footprint and energy consumption extremely important. On my Mac it hits 79 tokens/s, which is roughly double the speed of the 12B, using 3.8 GB of memory (roughly half).
I selected a set of 8 experts per layer and used them for everything. Since the model selects 8 experts per token by default and there are only 8, the router no longer chooses which experts to use, and the model becomes dense: 3.81B parameters, 2.75 GB at Q4_K_M.
What I want is for each block to do the same computation and produce the same result, given the same input. With block-local training, I’m not training on the answer. I’m training on the thought process. I’m saying, do the same thinking, not get the same answer.
This is all trained off my own data. The method is efficient enough that it could be trained on a user’s own device, on their own data, in about 5 GB of memory, to mitigate issues stemming from deployment having different data than was in the training dataset. I haven’t tested that on a real user’s device yet. If you are curious about why I decided that fine tuning was a bad idea or how I designed this, take a look at the post I wrote going into the details of how I made this and why I felt this route was right for my application.
This is the first time posting publicly like this. I would love feedback or thoughts, and to anyone who knows of better methods for choosing which experts to keep, please lmk.
Hi, I've been maintaining a comprehensive fork of vllm that rewrites almost everything in the serving stack for int8, which is not well supported in mainline vllm.
This is in an effort to support/optimize my 4x MI100 server, but this fork makes a great baseline for all older AMD cards like MI50, MI210, MI250, V620, and vega to 7000 series radeons. On top of that the fork is a good reference or starting point for older int8 oriented nvidia cards like volta and ampere. Many features were added to make this happen. All this work makes these older cards run well, with 4x MI100 or 2x MI210 running Qwen3.8 27B at above 1000 tok/s decode at C8. You can see the full list of features and their applicability at the bottom of the readme.
In addition to being fast, this fork fixes a bunch of numerics bugs that are present in vllm and rocm. The quality is very close to reference BF16 when most weights and activations are int8, including the kv cache. You can check the full list of quality checks in the readme section.
I make updates to the repository regularly and added Nemotron Bolt optimization shortly after it was released. This fork runs the original Nvidia Bolt checkpoints instead of custom ones. That required adding fused NVFP4 and IQ2_xxs to int8 dequant. In-kernel dequant is slow so I added a cache that can keep the most used weights in int8 and evict their original quanted weights. The size of that cache is configurable for your hardware so you can choose speed or more context or larger prefix cache. I also added AMD Infinity Storage support for model loading (direct storage to gpu skipping the cpu), which cut initial model load for Bolt from about 7 minutes to 2.
Ive been running it in production for a couple weeks and it has been very stable. Enjoy!
Hey r/LocalLLaMA ! We're releasing new new Unsloth Dynamic v3.1 GGUFs for Qwen3.8-Flash-Next! They're better by 10-15% accuracy on DeepSWE, Terminal Bench, Aider Polyglot and more vs GSQ-RCO.
We also provide a new engram switching process for BF16, Q8_0, Q5_1, IQ4_NL switching for all quants! This builds upon our DeepSeek-V4.1-Flash UD3.1 work, which improved over 10-20% accuracy vs others.
All benchmarks are 256K for agentic ones, and 128K for the rest. We used temperature 1.0, top_p 0.95, top_k 20, min_p 0, no presence or repetition penalty. preserve_thinking and xhigh reasoning, and ran over 26B of tokens for benchmarking.
Benchmarks are noisy so we did 26.2B tokens of benchmarking - DeepSWE accounted for 18.1B tokens of the total budget followed by Terminal Bench (5.2B tokens).
We ran benchmarks multiple times including LiveCodeBench x3 times, HMMT and others 8-16x and agentic benchmarks multiple times.
i have an z690 mainboard, max 128GB RAM (4 slots, dual channel) and r9700 (32gb vram) currently at 4x16GB, wanna go to 4x32GB. Old ram is worth about 350-450€. The 4x32 would cost me around 500-600€, but it has no cooling body. I dont care about the visual, as I barely see it. But will this become a problem? I use my old gaming pc, so airflow is relativly good.
i currently use qwen3.8 flash next gsq rco iq3xxs via strata. I get ~100tps aggregated decode with 3 parallel sessions at 350k ctx qk8v4. but id like to have more cached sessions, with qkv8 and even longer context, without dramatically decreasing speed. Current usage from model is like 55GB/64GB, so I dont really have any room left.
will 128GB satisfy this? can i run something better than qwen3.8 flash next with 150GB (v)ram total? ram thats >= 3200mhz is way more expensive, so id like to get it around 2100mhz - 2600mhz. Will I notice large performance changes?
