Self-hosting Kimi K3: 20% more hardware cost, 20% better task resolution
Posted by flifenstein 5 days ago
Comments
Comment by ktosobcy 5 days ago
Comment by jszymborski 5 days ago
Here are the tok/s I get:
- Gemma-4-26B-A4B (Q4_0) = 214 tok/s
- Gemma4-31B-QAT (Q4_0) = 58 tok/s
- Qwen3.6-35B-A3B (QB_0) = 30 tok/s
- Qwen3.6-27B (QB_0) = 9 tok/s
EDIT: Updated tok/s after updating llama.cpp
Comment by NorwegianDude 4 days ago
Comment by jszymborski 4 days ago
Comment by walrus01 4 days ago
Comment by Ilaurens 5 days ago
Comment by jszymborski 5 days ago
EDIT: Updating llama.ccp gets me 58 tok/s on Gemma 31b
Comment by fhars 4 days ago
Comment by jszymborski 4 days ago
EDIT: I get 259 tok/s with the Q4_K_M quant
Comment by pixelesque 4 days ago
Comment by jszymborski 4 days ago
https://dl.jszym.com/share/boards/pictures/Screenshot_202607...
Comment by mft_ 5 days ago
Comment by flockonus 4 days ago
I find them insufficient for my projects (mid sized), but curious what people see working.
Comment by serf 4 days ago
I use sota models for concept, implementation plans, and initial deployment.
I find that local models can perform at a very high level if given a very strict environment and the already bounded rules of an existing code base.
aye aye aye.
Comment by StopTencent 4 days ago
Comment by colordrops 5 days ago
Comment by jszymborski 5 days ago
Comment by infecto 5 days ago
Obviously does not compare to a leading model but it’s impressive for something that was running on my phone. I could see thinking token output and it’s directionally interesting thought.
Comment by walrus01 4 days ago
Things are moving fast enough these days that llama-server needs to be built from source every 4 or 5 days to keep up with model support and various tweaks in published quantized GGUF files.
Additionally there are a few different tweaks/branches of llama.cpp/llama-server that you can grab and compile to take advantage of changes people have made specific to discrete models and/or types of GPUs.
Comment by incognito124 5 days ago
Comment by Lord-Jobo 5 days ago
…
> spark, costs less than a conference trip.
I know putting actual prices regionally localizes your article and temporally, with how prices are so unstable. But analysis of “what to buy” without actual prices is borderline meaningless.
Overall, good article, very interesting to see a real deployment that’s actually attainable and not just a subscription to a big 3 token plan.
Comment by walrus01 4 days ago
> In our runs, K3 served 16 concurrent sessions (GLM-5.2 managed 24). Aggregate token throughput is about 30% lower (122 vs 170 tok/s at 16 users), and median task time is about 50% longer (38 vs 26 minutes). That makes K3 roughly 8 times slower than our Claude Code baseline. However, K3 makes up for it in quality, resolving 86.4% of tasks, 24 percentage points above both GLM-5.2 and Opus 4.8 (62.5% for both).
I think there's some less tangible advantages to self-hosting something on the scale of Kimi K3 that can't be quantified in a specific number like token/s or percentage of problems solved. Such as:
a) data privacy/sovereignty from a wide range of possible perspectives, from medical to personal to "we can't have our data go to the USA" for some Canadians and Europeans.
b) being able to give it information security/network security tasks and red team scenarios without triggering claude or openai refusals.
c) being able to give it information security/network security tasks with zero risk of getting your account banned or investigated by anthropic or openai.
Comment by personjerry 4 days ago
Comment by walrus01 4 days ago
I imagine that within Anthropic and OpenAI there is a huge data set of "big no no!" topics that they maintain and continually add to. For alignment training and for more blunt purposes. For instance ChatGPT 3.5 could be instructed, as satire, to write a press release in the style of the English language propganda arm of ISIS but they put a stop to that fairly quick.
Comment by joshstrange 5 days ago
Comment by ahachete 5 days ago
Comment by phoghed 5 days ago
Comment by joshstrange 5 days ago
What a strong start to a sentence before veering into a pretty gross equivalency.
Comment by mindwraps 5 days ago
Comment by matheusmoreira 4 days ago
Comment by jckahn 4 days ago
Comment by matheusmoreira 4 days ago
You will nothing, and you'll be happy.
Comment by Capricorn2481 4 days ago
Comment by tuesdaynight 4 days ago
Comment by matheusmoreira 4 days ago
It's these 200kUSD+ nodes with a dozen or more data center class GPUs that are killing the self-hosting dream. The cheapest nodes are is in the same price category as literal houses.
Either we get some competition in this space, or computing will go back to their roots as ivory tower big iron.
Comment by Tuna-Fish 4 days ago
Long term, HBF shouldn't be more than 4x as expensive as commodity flash, and Kimi K3 is an interesting target for a system using it given how aggressively it compresses the KV-cache. An inference box with ~1.5TB of HBF and ~48GB of DRAM should be able to be built for less than a couple of grand, and get something near to 100tok/s on full Kimi K3 for a single token stream.
Comment by michalpleban 5 days ago
Comment by nicman23 4 days ago
Comment by arjie 5 days ago
A decade and a half ago we used to run massive map reduce jobs overnight. Code will be handled like this.
Comment by boomskats 5 days ago
Interesting because again, the license Kimi shipped under [0] defines "Model as a Service" as
> giving a third party access to language model inference or fine-tuning (e.g., via API) in a manner that allows such third party to exercise meaningful control over the inputs, parameters, or training data
and then they have that clause around if you operate such a business above $20M aggregate revenue you need a separate agreement with Moonshot before commercial use, which presumably captures the majority of the larger neoclouds best placed to optimise this.
But where's the line? Say you offer infra optimised for GPU inference, warm pools, isolation per customer, exposed control plane, billed per GPU-hour rather than token, the invoice says compute rather than calls. The customer arguably 'self-hosts', you're probably fine? And if you as a provider run the serving stack and hand your customer an inference API, you're inside the definition regardless of whether you charge by the second or by the token. But what about if you give them direct hardware access, but have the weights cached on NVMe / ramdisk hyperlocal to the infra they're renting so that their hf cli pull only takes a few seconds? Sure, a managed warm pool of GPUs with K3 pre-loaded probably isn't ok, but a local hugging face lru cache holding 'whatever your customers pull down most often', superoptimised for fast weight swaps that the customer controls... is? Is it?
Again, where's the line? Is it materially different from a local docker registry mirror? What about safetensors checkpoints pre-sharded for the specific hardware topology you're offering? Does it matter whether you perform the checkpoint optimisation yourself and make it available, or merely cache one published on HF that happens to target exactly the hardware you rent out? What if you published that checkpoint yourself?
I'm definitely overthinking this, and I'm sure there's been conversation here about this already, but the other kimi threads[1] are enormous. And I am curious.
I'm also curious to know whether Moonshot would actually be against a setup like this. Guessing they would if it was AWS (not quite elastic but not that dissimilar), but what about others? Realistically I guess it'd be easier to just talk to them, especially if you were doing it in a way that targets a slice of the pie they never would have gotten anyway due to data residency requirements etc..
[0]: https://huggingface.co/moonshotai/Kimi-K3/blob/main/LICENSE [1]:https://news.ycombinator.com/item?id=49065752
Comment by martinjc 5 days ago
Comment by zop_10 12 hours ago
Comment by flifenstein 5 days ago
Let us know your thoughts, we really value feedback!
Comment by michalpleban 5 days ago
Comment by NitpickLawyer 5 days ago
Comment by johndough 4 days ago
Comment by mindwraps 5 days ago
Comment by walrus01 4 days ago
Unsloth Q4 is 1.51TB which doesn't really help much and isn't likely to be any different in performance.
Unsloth Q2-K-XL is 861GB and could possibly fit on 1TB resources but I would want to see a very thorough series of tests to see how much knowledge and capability is lost between it and the full thing.
Using an example from the much smaller gemma 4 31B because it's a decent set of charts I could find quickly, I don't know if anyone has published KL divergence charts for Q4 vs Q4 vs Q8 of Kimi K3:
https://localbench.substack.com/p/gemma-4-31b-gguf-kl-diverg...
Comment by deflator 5 days ago
The value proposition changes a lot if you can get 90% of the quality for 50% the price with a quant due to halving your hardware requirement.
Thank you for the article, though! Very informative.
Comment by lcampbell 4 days ago
Is that actually the aggregate throughput? 8xB300 (with 4TB/s/GPU bandwidth) is only pushing 8 tg/s/session? That seems… incredibly low, even for an A100B model.
Is it actually 122 tg/s per session? (1952 tg/s aggregate throughout)?
Comment by Openk3 4 days ago
Comment by legastenigga 4 days ago