On-Prem AI Deployment: Why Self-Hostable Frontier AI Matters for the Shop Floor

by | Blog

Two frontier-class AI models shipped within 72 hours of each other. One is downloadable today under an MIT license. The other releases its weights within the week. For anyone weighing on-prem AI deployment, that timing matters more than any benchmark chart.

If you’re piloting an AI copilot on maintenance logs and work orders, one question outranks model quality: where does the data go? Until now, frontier-grade capability usually meant sending that data to someone else’s API and accepting their data-handling terms. That tradeoff just got smaller.

Below: what shipped, what it changes for a shop-floor pilot, and what self-hosting leaves unsolved.

What Actually Shipped

DeepSeek-V4-Flash is a mixture-of-experts (MoE) model with 284 billion total parameters, of which 13 billion are active for any given token. It ships under the MIT license, and the weights are available to download now.

Qwen 3.8-Max is larger. It has 2.4 trillion total parameters with 95 billion active. Its API is live today, and the weights are due within the week.

Open weights also change how you evaluate. You can test a model against your own maintenance records inside your own environment, without routing a sample of them through a hosted trial.

The MoE design matters because only a fraction of the model runs for each token, which keeps compute per answer well below what the total parameter count suggests. All the weights still have to sit in memory, so plan on real GPU infrastructure.

We’re reporting specs here. Thinaer works with any cloud and any model, so which one fits your pilot is a decision for your IT, security, and compliance teams.

Who Controls the Infrastructure Matters More Than the Benchmarks

Benchmark scores will keep shifting. The model that leads this month trails next month, and your pilot’s results depend more on the quality of your data than on a few leaderboard points. What changed this week is who gets to run frontier capability, and where.

An open-weight model hands you the trained model itself. You download it, load it onto servers you own, and run it inside your network. No request goes out to a vendor, and no vendor sets your retention policy. That is the core of on-prem AI deployment, and with these releases self-hosting is now a viable frontier-tier option.

It is also an infrastructure commitment. Someone has to buy the GPUs, operate them, and patch the stack. If your IT group already runs GPU workloads, this is familiar territory, and it is a decision your own team can make and revisit.

Can AI Be Deployed On-Premise?

Yes. An open-weight model runs on GPUs inside your own facility or data center, so prompts, documents, and outputs stay on your network. You own the hardware, the access controls, and the logs.

What Is an On-Prem AI Model?

It is a model whose weights run on hardware your organization controls instead of behind a vendor’s API. The model does the same work. Where it runs, and who can see the traffic, is what changes.

Why On-Prem AI Deployment Fits a Shop-Floor Pilot

A common first pilot is a copilot that reads machine logs and work orders, then drafts maintenance tickets for a planner to review.

Run that through a cloud API and every log entry travels with the request. That includes machine names, failure descriptions, and supplier part numbers. Each one looks harmless alone. Together they describe what you build, where your equipment is failing, and who you buy from.

Cloud APIs are convenient, and for low-sensitivity workloads that convenience can win. The math changes when the inputs describe how your equipment fails and who supplies it. A plant can also split the difference, keeping sensitive workloads on its own servers and sending low-sensitivity ones to a hosted API.

Run the same workflow on a self-hosted model and nothing changes for the planner. The copilot reads the same logs and drafts the same tickets. The difference shows up in the network diagram: the data never leaves infrastructure you control.

Same copilot. Same workflow. Different data path.

Cloud API

Request travels to a vendor's servers

  • Machine names leave the network
  • Failure descriptions leave the network
  • Supplier part numbers leave the network
  • Retention follows the vendor's terms

Self-hosted open-weight model

Request stays on infrastructure you control

  • Machine names stay on your network
  • Failure descriptions stay on your network
  • Supplier part numbers stay on your network
  • Retention follows your own policy

Self-hosting covers the model layer. The data still has to be structured and governed before it reaches any model.

Before a pilot starts, put three questions to your vendor and your own security team: which fields leave the network, who sets retention, and what happens when those terms change. A self-hosted model answers all three with your own policy.

Vendor retention terms and privacy toggles stop being your problem, because no vendor receives the data. We broke down a recent case where an AI coding tool uploaded gigabytes of a developer’s files when the task needed kilobytes, and a privacy setting did not stop it.

Self-Hosting Solves One Layer of the Problem

A copilot reading maintenance logs only drafts good tickets if the logs are complete and tie each entry to the right machine, place, and time. In many plants that information lives in handwritten notes, spreadsheets, and tribal knowledge. A self-hosted model reading messy records produces wrong tickets on a server you own.

We don’t build models. We capture structured, AI-ready data from physical environments, so any model, hosted anywhere, has ground truth to work from. The data stays inside the customer’s security boundary, under the customer’s ownership and access controls. The same data that powers Sonar’s live map and alerts feeds whichever model the customer runs, so the planner and the copilot work from one record. Ground Truth for AI explains why live telemetry is the missing piece.

What Is an Air Gap in AI?

An air gap isolates a system from unsecured networks, including the internet. In cybersecurity, an air-gapped system has no connection to the outside by design. In AI, an air-gapped deployment means the model runs with no outbound path, so prompts and data have nowhere to go.

Air-gapped AI deployment diagram showing a secured facility isolated from the cloud
For defense and classified customers, self-hosting an open-weight model is necessary but not sufficient. It sits inside a larger governance stack: on-premises or air-gapped infrastructure, GovCloud where required, and the approvals those programs demand. Where a model comes from and how it was sourced is a separate review from where its weights run, and defense programs apply their own requirements to both.

Thinaer is DISA approved and supports on-premises, air-gapped, and GovCloud deployment. Your Data, Your LLM walks through each option, and Operational Data in Classified Environments covers the data side.

The Models Are Here. The Data Is the Open Question.

The models are here, and open-weight frontier models are now available or about to be. Self-hosting is a viable choice for a shop-floor pilot, and it keeps your maintenance data on infrastructure you control.

The part still worth getting right is the data. Structured, governed operational data decides whether a copilot helps your planners, wherever the model runs. See how Sonar gives you a live picture of your operations from day one, and how the same AI-ready data feeds any model you choose.