ColonelPhantom

Isn't Anthropic doing the same, with Opus 5.5 being out while Fable/Mythos is still on 5.1?

Or HOGS? HTMX-OS-Go-Sqlite. While having "OS" in there is kind of redundant, it does make for a nice and general acronym.

Which model class requires an 80 GB VRAM GPU? From my perspective, popular models seem to be either in the ~30B range (Qwen3.6, Gemma 4), while the larger models (MiniMax, MiMo, StepFun, Deepseek) are in the multiple hundreds of billions parameters, for which 80 GB is simply too small.

You can just about reach the lower end of the latter category with a 128GB machine like a DGX Spark, Framework Desktop, or M5 Max, though those are usually not super fast. For the former category, you can easily run them fast with something like a 3090 or 5090, hell, probably even a 5060 Ti.

> the most likely experts

Is that how MoEs work? I though that an important constraint for MoEs is that experts need to be uniformly used to make sure they can be used effectively. If there is a 'common subset' that, if anything, sounds like a symptom of undertraining (i.e. the same trick will not work as well for Deepseek V4.1).

Also, even if your MoE hitrate is 90%, you still spend half your time waiting for the SSD, giving similar total speed to a 27B model!

Finally, it looks like Deepseek V4 is pretty much only runnable with antirez's ds4, and SSD streaming only works with Metal; but I would like to try what you say with llama.cpp which uses mmap to also potentially do SSD streaming. (I can maybe try the large Qwen3.5 MoEs?)

> as context length increases

What kind of context length do you consider reasonable, though? From what I know, all models (even frontier ones) start degrading once you pass a few hundred thousand tokens. So realistically, limiting context size might even improve quality, especially if you use token-efficient harnesses.

> Or you could fit the dense portion of a much more capable model and still take advantage of that hardware.

Your point about consumer hardware was that it would be "borderline unusable" when running Qwen 3.6 27B. However, you need much less hardware to run a 27B than DSv4 Flash. In addition, you can do the same 'trick' with low-end GPUs and small MoEs: my desktop with 32 GB DDR4-3200 and an RTX 2070 8GB can run the ~30B class MoEs at 20-30 tokens per second and similar speeds to my laptop.

Deepseek V4 Flash still has 13B active params though? That is about half as many as Qwen3.6-27B (and much more than Qwen3.6-35B-A3B). Given that RAM (even on a base M4 or 'regular' Intel/AMD system) is like an order of magnitude faster than an SSD, even Qwen 27B running from RAM will be much faster than any Deepseek V4 model with SSD offloading. And the MoE will be much faster still.

Qwen 27B is also small enough to completely fit in a high-end consumer or mid-end pro GPU, like an RTX 5090 or Radeon PRO R9700. I found results claiming 30 tokens per second generation for 27B(-Q4_K_XL) on an R9700. I doubt you get more than 5 tokens per second doing SSD MoE streaming.

Even for relatively short contexts, I honestly already find the ~30B class MoE models to be only borderline acceptable in terms of speed on my laptop (Ryzen 7 7840U, 64 GB LPDDR5-6400), though I use Gemma 4 26B-A4B more than Qwen3.6 35B-A3B.

Carp is memory safe via linear types + references, similar to Rust, so I would not describe it as C-like but rather Rust-like.

But what _is_ a "Text User Interface"? Google Images just returns what is being discussed here: "GUIs" that run in some kind of text mode. And to me, that's also what a TUI is.

A more textually oriented environment (like a normal Unix shell) is, in my experience, usually referred to as a CLI: Command Line Interface.

I did find an interesting hybrid in the Pi coding agent: it seems to leverage the normal terminal scrollback, while still enhancing it with things like transient input fields and status lines, so that it can display those without cluttering scrollback.

You mentioned Strix Halo, which also has off-die memory. Strix Halo does have a real advantage from its wider memory bus (four channels for 256 bit instead of 128 bit), but Strix Point is equivalent-ish to Intel's platforms like Panther Lake or Arrow Lake in terms of memory setup.

In fact, Intel also had Lunar Lake, which had on-package memory. However, it was still limited to 128-bit dual-channel, so there weren't really many performance benefits; it did however help with power efficiency.

Hilariously, those AMD chips are way behind the Intels in terms of memory.

First off, I believe that Intel has its memory far more "unified". AMD typically has a stricter VRAM/RAM 'tradeoff' setting that does not exist on Intel in the same way to my knowledge. (See how on Strix Halo systems, there is a thing about "allocating" 96 GB to the GPU, which seems to be needed sometimes but prevents the CPU from accessing that memory.)

Secondly, the Panther Lake board has LPDDR5X LPCAMM2 memory at 7467 MT/s, while the AMD boards are stuck with DDR5 SODIMMs at a meagre 5600 MT/s. In other words, the Intel board gets a third more memory bandwidth!

Nvidia Turing (RTX 20) definitely marked a major shift IMO.

- It was the first card to enable real-time ray-traced effects. - Mesh shaders are a significant overhaul of the geometry pipeline that's only recently getting real traction. - Its tensor cores enabled a new generation of AI-driven upscaling/antialiasing. DLSS 2, FSR 4 and XeSS are all some variation of "TAA + neural networks", and these all rely on specialized matrix hardware to get optimal performance.

Obviously all of these features are supported across all vendors. Intel Arc Alchemist has all of these features as well, and AMD got RT and mesh shader support with RDNA2 along with slowly building up to tensor cores with RDNA3/4. But Turing clearly debuted these feature which have majorly changed the landscape of realtime 3D graphics.

838 seems to be the real INT8 TOPS number for the 5090; going from 800 to 3400 takes an x2 speedup for sparsity (so skipping ops) and another x2 speedup for FP4 over INT8.

So it's closer to half the speed than a tenth. Intel also seems to be positioning this card against the RTX PRO 4000 Blackwell, not the 5090, and that one gets more like 300 INT8 TOPS. It also has less memory but at a slightly higher bandwidth. The 5090 is much faster and IIRC priced similarly to the PRO 4000, but is also decidedly a consumer product which, especially for Nvidia, comes with limitations (e.g. no server-friendly form factor cards available, and there are or used to be driver license restrictions that prevented using a consumer card in a data center setup).

Aren't Intel Xeon Rapids and Intel Xeon Forest just different target markets? Rapids has fewer but faster cores in general, and more special-purpose accelerators (e.g. AMX, QAT), while Forest is focused on maximum compute density (just pack in as many fast-enough cores as you can).

IIRC Granite Rapids is also not _that_ old, and either current or a single generation behind. (Has its successor landed yet? IIRC GNR is the same generation as Sierra Forest).

Very cool! I am wondering one thing: how fast is it? Much of the "secret sauce" of the Voodoo is its high speed: a first-gen Verite or (God forbid) any ViRGE takes many more cycles for common operations like, say, Z-buffered pixels.

I'm guessing this isn't fully cycle-accurate, but is it at least somewhat "IPC-accurate"? I'm guessing yes? But much of that was also derived from Voodoo's (for the time) crazy high memory bandwidth AFAIK.

GPT-OSS is tailored to be extremely memory efficient. Not only is it natively using the 4.25 bit per token MXFP4 format, but it also uses sliding window attention for half of its layers. It also doesn't have that many layers, only 36 for the 120B version and 24 for the 120B version. (The 120B is also much much sparser than the 20B.)

I found a Reddit comment claiming only 36 KiB per token. With that, half a million tokens fits in 18 GB, which is less than one GPU. And three GPUs fit the parameters with room to spare (64 out of 72 GB).

Interesting; I was not aware of those "universal synthetics" but they make sense: a stronger reasoning base would make modeling tasks easier. Thanks for the link!

Again, though, if those work I assume they will be used for the slowrun. Surely a few hundred LoC to generate data would not be considered cheating :)

If generating synthetic data is such a great way to improve performance, why would it not be applied to the slowrun? Especially for the unlimited compute track, you should have plenty of time to generate as much synthetic data as your heart desires.

Intuitively, I would expect the synthetic data to mostly just "regurgitate" the existing data, and not add much. But I could be wrong of course, and perhaps doing reinforcement learning somewhere could solve that issue as well (though I don't know if there is much hidden in FineWeb that you could RL on; at best you can do self-verification probably?)

I like the idea of LLM-calling as an automation-friendly CLI tool! However, putting all my agents in ~/.config feels antithetical to this. My Bash scripts do not live there either, but rather in a separate script collection, or preferably, at their place of use (e.g. in a repo).

For example, let's say I want to add commit message generation (which I don't think is a great use of LLMs, but it is a practical example) to a repo. I would add the appropriate hook to /.git, but I would also want the agent with its instructions to live inside the repo (perhaps in an `axe` or `agents` directory).

Can Axe load agents from the current folder? Or can that be added?

Interesting read! One remark though: I'm not too familiar with the architecture of a Google TPU, but comparing the TPU's VMEM with Nvidia's shared memory feels wrong to me.

Looking at the size, and its shared nature, it feels far more natural to compare with the L2 cache, which is also shared across the entire GPU and is in the same order of size (40MB on the listed A100).

The reason for that is that most memory bandwidth bumps come with new memory generations. For example an early DDR4 platform (e.g. Intel Skylake/Core iX-6000) and a late one (e.g. AMD Zen3/Ryzen 5000) only differ by 1.5x as well, typically.

The same trend is visible in GPUs: for example, my RTX 2070 (GDDR6) has the same memory bandwidth as a 3070 and only a little bit less than a 4070 (GDDR6X). However, a 5070 does get significantly more bandwidth due to the jump to GDDR7. Lower-end cards like the 4060 even stuck to GDDR6, which gave them a bandwidth deficit compared to a 3060 due to the narrower memory buses on the 40 series.

It's not just Qwen; we also recently had GLM-4.7-Flash in the same roughly 30B-A3 range. Seems to me like there's no shortage of competition for good old GPT-OSS 20B (not just Qwen3.5-35B and GLM-4.7-Flash, but also Qwen3(-Coder)-30B or Granite 4 Small).

> Meanwhile, European makers are stuck not knowing what to do, make Americans happy or compete with the Chinese.

Huh? This comment sounds extremely America-centric to me. Porsche sells more cars into Europe than North America, despite taking a bigger there (-13-16% vs 0%)!

In general I don't think Porsche is representative of the car market as a whole, given their cars are all premium sports cars to at least some degree.

If you want more representative numbers look at more mass-market manufacturers. Notably, the Volkswagen group has a huge 20%+ market share in the EU, while it is below 5% in the USA. Renault is another example of a strong EU-centric brand and manufacturer with over 10% market share, even over 25% at home in France. Ford is a good example of the opposite, having 13% market share in the USA and only 2-3% here. Stellantis is strong in both markets, but has significant differentiation, even having different brands in both markets.

Each layer of the LM is also at most 16 KiB, so if you want to minimize bank switching, I think making sure each layer is in one bank would be enough? Bank switching shouldn't give much overhead anyway unless it complicates an inner loop, which would be avoided if no layers are split across banks.

Touchegg kinda sucks (gestures are not 1:1 but rather just "triggered"), and you also don't need it. KDE and Gnome (as well as some WMs like Niri) have native touchpad gesture support on Wayland. Using my touchpad for history navigation also works flawlessly on Firefox with two fingers (essentially just horizontal scrolling).

I have no idea what you are saying (with "is"??), but I don't think this is true: KDE Dolphin is very full-featured and runs natively on Wayland.

That's fair! I believe that window positioning also works on XWayland, though, so running your file manager that way should still work with the rest of the system being Wayland (and Gnome has no plans to drop XWayland afaik).

I believe the main holdup is a desire for Wayland to be usable with e.g. VR interfaces where there is no simple 2d grid.

Out of curiosity, how do you want the file manager to behave? And did you write your own or are you using an existing one that works that way?

I think FTE is mostly used as a 'unit'. E.g. if two people work on something 50% of the time, you get one "FTE-equivalent", as there is roughly one full-time employee of effort put in.

Though in this context it just seems to be the number of people working on the code on a consistent basis.

Anecdotally, I strongly doubt this is true, although my environment is probably quite biased. I know a ton of people who use Gnome, some who use KDE, and I think roughly all of these people use them with Wayland. The standalone-WM users I know are also mostly on Sway or other Wayland ones. The only real X11 holdouts seem to be people using X11-only DE's, such as Xfce or Cinnamon.

Rumors of Gnome's demise seem greatly exaggerated to me. It's still the default DE in nearly all major distributions, and it doesn't seem to have incurred major mindshare or marketshare hits recently. I feel like most of the 'complainers' already abandoned the Gnome ship with the release of GNOME 3.

Really the only high-profile 'switch' in recent times I can think of is that Fedora promoted KDE to be first-class ('edition') alongside Gnome, instead of delegated to a more second-class spin. And while KDE is a bit more conservative in this regard, I believe that in the long term KDE also wants to go Wayland-only at some point.

Personally I did switch from Gnome to KDE some time after Gnome 40, since I quite liked 3.x but the UI overhaul 40 did wasn't really my thing. It also helps that KDE got a lot better in recent years.

Where is this Wayland black box then? If anything, Wayland made this situation significantly better: the X11 server was exactly this 'single point of failure black box' you are describing. Wayland replaces this with a much simpler protocol with multiple independent implementations (notably Mutter/gnome-shell, KWin, wlroots-based ones such as sway, and Smithay-based ones such as niri).

I don't think it's true that anything is architecturally or fundamentally broken in Wayland (though if you disagree, I'm very curious what you think is so deeply broken).

Most of the issues and slow adoption were because the core protocol was deliberately kept extremely minimal, and agreeing on all the needed extensions took a long time. Don't take it from me, but rather from KDE developer Nate Graham: https://pointieststick.com/2023/09/17/so-lets-talk-about-thi...

As such, anyone who tried it early probably had to deal with a pretty large amount of non-working stuff, but by now the platform is capable of most features people require and the biggest remaining bottleneck is that software needs to use these new APIs.