7 ms·
Show HN: sllm – Split a GPU node with other developers, unlimited tokens
Running DeepSeek V3 (685B) requires 8×H100 GPUs which is about $14k/month. Most developers only need 15-25 tok/s. sllm lets you join a cohort of developers sharing a dedicated node. You reserve a spot with your card, and nobody is charged until the cohort fills. Prices start at $5/mo for smaller models.
The LLMs are completely private (we don't log any traffic).
The API is OpenAI-compatible (we run vLLM), so you just swap the base URL. Currently offering a few models.
- mmargenot 6mo agoThis is a great idea! I saw a similar (inverse) idea the other day for pooling compute (https://github.com/michaelneale/mesh-llm https://github.com/michaelneale/mesh-llm). What are you doing for compute in the backend? Are you locked into a cohort from month to month?
- vova_hn2 6mo ago1. 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 sounds overly critical. I think that pooling money with other developers to collectively rent a server for LLM inference is a really cool idea. I also thought about it, but haven't found a satisfactory answer to my question number 2, so I decided that it is infeasible in practice.
- esafak 6mo agoLike vast.ai and TensorDock, and presumably others.
- spuz 6mo agoIt seems crazy to me that the "Join" button does not have a price on it and yet clicking it simply forwards you to a Stripe page again with no price information on it. How am I supposed to know how much I'm about to be charged?
- jrandolf 6mo agoThat was an error on our part lol. We'll update with the price.
- peter_d_sherman 6mo agoWhat a brilliant idea! Split a "it needs to run in a datacenter because its hardware requirements are so large" AI/LLM across multiple people who each want shared access to that particular model. Sort of like the Real Estate equivalent of subletting, or splitting a larger space into smaller spaces and subletting each one... Or, like the Web Host equivalent of splitting a single server into multiple virtual machines for shared hosting by multiple other parties, or what-have-you... I could definitely see marketplaces similar to this, popping up in the future! It seems like it should make AI cheaper for everyone... that is, "democratize AI"... in a "more/better/faster/cheaper" way than AI has been democratized to date... Anyway, it's a brilliant idea! Wishing you a lot of luck with this endeavor!
- kaoD 6mo agoHow 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?
- ninjha 6mo ago> 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
- jrandolf 6mo agovLLM 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.
- kaoD 6mo ago> The model weights stay resident in VRAM permanently so there's no loading/unloading per request. Yes, I was thinking about context buffers, which I assume are not small in large models. That has to be loaded into VRAM, right? If I keep sending large context buffers, will that hog the batches?
- deleted 6mo ago[deleted]
- jrandolf 6mo agoNot if you are the only one. We have rate limits to prevent this in case, idk, you share your key with 1000 people lol.
- spuz 6mo agoIs 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.
- jrandolf 6mo agoOpenRouter is a little different. We are trying to experiment with maximizing a single GPU cluster.
- singpolyma3 6mo ago25 t/s is barely usable. Maybe for a background runner
- lelanthran 6mo ago> 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.
- singpolyma3 6mo agoSure if it was just a matter of typing. But in practise it means sitting and staring for minutes at nothing happening with a "thinking" until something finally happens. I mean my local 122b is only 20t/s so for background stuff it can be used for that. But not for anything interactive IME.
- lelanthran 6mo ago> I mean my local 122b is only 20t/s so for background stuff it can be used for that. But not for anything interactive IME. What are you running that local 122b on? I mean, this looks attractive to me for $5/m running unlimited at 20t/s-25t/s, but if I could buy hardware to get that running locally, I don't mind doing so.
- singpolyma3 6mo agoFramework desktop
- freedomben 6mo agoThis 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?
- jrandolf 6mo agoWe 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.
- freedomben 6mo agoIs there any way to buy into a pool of people with similar usage patterns? Maybe I'm overthinking it, but just wondering
- ssl-3 6mo agoI think it'd be best to pool with people with different patterns, not the same patterns. Perhaps it would be best to pool with people in different timezones, and/or with different work/sleep schedules. If everyone in a pool uses it during the ~same periods and sleeps during the ~same periods, then the node would oscillate between contention and idle -- every day. This seems largely avoidable. (Or, darker: Maybe the contention/idle dichotomy is a feature, not a bug. After all, when one has control of $14k/month of hardware that is sitting idle reliably-enough for significant periods every day, then one becomes incentivized to devise a way to sell that idle time for other purposes.)
- vineyardmike 6mo agoThis is basically why the big companies can sell subscriptions for cheaper than API costs. First priority can go to API users, lower priority subscription users get slotted in as space/SLO allows, and then sell the remaining idle GPU to batch users and spare training. Oh and geography shift as necessary for different nations working hours.
- varunr89 6mo ago$40/mo for deepseek r1 seems steep compared to a pro sub on open ai /claude unless you run 24x7. im not sure how sharing is making this affirdable.
- lelanthran 6mo ago> $40/mo for deepseek r1 seems steep compared to a pro sub on open ai /claude unless you run 24x7. "Running 24x7" is what people want to do with openclaw.
- mrklol 6mo agoSeems like they have a rate limit so it is kinda the same as normal subs - don’t really see the advantage yet
- wongarsu 6mo agoPresumably the rate limit is much higher
- lelanthran 6mo ago> Seems like they have a rate limit so it is kinda the same as normal subs - don’t really see the advantage yet It's not really the same "limit", AIUI. SLLM: Being capped to the rate would make your openclaw run slowly, but still be able to work 24x7. Normal Subs: Hiting the limit means your openclaw doesn't run at all for hours.
- mememememememo 6mo agoYes you don't choose this for the price. But because you want to control yout dependencies.
- Lalabadie 6mo agoThis 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.
- mogili1 6mo agoCan you show a comparison of cost of we went per token pricing.
- jrandolf 6mo agoSee https://news.ycombinator.com/item?id=47670843 https://news.ycombinator.com/item?id=47670843
- QuantumNomad_ 6mo ago> How does billing work? > When you join a cohort, your card is saved but not charged until the cohort fills. Stripe holds your card information — we never store it. Once the cohort fills, you are charged and receive an API key for the duration of the cohort. Have any cohorts filled yet? I’m interested in joining one, but only if it’s reasonable to assume that the cohort will be full within the next 7 days or so. (Especially because in a little over a week I’m attending an LLM-centered hackathon where we can either use AWS LLM credits provided by the organizer, or we can use providers of our own choosing, and I’d rather use either yours or my own hardware running vLLM than the LLM offerings and APIs from AWS.) I’d be pretty annoyed if I join a cohort and then it takes like 3 months before the cohort has filled and I can begin to use it. By then I will probably have forgotten all about it and not have time to make use of the API key I am paying you for.
- jrandolf 6mo agoNo cohorts have been filled yet. We're still early. We are seeing reservations pick up quickly, but I'd be able to give you a more concrete estimate of fill velocity after about a week. That said, we're planning to add a 7-day window: if a cohort doesn't fill within 7 days of your reservation, it cancels automatically and your card is released. We don't want anyone's payment method sitting in limbo indefinitely.
- tcdent 6mo agoThis is a fantastic idea. On a nonzero number of occasions I have priced the cost of running an inference server with a model that is actually usable and the annual cost is astronomical.
- p_m_c 6mo agoDo you own the GPUs or are you multiplexing on a 3rd party GPU cloud?
- jrandolf 6mo agoMultiplexing on a GPU cloud.
- RIMR 6mo agoI read the FAQ, and I can't imagine this is going to work the way you want it to. It fundamentally doesn't make sense as a business model. I can sign up for a cohort today, but there's not even a hint of how long it will take the cohort to fill up. The most subscribed cohort is only at 42% (and dropping), so maybe days to weeks? That's a long time to wait if you have a use case to satisfy. And then the cohort expires, and I have to sign up for another one and play the waiting game again? Nobody wants that level of unreliability. Also, don't say "15-25 tok/s". That is a min-max figure, but your FAQ says that this is actually a maximum. It makes no sense to measure a maximum as a range, and you state no minimum so I can only assume that it is 0 tok/s. If all users in the cohort use it simultaneously, the best they're getting is something like 1.5 tok/s (probably less), which is abyssmal. You mention "optimization", but I have no idea what that means. It certainly doesn't mean imposing token limits, because your FAQ says that won't happen. If more than 25 users are using the cohort simultaneously, it is a physical impossibility to improve performance to the levels you advertise without sacrificing something else, like switching to a smaller model, which would essentially be fraud, or adding more GPUs which will bankrupt you at these margins. With 465 users per cohort, a large chunk of whom will be using tools like OpenClaw, nobody will ever see the performance you are offering. The issue here is you are trying to offer affordable AI GPU nodes without operating at a loss. The entire AI industry is operating at a loss right now because of how expensive this all is. This strategy literally won't work right now unless you start courting VCs to invest tens to hundreds of millions of dollars so you can get this off the ground by operating at a loss until hopefully you turn a profit at some point in the future, but at that point developers will probably be able to run these models at home without your help.
- jrandolf 6mo agoGoing on ChatGPT.com and using their AI for 24 hours doesn't mean you are actually using their LLM for 24 hours. It's only live for as long as the output is being generated. You reading, waiting for tool calls, etc. don't count toward concurrency. Factor in time-zones, lunch times, etc...it's more likely that we'd have an underutilization problem. For filling up the cohorts, I agree and we're launching for a week to gather feedback.
- aritzdf 6mo ago[flagged]
- tensor-fusion 6mo ago[flagged]
- scottcha 6mo agoPretty cool idea, but whats the stack behind this? As 15-25 tok/s seems a bit low as expected SoA for most providers is around 60 tok/s and quality of life dramatically improves above that.
- jrandolf 6mo ago15-25 was a rate based on oversubscription. Now it's 60 like others :).
- sacrelege 6mo ago[dead]
- IanCal 6mo agoCan you explain the benefits over something like openrouter?
- jrandolf 6mo ago24/7 LLM for $10/month.
- johndough 6mo agoIsn't this a bad deal? Or is there an error in my math? For $40, I'd get 20 tok/s * 2.6M seconds per month = 52M tokens of DeepSeek v3.2 per month if I run it 24/7, which is not realistic for most workloads. On OpenRouter [1], $40 buys 105M tokens from the same model, which is more than 52M tokens, and I can freely choose when to use them. [1]: https://openrouter.ai/deepseek/deepseek-v3.2 https://openrouter.ai/deepseek/deepseek-v3.2
- deleted 6mo ago[deleted]
- jrandolf 6mo ago20 tok/s is an average. It can be more, it can be less. If you are running off-peak I'm sure you'd get some crazy number.
- moralestapia 6mo agoThis is great, thanks! I personally would like something like this but with "regular" GPU access. Some people still use them for something other than LLMs ^^.
- jrandolf 6mo agoThere is vast.ai!
- moralestapia 6mo agoWow! I recall hearing about them years ago. Good to see they're thriving!
- latchkey 6mo agohotaisle.xyz has amd mi300x VMs for $1.99/gpu/hr. on-demand, billed by the minute. (i'm the ceo)
- MuffinFlavored 6mo ago> Running DeepSeek V3 (685B) requires 8×H100 GPUs which is about $14k/month. Most developers only need 15-25 tok/s. > deepseek-v3.2-685b, $40/mo/slot for ~20 tok/s, 465 slots total > 465 users × 20 tok/s = 9,300 tok/s needed > The node peaks at ~3,000 tok/s total. So at full capacity they can really only serve: > 3,000 ÷ 20 = 150 concurrent users at 20 tok/s > That's only 32% of the cohort being active simultaneously.
- artificialprint 6mo agoPeople work 8 hours a day presumably, I guess they are banking on this idea
- ycui1986 6mo agoonly works if the users are evenly distributed around the globe (which is likely more of less the case). if the user concentrates in on century, the token rate will be terrible.
- artificialprint 6mo agoDidn't make sense to launch multiple 10 and 40 bucks subscriptions right at the start, because now they are competing with each other. Also mobile version is a bit broken, but good idea and good luck!
- jrandolf 6mo agoI'm feeling it Mr. Crabs.
- trvz 6mo ago[flagged]
- copperx 6mo agoThere's a big difference between non-compliant, illegal, and criminal.
- maxbeech 6mo ago[dead]
- aplomb1026 6mo ago[dead]
- avereveard 6mo agoInteresting there's a trickle of low intensity job one can always get running but like glm own plan is $30/mo and something about 300tps now I know that one is subsidized but still.
- spencer9714 6mo agoInteresting concept. One thing I’m curious about if I’m in a cohort for something like DeepSeek V3 and another user spins up a heavy 24/7 job, how do you keep TTFT from degrading? vLLM’s continuous batching helps, but there’s still a physical limit with shared VRAM/compute. I’ve been grappling with this exact 'noisy neighbor' issue while building Runfra. We actually ended up moving toward a credit per task model on idle GPUs specifically to avoid that resource contention entirely. Curious how you’re thinking about isolation here. Is there any hard guarantee on a 'slice' of the GPU, or is it mostly just handled by the vLLM scheduler?
- bluerooibos 6mo agoSo shared hosting for LLMs?
- jrandolf 6mo agoYes.
- wavemode 6mo ago> nobody is charged until the cohort fills So then what happens if some people's payment method fails once you do charge?
- lelanthran 6mo ago> So then what happens if some people's payment method fails once you do charge? I expect its a pre-auth, like car rental companies do; a pre-auth gives you a code from the card issuer and an expiry. The issuer will reserve the amount on the cardholders account, and only perform the transaction to the merchant once the merchant sends a second message with the pre-auth code.
- rendaw 6mo agoOnce you're in a cohort how do you actually use it?
- jrandolf 6mo agoYou get an API key
- yoavm 6mo ago> Prices start at $5/mo for smaller models. Is there actually any $5/mo offering? It seems like the cheapest models start at $10.
- dreamdayin9 6mo agowhat is the main moat of your idea? privacy? otherwise it looks like a less flexible API compared to what chutes.ai or openrouter.ai providing. and they have TEE instances, which are more private. also why did u decide on launching V3 instead of some much more exciting models revealed recently like MiMo-V2-Pro or Arcee's Trinity Large?
- jrandolf 6mo agoYou're right that we're less flexible than OpenRouter or Chutes. We don't let you hop between models per-request. If you want that, use those. If you want predictable cost and guaranteed throughput on one model, that's us. On TEE: yeah, it's stronger, but it also adds cost and latency. We run dedicated hardware with no prompt logging and an isolated proxy. For most people who just don't want their data in someone's training set, that's enough. If your threat model is more serious than that, we're not the right choice. On models: we are focusing on Qwen for now. We add based on demand. Would you actually use MiMo-V2-Pro or Trinity if we had them?
- trick-or-treat 6mo ago[flagged]
- tapvt 6mo agoFor my part, the code quality of the next.js dashboard isn't even something I'd evaluate. I instantly get a quick, functional-appearing view of the offering. I can picture how I might interact with it and what mental gymnastics stand between right now and me pulling out a credit card. I don't see marketing fluff that bring up more questions than it provides answers. I can be pretty certain I won't wind up in a sales funnel from hell, also.
- trick-or-treat 6mo agoRight but without at least the effort of a sales funnel I have zero confidence that this guy has thought anything through. This is a single afternoon vibe-coded project by all indications.
- jrandolf 6mo agoThe audience here is developers buying API access. They want to see the model, the price, and the throughput, not a hero image and three paragraphs about our mission. Marketing copy between a developer and that information is friction.
- OJFord 6mo agoEspecially with only 1mo commitment, what happens if there's a lot of churn after the first month – more people leave a cohort than are waiting for one? The whole cohort is then waiting for it to fill again before it restarts? And will people waiting for the next cohort to fill automatically be reassigned to the last (now not full) one anyway, or would there then be multiple partially filled cohorts for a single spec? I like the idea, I just wouldn't want my subscription to suddenly be on hold because a peer decided to stop theirs.
- calvinsun1102 6mo ago“Unlimited tokens” is doing a lot of heavy lifting here. This feels less like a pricing breakthrough and more like shifting the abstraction down to GPU sharing — which most developers probably don’t want to think about. Curious how usable this actually feels under contention.
- aerhardt 6mo agoThis comment reeks of AI. Out of your other three comments in the your entire account’s history, two of them are pretty structurally identical: quote hook + tangentially related question. What is the ultimate play for all these AI accounts? Warming them up for future astroturfing and marketing? Manipulating upvotes?
- adamsilvacons 6mo ago[flagged]
- pgbouncer 6mo ago1 week or even 1 day windows would be great, especially just to test it at this early stage
- latchkey 6mo agoThere are a number of on-demand providers of GPU compute out there. It is relatively straightforward to run inference on them. I've got a box of 8x MI300x sitting around waiting for stuff like this. $128... 8x MI300X Bare Metal - $15.94/hour (1 available) CPU: Xeon Platinum 8462Y+ (64 cores) • Memory: 2.0 TiB • Disk: 124 TB • Minimum Reservation: 8 hours ssh admin.hotaisle.app (i'm ceo)
- rpdaiml 6mo ago[dead]
- jrandolf 6mo agoThanks to everyone who shared feedback. We’re implementing it now. Here’s what’s changed: - We’ve removed the other LLMs for now and are focusing entirely on Qwen 3.5. We’ll bring back additional smaller models later, but most usage was already concentrated on Qwen 3.5. - Pricing is now around $50. You get roughly 2× the throughput (61 tok/s vs. 31 tok/s, verified in testing), and it’s still unlimited. For context, that’s about 158M tokens per month. Comparable providers like Novita charge around $3.2 per million tokens, so this comes out to roughly 10% of typical token costs. - Context size is now capped at 32K tokens. For the vast majority of use cases, this is more than sufficient.
- dockerd 6mo agoI received an email mentioning that earlier cohorts are canceled. Apparently, the earlier pricing was better for us as customers because I had the option to opt for a lower price, i.e $10 per month with a one month commitment and see how the platform evolves and then sign up for other models post testing as needed. I am not sure how long this new cohort will take to fill now. A slightly better option (looking back) would have been to take multiple options from the customer list and start with the one that meets the threshold.
- jrandolf 6mo agoFirst, thanks for signing up early. It means a lot. The $10/mo price needed 465 people to fill a cohort before we could turn on a single GPU. People signed up and churned while waiting, so we looked at the reservation pattern and determined 80 slots was optimal. This reflects in the new price and throughput. We're considering a 1-week option so people can test it out before committing to a full month. Would that help?
- sunsation 6mo ago[flagged]
- jrandolf 6mo agoWe collect emails to notify you when the cohort fills or any important information such as cancellation. No one's selling your email. Also, please read https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. HN is a community for thoughtful discussion.
- sunsation 6mo agoI was monitoring all the cohort as I was looking for to this. The site was showing that 4 out of 6 had a sign up of 464 out of 465, so numbers were deceiving. Now I end up with not having a way to unsubscribe or close my account.
- jrandolf 6mo agoWe are aware of this. There was a bug that overcounted and now it's been fixed. If you'd like for us to delete your account, please contact support@sllm.cloud.
- tensor-fusion 6mo ago[dead]
- cedws 6mo agoJust came back to this and saw it's shutting down. Unfortunate.