Live data from Hacker News

Kimi-K3 Technical Report [pdf]

github.com

131–140 of 199 posts

Re: Kimi-K3 Technical Report [pdf]

#131
post #56

Does anyone know if a torrent is available? I think it would take quite a while to download 1.5tb from their servers.

Your best bet will be to start a network optimized ec2 (or gcp compute instance) and save to some bucket. Cloud network will be a lot more stable than home.

Re: Kimi-K3 Technical Report [pdf]

#132
post #112

It's funny that we've finally returned to tanh activation functions, time is a circle.

From the paper (page 6 with a comparison to GLU and SwiGLU) they are not using tanh directly (i.e. f(x) = tanh(x)) but: f_gate(b,x) = b * tanh(x / b) * sigmoid(x) f_up(b,x) = b * tanh(x / b) Looking at the graph I wonder if this is to try and get the best of both GLU (better representation at higher values of x >~ 5) and SwiGLU (the value bump just before 0).

Which part of that is doing gating? I thought gate generally looks like

    f_gate(x, y) = f(x) * y
for some f. In your case b is a constant hyperparameter though, e.g.

    f_gate(x) = 4 * tanh(x / 4) * sigmoid(x)
So where's the gate?

Re: Kimi-K3 Technical Report [pdf]

#133

Earlier quoted context omitted.

Exactly. I wish people would just stop saying "open source" regarding models. Even "open weight" is disingenuous. "self-hostable" would be more honest.

It's a gradient almost, with some steps. So far, I think you could categorize every single released so far as one of: - Proprietary - No access beyond remote endpoints - Downloadable - You can run it, but there are restrictions and training data/code isn't public and/or under FOSS license, nor are the weights under a FOSS license - Open weights - The weights are under a FOSS license and downloadable without restricti…

"Downloadable" should be "weights available" by analogy to "source available". K3 is weights available because it includes usage restrictions. K2.6 is open weights, because the only restriction is a weaker version of the "obnoxious BSD advertising clause", which is accepted as FOSS.

Re: Kimi-K3 Technical Report [pdf]

#135

Back of the envelope calculation (could be off, correct me if I am) If you are a large enough company that spends million+ on inference a month, it makes sense to buy a GB300 rack ($6M on top range from what I could find) which has 20.7 TB. Since the model is mixed trained (MXFP4), you would need less than 10% of the rack's memory to serve the full model. Aggregate HBM bandwidth: 576 TB/s. You can run over 6000 paral…

We're running Kimi 2.8 on a $107k server and getting around 50k tokens per second or better on most things.

We've already saved money compared to last years token cost on Claude/Gemini

Re: Kimi-K3 Technical Report [pdf]

#137
post #32

Earlier quoted context omitted.

I wonder how they'll figure out who to target for litigation when this license is violated.

How many companies host and serve models via API and have a $20M+ revenue? Going to be pretty straightforward to catch offenders.

Demonstrating a company is using this model in court seems non-trivial, no? Or am I interpreting this post incorrectly.

Re: Kimi-K3 Technical Report [pdf]

#138
post #133

Earlier quoted context omitted.

It's a gradient almost, with some steps. So far, I think you could categorize every single released so far as one of: - Proprietary - No access beyond remote endpoints - Downloadable - You can run it, but there are restrictions and training data/code isn't public and/or under FOSS license, nor are the weights under a FOSS license - Open weights - The weights are under a FOSS license and downloadable without restricti…

"Downloadable" should be "weights available" by analogy to "source available". K3 is weights available because it includes usage restrictions. K2.6 is open weights, because the only restriction is a weaker version of the "obnoxious BSD advertising clause", which is accepted as FOSS.

Yeah, thanks, "Weights available" does sound much better than "Downloadable", I agree.

Re: Kimi-K3 Technical Report [pdf]

#139

Earlier quoted context omitted.

Yeah but you don't need two such people, or even one, dedicated to this single rack. A company of the size that this is worthwhile for, probably has dedicated devops on staff already and can add this rack to the inventory with no additional staff.

Who is going to upgrade the models ? Who is going to fix it when the api does something weird ? Who is going to proactively make sure it’s not overheating? Chat GPT has enterprise contracts for a reason.

All of the answers to your questions above are in gp's comment already:

> A company of the size that this is worthwhile for, probably has dedicated devops on staff already

Re: Kimi-K3 Technical Report [pdf]

#140
post #114
post #86

Earlier quoted context omitted.

I think internal use is allowed at any scale in the license? > 4. The requirements set forth in Sections 2 and 3 do not apply to: (a) internal use of the Software, defined as any use that does not make the Software, its outputs, or its underlying capabilities available to third parties; [...]

It's very hard to make sure none of the outputs are ever made available to third parties. Source code can end up widely distributed (e.g. client-side js, open source). Prose will frequently get shared across organization boundaries (e.g. emails, websites, documents).

License for LLMs already have very little strength (it's not clear at all that they have any legal basis whatsoever) an AI lab is very, very unlikely to sue you for violating this kind of license clause for the reason you mentioned. It's clearly worded in a way to deter people from running a third party inference business out of it, they would have been much more explicit if they wanted to deter people from running it for internal use.
Post reply on HN