Most active commenters
  • bick_nyers(4)
  • CuriouslyC(3)
  • nl(3)

←back to thread

Show HN: Llama-dl – high-speed download of LLaMA, Facebook's 65B GPT model

(github.com)
343 points sillysaurusx | 16 comments | 05 Mar 23 04:28 UTC | HN request time: 1.835s | source | bottom
Show context
v64 ◴[05 Mar 23 11:44 UTC] No.35028738[source]▶
If anyone is interested in running this at home, please follow the llama-int8 project [1]. LLM.int8() is a recent development allowing LLMs to run in half the memory without loss of performance [2]. Note that at the end of [2]'s abstract, the authors state "This result makes such models much more accessible, for example making it possible to use OPT-175B/BLOOM on a single server with consumer GPUs. We open-source our software." I'm very thankful we have researchers like this further democratizing access to this data and prying it out of the hands of the gatekeepers who wish to monetize it.

[1] https://github.com/tloen/llama-int8

[2] https://arxiv.org/abs/2208.07339

replies(5): >>35028950 #>>35029068 #>>35029601 #>>35030214 #>>35030868 #
downvotetruth ◴[05 Mar 23 12:34 UTC] No.35029068[source]▶
Eagerly awaiting the int8 vs 4 benchmarks. Also, it can run on CPU https://github.com/markasoftware/llama-cpu So, an int8 patch could allow the 65B to run on a standard 128 GB setup assuming the 65B model's cache bursts fit, which if I were to speculate is why the released models stop @ 65B & meta likely already has larger unreleased internal ones.
replies(1): >>35029092 #
v64 ◴[05 Mar 23 12:37 UTC] No.35029092[source]▶
early int4 experiments seem to indicate it's possible but you do lose performance, see this thread https://www.reddit.com/r/MachineLearning/comments/11i4olx/d_...

edit: to clarify, it may be possible to get this loss back and there is reason to be optimistic

replies(1): >>35029917 #
1. CuriouslyC ◴[05 Mar 23 14:36 UTC] No.35029917[source]▶
Probably the best method is to just train it on int4 in the first place. Fine tuning after quantization would definitely help though.
replies(2): >>35030116 #>>35034771 #
2. sp332 ◴[05 Mar 23 14:58 UTC] No.35030116[source]▶
Isn't that backwards? You need fairly good resolution during training or your gradients will be pointing all over the place. Once you've found a good minimum point, moving a little away from it with reduced precision is probably OK.
replies(2): >>35030220 #>>35030326 #
3. brookst ◴[05 Mar 23 15:10 UTC] No.35030220[source]▶
I have no idea what the right answer is, but I think the argument for int4 training is that the loss measurements would take the lower resolution of the model as a whole into account.

Is it better to have billions of high resolution parameters and quantize them at the end, or to train low resolution parameters where the training algorithms see the lower resolution? It’s beyond me, but I’d love to know.

replies(2): >>35031851 #>>35035673 #
4. rfoo ◴[05 Mar 23 15:21 UTC] No.35030326[source]▶
GP could be mentioning quantization aware training, during which the weight and gradient are still computed in fp16/fp32.
replies(1): >>35037181 #
5. Scene_Cast2 ◴[05 Mar 23 17:36 UTC] No.35031851{3}[source]▶
But by default, training algos don't see the lower resolution, your gradient just doesn't work as well. There is a body of research on how to make training aware of / adapt to the lower precision.
6. nl ◴[05 Mar 23 22:22 UTC] No.35034771[source]▶
> Probably the best method is to just train it on int4 in the first place

Unclear why you think that since experiments show the opposite.

In general the gradient seems to get too "bumpy" to do good gradient decent at lower levels of precision.

There are some papers showing that making the training loop aware of quantitization can help ultimate quantizied performance but I'm not aware of this being implemented at large scale.

replies(2): >>35035732 #>>35036328 #
7. bick_nyers ◴[06 Mar 23 00:01 UTC] No.35035673{3}[source]▶
I think the answer is it depends, and further, a dynamic approach may be best. Imagine you are going on a hike, and you have different maps at various resolutions (levels of detail). When planning the hike, you will want to see the zoomed out picture to get general directions, elevations and landmarks identified. Then you can zoom in to see the actual trails themselves, to identify your route, and then you zoom in even further when you are on the ground actually walking, avoiding obstacles along the way.

Different resolutions draw your attention to different types of features.

8. bick_nyers ◴[06 Mar 23 00:08 UTC] No.35035732[source]▶
What if you smooth the gradient, either by interpolating/removing data points that make the surface "jagged", or maybe change the "window" of gradient descent, meaning instead of using a tangent (derivative, infinitesimally small window) you use a secant (???, window of specified length, likely calculated from the data space).

Forgive my lack of proper terminology here.

replies(1): >>35036021 #
9. nl ◴[06 Mar 23 00:40 UTC] No.35036021{3}[source]▶
Sure, there are multiple ways to reduce the complexity of your loss-space, but the issue is that you usually want these small gradient values because they are important. Roughly if you "smooth over what appears to be a small hole" often you'll miss a large space that needs to be explored (obviously this is multi-dimensional but you get the idea).

However you can reduce memory by doing mixed-precision training if you are careful. See section "2.3.1. Loss Scaling To Preserve Small Gradient Magnitudes" in https://docs.nvidia.com/deeplearning/performance/mixed-preci...

replies(1): >>35036318 #
10. bick_nyers ◴[06 Mar 23 01:15 UTC] No.35036318{4}[source]▶
So then you would need to do some kind of mesh simplification that also preserves the topology, that makes sense.

I'm not quite sure I understand what they are describing in 2.3.1, are they scaling those small gradient magnitudes larger to try to "pull" you into those holes faster?

I was thinking the a way to go about it would be to just increase the "mesh resolution" near the small hole, which in this case would be use a larger precision in the area local to the hole.

replies(2): >>35038002 #>>35040827 #
11. CuriouslyC ◴[06 Mar 23 01:16 UTC] No.35036328[source]▶
My take away was that the reduced performance of natively trained models was more about numerical instability related to training process than a statement about limitations of low precision models.
12. CuriouslyC ◴[06 Mar 23 03:23 UTC] No.35037181{3}[source]▶
It can go farther than that, it seems like the weight gradients are the main thing where the precision is a bottleneck (see https://arxiv.org/abs/1805.11046).
13. nl ◴[06 Mar 23 06:09 UTC] No.35038002{5}[source]▶
> are they scaling those small gradient magnitudes larger to try to "pull" you into those holes faster?

No, they are making the numbers bigger so the drop in precision doesn't lose details.

14. lumost ◴[06 Mar 23 13:41 UTC] No.35040827{5}[source]▶
I suspect that changing the resolution around hot points in the manifold would be a more expensive task than training the model on a higher global resolution. Optimization algorithms currently do not maintain state on the loss-manifold.
replies(1): >>35042904 #
15. bick_nyers ◴[06 Mar 23 16:25 UTC] No.35042904{6}[source]▶
My naive (and I do mean naive) thought here is that you just need a cheap detection function of when you need to swap precision. I'm pretty stuck on the geometric interpretation here but basically if the training step is "within a radius" of a known hot point of the manifold then you swap precision. It's very possible though that I am hallucinating something that is not possible, I don't actually understand how this stuff really works yet.
replies(1): >>35050211 #
16. lumost ◴[07 Mar 23 01:13 UTC] No.35050211{7}[source]▶
The challenge here is knowing the shape of the manifold within an epsilon radius 65 Billion dimension sphere around the position being evaluated. To calculate this you would need to sample points within epsilon radius around the current point. As these points will be lower-precision by default, you would have minimal knowledge of the shape of the manifold within the sphere if epsilon is < the minimum precision.

It might be possible to work around this by estimating the gradient volatility through the n^th order derivatives, but you would then also have to deal with mixed precision SIMD which hardware doesn't really support.