Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Stella Nera – Maddness Hardware Accelerator

github.com

Post reply on HN
Print view View original

11–20 of 28 posts

Re: Show HN: Stella Nera – Maddness Hardware Accelerator

#11

Post by joennlae »

fxtentacle wrote: post #3

I am surprised that they do not mention comparing against quantized matrix multiplication because their "encoding" appears to be something like a quantization step with unevenly sized buckets. And then their approximate multiplication step to me looks like multiplying a quantized input vector against a 1-bit quantized matrix. But overall this is an extremely exciting development because it shows how one could convert…

Author here:

Thank you for the feedback :-) A lot of the work regarding the comparison with „simple“ approximate matrix multiplication has been done in the preceding paper: https://arxiv.org/abs/2106.10860

While I share your enthusiasm regarding the potential, we have to be careful about the limiting factors. Our main contributions on the algorithmic side are the reformulation of Maddness such that it is differentiable (autogradable), and we can use it in e2e DNN training, as decision trees are not differentiable.

We are still in the process of understanding how to optimise the training. In the next step, we want to look into transformers as, for now, we only looked into ResNets for easy comparability.

If you are a student at ETH Zurich and want to work on this -> reach out to me

Re: Show HN: Stella Nera – Maddness Hardware Accelerator

#13

Post by maizeq »

fxtentacle wrote: post #5
larodi wrote: post #4

Next level algorithm design with approximation of everything. I’m getting high from such proposed technology.

You'd be surprised how far that takes you. I mean I was truly astonished when I saw that a GptNeoX LLM quantized down to 1.5 bits per value at 90% sparsity was still producing acceptable predictions. But the size went from multiple GBs to less than 1 MB of (compressed) parameters.

Any link to this? I actually haven't seen any reported results on less than 2 bits.

Re: Show HN: Stella Nera – Maddness Hardware Accelerator

#14

Post by fxtentacle »

baq wrote: post #9
fxtentacle wrote: post #7

Earlier quoted context omitted.

That's the beauty of their method: If you can replace a 8192x8192 matrix multiplication with a 8192x256 decision tree and then a 256x8192 look up table, your memory requirements go from 67,108,864 down to about 2,162,688 parameters. (I assumed that their decision tree for encoding is perfectly balanced and only uses log(256) parameters per row) EDIT: And given that this work is centered around energy-efficiency and w…

Mind blown. Sounds almost too good to be true except the human brain runs on 20W and this brings us to the same ballpark. This was hard scifi a year ago! Can an approach like this be integrated into stuff like llama.cpp so I could have a 200B model hashed down to 7B to run on civilian hardware or even a CPU?

I'd expect that on a regular CPU, the RAM access latency will destroy any performance improvements. This work is much better suited for FPGAs or ASICs.

Re: Show HN: Stella Nera – Maddness Hardware Accelerator

#15

Post by joennlae »

fxtentacle wrote: post #7
joelthelion wrote: post #6

Earlier quoted context omitted.

> My prediction would be that this will develop in the way that we can soon buy $1 hardware accelerators for things like word embedding, grammar, and general language understanding. And then you need those expensive GPUs only for the last few layers of your LLM, thereby massively reducing deployment costs. You'd still need a lot of RAM for storing these weights, wouldn't you? I mean, obviously, a $1 accelerator is a…

That's the beauty of their method: If you can replace a 8192x8192 matrix multiplication with a 8192x256 decision tree and then a 256x8192 look up table, your memory requirements go from 67,108,864 down to about 2,162,688 parameters. (I assumed that their decision tree for encoding is perfectly balanced and only uses log(256) parameters per row) EDIT: And given that this work is centered around energy-efficiency and w…

Thank you for the feedback :-)

We have to be careful with the comparisons we make. The TPUv3 is a training and datacenter chip and not an Edge/Inference chip. They optimise for a different tradeoff, so while the comparison looks good, it is unfair.

Re: Show HN: Stella Nera – Maddness Hardware Accelerator

#16

Post by pmontra »

joennlae wrote: post #11
fxtentacle wrote: post #3

I am surprised that they do not mention comparing against quantized matrix multiplication because their "encoding" appears to be something like a quantization step with unevenly sized buckets. And then their approximate multiplication step to me looks like multiplying a quantized input vector against a 1-bit quantized matrix. But overall this is an extremely exciting development because it shows how one could convert…

Author here: Thank you for the feedback :-) A lot of the work regarding the comparison with „simple“ approximate matrix multiplication has been done in the preceding paper: https://arxiv.org/abs/2106.10860 While I share your enthusiasm regarding the potential, we have to be careful about the limiting factors. Our main contributions on the algorithmic side are the reformulation of Maddness such that it is differentiab…

As you are the author: why the name Stella Nera / Black Star?

Re: Show HN: Stella Nera – Maddness Hardware Accelerator

#17

Post by fxtentacle »

joennlae wrote: post #11
fxtentacle wrote: post #3

I am surprised that they do not mention comparing against quantized matrix multiplication because their "encoding" appears to be something like a quantization step with unevenly sized buckets. And then their approximate multiplication step to me looks like multiplying a quantized input vector against a 1-bit quantized matrix. But overall this is an extremely exciting development because it shows how one could convert…

Author here: Thank you for the feedback :-) A lot of the work regarding the comparison with „simple“ approximate matrix multiplication has been done in the preceding paper: https://arxiv.org/abs/2106.10860 While I share your enthusiasm regarding the potential, we have to be careful about the limiting factors. Our main contributions on the algorithmic side are the reformulation of Maddness such that it is differentiab…

Thanks for pointing that out :) When I first read the paper, I thought that 4. DIFFERENTIABLE MADDNESS was still part of the 3. BACKGROUND section.

Also, I have to admit that I don't quite understand that section, even after trying a 2nd time. The text implies that Sc would be 15x4 and Hc would be 16x15 but in the illustration it looks like 3x2 and 4x3. I guess I'll have to read Zhang [37] first because like this, I'm not sure what the selection matrix and description matrix do here. That said, (8) and following is easy to understand again. You use the softmax to create an approximately correct gradient but use the hard maximum for calculation the forward pass values.

Re: Show HN: Stella Nera – Maddness Hardware Accelerator

#18

Post by fxtentacle »

pmontra wrote: post #16
joennlae wrote: post #11

Earlier quoted context omitted.

Author here: Thank you for the feedback :-) A lot of the work regarding the comparison with „simple“ approximate matrix multiplication has been done in the preceding paper: https://arxiv.org/abs/2106.10860 While I share your enthusiasm regarding the potential, we have to be careful about the limiting factors. Our main contributions on the algorithmic side are the reformulation of Maddness such that it is differentiab…

As you are the author: why the name Stella Nera / Black Star?

Not the author but

https://www.youtube.com/watch?v=N8JCMJQ1jyw&list=OLAK5uy_lYv...

was a Platin hit in Switzerland, where the ETH Zürich is located.

Re: Show HN: Stella Nera – Maddness Hardware Accelerator

#19

Post by joennlae »

Author here: Let me try to give an overview as I saw some questions repeating itself.

* This accelerator is for an Edge/Inference case, so there is no training on this chip.

* We introduce a differentiable form of Maddness, allowing Maddness to be used in e2e training and present an application -> ResNet.

* We are still in the process of understanding how this will translate to transformers.

* The goal was to show that Maddness is feasible with a good codesign of the hardware.

* Compared to other extreme quantisation (BNN/TNN) and pruning schemes, this is more general as it replaces the matmul with an approximate matmul.

* The model architecture is not fixed in hardware. It is „just“ a matmul unit.

I hope this helps :-)

Re: Show HN: Stella Nera – Maddness Hardware Accelerator

#20

Post by fxtentacle »

maizeq wrote: post #13
fxtentacle wrote: post #5

Earlier quoted context omitted.

You'd be surprised how far that takes you. I mean I was truly astonished when I saw that a GptNeoX LLM quantized down to 1.5 bits per value at 90% sparsity was still producing acceptable predictions. But the size went from multiple GBs to less than 1 MB of (compressed) parameters.

Any link to this? I actually haven't seen any reported results on less than 2 bits.

Nothing public, sorry. I do consulting on how to convert AIs from CUDA to C++ to save money. With a good quantization, you can sometimes replace a $19k A100 with a $0.5k EPYC. And especially for apps and/or WebGL interference, you want small models.

Anyway, if you quantize to -1, 0, or +1 and then use arithmetic coding, you come out at around 1.58 bits per parameter. And then by skewing the distribution with forced sparsity, you have something like 5% x -1, 90% x 0, 5% x +1 which comes out at about 0.6 bits per parameter after arithmetic coding.

I used that on "gpt_neox.layers.*.mlp.dense_h_to_4h.weight" (HuggingFace PyTorch implementation), for example. But for other layers you need more bits. For example, I could never get gpt_neox.embed_in.weight to less than 2% -2, 8% -1, 80% 0, 8% +1, 2% +2 which comes out at around 1.1 bits per parameter [1]. And then stuff like gpt_neox.layers.0.attention.query_key_value.weight will drive up your overall bits per parameter because those are very difficult to quantize or sparsify. That 1.5 was the average over the entire model and some layers compress even better while others compress worse.

[1] example calculation: https://www.wolframalpha.com/input?i=-%28log2%280.02%29*0.02...

Post reply on HN