Self-Hosted LLM Customer Support for Hosting Providers

For hosting providers handling sensitive infrastructure data, sending every support ticket through a third-party LLM API is not always acceptable. Self-hosted LLM customer support keeps inference on hardware you control, satisfying data sovereignty obligations and giving you full authority over the model. This guide covers the models DeskNexo supports, the hardware required to run them, and how the economics compare to managed cloud APIs.

Why Hosting Providers Choose Self-Hosted LLMs

Hosting providers occupy a unique position: your customers trust you with their virtual machines, their billing records, and their network traffic. When a support ticket mentions an IP address, a root password reset, or a Proxmox node identifier, that is infrastructure data that many enterprises and public-sector clients contractually require to stay within a defined jurisdiction. Routing it through a consumer LLM API headquartered in another continent can breach those terms.

Self-hosting the language model solves three problems at once. It guarantees data sovereignty because no ticket content ever leaves your network. It eliminates per-token costs, which is decisive when you process thousands of tickets per month. And it removes the risk of an upstream provider silently changing model behaviour, rate limits, or retention policies. For providers targeting regulated industries, on-premise AI support is often the only path to a signed contract.

Supported Models and the OpenAI-Compatible API

DeskNexo Enterprise supports any model that exposes an OpenAI-compatible inference endpoint. In practice this means you point DeskNexo at a local URL and it behaves exactly as if it were calling a commercial API. The most commonly deployed models are:

• Llama 3 (8B and 70B) - Meta's open-weight model, strong at instruction following and ticket triage. The 8B variant runs on a single consumer GPU and is the most popular entry point.
• Mistral and Mixtral (7B, 8x7B, 8x22B) - efficient reasoning with a permissive Apache licence. Mixtral 8x7B is a frequent choice for providers who need GPT-3.5-class quality without the per-token bill.
• Qwen 2.5, Gemma 2, Phi-3, and DeepSeek - all expose OpenAI-compatible endpoints through serving runtimes such as vLLM, Ollama, or text-generation-inference.
• Fine-tuned derivatives - many providers fine-tune Llama 3 on their own resolved ticket history to sharpen domain vocabulary (WHMCS module names, Proxmox error codes, VirtFusion statuses).

Because DeskNexo uses the OpenAI chat completions schema, switching models is a configuration change, not a code change. You can run a smaller model for the initial ticket classification pass and a larger model for the diagnosis and response-drafting pass, keeping GPU cost proportional to the difficulty of each ticket.

Hardware Requirements

The resource footprint depends almost entirely on the model you select. The figures below assume quantized inference (4-bit or 8-bit) through vLLM, which is the realistic deployment for a production support workload.

CPU-only inference is technically possible with small models through Ollama, but latencies of 5 - 15 seconds per response make it impractical for live customer-facing replies. For a hosting provider that already operates a GPU-equipped node for other workloads, colocating the LLM is effectively free. For everyone else, a dedicated A10 (24 GB) at roughly 0.75 per hour on the spot market comfortably runs Llama 3 8B for an entire support team.

Self-Hosted vs Cloud LLM: Cost Analysis

The break-even point where self-hosting beats per-token API pricing arrives sooner than most providers expect. The table below compares a Business-tier workload of 1,000 tickets per month against three inference strategies.

At 1,000 tickets per month, a self-hosted 8B model on a single GPU cuts inference cost by roughly 60 percent compared to a managed API while removing data-residency concerns entirely. The gap widens as ticket volume grows: at 5,000 tickets per month the managed API bill can exceed 1,200, whereas the dedicated GPU cost stays flat. The trade-off is operational - you now own GPU monitoring, model updates, and failover.

Setup Process

1. Deploy an Inference Runtime

Install vLLM or Ollama on a GPU node inside your infrastructure. vLLM is recommended for production because it supports continuous batching, which keeps response latency stable even when multiple agents handle tickets concurrently. Expose the runtime on an internal address such as http://llm.internal:8000/v1.

2. Configure DeskNexo

In the DeskNexo Enterprise settings, set the LLM provider to "OpenAI-compatible" and enter your internal endpoint plus model name. DeskNexo validates the connection, runs a short benchmark to confirm latency is within acceptable bounds, and then routes all inference through your hardware. No ticket content is transmitted to any external service.

3. Validate With Dual-LLM Verification

DeskNexo runs a secondary verification pass before executing any VM action. With a self-hosted deployment you can use the same local model for both passes or run a smaller guardrail model alongside the primary one. Either way, the verification logic, snapshot creation, and human-approval gating for destructive operations all work identically to the managed deployment.

When to Choose Self-Hosted vs Managed

Self-hosting is the right call when you process more than roughly 500 tickets per month, when your customers or regulators mandate on-premise processing, or when you already own GPU capacity. The Enterprise plan is built for exactly this scenario, including the self-hosted LLM option alongside higher ticket volume and full audit capabilities. See our GDPR compliant AI support guide for how self-hosting interacts with data-protection obligations, and the AI for hosting providers overview for the broader automation architecture.

For smaller teams, the managed cloud model on the Essential or Business plan remains simpler and cheaper. You can read about the trade-offs in our guide to reducing hosting support costs and migrate to self-hosted later without changing how DeskNexo is configured - the agent logic, WHMCS integration, and Proxmox and VirtFusion connectors are identical either way.