Private LLM hosting for hospitality and travel
A dedicated DGX Spark for reading guest records, booking data, and loyalty history with a language model that never phones home. The instance is yours alone, in EU-Central, at $0.79/hour for a single node or $1.79/hour for a linked 256 GB cluster.
What hotels and travel operators put in front of an LLM
A hotel group, a booking platform, or a tour operator adopting an LLM is usually after one of a few things: summarizing guest reviews and complaint tickets, drafting responses to booking inquiries, or reconciling loyalty program activity across properties. Each of those touches personal data that guests handed over expecting it to stay inside the reservation system, not get routed through a third-party AI vendor's servers.
A guest record is name, contact details, and often passport or ID number for cross-border bookings, plus stay history and preferences. Booking data adds payment-adjacent details: not the card number itself, ideally, since that should stay inside a PCI-scoped payment processor, but the booking reference, rate paid, and cancellation history that sits next to it in most property management systems. Pasting a guest folio into a public chatbot to draft a response to a complaint means that guest's stay history, and whatever card-adjacent metadata is attached to the record, leaves your system and enters a vendor's, on terms you didn't negotiate.
Loyalty program data is its own category. A member's tier, points balance, and redemption history reveal spend patterns and travel frequency that competitors would pay for, and members generally have no idea a support ticket about their reservation might get processed by a model outside the property's own systems.
What dedicated hardware changes
A DGX Spark from GPUwerk is single-tenant: no other customer's workload runs on the machine while it's yours, and the container and workspace are removed from the node before it's offered to anyone else, as described in our Privacy Policy, section 12. You choose the model, open-weight or a commercial model you self-host under its own license, and the guest records, booking data, and loyalty history stay on that instance. We don't access, read, copy, index, or analyse what runs on it.
128 GB of unified memory on a single Spark is enough to run a 70B-class model for the tasks a property or a booking platform needs most: drafting a reply to a guest complaint that references their actual stay history, summarizing a batch of reviews by property, or answering internal questions about a loyalty tier's benefits. A multi-property group running inference across many hotels at once, or a booking platform serving live traffic, would want the linked 256 GB cluster for the added throughput.
Where GDPR applies
Guest and loyalty records are personal data under the GDPR whenever a guest is identifiable, which is nearly always the case in hospitality. Our Data Processing Agreement under Article 28 applies to how we handle the infrastructure it runs on; the DPA states plainly that GPUwerk hosts the machine but does not access the content of the instance, and that the controller decides what runs on it. We are not your lawyer and this isn't legal advice: whether you can lawfully use an LLM on guest data at all, what consent or legitimate-interest basis applies, and how long you can retain loyalty history are questions for your own data protection officer or counsel. What we can say concretely is where the compute sits and who can reach it.
Practical starting points
Most properties don't start by handing an LLM the full guest database. A hotel group we'd point toward this setup might start with review summarization: pulling recurring themes out of a quarter's worth of guest reviews per property, without any review text or guest identifier leaving the property's own infrastructure. A 70B-class model on a single Spark handles that well, and the output is easy to spot-check against the source reviews.
A second common starting point is complaint response drafting, having the model produce a first draft of a reply to a service complaint using the guest's actual stay history, which a staff member then edits before sending. A third is loyalty program analysis internally, flagging members approaching a tier threshold or a redemption pattern worth a manual review. None of these need a flawless model; they need one fast enough for a first pass and private enough to run on real guest and payment-adjacent data without exposing it to a vendor you don't control.
Getting started
Deploy a Spark directly from the console, or if you'd rather scope the workload first, an AI Opportunity Session covers your existing systems (property management system, booking engine, loyalty platform) and what a first pilot should look like before you commit to a rollout.
Back up before you terminate. Terminating deletes the workspace and GPUwerk's recovery copy of it. Export what you need before you stop paying for it.
Related pages
Run your hospitality workload on hardware that's only yours.
Single-node Spark from $0.79/hour, no shared GPUs, no egress fees.
Deploy a Spark Book an engagement