return to table of content

Exo: Run your own AI cluster at home with everyday devices

hagope
43 replies
13h26m

I used to be excited about running models locally (LLM, stable diffusion etc) on my Mac, PC, etc. But now I have resigned to the fact that most useful AI compute will mostly be in the cloud. Sure, I can run some slow Llama3 models on my home network, but why bother when it is so cheap or free to run it on a cloud service? I know Apple is pushing local AI models; however, I have serious reservations about the impact on battery performance.

wokwokwok
20 replies
13h2m

Sure, I can run some slow Llama3 models on my home network, but why bother when it is so cheap or free to run it on a cloud service?

Obvious answer: because it's not free, and it's not cheap.

If you're playing with a UI library, lets say, QT... would you:

a) install the community version and play with ($0)

b) buy a professional license to play with (3460 €/Year)

Which one do you pick?

Well, the same goes. It turns out, renting a server large enough to run big (useful, > 8B) models is actually quite expensive. The per-api-call costs of real models (like GPT4) adds up very quickly once you're doing non-trivial work.

If you're just messing around with the tech, why would you pay $$$$ just to piss around with it and see what you can do?

Why would you not use a free version running on your old PC / mac / whatever you have lying around?

I used to be excited about running models locally

That's an easy position to be one once you've already done it and figured out, yes, I really want the pro plan to build my $StartUP App.

If you prefer to pay for an online service and you can afford it, absolutely go for it; but isn't this an enabler for a lot of people to play and explore the tech for $0?

Isn't having more people who understand this stuff and can make meaningful (non-hype) decisions about when and where to use it good?

Isn't it nice that if meta released some 400B llama 4 model, most people can play with it, not just the ones with the $7000 mac studio? ...and keep building the open source ecosystem?

Isn't that great?

I think it's great.

Even if you don't want to play, I do.

itake
14 replies
12h48m

I’m a bit confused. Your reasoning doesn’t align with the data you shared.

The startup costs for just messing around at home are huge: purchasing a server and gpus, paying for electricity, time spent configuring the api.

If you want to just mess around, $100 to call the world’s best api is much cheaper than spending $2-7k Mac Studio.

Even at production level traffic, the ROI on uptime, devops, utilities, etc would take years to recapture the upfront and on-going costs of self-hosting.

Self hosting will have higher latency and lower throughput.

wokwokwok
6 replies
11h56m

The startup costs for just messing around at home are huge

No, they are zero.

Most people have extra hardware lying around at home they're not using. It costs nothing but time to install python.

$100 is not free.

If you can't be bothered, sure thing, slap down that credit card and spend your $100.

...but, maybe not so for some people?

Consider students with no credit card, etc; there are a lot of people with a lot of free time and not a lot of money. Even if you don't want to use it do you do seriously think this project is totally valueless for everyone?

Maybe, it's not for you. Not everything has to be for everyone.

You are, maybe, just not the target audience here?

lynx23
4 replies
11h49m

And its not entitled to cliam that "Most people have extra hardware lying around at home". Your story doesn't sound plausible at all.

wokwokwok
2 replies
11h40m

This project is literally aiming to run on devices like old phones.

I don't think having an old phone is particularly entitled.

I think casually slapping down $100 on whim to play with an API... probably, yeah.

/shrug

itake
1 replies
11h33m

According to this tweet, Llama 3 costs about $0.20 per Million tokens using an M2.

https://x.com/awnihannun/status/1786069640948719956

In comparison, GPT3.5-turbo costs $0.50 per million tokens.

Do you think an old iPhone will less than 2x efficient?

nightski
0 replies
6h44m

FWIW depends on cost of power. Where I live cost of power is less than half the stated average.

bryanrasmussen
0 replies
8h48m

Most people who would want to be running machine learning models probably have some hardware at home that can handle a slow task for playing around and determining if it is worthwhile to pay out for something more performant.

This is undoubtedly entitled, but thinking to yourself huh, I think it's time to try out some of this machine learning stuff is a pretty inherently entitled thing to do.

Aurornis
0 replies
2h33m

You are, maybe, just not the target audience here?

The difference between an open model running on a $100 computer and the output from GPT4 or Claude Sonnet is huge.

I use local and cloud models. The difference in productivity and accuracy between what I can run locally and what I can get for under $100 of API calls per month is huge once you get past basic playing around with chat. It’s not even close right now.

So I think actually you are not the target audience for what the parent comments are taking about. If you don’t need cutting edge performance then it’s fun to play with local, open, small models. If the goal is to actually use LLMs for productivity in one way or another, spending money on the cloud providers is a far better investment.

Exceptions of course for anything that is privacy-sensitive, but you’re still sacrificing quality by using local models. It’s not really up for debate that the large hosted models are better than what you’d get from running a 7B open model locally.

zeta0134
2 replies
10h24m

You are vastly overestimating the startup cost. For me this week it was literally these commands:

pacman -S ollama

ollama serve

ollama run llama3

My basic laptop with about 16 GB of RAM can run the model just fine. It's not fast, but it's reasonably usable for messing around with the tech. That's the "startup" cost. Everything else is a matter of pushing scale and performance, and yes that can be expensive, but a novice who doesn't know what they need yet doesn't have to spend tons of money to find out. Almost any PC with a reasonable amount of RAM gets the job done.

monkmartinez
0 replies
22m

llama3 at 8billion params is weak sauce for anything serious, it just isn't in the same galaxy as Sonnet 3.5 or GPT-4o. The smaller and faster models like Phi are even worse. Once you progress past asking trivial questions to a point where you need to trust the output a bit more, its not worth effort in time, money and/or sweat effort to run a local model to do it.

A novice isn't going to know what they need because they don't know what they don't know. Try asking a question to LLaMA 3 at 8 billion and the same question to LLaMA 3 at 70 billion. There is a night and day difference. Sonnet, Opus and GPT-4o run circles around LLaMA 3 70b. To run LLaMA at 70 billion you need serious horse power as well, likely thousands of dollars in hardware investment. I say it again... the calculus in time, money, and effort isn't favorable to running open models on your own hardware once you pass the novice stage.

I am not ungrateful that the LLaMA's are available for many different reasons, but there is no comparison between quality of output, time, money and effort. The API's are a bargain when you really break down what it takes to run a serious model.

Aurornis
0 replies
2h36m

I’m familiar with local models. They’re fine for chatting on unimportant things.

They do not compare to the giant models like Claude Sonnet and GPT4 when it comes to trying to use them for complex things.

I continue to use both local models and the commercial cloud offerings, but I think anyone who suggests that the small local models are on par with the big closed hosted models right now is wishful thinking.

J_Shelby_J
1 replies
4h14m

Devs that refuse to move off Apple are severely disadvantaged in the LLM era.

jondwillis
0 replies
3h53m

lol tell that to the 3 year old laptop with 64 GB of RAM that I use exclusively for local LLMs while dev’ing on my work laptop with 96 GB of RAM…

sudohackthenews
0 replies
12h43m

People have gotten manageable results on all sorts of hardware. People have even squeezed a few tokens/second out of Raspberry PIs. The small models are pretty performant- they get good results on consumer gaming hardware. My 2021 laptop with a 3070m (only 8gb vram) runs 8b models faster than I can read, and even the original M1 chips can run the models fine.

jrm4
1 replies
4h39m

Right, I think people here are vastly underestimating this idea of

"What if I want to play around with really PERSONAL stuff."

I've been keeping a digital journal about my whole life. I plan to throw that thing into an AI to see what happens, and you can be damn sure that it will be local.

monkmartinez
0 replies
14m

Yes, I am with you 100% and keep several LLaMA's on my workstation for that reason. I use Openrouter for everything else. Everything that isn't sensitive goes to one of the big kid models because they are just sooooo much better. LLaMA 400b might be the start of running with the big kids, but I know we are not close with the current available models.

nl
0 replies
5h16m

Well, the same goes. It turns out, renting a server large enough to run big (useful, > 8B) models is actually quite expensive. The per-api-call costs of real models (like GPT4) adds up very quickly once you're doing non-trivial work.

I run my own models, but the truth is most of the time I just use an API provider.

TogetherAI and Groq both have free offers that are generous enough I haven't used them up in 6 months of experimentation and TogetherAI in particular has more models and gets new models up quicker than I can try them myself.

FeepingCreature
0 replies
12h55m

I just prepay $20/mo to openrouter.ai and can instantly play with every model, no further signup required.

Aurornis
0 replies
2h39m

Why would you not use a free version running on your old PC / mac / whatever you have lying around?

Because the old PC lying around can’t come anywhere near the abilities or performance of the hosted AI compute providers. Orders of magnitudes of difference.

The parent commenter is correct: If you want cutting edge performance, there’s no replacement for the hosted solutions right now.

Running models locally is fun for playing around and experimenting, but there is no comparison between what you can run on an old PC lying around and what you can get from a hosted cluster of cutting edge hardware that offers cheap output priced per API call.

PostOnce
5 replies
7h39m

Maybe you want to conduct experiments that the cloud API doesn't allow for.

Perhaps you'd like to plug it into a toolchain that runs faster than API calls can be passed over the network? -- eventually your edge hardware is going to be able to infer a lot faster than the 50ms+ per call to the cloud.

Maybe you would like to prevent the monopolists from gaining sole control of what may be the most impactful technology of the century.

Or perhaps you don't want to share your data with Microsoft & Other Evils (formerly known as dont be evil).

You might just like to work offline. Whole towns go offline, sometimes for days, just because of bad weather. Nevermind war and infrastructure crises.

Or possibly you don't like that The Cloud model has a fervent, unshakeable belief in the propaganda of its masters. Maybe that propaganda will change one day, and not in your favor. Maybe you'd like to avoid that.

There are many more reasons in the possibility space than my limited imagination allows for.

tarruda
1 replies
4h1m

It is not like strong models are at a point where you can 100% trust their output. It is always necessary to review LLM generated text before using it.

I'd rather have a weaker model which I can always rely on being available than a strong model which is hosted by a third party service that can be shut down at any time.

Aurornis
0 replies
2h29m

I'd rather have a weaker model which I can always rely on being available than a strong model which is hosted by a third party service that can be shut down at any time.

Every LLM project I’ve worked with has an abstraction layer for calling hosted LLMs. It’s trivial to implement another adapter to call a different LLM. It’s often does as a fallback, failover strategy.

There are also services that will merge different providers into a unified API call if you don’t want to handle the complexity on the client.

It’s really not a problem.

gtirloni
1 replies
2h35m

> eventually your edge hardware is going to be able to infer a lot faster than the 50ms+ per call to the cloud.

This is interesting. Is that based on any upcoming technology improvement already in the works?

a_t48
0 replies
1h50m

GP is likely referring to network latency here. There's a tradeoff between smaller GPUs/etc at home that have no latency to use and beefier hardware in the cloud that have a minimum latency to use.

jumpCastle
0 replies
3h50m

Aren't services like runpod solve half of these concerns?

Cantinflas
2 replies
13h20m

Why bother running models locally? Privacy, for once, or censorship resistance.

seasonman
0 replies
13h10m

Also customizability. Sure, you can fine-tune the cloud hosted models (to a certain degree of freedom), but it will probably be expensive, inefficient, difficult and unmaintainable.

hanniabu
0 replies
12h55m

And offline access

nhod
1 replies
13h13m

Is this a hunch, or do you know of some data to back up your reservations?

Copilot+ PC’s, which all run models locally, have the best battery life of any portable PC devices, ever.

These devices have in turn taken a page out of Apple Silicon’s playbook. Apple has the benefit of deep hardware and software integration that no one else has, and is obsessive about battery life.

It is reasonable to think that battery life will not be impacted much.

fragmede
0 replies
13h0m

That doesn't seem totally reasonable. The battery life of an iphone is pretty great if you're not actually using it, but if you're using the device hard, it gets hot to the touch, along with the battery getting drained. playing resource intensive video games, maxing out the *PU won't stop and let the device sleep at all, and has a noticable hit on battery life. Where inference takes a lot of compute to perform, it's hard to imagine inference being totally free, battery-wise. It probably won't be as hard on the device as playing specific video games non-stop, but I get into phone conversations with ChatGPT as it is, so I can imagine that being a concern if you're already low on battery.

dsign
1 replies
10h33m

For my advanced spell-checking use-case[^1], local LLMs are, sadly, not state-of-the-art. But their $0 price-point is excellent to analyze lots of sentences and catch the most obvious issues. With some clever hacking, the most difficult cases can be handled by GPT4o and Claude. I'm glad there is a wide variety of options.

[^1] Hey! If you know of spell-checking-tuned LLM models, I'm all ears (eyes).

bruce343434
0 replies
8h14m

I think the floating point encoding of LLMs is inherently lossy, add to that the way tokenization works. The LLMs I've worked with "ignore" bad spelling and correctly interpret misspelled words. I'm guessing that for spelling LLMs, you'd want tokenization at the character level, rather than a byte pair encoding.

You could probably train any recent LLM to be better than a human at spelling correction though, where "better" might be a vague combination of faster, cheaper, and acceptable loss of accuracy. Or maybe slightly more accurate.

(A lot of people hate on LLMs for not being perfect, I don't get it. LLMs are just a tool with their own set of trade offs, no need to get rabid either for or against them. Often, things just need to be "good enough". Maybe people on this forum have higher standards than average, and can not deal with the frustration of that cognitive dissonance)

dotancohen
1 replies
12h17m

I have found many similarities between home AI and home astronomy. The equipment needed to get really good performance is far beyond that available to the home user, however intellectually satisfying results can be had at home as a hobby. But certainly not professional results.

grugagag
0 replies
6h40m

When learning and experimenting it could make a difference.

jrm4
0 replies
4h42m

What do you mean by useful here?

I'm saying because I've had the exact OPPOSITE thought. The intersection of Moore's Law and the likelihood that these things won't end up as some big unified singularity brain and instead little customized use cases make me think that running at home/office will perhaps be just as appealing.

friendly_chap
0 replies
11h44m

We are running smaller models with software we wrote (self plug alert: https://github.com/singulatron/singulatron) with great success. There are obvious mistakes these models make (such as the one in our repo image - haha) sometimes but they can also be surprisingly versatile in areas you don't expect them to be, like coding.

Our demo site uses two NVIDIA GeForce RTX 3090 and our whole team is hammering it all day. The only problem is occasionally high GPU temperature.

I don't think the picture is as bleak as you paint. I actually expect Moore's Law and better AI architectures to bring on a self-hosted AI revolution in the next few years.

dws
0 replies
2h32m

Sure, I can run some slow Llama3 models on my home network, but why bother when it is so cheap or free to run it on a cloud service?

Running locally, you can change the system prompt. I have Gemma set up on a spare NUC, and changed the system prompt from "helpful" to "snarky" and "kind, honest" to "brutally honest". Having an LLM that will roll its eyes at you and say "whatever" is refreshing.

diego_sandoval
0 replies
2h28m

why bother when it is so cheap or free to run it on a cloud service?

For the same reasons that we bother to use Open Source software instead of proprietary software.

bongodongobob
0 replies
13h16m

I have a 2 year old Thinkpad and I wouldn't necessarily call llama3 slow on it. It's not as fast as ChatGPT but certainly serviceable. This should only help.

Not sure why your throwing your hands up because this is a step towards solving your problem.

aftbit
0 replies
3h27m

What if you want to create transcripts for 100s of hours of private recorded audio? I for one do not want to share that with the cloud providers and have it get used as training data or be subject to warrentless search under the third party doctrine. Or what if you want to run a spicy Stable Diffusion fine-tune that you'd rather not have associated with your name in case the anti-porn fascists take over? I feel like there are dozens of situations where the cost is really not the main reason to prefer a local solution.

Hihowarewetoday
0 replies
10h31m

I'm not sure why you have resigned?

If you don't care about running it locally, just spend it online. Everything is good.

But you can run it locally already. Is it cheap? No. Are we still in the beginning? yes. We are still in a phase were this is a pure luxury and just getting into it by buying a 4090, is still relativly cheap in my opinion.

Why running it locally you ask? I personally think running anythingllm and similiar frameworks on your own local data is interesting.

But im pretty sure in a few years you will be able to buy cheaper ml chips for running models locally fast and cheap.

Btw. aat least i don't know a online service which is uncensored, has a lot of loras as choice and is cost effective. For just playing around with LLMs for sure there are plenty of services.

mg
11 replies
11h35m

    This enables you to run larger models
    than you would be able to on any single
    device.
No further explanation on how this is supposed to work?

If some layers of the neural network are on deviceA and some layers are on deviceB, wouldn't that mean that for every token generated, all output data from the last layer on deviceA have to be transferred to deviceB?

mikewarot
5 replies
11h3m

Yes, so you would have a vector about 8k values long to be transferred on each token generated.

You could do that easily with any modern network.

mg
4 replies
10h50m

That's exciting. So we could build a SETI@home style network of even the largest models.

I wonder if training could be done in this way too.

alexandercheema
3 replies
10h42m

Repo author here. That's correct. The embeddings for Llama-3-8B are around 8KB-10KB. For Llama-3-70B they're around 32KB. These are small enough to send around between devices on a local network. For a SETI@home style network, latency will kill you if you go over the internet. That's why we're starting with local networks.

mg
1 replies
9h18m

Ah yes. At first, I thought that since it is all one-way forward-only communication, latency would only affect the time to the first token.

But I guess the final output needs to be sent back to the first node before it can continue. So if there are 50 nodes with a latency of 40ms each, each token would take 2s to process.

alexandercheema
0 replies
9h11m

Yeah, unfortunately the autoregressive nature of these models slows it down significantly with added device<->device latency. However, you can still max out on throughput with pipeline parallelism, where you overlap execution. See: https://pytorch.org/docs/stable/pipeline.html

steeve
4 replies
11h30m

Yes, that’s how it works (pipeline parallelism)

mg
3 replies
11h28m

Interesting. Let's do the math ...

Let's say the model has 50B parameters and 50 layers. That would mean about one billion values have to travel through the wifi for every generated token?

I wonder how much data that is in bytes and how long it takes to transfer them.

blackbear_
2 replies
11h2m

It's not the parameters that are sent, it's the layer outputs. That makes for a few thousands floats per token

mg
1 replies
10h53m

Woops! I would have thought the number of neurons roughly equals the number of parameters, but you are right. The number of parameters is much higher.

tama_sala
0 replies
44m

The embedding size is only 8k so while the parameters are 70B. So it's a huge difference

pyinstallwoes
7 replies
6h23m

Swarm compute should be the norm for all compute - so much unused cpu across all the devices we collectively own.

_factor
2 replies
5h9m

This exists: https://aihorde.net/

I haven’t tried it, and not the norm, but I agree it should be more common. We have a global supercomputer with higher latency, but still a supercomputer.

dchuk
1 replies
4h25m

I might just still be too tired from just waking up, but I can’t for the life of me find any details on that site about what models are actually being served by the horde?

burkaman
0 replies
3h40m

Go to https://aihorde.net/api/, scroll down to /v2/status/models, and click Try it out and then Execute. It's an enormous list and I think it can be dynamically updated, so that's probably why it isn't listed on the website.

KronisLV
2 replies
5h58m

This might not work for use cases where you need low latency, but for longer winded processing it would be amazing if possible.

For example, if I have a few servers, laptop (connected to power) as well as a desktop PC and they’re all connected to a fast local network, it’d be great to distribute the task of rendering a video or working with archive files across all of them.

greggsy
1 replies
5h23m

Those are two precise examples that benefit from single core compute power, and are wholly unsuited to distributed computing…

KronisLV
0 replies
3h59m

Distributed rendering farms have existed for a while.

phito
0 replies
4h1m

I'd rather my CPU to be idle and not consome much power

matyaskzs
3 replies
8h25m

Cloud cannot be beaten on compute / price, but moving to local could solve privacy issues and the world needs a second amendment for compute anyway.

CuriouslyC
2 replies
6h22m

You can beat gpt4/claude in terms of price/performance for most things by a mile using fine tuned models running in a colo. Those extra parameters give the chatbots the ability to understand malformed input and to provide off the cuff answers about almost anything, but small models can be just as smart about limited domains.

ComputerGuru
1 replies
2h33m

The problem is that once you say “fine tuned” then you have immediately slashed the user base down to virtually nothing. You need to fine-tune per-task and usually per-user (or org). There is no good way to scale that.

Apple can fine-tune a local LLM to respond to a catalog of common interactions and requests but it’s hard to see anyone else deploying fine-tuned models for non-technical audiences or even for their own purposes when most of their needs are one-off and not recurring cases of the same thing.

CuriouslyC
0 replies
1h13m

Not necessarily, you can fine tune on a general domain of knowledge (people already do this and open source the results) then use on device RAG to give it specific knowledge in the domain.

iJohnDoe
3 replies
12h24m

Anyone run this? Works?

tdubhro1
1 replies
12h7m

The readme shows how to run it assuming you can run a python program on the device, so I expect it works with laptops and PCs but there's a note at the end of the page saying that the iOS app has fallen behind the python version so it's not clear to me how to get this running on your iphone or other such devices.

orsorna
0 replies
11h47m

The "device" in question must be Apple Silicon because the `mlx` package is a hard dependency, or at least an ARM machine (I do not have any Apple Silicon Macbooks or ARM machines to run this). I tried tweaking this before realizing calls to this library is littered all over the repo. I don't really understand the AI ecosystem very well but it seems that the use of the `mlx` library should be supplanted by some other library depending on the platform machine. Until then, and the actual release of the iOS code somewhere, "everyday devices" is limited to premium devices that almost no one has more than one of. I'm looking forward to run this on other machine platforms and squeeze out what I can from old hardware laying around. Otherwise I doubt the tagline of the project.

Edit: to add on, the only evidence that this runs anywhere but Apple Silicon is the maintainer's Twitter where they show it running on two Macbook Pros as well as other devices. I'm not sure how many of those devices are not ARM.

I'm not throwing shade at the concept the author is presenting, but I'd appreciate if they could slow down functional commits (he is writing them right now as I type) and truthfully modify the documentation to state which targets are actually able to run this.

acosmism
0 replies
11h46m

why ask? try it!

ulrischa
2 replies
3h20m

Does somebody know if it runs on a raspberry?

alexandercheema
1 replies
1h7m

It *should* but I haven't tried it. I will try it. Updated in this issue:

We could also try raspberry pi + coral usb tpu (https://coral.ai/products/) - that might be a killer combo for super cheap home ai cluster.

makmanalp
2 replies
3h43m

Question - if large clusters are reporting that they're seeing gains from using RDMA networks because communication overhead is a bottleneck, how is it possible that this thing is not massively bottlenecked running over a home network?

derefr
0 replies
2h47m

I haven't looked into exactly what this project is doing, but here's my understanding:

Inference across O(N) pre-trained hidden layers isn't exactly an "embarrassingly parallel" problem, but it is an "embarrassingly pipeline-able" problem (in the CPU sense of "pipelining.") Each device can keep just one or a few layers hot in their own VRAM; and also only needs to send and receive one small embedding (<1MB) vector per timestep — which is so trivial that it's easily achievable in realtime even if all the devices are on wi-fi, talking to the same router, in your "noisy" apartment where 100 other neighbours are on the same bands.

(To put it another way: running a single inference job, has more forgiving realtime latency+throughput requirements than game streaming!)

Assuming that you have a model that's too big for any of your home machines to individually hold; and that all you care about is performance for single-concurrent-request inference on that model — then in theory, you just need one GPU of one node of your homespun Beowulf GPU cluster to have enough VRAM to keep the single largest layer of your model always-hot; and then other smaller devices can handle keeping the smaller layers always-hot. And the result should be faster than "overloading" that same model on that single largest-VRAM device and having some layers spill to CPU, or worse yet, having the GPU have to swap layers in and out repeatedly with each inference step.

(Also, if you're wondering, in the case where a single machine/node has multiple GPUs — or a GPU+VRAM and also a CPU+RAM! — you can treat this as no different than if these were multiple independent nodes, that just-so-happen to have a very efficient pipeline communication channel between them. As the VRAM+computation cost of running inference far outweighs the communication overhead of forward propagation during inference, a home-network inference-pipelining cluster scheduler like this project, would still likely "schedule" the model's layers purely in consideration of the properties of the individual GPU+VRAM (or CPU+RAM), rather than bothering to care about placement.)

---

That being said, AFAIK training is "pipeline parallelizable" exactly as inference is. And people training models do do this — but almost always only across multiple top-of-the-line GPUs in one machine; not across multiple machines.

When you think about what pipelining achieves for training — all you get is either:

1. the ability to use a bunch of small-aggregate-VRAM nodes to achieve the aggregate training capacity of fewer, larger-aggregate-VRAM nodes — but with more power consumption = higher OpEx; and where also, if you scale this to O(N), then you're dumping a quadratic amount of layer-propagation data (which is now both forward-prop and backprop data, and backprop data is bigger!) over what would likely be a shared network just to make this work. (If it's not a shared network — i.e. if it's Infiniband/other RDMA — then why did you spend all that CapEx for your network and not on your GPUs!?)

2. the ability to pipeline a bunch of large-aggregate-VRAM nodes together to train a model that will then never be able to be deployed onto any single node in existence, but can instead only exist as a "pipelined inference model" that hogs O(log N) nodes of your cluster at a time for any inference run. Which makes cluster scheduling hell (if you aren't just permanently wiring the scheduler to treat O(log N)-node groups as single "hyper-nodes"); makes it so that you'll never be able to practically open-source the model in a way anybody but other bigcorps could ever run it (if that's something you care about); and very likely means you're cutting the concurrent-inference-request-serving capacity of your huge expensive GPU cluster by O(log N)... which the product team that allowed that cluster to be budgeted is really not gonna like.

That being said, I imagine at some point one of these proprietary "Inference-as-a-Service" models has been trained at a layer size that puts it into pipelined-inference-only territory, temporarily. Doing so would be the ML engineer's equivalent to the CPU engineer's "we have no fundamentally clever advance, so this quarter we'll just crank up the clock frequency and deal with the higher TDP." (Heck, maybe GPT-4o is one of these.)

---

What people with GPU clusters want, is 1. for the output of the process to be a model that runs on a single (perhaps multi-GPU) node; and 2. for the process itself to be mostly-shared-nothing with as little cross-node communication burden as possible (such that it's just a question of building highly internally communication-efficient nodes, not so much highly-communication-efficient clusters.)

And both of those goals are achieved by sizing models so that they fit within a single node; continuously fanning out streams of training data to those nodes; and then periodically fanning back in model-weights (or model-weight deltas) in an AllReduce operation, to merge the learning of O(N) independently-training nodes to become the new baseline for those nodes.

(If you'll note, this architecture doesn't put any latency requirements on the network, only some monstrous throughput requirements [at the fan-in step] — which makes it a lot easier to design for.)

DistractionRect
0 replies
3h12m

I suspect that most of the devices you'd expect to find in your consumer cluster are too small/slow to saturate the link.

Edit: it's also a matter of scale. You probably have a small number of small/slow devices in a consumer network versus a lot of large/fast devices in your enterprise cluster.

ajnin
2 replies
7h11m

It requires mlx but it is an Apple silicon-only library as far as I can tell. How is it supposed to be (I quote) "iPhone, iPad, Android, Mac, Linux, pretty much any device" ? Has it been tested on anything else than the author's MacBook ?

orsorna
0 replies
4h34m

One of the maintainers has a video demo on his twitter claiming iOS, android and Linux. Some of the code is not released and I wish they were advertising that properly.

lopuhin
0 replies
2h23m

The README says they plan to add llama.cpp support which should cover a lot of targets, also they have tinygrad already integrated I think.

whoami730
1 replies
7h19m

Is it possible to use this for image recognition and like? Not sure what can be the usage of this apart from as a chatbot.

tama_sala
0 replies
42m

You can use other models like a vision LLM, or use AI agents as well

throwawaymaths
1 replies
1h11m

Is this sensible? Transformers are memory bandwidth bound. Schlepping activations around your home network (which is liable to be lossy) seems like it would result in atrocious TPS.

alexandercheema
0 replies
1h9m

"Transformers are memory bandwidth bound" - this is the precise reason why this makes sense. If a model doesn't fit into memory on a single device, it needs to be incrementally loaded into memory (offloading), which is bottlenecked by memory bandwidth. Splitting the model over multiple devices avoids this, instead trading off for latency of communicating between nodes. The network bandwidth requirements are minimal since only the activations (intermediary embeddings) are passed between devices. For Llama-3-8B these are ~10KB, for Llama-3-70B these are ~32KB.

tarasglek
1 replies
10h51m

This is the first timer i've seen tinygrad backend in the wild. Amusing that it's supposedly more stable than llama.cpp for this project.

alexandercheema
0 replies
10h46m

Repo author here. Tinygrad changes rapidly so wouldn't it say it's "more" stable, but it certainly supports more accelerators than llama.cpp. As George Hotz likes to say, it sits somewhere on the spectrum between llama.cpp and Mojo. No hand-written kernels, optimal kernels are generated and found by beam search.

pierrefermat1
1 replies
8h7m

Would be great if we could get some benchmarks on commonly available hardware setups.

pharrington
0 replies
7h58m

I'm sure someone will show their benchmarks in a couple years!

dcreater
1 replies
2h25m

This is a great ideal and user friendly as well. Has the potential of converting multiple old devices overnight from being useless. However, I wish they had provided some results on tok/s, latency with some example setups.

alexandercheema
0 replies
2h18m

We didn't expect this to blow up so quickly. A lot of work needs to be done on getting different setups working. I have made an issue here: https://github.com/exo-explore/exo/issues/11

christkv
1 replies
6h12m

Is apple silicon with a lot of memory 32Gb and up still considered a cheapish way to run models or are there other options now?

talldayo
0 replies
2h35m

A good Apple Silicon Mac with 32gb of RAM will cost you over $2,000 on-sale. For that price you might as well buy an Nvidia machine instead, either two 3090s or a 64gb Jetson Orin board would be both cheaper and faster.

The markup on Apple hardware is so big that I just don't think "cheapish" will ever be a way to describe the position they hold in the AI market. Apple's current budget lineup gets smoked by an RTX 3060 in a cheap Linux homeserver; the bar for high-value AI has been raised pretty high.

thom
0 replies
11h9m

Bexowulf.