3 ms·
From what I get skimming through the article the main cost is speed of token generation (token latency). You can always run a large model by reading directly fr
by freehorse 2y ago
From what I get skimming through the article the main cost is speed of token generation (token latency). You can always run a large model by reading directly from the disk and not care much about ram; but it is very slow. They try to improve that aspect doing some optimisations, but it is still definitely slower than using ram or vram.
- refulgentis 2y agoTable 3 directly refutes this* and claims 0 tradeoffs.** 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"
- sgc 2y agoI want to add that their chart shows s/token per device (edit: as per the heading on table 1 - it could also be confusing grammar), so it sounds like you are getting 4x the listed s/t on their 4 laptop cluster . Their laptops are not even hardwired - they are connecting over wifi. 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.