How can I make sure that each github runner uses exactly one cpu core?
HN user
joennlae
Trainable Llama-like transformer (with backpropagation) in numpy only (~600 lines)
+1. Does someone know how to do that?
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 :-)
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.
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
That is true. I went for a simple implementation of the layer norm and included it in the tensorli definition. But it would have been better to define it as a moduli for clarity.
This would be interesting to consider. But at the moment, nothing is optimized, so many things must be tackled first (especially in the backwards path, for example, buffering) to justify moving to cupy. The goal was to use it as an educational exercise for me.
They are still applying: https://tmsearch.uspto.gov/bin/showfield?f=doc&state=4805:wl...
The author here: I absolutely agree with you. I went for a bit more catchy title.
Llama1 --> 1.0T Llama2 --> 2.0T Mistral --> ??
They do not publish how many tokens it is pre-trained on, additionally to sharing no info on datasets used (except for fine-tuning).
To my knowledge, no one has trained a larger LLM (>250M) to the capacity limit. As discussed in the original GPT3 paper (https://twitter.com/gneubig/status/1286731711150280705?s=20)
TinyLlama is trying to do that for 1.1B: https://github.com/jzhang38/TinyLlama
As long as we are not at the capacity limit, we will have a few of these 7B beats 13B (or 7B beats 70B) moments.
You will probably notice it also when trying to push a new branch:
`error: failed to push some refs to ` when using --set-upstream