On-Prem Ticket AI: GPU Hardware You Need and What It Really Costs
What GPU VRAM you need for on-prem ticket AI, how hardware and API costs compare, and what Open Ticket AI runs locally — classification, summaries, Full On-Prem.
On-Prem Ticket AI: GPU Hardware You Need and What It Really Costs
📖 8 minute read • Updated July 28, 2026
IT and service-desk leaders keep asking the same three questions: What does the software actually do? Which GPU do we need? And is buying hardware cheaper than paying an AI API every month?
This guide answers all three for on-prem ticket AI — models that classify and summarize tickets next to your helpdesk, on infrastructure you control. It is written for buyers and admins evaluating Open Ticket AI Full On-Prem, and for anyone sizing a self-hosted stack for OTOBO, Znuny, or Zammad.
Trying the product first? Start with the Free Cloud Trial to evaluate routing, priority, multi-field classification, and summaries online — then move to Full On-Prem when tickets must stay inside your network.
Why on-prem ticket AI is a hardware decision
Cloud AI APIs are convenient until compliance, works councils, or security review ask where ticket bodies go. Ticket text often contains personal data, customer names, passwords pasted by accident, and internal incident detail. Once that content leaves your network, you inherit retention, subprocessors, and transfer questions that many DACH organizations would rather not open.
On-prem flips the model: the GPU becomes the unit of capacity, not tokens. You pay for the box once (or lease it), run inference locally, and keep ticket content where the helpdesk already lives. That is the core of Full On-Prem: train and run on your GPU, fully isolated — nothing leaves, not even setup data.
The trade-off is real. You need a card with enough video memory (VRAM), power, and cooling — and you need a clear picture of what the software will do on that card.
What Open Ticket AI does on that GPU
Skip the feature brochure. For production buyers, the shipped jobs that matter today are:
| Capability | What it does in the helpdesk | Status |
|---|---|---|
| Attribute classification | Sets routing target (queue / group), priority, and other single-select fields | Available |
| Ticket summary | Writes a concise summary agents can read without opening the full thread | Available |
| Chatbot | Customer-facing answers from your knowledge | Coming soon |
| Agent reply drafts | Suggested responses for agents | Coming soon |
Classification is tuned to how your helpdesk is organized — team names, priorities, categories, and field structure — not a generic chatbot prompt. Runtime connectors for systems such as Zammad, OTOBO, and Znuny read new tickets locally and write results back. No ticket export required for day-to-day inference.
Autonomous “resolve and close every ticket” is not the product. Humans stay in control; AI fills structured fields and summaries so agents start each ticket further ahead.
How much GPU do you actually need?
VRAM is the constraint that matters. Model weights, context, and concurrency all compete for the same memory pool. Open Ticket AI Full On-Prem requires a GPU with at least 24 GB of VRAM so training and inference can stay fully on your infrastructure (product deployment guidance).
Use this ladder as a practical starting point — not a purchase order:
| Tier | Typical VRAM | Example class of card | Fits when… |
|---|---|---|---|
| Entry production | 24 GB | NVIDIA RTX PRO 4000 Blackwell (or comparable 24 GB workstation/server GPU) | Classification + summaries for a single helpdesk; mainstream local models in the ~24–35B class |
| Headroom | 48 GB | NVIDIA RTX PRO 5000 Blackwell (or comparable) | Larger models, more concurrent jobs, or room to add chatbot / reply-draft workloads later |
| Scale-out | 2× / 4× 48 GB | Multiple professional GPUs (separate cards, not one magic pool) | Higher ticket volume, redundancy, or isolated environments |
A few sizing rules that save expensive mistakes:
- Start at 24 GB if you are unsure. That is the published Full On-Prem floor and the sweet spot many teams already use for local helpdesk LLMs (see our Ollama model guide for Zammad AI for adjacent VRAM intuition).
- Multiple GPUs do not automatically merge into one bigger VRAM pool. Plan for separate models, replicas, or nodes — not “96 GB as one card.”
- Headroom beats maximum model size. A model that barely fits will swap, stall, or time out under real ticket traffic.
- Workstation vs rack is an ops choice. A quiet tower with a 24 GB professional GPU can pilot a team without a data-center rebuild; rack servers with redundant power suit always-on production.
Official GPU specs change by generation; always confirm VRAM and driver support against the vendor datasheet before you order (for example the NVIDIA RTX PRO 4000 Blackwell datasheet).
The economical side: CapEx GPU vs OpEx APIs
Buyers often compare “one GPU invoice” to “a few cents per request” and stop there. The useful comparison is total cost of ownership over 24–36 months, plus risk.
What you pay on-prem
| Cost bucket | What it covers | How to think about it |
|---|---|---|
| GPU / server CapEx | Card + host (or a small dedicated node) | Amortize over 3 years; street prices for 24 GB professional GPUs are typically a few thousand euros in the EU, 48 GB cards more |
| Power & cooling | Continuous draw for the GPU node | Often tens of euros per month for a single workstation-class card — not zero, but predictable |
| Software | Open Ticket AI Full On-Prem | Priced On Request on the products page — sized to your helpdesk, not sold as a public €/agent sticker |
| Ops time | Updates, monitoring, backup of Studio/Runtime config | Usually lighter than running a second SaaS vendor review cycle |
Illustrative European street-price bands for cards alone (mid-2026 market checks; retailers vary): roughly €2k–€2.5k for many 24 GB professional Blackwell cards, and €5k–€6.5k for many 48 GB class cards. Treat those as hardware market ranges, not Open Ticket AI list prices. A complete node (chassis, CPU, RAM, PSU) costs more; many customers already have a suitable host and only add the GPU.
What you pay with hosted AI APIs
| Cost bucket | What it covers | Hidden friction |
|---|---|---|
| Tokens / requests | Every summary and classification call | Cost scales with ticket volume and prompt length; busy months surprise finance |
| Egress & retention | Data leaving your network | Legal review, DPA, subprocessors, deletion proofs |
| Quality tuning | Prompt engineering per field | Drift when models or prompts change; hard to audit |
API pricing can look cheap at low volume. At steady helpdesk traffic — hundreds or thousands of tickets per day, each with multi-turn history — monthly token spend often approaches or exceeds the amortized cost of a dedicated 24 GB node, without solving data residency.
A simple planning sketch (illustrative numbers only):
| Scenario | Rough monthly AI variable cost | Notes |
|---|---|---|
| Hosted API, 5k tickets/month, summary + classify | Rises with tokens; easy to land in hundreds of €/month | Spikes when tickets get long |
| On-prem 24 GB node, amortized CapEx | GPU CapEx ÷ 36 months + power | Flat once sized; no per-ticket surcharge |
| On-prem + Full On-Prem software | Hardware OpEx + software (On Request) | Predictable budget line for IT |
Use your ROI calculator for agent-time savings; use this article for the infrastructure half of the business case.
When API still wins
- Short proof-of-concepts where tickets are synthetic or heavily redacted
- Tiny volumes where a GPU would sit idle most of the day
- Teams that already approved a specific cloud AI vendor for all workloads
For production helpdesks under GDPR pressure, the GPU conversation is usually shorter than the API legal conversation.
Putting it together: a sensible buying path
- Evaluate with the Free Cloud Trial — confirm classification and summaries match how you work.
- Measure ticket volume and which fields you want automated (routing, priority, others).
- Size at ≥24 GB VRAM for Full On-Prem; step to 48 GB if you expect concurrency or larger models soon.
- Deploy Studio + Runtime next to your ticket system with Docker; keep ticket content on your network.
- Expand later into chatbot and reply drafts (coming soon) on the same hardware ladder when those capabilities ship.
If you already run local models for native helpdesk AI (for example Zammad 7 + Ollama), read the best Ollama model for Zammad AI guide for model choice — then treat Open Ticket AI as the controllable classification and summary layer with governance suited to production, not only a chat box inside the agent UI.
Conclusion
On-prem ticket AI is not “buy the biggest GPU and hope.” It is a clear stack: know the jobs (classify attributes, summarize tickets), meet the VRAM floor (24 GB for Full On-Prem), and compare three-year cost and risk against APIs that bill per token and process ticket text elsewhere.
Hardware ranges move; product capabilities evolve. What stays stable is the buyer question this article targets: Can we run useful ticket AI ourselves, on hardware we understand, without sending the helpdesk to the cloud?
Ready to talk through sizing for your helpdesk? Contact sales for Full On-Prem, or start online with the Free Cloud Trial.