Hacker Newsnew | past | comments | ask | show | jobs | submit | withinboredom's commentslogin

The GPU isn’t connected to the disk though. Usually. So you’d still have to load from disk, to ram, then from ram to the GPU.

PCI-E is really very flexible https://developer.nvidia.com/gpudirect

> The GPU isn’t connected to the disk though. Usually.

It can be. That was the big new innovation in video game load times


I don't wear a watch for health bs. I wear a watch to tell time; the fact that it can also call my family is a bonus. Or show the current weather.

You’ve just described why people have a phone.

In 2010. Nobody has a phone to check the time and call people anymore, and haven't since smart phones became de rigeur.

I failed at 2 times. My folding couch couldn't supply the required pressure beyond that point.

Reminds me of a new PM believing that "arabic numerals" mean arabic script instead of real every day numbers because AI told them so. Despite the entire team trying to explain it to them.

Some people would just rather believe a computer than the evidence right in front of them.


If by "understand" you mean to put the hidden state of the transformer into the desired topological basins. Yes, it does "understand" them better.

10 gb per second is pretty slow for a disk. You should be seeing much higher than that.


??? The only configuration that will allow disk reads at 10 GB/s is if you're using PCIe 5.0. PCIe 4.0 or lower, and SATA will not drop out long before that.

He's very clearly hauling data straight from the page cache.


I didn't know the US had royalty... You should consider moving to the EU if you want to do work for lords and ladies.


That doesn’t make any sense. But happy to answer any questions you may have!


The problem is dram bandwidth to the cpu. Each token costs roughly 20gb of traffic and ddr5 is roughly 50-80gb/s, plus you still have to run the compute sequentially. That’s your limit.


Why quantize to int8 when k3 is int4? I could be wrong, but that’s what I remember seeing.


We have a lossless compression codec (working on open sourcing it over the next couple of weeks) that reduces it down to its minimum entropy -- it cannot be compressed further. On all tested large models, it's a ratio of 1.34-1.23 -- and smaller models up to 3.76x. It also increases the effective bandwidth by the same rate.


Exploring compression algorithms for weights is a good idea, and I hope you have a successful product. However, if you can prove this statement:

> reduces it down to its minimum entropy -- it cannot be compressed further.

I think you could make a lot more money elsewhere :-)

https://en.wikipedia.org/wiki/Kolmogorov_complexity#Formal_p...


We're not an AI company ... nor do we have any reason to use it. Just a fun idea that was fruitful.


And to clarify -- it only applies to models, not arbitrary data. So its useful to exactly zero other fields.


That's very interesting. Does that mean you can reduce say, a 30B class Q8 from ~30 GB down to 10 GB or less?


704gb -> 564gb; 358 gb -> 270 gb; 28.79 gb -> 7.65 gb; 439 gb -> 93 gb

It depends on the total entropy of the model. Smaller models have less entropy.


> Smaller models have less entropy.

Interesting. Why is that? I would have expected the opposite, since larger models have to try less hard to fit the training data. Or maybe this leaves more parameters with random initialization, resulting in higher entropy for larger models?


I honestly don't know... I didn't train the models, so I can't tell why the math works out that way. It just does. I suspect it has to do with the fact that all the small models I've tested have been quantized. I don't know of any small model trained from scratch. If you know of any, I'd be happy to encode it and see what it looks like.


We have a lossless compression codec (working on open sourcing it over the next couple of weeks) that reduces it down to its minimum entropy

LOL


[flagged]


Thanks for your opinion


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: