More seriously though, I think we should be fine: we don't host any content, and what people do with the models is their own responsibility (legally speaking, in our jurisdiction, at least according to Claude -- we're talking to a real lawyer next week). Like any other provider, we offer no guarantees of sane, safe, or accurate results.

▲

gguingff 5 hours ago | parent | next [-]

Thanks for bringing up a service like this, it's quite important. A few serious questions if you don't mind.

Confidentiality? Do you use any sort of logging and if not do you have a way to guarantee that your hosting providers are not snooping?

Price vs Vast or Runpod? If i have a very large or a very small workload do you have a competitive rate vs a gpu provider that offers private gpu access?

Subscription vs Api costs? Do you only offer api rate or will you offer discounted tokens for subscription? Subscription friendly towards open source harnesses such as omp?

Heretic ablation vs other methods? KL divergence scores? Do you post train the weights yourselves or do you offer weights trained by other organizations and is this information available on the service?

Cache hit/miss pricing policy? 90/10 or a different cache pricing policy, and how long do conversions stay in kv cache?

Quantized cache and model? Do you offer a choice if i want a quantized model for speed or a quantized cache? If not do you publish the information?

SGlang vs vllm or other inference engine? Do you publish your engine stack details?

Thank you kindly I find the competition in this space very lacking.

	▲	TofuLover 4 hours ago \| parent [-]
		These are great questions, thanks! I'll answer them in turn, in a list because I like lists. * Confidentiality: no logging, third party analytics, or anything like that. More details in our Privacy Poilicy [1]. Our hosting providers will have their own policies, but we're not running a super private service like Proton or similar. Might do some kind of secure tenancy in the future if there's demand. * Price: I think Runpod vs per-token are very different beasts and for different purposes. I really can't make a direct comparison, as it'll be based on use case, but we're going for convenience over price, so all else being equal I'd expect us to be more expensive for most users anyway (edit: i meant "than other API providers"! We'd definitely need to be cheaper or at least competitive with spinning up your own cloud infra. We'd have parallelism and economies of scale on our side for this). We have a lot of experience with running and optimising open models though, so that's part of the value proposition too. * Subscriptions: Only API for now. Maybe subscription later but honestly we prefer simplicity. My own experience with subscription plans is that they're usually sold at a huge loss at first, then the price creeps up as the service is enshittified. That feels like a bit of a scam to get users, and that's not really what we're about. We want to provide something specific, and aren't really concerned about scaling as fast as possible. Maybe we'll provide subscriptions if there's a real demand for it, but no plans at the moment to do so. * Methodology: we use abliterated models, but I've been advised to hold off talking about that for now. Might make a blog post about this though (when we have a blog). * Cache: yeah about 90/10 for pricing. We're still trying to find the sweet spot for tuning eviction. Running LRU with no guarantee/storage at the moment, could probably be less aggressive with retention, but that also has privacy surface area implications. Ongoing conversation. * Quantisation: my brother in christ, everyone runs quantised. :) We're initially targetting FP8 on most models, but have had great results with MXFP4 though. If we can pack more concurrency onto nodes without losing quality, we'll reflect that in pricing. Or we'll offer as a separate model for cheaper and give users the choice. Edit: I see you were asking specifically about speed, which MXFP4 doesn't improve, but maybe if there's demand we'll run other qaunts for speed increase, especially on the larger models. * Engine: vLLM gang all the way! For now at least, as it's what we have most experience with, and we find it the most flexible. We've been experimenting with SGLang though, and there's definitely some interesting optimisations we could do with it. Hope this answers your questions, at least the ones I could! The irony of that hasn't escaped me! [1]: https://violentdelights.ai/privacy

▲

Xunjin 6 hours ago | parent | prev | next [-]

>legally speaking, in our jurisdiction, at least according to Claude -- we're talking to a real lawyer next week

That's going to be fun lol

	▲	TofuLover 5 hours ago \| parent [-]
		We look forward to providing many headaches to our lawyers going forward.

▲

tiahura 4 hours ago | parent | prev [-]

Let us know what your insurance is like.