"A tad messy" really undersells it. You need a solid process to manage the (sticky, carcinogenic, smelly) liquid resin both as an input and waste product, along with having to dispose of (carcinogenic, smelly, flammable) cleaning solvent.
The problem isn't so much the process of a successful print as how you deal with a failed one. At that point you've got a vat full of resin with some solid parts stuck to the bottom, so you need to filter and clean the damn thing which means taking it out of whatever containment you've got. And that step you can't use the usual solvent for because it damages the sheet. But you'll have ample time to figure all this out because you'll get loads of failed prints as you figure out how slicing and supporting for resin works: it's different to FDM, some knowledge carries over but not that much.
Focusing on the 10-30 minute curing process ignores the part prep step: SLA is much more reliant on supports than FDM in general, so there will be either rough surfaces hopefully out of sight, or (if it's not a model that orients well) scraping/sanding/filling. And you want to do support separation and get that as clean as possible before curing, while the resin is still a bit soft, but that means it's only partially cured and you need to be PPE'd up.
When I'm doing anything with my resin printer I don't even go into the room without a breathing filter, don't touch anything without gloves. It really is a very different experience to FDM.
Not the GP but the experience of being on the wrong end of a vociferous false positive is not great, and there are enough readers to make that not an unlikely outcome.
I'll probably get a kiosk panel next time. But this time, yeah, I've just not configured the network. All content comes from the console. Which is a different bundle of problems and no better in a lot of ways, but it's more of a known quantity.
Positive note from me: one thing I've had good experience with is following the path from a project that does something similar to what I want; extract a tech-neutral prose spec from the source; convert that prose spec into a formal spec; use that spec to generate valid traces, a language-specific interface layer, and conformance checks to test whether an implementation of the interface generates good traces. Once you've got that, implementing the system is a matter of colouring the interface in by numbers, which is really easy for a model.
The bonus here is that you can cut in at the prose spec stage and change it to whatever you need, as well as being able to target it at specific technical choices at the last couple of steps.
Where I've seen this work really well is with privilege escalation management, where you do actually want to be careful about the states the system can get into, and the APIs available for managing privileges in a system might be super specific to that system. But I can imagine the workflow being quite a useful one any time you've got anything state-machine flavoured.
A trace is basically a sequence of states. If you're using TLA+ or something built on it (quint in my case) then you can get it to dump out valid sequences that you can then compare to output produced by your implementation. You have to explicitly instrument where the implementation performs the updates, so it's not free and there's potential for error there, but it clearly signals "this bit of code is responsible for that bit of the model".
The other choice is AWS Bedrock, if it happens to have the model you're interested in. They do have GLM-5.3. They don't have DS-4 or 4.1 yet, and updates are intermittent at best, but they're already on the trusted provider list for anywhere large enough to be interesting.
Depends on the parameters of "acceptable", but they do offer inference in non-US zones. If the company is already on AWS for meaningful workloads with sensitive data (which is not uncommon), they've already been through the hard part.
That being said it's not quite as simple as would be ideal, you do need to check whether there's an additional EULA on your specific model choice.
For data residency reasons? You can meet data residency requirements on AWS, I'm pretty sure. Mind sharing which condition blocked it in your experience? Mostly curious because in the US there isn't that much interest in on-prem deployments because it's easier to scale up and upgrade using the cloud and it's easier to use AWS because you don't have to run a new compliance process for each part of the stack.
You could until the Trump admin decided to (attempt to) overrule the deal that was in place (the DPF).
The perceived lack of independence of the FTC is a major driver behind the exodus on this side of the Atlantic and it isn't just the smaller players that are moving. Airbus for instance.
Now the datacenters supposedly operating under at-arms-length management are no longer sufficient for compliance.
There are calls to repeal the whole thing with respect to the US.
I see. So there's a risk that the EC or CJEU make a determination against the existing system because of the non-independence ruling of the FTC. So the movement away to regional providers is because no one wants to be caught surprised if the EC/CJEU make such a determination. Interesting. It must be early stage because from what I can see the most spend is still on the big two, but this does bode well for Mistral and EU-based open model hosts. Lots of room in the 20%.
Yeah, about that... My kid works for a very small company. Chatted the other day about in-house inference vs ZDR providers and all. His team is trying to get access to GLM on AWS Bedrock. It is a second week they are trying to schedule a simple meeting to discuss what they need. Random silence, and back and forth from a new person each time. 2 WEEKS to just schedule a meeting... And as far as I know, no luck so far.
That's pushing the timelines a bit. I had more than one early Ubuntu completely hose itself on dist-upgrade pre 16.04, despite it being based on Debian for which such things have never been a problem for me. Until 22.04->24.04 my rule was always to reinstall as a result.
I can also respect the mastery that results in every keg of Heineken being functionally identical. I don't have to like the stuff. Or, heaven forbid, drink it.
Anyone who's brewed beer can understand two things at once.
1) The brewmasters of mass-market lagers are legitimate masters of their craft, because that style leaves absolutely no room for error and nowhere to hide mistakes. You can screw up an IPA and cover it in hops, at least to a point. You can screw up a porter or stout and cover it in malt. You have to nail a lager.
2) The product itself is still usually insipid, flavorless, and not worth drinking.
Arguably the customer gains the option of not paying, which has some value. Whether that option value is close to the extra they pay through the subscription is left as an exercise for the reader.
The problem isn't so much the process of a successful print as how you deal with a failed one. At that point you've got a vat full of resin with some solid parts stuck to the bottom, so you need to filter and clean the damn thing which means taking it out of whatever containment you've got. And that step you can't use the usual solvent for because it damages the sheet. But you'll have ample time to figure all this out because you'll get loads of failed prints as you figure out how slicing and supporting for resin works: it's different to FDM, some knowledge carries over but not that much.
Focusing on the 10-30 minute curing process ignores the part prep step: SLA is much more reliant on supports than FDM in general, so there will be either rough surfaces hopefully out of sight, or (if it's not a model that orients well) scraping/sanding/filling. And you want to do support separation and get that as clean as possible before curing, while the resin is still a bit soft, but that means it's only partially cured and you need to be PPE'd up.
When I'm doing anything with my resin printer I don't even go into the room without a breathing filter, don't touch anything without gloves. It really is a very different experience to FDM.
reply