The number of layers, and the amount of time spent in each of them, makes me think any benefit from pre-loading the layer ahead is negligible.
You really need the entire model on device to consider it performant.
For vanilla models, you always use all the weights. That isn't true for mixture-of-experts, though, and in that setting, your approach has merit.
The actual goal of the article is to highlight that we can optimise the overall speed by decreasing link latency. Yeah link latency, because it's not 1 machine but several low devices that are used together to serve the 70B LLM.
In other words, if I want 100 tokens of output, do I have to wait 2990 seconds? If so, the terminology seems unnecessarily confusing.
Below that, they indicate that a key part of the implementation is loading weights from disk before they're needed using a separate thread.***
* maybe I'm missing something though, someone please triple check :)
** ttft (time to first token) and s/token (seconds per token) are both lower than any alternative in all cases.
*** "daemon thread asynchronously preloads the weights"
This comes at a very interesting time for me. I have an ancient dual xeon workstation with 64gb memory that I was researching how to convert to run an llm. I can just run that with 4 instances on the same machine and see how it goes, without purchasing a better GPU, to start. It sounds like this will allow you to run very large models with minimal quants, on craigslist quality devices.
If it does what they say it does (and it seems to do), it will be an absolute game changer for most users.
They're claiming to be able to efficiently run larger models without loading the entire thing into GPU memory. If they're using the same weights, the same architecture and just using tensor parallel operations to perform the forward pass that would imply no loss in quality.
I'm sure there are trade-offs but they're not clear by just looking at the abstract.