Live data from Hacker News

Show HN: sllm – Split a GPU node with other developers, unlimited tokens

sllm.cloud

11–20 of 117 posts

Re: Show HN: sllm – Split a GPU node with other developers, unlimited tokens

#11
post #3

1. Is the given tok/s estimate for the total node throughput, or is it what you can realistically expect to get? Or is it the worst case scenario throughput if everyone starts to use it simultaneously? 2. What if I try to hog all resources of a node by running some large data processing and making multiple queries in parallel? What if I try to resell the access by charging per token? Edit: sorry if this comment sound…

1. It's an average. 2. We have sophisticated rate limiter.

Re: Show HN: sllm – Split a GPU node with other developers, unlimited tokens

#12
post #8

Is this not a more restricted version of OpenRouter? With OpenRouter you pay for credits that can be used to run any commercial or open-source model and you only pay for what you use.

OpenRouter is a little different. We are trying to experiment with maximizing a single GPU cluster.

Re: Show HN: sllm – Split a GPU node with other developers, unlimited tokens

#13
This is an excellent idea, but I worry about fairness during resource contention. I don't often need queries, but when I do it's often big and long. I wouldn't want to eat up the whole system when other users need it, but I also would want to have the cluster when I need it. How do you address a case like this?

Re: Show HN: sllm – Split a GPU node with other developers, unlimited tokens

#14
post #7

How is the time sharing handled? I assume if I submit a unit of work it will load to VRAM and then run (sharing time? how many work units can run in parallel?) How large is a full context window in MiB and how long does it take to load the buffer? I.e. how many seconds should I expect my worst case wait time to take until I get my first token?

> how many work units can run in parallel

not original author but batching is one very important trick to make inference efficient, you can reasonably do tens to low hundreds in parallel (depending on model size and gpu size) with very little performance overhead

Re: Show HN: sllm – Split a GPU node with other developers, unlimited tokens

#17
post #7

How is the time sharing handled? I assume if I submit a unit of work it will load to VRAM and then run (sharing time? how many work units can run in parallel?) How large is a full context window in MiB and how long does it take to load the buffer? I.e. how many seconds should I expect my worst case wait time to take until I get my first token?

vLLM handles GPU scheduling, not sllm. The model weights stay resident in VRAM permanently so there's no loading/unloading per request. vLLM uses continuous batching, so incoming requests are dynamically added to the running batch every decode step and the GPU is always working on multiple requests simultaneously. There is no "load to VRAM and run" per request; it's more like joining an already-running batch.

TTFT is under 2 seconds average. Worst case is 10-30s.

Re: Show HN: sllm – Split a GPU node with other developers, unlimited tokens

#18

This is the most "Prompted ourselves a Shadcn UI" page I've seen in a while lol I dig the idea! I'm curious where the costs will land with actual use.

Thanks lol. I actually like Shadcn's style. It's sad that people view it as AI now.

Re: Show HN: sllm – Split a GPU node with other developers, unlimited tokens

#19

25 t/s is barely usable. Maybe for a background runner

> 25 t/s is barely usable. Maybe for a background runner

That's over a 1000 words/s if you were typing. If 1000 words/s is too slow for your use-case, then perhaps $5/m is just not for you.

I kinda like the idea of paying $5/m for unlimited usage at the specified speed.

It beats a 10x higher speed that hits daily restrictions in about 2 hours, and weekly restrictions in 3 days.

Re: Show HN: sllm – Split a GPU node with other developers, unlimited tokens

#20

This is an excellent idea, but I worry about fairness during resource contention. I don't often need queries, but when I do it's often big and long. I wouldn't want to eat up the whole system when other users need it, but I also would want to have the cluster when I need it. How do you address a case like this?

We implement rate-limiting and queuing to ensure fairness, but if there are a massive amount of people with huge and long queries, then there will be waits. The question is whether people will do this and more often than not users will be idle.
Post reply on HN