- *for certain definition of self hosted.
Developed by Chinese open weights model dev Z.ai, GLM 5.1 isn’t exactly a small model. At roughly 754 billion total parameters (40 billion activated for each token generated), the model requires roughly 380 GB of GPU memory just to hold the weights and another 6-26 GB per user to maintain context depending on precision.
To serve GLM-5.3 at scale, Revolut deployed 56 Nvidia B200 GPUs, equivalent in GPU count to seven eight-GPU DGX B200 systems. But as Abitbol noted, the greatest performance gains didn’t come from adding GPUs, but rather tuning the model’s hyperparameters along with switching to NVFP4 quantization, implementing disaggregated prefill and decode, and tuning context lengths.
The quoted numbers are the interesting part. 380 GB just for weights plus several GB of context per user means this only pays off at Revolut’s scale. What stood out to me is that the article credits the biggest gains to NVFP4 quantization, splitting prefill and decode, and context tuning rather than adding GPUs. Those tricks carry over to much smaller setups too.
Agreed. Economies of scale are about the only way this makes sense.
I was just working thru the use case for purchasing a 64gb Strix (vs the typical coding I might do using OR or Open Code Go). The ROI is somewhere in the order of 7-10 years for me. So, on a purely dollar cost basis, local inference is $$$. OTOH, from a sovereignty and “own your own code” basis…there’s something to be said for it.
Probably I will run a few tests using OR with a few outstanding tickets of mine, to kick the tyres of Qwen3.8-27B. I’ve tried Qwen3.6-35B and frankly it’s…not very good at code gen or patching.
To boot, code gen isn’t the only thing I use LLM for, so I suppose it depends on how bloody minded I want to be about future use case (I do actually have one).
FWIW I wouldnt recommend a 64GB strix halo for local LLM inference. I use a 128GB framework desktop for running qwen-flash-next which it just manages at Q4_K at a reasonable rake of 20-30 tk/s qwen27B is sloooow on it due to strix halo’s lower memory throughput than either a GPU or a integrated memory mac.
Though its possible this advice will change in the next few weeks with the release of Qwen4.
Absolutely. And given my druthers, I’d grab the 128. The issue is, it’s about triple the cost locally vs the 64.
I’m going to have to benchmark QFN or hell, even Qwen3.6-35B to see if they are capable for the tasks I want in the constrained environment (at sea, solar powered).
I won’t go into the minutae, but tasks like this via Signal K MCP- using wake word, STT and TTS
Me: “Hey Boat, how far are we from Palau?”
Boat: “We are 420 nautical miles from Palau, with approximately 510 nautical miles remaining on our planned route.”
Me: “What is the weather like?” Boat: “The wind is south-westerly at 12 knots. The barometer reads 1016 hPa. Our latest forecast indicates stronger winds tomorrow.”
Me: “And the day after that?” Boat: “The latest 7 day forecast indicates increasing winds tomorrow afternoon. Would you like the details?”
Me: “Yes. And given our present course, should we consider another anchorage?”
Boat: “Possibly. Let me compare the forecast with nearby anchorages and their exposure.”
IOW, the MCP system communicating and tallying actual on board sensors to help with navigation, decision making etc.
I probably won’t need to vibecode the next $1M ARR SAAS while pottering around the Western Pacific but I will need something small, smart and fast that can work onboard within constrained power envelope (say… 3kwh per day across all systems).
For something that can WoL (I use a Raspberry pi as an always on SBC), answer my question and then piss off without gobbling power, the Strix looks promising.