Back to News
Advertisement
Advertisement

⚡ Community Insights

Discussion Sentiment

79% Positive

Analyzed from 577 words in the discussion.

Trending Topics

#nodes#models#network#lab#model#token#split#hardware#glm#cores

Discussion (22 Comments)Read Original on HackerNews

SwellJoe•about 2 hours ago
I note the lack of performance information. I can only imagine it's much, much, slower than any other way to run a larger model (including, e.g. using system RAM and streaming some stuff from disk). Consumer networks, even 10gbit ethernet, are slow as hell compared to local RAM and even disks.

Are we talking 1 token per second for a split model? Less?

Edit: Found a number. On the models list, Qwen 235B A22B says "MoE 235B/22B, proven at 16 tok/s across 2 nodes". They don't say what the nodes are and what network connection they have, but that's a respectable speed. Not quite comfortable for interactive use, but pretty close.

i386•about 1 hour ago
This was done on my home lab simulating 5ms latency and jitter between machines. Splits work quite well if you your nodes are over WAN at metro latency’s but not super fast on global WAN.

The idea is that you could take several machines without dedicated RDMA or NVLINK fabric and use them to serve a large model on hardware you own then share it with others.

I’m currently working on GLM 5.2 on my lab environment with around 10 tok/s on the same split.

SwellJoe•about 1 hour ago
That sounds cool, but it's still pretty meaningless without information about what your home lab looks like. A few DGX Sparks wired up with their fancy super fast network is much different than a few laptops on wifi.
zdw•about 1 hour ago
What hardware (CPU/GPU/memory) and network was used for this? What quantization for GLM 5.2? How much tuning of the split was needed?
i386•42 minutes ago
The lab features two Mac Studios: an Apple M3 Ultra (32 CPU cores, 80 GPU cores, 256 GB unified memory) and an Apple M1 Ultra (20 CPU cores, 48 GPU cores, 128 GB unified memory), both connected via 1Gbit Ethernet.

We use a customized Q2 quantization that preserves sensitive tensors at Q8.

To reduce compute time per layer, we are developing a custom GLM DSA Metal graph.

While we are not yet approaching MTP, we plan to port our existing MTP implementations from versions 4.7 and 5.1 to 5.2.

Since GLM's MTP acceptance rate is very high for a single predicted token, we are exploring token prediction techniques to widen the predicted tokens and utilize parallelism for verification.

woadwarrior01•about 2 hours ago
Perf should be fairly straightforward to ballpark. You'll need to transfer roughly 2 . hidden_size . num_shards bytes over the network per token during autoregressive decoding. And divide that number by chunk size during prefill.
i386•about 2 hours ago
I’m one of the contributors to Mesh LLM and happy to answer any questions. I authored the skippy engine that allows you to split large models across nodes.
iotapi322•39 minutes ago
This is super impressive, We have a lab with lots of different epycs and different models - to bring them together this way is amazing. Well done!
i386•32 minutes ago
Thank you! AMD is a weak spot in our testing right now. If you’re willing to contribute or let us borrow some compute time, drop in on the Discord.
darkpicnic•about 2 hours ago
Does Mesh LLM encrypt the payload between nodes? Is it possible to read requests from other users?
metadat•about 1 hour ago
Just wondering, why do you care about encryption in this context?
darkpicnic•29 minutes ago
If payloads to LLMs are being passed around to various nodes, even trusted ones (like friends and family), it gets awkward if you send something very personal. Think sending a medical question to medgemma:27b.
tekacs•about 2 hours ago
I'm not affiliated, but yes – the main 'point' of iroh is that it's 'dial-a-key', QUIC with encryption based on the keys of the endpoints.
jmercouris•about 3 hours ago
I thought about this too, but the throughput over a network is incredibly slow. It’s not usable for interactive use.
i386•about 1 hour ago
That isn’t true. llama RPC is incredibly slow but staged splits in skippy are orders of magnitude faster.
turtleyacht•about 3 hours ago
It sounds like iroh enables distributed compute without having to finangle custom hardware.
darkpicnic•about 3 hours ago
cocompute.ai is already doing this really well.
SwellJoe•about 3 hours ago
Is it? I don't see anything on the website about splitting a model across multiple devices, only about putting local models on the internet, a wholly orthogonal problem (which is already easy with existing tools, since models use an http API).
darkpicnic•about 2 hours ago
Good point. I know cocompute is working on splitting, but it’s not there yet; I was referring to the round-robin delegation within a trusted pool. Mesh LLM looks great too!
dnoberon•about 3 hours ago
Cool, always good to have more in the ecosystem. I love Iroh and hope this continues to succeed.
_superposition_•about 1 hour ago
I just wish I had the hardware to try it out!