Genuine question: how reproducible / usable / verifiable are these architectures from the published documentation? Are they similar to PDF/DWG/PSD specifications, where the format look like an open spec at first sight until you attempt to implement it and realize the crucial implementation details are undocumented?
Implementing models directly from papers is typically pretty doable (and is of course more straightforward when the full implementation is open sourced). Often there is some amount of specific knowledge, like particular hyperparameters, that is missing and has to be trial and errored by the community, but generally speaking, getting the core model architecture implemented is a reasonable task for most well documented models.
Reproducing the exact training run, however, is basically impossible without the original dataset and training pipeline (here meaning all of the code + infra involved in actually executing the pre and post training loops). Also, it would be exorbitantly expensive to do if you weren't also a lab trying to train a similar model.
But you can still scale the architecture down and experiment as a solo researcher using the published research. There are probably some open source implementations already on GitHub for any given big open model release.
The exact training run is basically impossible anyway. Randomness plays a role. Even if you fix your RNG seed, in a distributed training scenario like this one some weight updates might come at different times and be included in different update steps. Should have minimal impact on the final outcome, but would still be a different model as some of the weights will differ in the end.
The architectures are high level concepts and the mechanics usually have enough detail for you to try and implement.
Transformers are very "mendable" in that you can permute the architecture in crazy or random ways, and still basically always end up with get a coherent LLM. The difference comes down to training efficiency, inference efficiency, and usually minor differences in performance.
Hyperparams and stuff, I mean it's standard to do a sweep anyway.
It's entirely reproducible from the available documentation (which is why you see vLLM, SGLang, MLX etc all racing to produce optimized implementations).
(As an aside, this is why the "open weights are not open source" thing is a complete misunderstanding. The weights themselves along with the documentation give you enough to fine tune the LLM. You can't rebuild it from scratch, but you can't do this even with the data anyway (because of randomness!))
I agree that if you have the weights you can use/train a model with the same architecture, and that you won't get the exact weights on your own due to randomness. But isn't data an extremely important part of your ability to effectively train/finetune? It might be much harder to get close to the level of the open weight model if you don't have the data that made it, which is why I think the open weights vs open source distinction is useful.
Isn’t this a bit like saying “ ‘open object files are not open source’ is a complete misunderstanding” because “You can’t rebuild the executable from scratch, but you can’t do this even with the source code anyway (because of build nondeterminism / compiler versions / etc.)”?
Depends on your compiler. You could have a compiler that deliberately uses randomised algorithms. They are often faster and easier to understand and write.
Though in practice you can get all the benefits of both determinism and (that kind of) randomisation by using a PRNG and saving the seed you are using.
It's an open question roughly on par with P vs NP whether true randomisation is ever necessary, or whether PRNGs are enough. So far we haven't found any problem or algorithm where true RNG is necessary and good PRNG ain't enough.
Also, most (optimizing) compilers ”optimize” the code for a fixed amount of time, leading to better optimized binaries on faster computers. That’s why developers should have as fast computers money can buy!
> (As an aside, this is why the "open weights are not open source" thing is a complete misunderstanding. The weights themselves along with the documentation give you enough to fine tune the LLM. You can't rebuild it from scratch, but you can't do this even with the data anyway (because of randomness!))
They could give you the random seeds? (Assuming you carefully train in such a way to remove other sources of randomness, like concurrent execution.)
> It's entirely reproducible from the available documentation
You have a very interesting understanding of "reproducibility", I'll give you that :)
But even with that, there are plenty of technical details (especially in regards to the training process) missing from the tech report that leads to these weights not being reproducible in any sense of that word.
But what's the point of even saying that? Of course it is, otherwise how is it supposed to run in the runtimes? You cannot release model weights that others can run, without also releasing the model architecture, it's in the code at the very least...
There's more to open source than reproducibility. For instance introspection which is even more important with weights since detection of backdoors in models is NP hard IIRC.
Good question, it's 100%. I.e., the developers usually share a reference implementation with e.g., Hugging Face transformers to load their weights, and from there on you can read the code and, if you have time, reimplement and check everything. It's actually a great learning exercise where you can self-check whether you reimplemented it correctly by comparing the LLM outputs to the reference implementation. Made a video about that workflow a while back here: https://www.youtube.com/watch?v=TXzQ7PGpO6w
I wonder if Kimis KDA architecture is a way closer to online models(models that learn during interference).As KDA updates its state matrix:
St =St−1 +βt (vt −St−1 kt )ktT
The expression (vt −St−1 kt )ktT is literally the gradient step of a linear regression model updating its weights (S) on a single sample using Mean Squared Error loss.
Interesting what other labs comes up with from this.
His was the only Packt book (on ML, circa 2019 IIRC) that I have never regretted purchasing. Clear thinker, attention to details, and clean coder. Highly recommend.
"Interestingly, Kimi K3 got rid of all RoPE layers and uses NoPE (No Positional Embeddings) everywhere instead."
It just baffles me that this even works at all. Doesn't it just become a token soup? Is attention that precise that a second token can tell its the second token just because it learns to accumulate something in the embedding space without any sort of inductive bias?
And adding to that, there is also the recurrent state in the Kimi Delta Attention. I wouldn't call it position information but more sth like "position sensitivity"
"Kimi K3 uses no explicit positional embedding (NoPE), and instead encodes positional information implicitly through the recurrent gating and decay mechanism of KDA."
As a sibling comment points out you don't strictly need positional embeddings for decoder-only causal transformers. You definitely need it for non-causal ones (e.g. the encoder of the original transformer paper!).
And yes accumulation is a good intuition for what's going on. You could imagine a part of the attention head that just kept writing to the same part of the residual stream causing that to keep accumulating (simply via attention summation) as more input tokens come in thereby functioning as a kind of index without the need for any positional encoding.
Linear layers use decays (like IIR filters) that naturally provide relative positions. Full attention layers can then be free to develop concepts that attend to each other regardless of distance.
When you have recurrent blocks in your model, you implicitly have a timestep T(amount of recurrent steps). Similar to Diffusion Transformers, it then becomes valuable to encode the knowledge of where you are in this chain somehow. NoPE is more flexible than RoPE for this.
I feel like the Kimi team is amongst the best in the industry to pick and choose what is meaningful from the other models. For example, avoiding the expensive and empirically uncertain mHC in favor of simpler residuals. Latent MoE.
My only doubts are around Linear Attention instead of DSA as this is inherently lossy. You are kind of banking on that your query is inherently in the embedding space of the model already and can be lossy.
Anybody getting the result that Kimi 3 is more expensive than Opus 5 or Sol on Cursor? Pretty sure Kimi 3 sucked up a good chunk of my ultimate plan in a few prompts. Anyone have any tools or ways to understand per model usage towards cursor subscriptions? I know there are alternatives to cursor just haven’t made the move yet. (Edit spelling)
The assertions doing the rounds that Kimi K3 and GLM 5.2 are way cheaper than Claude/GPT are not true -- DeepSeek V4 Pro is a lot cheaper but K3 and 5.2 ain't. Turns out that you actually have to fork out some cash for frontier-esque models, be they Chinese or American. Hope that helps.
Just tried K3 out for the first time today and it's a legitimate threat.
Temporarily (maybe permanently) using it as my daily driver but it's wild how comparable it is to Opus 4.7/4.8 (what's been my go to for a bit now—wrote a quick post on what I found today [1]).
Better than Opus 4.8 on complex tasks but tends to overthink.
It found a bunch of bugs and architecture issues that only 5.6 Sol Max and Fable on my C++ projects.
For me it got exhausted faster than I'd like, subjectively less value than the Anthropic 100 USD subscription, BUT their 5 hour limits are very generous, whereas I keep bumping into Anthropic's all the time: https://blog.kronis.dev/blog/kimi-k3-is-out-is-anthropic-don...
Their 200 USD tier is pretty good and I might move to them because their annual discounts also make it even cheaper. I dislike the way how Opus/Fable write and Kimi has less of that slop writing problem, but also ends up feeling kinda slower (especially on Max reasoning), technical abilities are not 100% the same but close (better in some tasks, worse on others).
Great breakdown. After using Kimi extensively, it's fascinating to see how architectural choices like KDA and NoPE translate into such strong real-world performance. Really impressive engineering.
So, unlike what leaders of western labs labs would like you to believe (that Kimi is just the result of distillation attacks), they are introducing new and novel approaches.
Even if they are distilling, I don't particularly care. Anthropic and others have been distilling copyrighted material by to build these models, largely without permission.
"Kimi is largely a byproduct of distillation" and "Kimi is introducing new and novel approaches" are not mutually exclusive, and I'm not sure it's clear from the paper how much of the improvement comes from the new approaches. So I wouldn't take the new approaches to be much evidence about whether the distillation attacks occurred.
I thought there is discussion circulating around whether the main reason Kimi is impressive is due to distillation. Though possibly if this occurred, this was just one component of their training pipeline and not a majority
Moreover, Distillation is a misused term here. Distillation means training a smaller student model using a larger teacher model to completely mimic its behavior. As in you take a base model and create its smaller “turbo” version. Like distillation in Chemistry it means it’s %100 purified version of its teacher.
They may have all this amazing architecture but Kimi has been super dumb recently. I reckon they’re under compute pressure and quantising to stay afloat. I was a heavy k2.5/2.6 user earlier in the year and built serious features with it, but even k3 now does stupid shit like fail tool calls and get stuck in endless thought trains. K2.6 was spinning its wheels on a problem for over 10 minutes today and then deepseek v4 fixed it in under a minute.
Good to hear. Most likely one of those monthly hickups, destroying main. Needed lots of reverts, and manual fixing. If in a branch I wouldn't care that much.
Yeah something is up. I have the same problem with K3 as I had with earlier kimis. I ask it to write <bash>code</bash> every turn, that does not seem very difficult, but kimi gets this wrong a large percentage of the time. Yet, the code it writes is pretty good.
kimi K3 felt on par with my claude opus 4.8 in my first tests and is exceptionally good at frontend and website motion design, but I still find it hard to switch back and forth between claude and kimi, and i’m not sure if others are experiencing the same thing.
I know some of these words, but I'd like to understand all of it better. Would anyone be so kind as to recommend a good learning resource for LLM design and the math involved?
Interesting that they went NoPE everywhere — everyone else hedges with RoPE in the local layers. Feels like the linear-attention stuff (Kimi Delta) is quietly doing the positional work so they can get away with it. Curious to see if it holds up at frontier scale.
Is frontier scale larger than this? Kimi K3 seems to benchmark in the same range as Opus and Fable. I would have expected they are all in the 2-4T range, with quality of the training and architecture differences as the major differentiators
The number of active parameters is vastly different. Deepseek CEO hinted that he estimates it as an order of magnitude difference in one of his recent interviews.
Kimi Delta Attention (KDA), despite having "Attention" in the name, isn't really attention at all in any conventional sense. It's more like an RNN which can be efficiently parallelized during training. It's a very small modification to Gated DeltaNet, which can be described as an RNN whose hidden state acts like a small, editable attention memory.
Because it's RNN-like, it has an inherent idea that X comes before Y which comes before Z in the sequence XYZ. Transformers, by default, don't have that. They operate on sets, unordered collections of unique items. They have no idea where those items are in relation to each-other so you have to clue them in.
Because There are 3 KDA layers per attention layer, and 3 KDA layers before the first attention layer, every single token position is going to be able to learn information about where it is in the sequence before the first actual attention layer.
RoPE is actually a bit destructive, so being able to omit it like this is very convenient. Models like Gemma-4 have a similar structure with 5:1 Sliding Window Attention (SWA) layers for every global attention layer. These are cheap, shitty attention layers which handle local information and which go in-between the big powerful ones, KDA serves the same role in this model. In Gemma only the SWA layers have RoPE while the global attention layers omit it. SWA is actual attention, even if it only operates on a small sliding window, so it needs the positional embedding. KDA isn't, so it doesn't.
>Curious to see if it holds up at frontier scale.
I don't know how much more frontier scale you can get than this, but yes, there's no reason why that wouldn't work at larger scales. Honestly, more parameters just makes it easier for the KDA layers to communicate that positional information better.
It has some weird side effects though. for example KV-caches are implemented in fixed incremental token blocks (1024 from the providers I used) instead of simply caching up to the most recent input prompt input. It results in up to 1023 additional input (cache miss) tokens per inference.
Sounds a lot like running the Qwen3.5/3.6-series models at home: you need checkpoints for the recurrent state (GDN in the case of Qwen). You avoid the miss for the common case of 100% prefix match (e.g. during interleaved tool calls and thinking) by keeping an additional checkpoint for the actual last generated token. If you're a cloud provider serving many concurrent clients then you might prefer to skip that complexity and always take the 1k worst-case prefill hit.
SWA has a similar issue. Unless you keep the entire KV prefix lying around (which is not unreasonable: you retain flop + bandwidth benefits but lose capacity benefits), you need to start 1 window back from the rollback point, in order to refill the sliding window before going into normal prefill.
Genuine question: how reproducible / usable / verifiable are these architectures from the published documentation? Are they similar to PDF/DWG/PSD specifications, where the format look like an open spec at first sight until you attempt to implement it and realize the crucial implementation details are undocumented?
The code is open source, and there probably several different implementations.
Implementing models directly from papers is typically pretty doable (and is of course more straightforward when the full implementation is open sourced). Often there is some amount of specific knowledge, like particular hyperparameters, that is missing and has to be trial and errored by the community, but generally speaking, getting the core model architecture implemented is a reasonable task for most well documented models.
Reproducing the exact training run, however, is basically impossible without the original dataset and training pipeline (here meaning all of the code + infra involved in actually executing the pre and post training loops). Also, it would be exorbitantly expensive to do if you weren't also a lab trying to train a similar model.
But you can still scale the architecture down and experiment as a solo researcher using the published research. There are probably some open source implementations already on GitHub for any given big open model release.
The exact training run is basically impossible anyway. Randomness plays a role. Even if you fix your RNG seed, in a distributed training scenario like this one some weight updates might come at different times and be included in different update steps. Should have minimal impact on the final outcome, but would still be a different model as some of the weights will differ in the end.
> Should have minimal impact on the final outcome, [...]
I share this expectation. But this is an interesting empiric question that deserves study; even if just to confirm what 'everyone knows'.
Reproducibility isn’t something that has been considered desirable in many pipelines until recent years.
Heck even ffmpeg introduce randomness when stitching together downloaded chunks from youtube. By design.
The architectures are high level concepts and the mechanics usually have enough detail for you to try and implement.
Transformers are very "mendable" in that you can permute the architecture in crazy or random ways, and still basically always end up with get a coherent LLM. The difference comes down to training efficiency, inference efficiency, and usually minor differences in performance.
Hyperparams and stuff, I mean it's standard to do a sweep anyway.
It's entirely reproducible from the available documentation (which is why you see vLLM, SGLang, MLX etc all racing to produce optimized implementations).
(As an aside, this is why the "open weights are not open source" thing is a complete misunderstanding. The weights themselves along with the documentation give you enough to fine tune the LLM. You can't rebuild it from scratch, but you can't do this even with the data anyway (because of randomness!))
> open weights are not open source" thing is a complete misunderstanding
> You can't rebuild it from scratch
There's is extremely clear and misunderstanding-free.
Open weights is not open source.
I agree that if you have the weights you can use/train a model with the same architecture, and that you won't get the exact weights on your own due to randomness. But isn't data an extremely important part of your ability to effectively train/finetune? It might be much harder to get close to the level of the open weight model if you don't have the data that made it, which is why I think the open weights vs open source distinction is useful.
Isn’t this a bit like saying “ ‘open object files are not open source’ is a complete misunderstanding” because “You can’t rebuild the executable from scratch, but you can’t do this even with the source code anyway (because of build nondeterminism / compiler versions / etc.)”?
not really, compiling isnt a heuristic problem, it has a lot less randomness involved
Depends on your compiler. You could have a compiler that deliberately uses randomised algorithms. They are often faster and easier to understand and write.
Though in practice you can get all the benefits of both determinism and (that kind of) randomisation by using a PRNG and saving the seed you are using.
It's an open question roughly on par with P vs NP whether true randomisation is ever necessary, or whether PRNGs are enough. So far we haven't found any problem or algorithm where true RNG is necessary and good PRNG ain't enough.
Also, most (optimizing) compilers ”optimize” the code for a fixed amount of time, leading to better optimized binaries on faster computers. That’s why developers should have as fast computers money can buy!
there's a reason reproducible builds are a thing and most compilations aren't
> (As an aside, this is why the "open weights are not open source" thing is a complete misunderstanding. The weights themselves along with the documentation give you enough to fine tune the LLM. You can't rebuild it from scratch, but you can't do this even with the data anyway (because of randomness!))
They could give you the random seeds? (Assuming you carefully train in such a way to remove other sources of randomness, like concurrent execution.)
Do AI labs even keep track of seeds? They don't even keep the checkpoints most of the time.
> You can't rebuild it from scratch
> It's entirely reproducible from the available documentation
You have a very interesting understanding of "reproducibility", I'll give you that :)
But even with that, there are plenty of technical details (especially in regards to the training process) missing from the tech report that leads to these weights not being reproducible in any sense of that word.
> You have a very interesting understanding of "reproducibility", I'll give you that :)
He was talking about two different things, hence the parentheses. The architecture is reproducible, not the model weights.
> The architecture is reproducible
But what's the point of even saying that? Of course it is, otherwise how is it supposed to run in the runtimes? You cannot release model weights that others can run, without also releasing the model architecture, it's in the code at the very least...
Because for other specs it's not the case.
The K3 arch can be implemented from the spec.
A PDF reader can not be implemented from the spec.
the beginning of the arguments was good but the "because of randomness" is wild
There's more to open source than reproducibility. For instance introspection which is even more important with weights since detection of backdoors in models is NP hard IIRC.
Good question, it's 100%. I.e., the developers usually share a reference implementation with e.g., Hugging Face transformers to load their weights, and from there on you can read the code and, if you have time, reimplement and check everything. It's actually a great learning exercise where you can self-check whether you reimplemented it correctly by comparing the LLM outputs to the reference implementation. Made a video about that workflow a while back here: https://www.youtube.com/watch?v=TXzQ7PGpO6w
I wonder if Kimis KDA architecture is a way closer to online models(models that learn during interference).As KDA updates its state matrix: St =St−1 +βt (vt −St−1 kt )ktT
The expression (vt −St−1 kt )ktT is literally the gradient step of a linear regression model updating its weights (S) on a single sample using Mean Squared Error loss.
Interesting what other labs comes up with from this.
Sabastian Raschka is one of the great LLM researchers/authors. I highly recommend his substack
I second that. I've always enjoyed his work!
This seems like a rare gem in a space swamped with lazily LLM generated summaries. Added to my RSS feed!
His was the only Packt book (on ML, circa 2019 IIRC) that I have never regretted purchasing. Clear thinker, attention to details, and clean coder. Highly recommend.
Never heard of him before but I was amazed how straight to the point yet very easy to grasp it was
I would describe him as a leading educator / explainer / teacher in this space.
Thoguhtleader
Thoughtleader as a brand is oversubscribed. Trusted is way less so -- and he is both.
"Interestingly, Kimi K3 got rid of all RoPE layers and uses NoPE (No Positional Embeddings) everywhere instead."
It just baffles me that this even works at all. Doesn't it just become a token soup? Is attention that precise that a second token can tell its the second token just because it learns to accumulate something in the embedding space without any sort of inductive bias?
Causal masking allow model to learn implicit positional embeddings. The meme that a transformer block is permutation invariant is not true.
And adding to that, there is also the recurrent state in the Kimi Delta Attention. I wouldn't call it position information but more sth like "position sensitivity"
The paper says:
"Kimi K3 uses no explicit positional embedding (NoPE), and instead encodes positional information implicitly through the recurrent gating and decay mechanism of KDA."
As a sibling comment points out you don't strictly need positional embeddings for decoder-only causal transformers. You definitely need it for non-causal ones (e.g. the encoder of the original transformer paper!).
And yes accumulation is a good intuition for what's going on. You could imagine a part of the attention head that just kept writing to the same part of the residual stream causing that to keep accumulating (simply via attention summation) as more input tokens come in thereby functioning as a kind of index without the need for any positional encoding.
Linear layers use decays (like IIR filters) that naturally provide relative positions. Full attention layers can then be free to develop concepts that attend to each other regardless of distance.
At least the SSM layers should have relative PE built in via recurrence, in a hybrid attention model like this.
The primary author of RoPE, Jianlin Su, is currently working at Moonshot (KIMI)
When you have recurrent blocks in your model, you implicitly have a timestep T(amount of recurrent steps). Similar to Diffusion Transformers, it then becomes valuable to encode the knowledge of where you are in this chain somehow. NoPE is more flexible than RoPE for this.
I feel like the Kimi team is amongst the best in the industry to pick and choose what is meaningful from the other models. For example, avoiding the expensive and empirically uncertain mHC in favor of simpler residuals. Latent MoE.
My only doubts are around Linear Attention instead of DSA as this is inherently lossy. You are kind of banking on that your query is inherently in the embedding space of the model already and can be lossy.
They need to work on token cost for unrestrained problem solving.
Anybody getting the result that Kimi 3 is more expensive than Opus 5 or Sol on Cursor? Pretty sure Kimi 3 sucked up a good chunk of my ultimate plan in a few prompts. Anyone have any tools or ways to understand per model usage towards cursor subscriptions? I know there are alternatives to cursor just haven’t made the move yet. (Edit spelling)
Oh no! First time dealing with an American corporation?
The assertions doing the rounds that Kimi K3 and GLM 5.2 are way cheaper than Claude/GPT are not true -- DeepSeek V4 Pro is a lot cheaper but K3 and 5.2 ain't. Turns out that you actually have to fork out some cash for frontier-esque models, be they Chinese or American. Hope that helps.
Source: my bank balance
is it cheaper for medium scale folks? not everyone needs to go big on ai subscriptions and a solid, reliable midrange option wouldn't go amiss
A few diagrams showing how the data flows through the architecture would make these concepts much easier to grasp.
Ask Kimi
Just tried K3 out for the first time today and it's a legitimate threat.
Temporarily (maybe permanently) using it as my daily driver but it's wild how comparable it is to Opus 4.7/4.8 (what's been my go to for a bit now—wrote a quick post on what I found today [1]).
[1] https://graybearding.bearblog.dev/kimi-k3-is-insane/
Better than Opus 4.8 on complex tasks but tends to overthink. It found a bunch of bugs and architecture issues that only 5.6 Sol Max and Fable on my C++ projects.
Agreed. Dropped my $200/mo Claude I was saturating for the $100/mo moonshot sub and have no complaints
Plus I can actually see the thinking traces and I’m not getting downgraded/denied by anthropic constsntly…
How much usage do you get out of the $100 Moonshot plan? I haven't heard great things.
For me it got exhausted faster than I'd like, subjectively less value than the Anthropic 100 USD subscription, BUT their 5 hour limits are very generous, whereas I keep bumping into Anthropic's all the time: https://blog.kronis.dev/blog/kimi-k3-is-out-is-anthropic-don...
Their 200 USD tier is pretty good and I might move to them because their annual discounts also make it even cheaper. I dislike the way how Opus/Fable write and Kimi has less of that slop writing problem, but also ends up feeling kinda slower (especially on Max reasoning), technical abilities are not 100% the same but close (better in some tasks, worse on others).
threat?
that's a weird way of describing a near frontier open weights un-crippled useful coding buddy
do you work for OpenAI or Anthropic per chance?
I work for myself. A quick check of my profile here would make that clear.
And yes, it's a legitimate threat to frontier models. Both K3 and the distillation approach.
Great breakdown. After using Kimi extensively, it's fascinating to see how architectural choices like KDA and NoPE translate into such strong real-world performance. Really impressive engineering.
So, unlike what leaders of western labs labs would like you to believe (that Kimi is just the result of distillation attacks), they are introducing new and novel approaches.
No! It's just not fair!! What about our financial bubble!
"attack"
Even if they are distilling, I don't particularly care. Anthropic and others have been distilling copyrighted material by to build these models, largely without permission.
Exactly,let Anthropic get back to training on the New York times.
"Kimi is largely a byproduct of distillation" and "Kimi is introducing new and novel approaches" are not mutually exclusive, and I'm not sure it's clear from the paper how much of the improvement comes from the new approaches. So I wouldn't take the new approaches to be much evidence about whether the distillation attacks occurred.
> distillation attacks
Like the distillation “attacks” Anthropic conducted against literally millions and millions of different creators?
Scanning google is an ‘attack’
Reading Claude's outputs is an 'attack'
Or against all those old books that they ingested and then literally destroyed
Even Anthropic hasn't claimed "Kimi is largely a byproduct of distillation"
There's been some distillation.
Just like how Elon said in court they distill to make Grok.
I thought there is discussion circulating around whether the main reason Kimi is impressive is due to distillation. Though possibly if this occurred, this was just one component of their training pipeline and not a majority
Moreover, Distillation is a misused term here. Distillation means training a smaller student model using a larger teacher model to completely mimic its behavior. As in you take a base model and create its smaller “turbo” version. Like distillation in Chemistry it means it’s %100 purified version of its teacher.
They may have all this amazing architecture but Kimi has been super dumb recently. I reckon they’re under compute pressure and quantising to stay afloat. I was a heavy k2.5/2.6 user earlier in the year and built serious features with it, but even k3 now does stupid shit like fail tool calls and get stuck in endless thought trains. K2.6 was spinning its wheels on a problem for over 10 minutes today and then deepseek v4 fixed it in under a minute.
Something is wrong at moonshot.
Deepseek is also struggling with simple tasks for the last two days. Claude is perfect, with the additional credits.
I’ve had no issues with deepseek at all. Maybe it’s just luck of the draw
Good to hear. Most likely one of those monthly hickups, destroying main. Needed lots of reverts, and manual fixing. If in a branch I wouldn't care that much.
I have a lot of problems with Opus 5 in the last days. So, maybe the problem is to expect reliability from something probabilistic?
Might be a bit more than just noise: https://marginlab.ai/trackers/claude-code-historical-perform...
Edit: well, crap.
Thanks, Anthropic.
Yeah something is up. I have the same problem with K3 as I had with earlier kimis. I ask it to write <bash>code</bash> every turn, that does not seem very difficult, but kimi gets this wrong a large percentage of the time. Yet, the code it writes is pretty good.
kimi K3 felt on par with my claude opus 4.8 in my first tests and is exceptionally good at frontend and website motion design, but I still find it hard to switch back and forth between claude and kimi, and i’m not sure if others are experiencing the same thing.
i like your detailed breakdown. Thanks. <3
I know some of these words, but I'd like to understand all of it better. Would anyone be so kind as to recommend a good learning resource for LLM design and the math involved?
Concise. Nice.
Interesting that they went NoPE everywhere — everyone else hedges with RoPE in the local layers. Feels like the linear-attention stuff (Kimi Delta) is quietly doing the positional work so they can get away with it. Curious to see if it holds up at frontier scale.
Is frontier scale larger than this? Kimi K3 seems to benchmark in the same range as Opus and Fable. I would have expected they are all in the 2-4T range, with quality of the training and architecture differences as the major differentiators
The number of active parameters is vastly different. Deepseek CEO hinted that he estimates it as an order of magnitude difference in one of his recent interviews.
> Seems to benchmark
yes, but in human usage the differences show up
Would you happen to have a link to that interview? Sounds like an interesting read.
It was posted to HN a few days back
1. https://news.ycombinator.com/item?id=49019012 (original chinese)
2. https://news.ycombinator.com/item?id=49052912 (translated english [pdf])
It's related to this: https://news.ycombinator.com/item?id=49052912
Kimi Delta Attention (KDA), despite having "Attention" in the name, isn't really attention at all in any conventional sense. It's more like an RNN which can be efficiently parallelized during training. It's a very small modification to Gated DeltaNet, which can be described as an RNN whose hidden state acts like a small, editable attention memory.
Because it's RNN-like, it has an inherent idea that X comes before Y which comes before Z in the sequence XYZ. Transformers, by default, don't have that. They operate on sets, unordered collections of unique items. They have no idea where those items are in relation to each-other so you have to clue them in.
Because There are 3 KDA layers per attention layer, and 3 KDA layers before the first attention layer, every single token position is going to be able to learn information about where it is in the sequence before the first actual attention layer.
RoPE is actually a bit destructive, so being able to omit it like this is very convenient. Models like Gemma-4 have a similar structure with 5:1 Sliding Window Attention (SWA) layers for every global attention layer. These are cheap, shitty attention layers which handle local information and which go in-between the big powerful ones, KDA serves the same role in this model. In Gemma only the SWA layers have RoPE while the global attention layers omit it. SWA is actual attention, even if it only operates on a small sliding window, so it needs the positional embedding. KDA isn't, so it doesn't.
>Curious to see if it holds up at frontier scale.
I don't know how much more frontier scale you can get than this, but yes, there's no reason why that wouldn't work at larger scales. Honestly, more parameters just makes it easier for the KDA layers to communicate that positional information better.
It has some weird side effects though. for example KV-caches are implemented in fixed incremental token blocks (1024 from the providers I used) instead of simply caching up to the most recent input prompt input. It results in up to 1023 additional input (cache miss) tokens per inference.
Sounds a lot like running the Qwen3.5/3.6-series models at home: you need checkpoints for the recurrent state (GDN in the case of Qwen). You avoid the miss for the common case of 100% prefix match (e.g. during interleaved tool calls and thinking) by keeping an additional checkpoint for the actual last generated token. If you're a cloud provider serving many concurrent clients then you might prefer to skip that complexity and always take the 1k worst-case prefill hit.
SWA has a similar issue. Unless you keep the entire KV prefix lying around (which is not unreasonable: you retain flop + bandwidth benefits but lose capacity benefits), you need to start 1 window back from the rollback point, in order to refill the sliding window before going into normal prefill.
This comment smells LLM generated.
"Quietly"
"at frontier scale"
"—"
Screams it in fact
Huh, which model? I didn't pick up any of the tells. It seemed normal enough to me. (I vouched it, oops.)
Telling which model wrote it is much harder than telling that some model wrote it.