Open-weights models have crossed a credibility threshold. Llama, Mistral, DeepSeek, and their successors are now serious production candidates for regulated European firms, not just research curiosities. The pitch is compelling: you control the weights, you control the runtime, you own the data pipeline. But the moment you deploy one on shared GPU infrastructure, a set of risks opens up that most vendors have no commercial incentive to explain clearly. This post does that job instead.

The question is not whether open-weights model deployment is inherently dangerous. It is not. The question is what the threat model looks like on shared hardware, and when that threat model demands something stronger.

What “open-weights” actually means

Open-weights means the numerical parameters of a trained model are publicly released. You can download them, run them, and fine-tune them on your own infrastructure. That is the meaningful definition for this discussion. A stricter “open-source AI” definition, as articulated by the Open Source Initiative, would also require release of training data and training code. Most current open-weights models do not meet that bar because the underlying datasets are proprietary.

The practical consequence is that you get full runtime autonomy without full transparency into how the model was built. That gap matters for supply chain risk, which we will come to shortly.

The hardware-level problem with shared GPU inference

When a CUDA context is destroyed after an inference pod finishes a request, the GPU DRAM pages it occupied are not zeroed before being returned to the allocator. This is a deliberate performance decision, not an oversight. The consequence is that the next CUDA context that receives those pages can read what was there before: model weights, intermediate activation tensors, KV-cache entries, raw prompt tokens.

On a shared inference cluster, that is not an abstract concern. Cloud AI platforms including AWS SageMaker multi-model endpoints, Azure Machine Learning managed inference, and GKE GPU node pools implement tenant separation at the Kubernetes layer while sharing GPU kernel drivers at the node level. A single NVKM instance services all models on a given node. An attacker who controls one model’s inference code can attempt NVKM exploitation against that shared kernel. Tenant isolation depends entirely on the correctness of the NVIDIA driver, which is a significant dependency to place your data-isolation guarantee on.

Beyond memory residue, research published as NVBleed (arXiv:2503.17847) demonstrated that an attacker can reside on a different GPU, or even in a separate VM instance, and still exploit inter-GPU communication channels to extract information from co-located workloads. The attack was validated against a public cloud provider. This is not a theoretical attack surface; it is a demonstrated one.

KV-cache integrity is a related and underappreciated vector. In multi-tenant serving environments where prefix caching is enabled, a co-located tenant can corrupt shared KV-cache prefix blocks via Rowhammer bit-flip techniques, causing other tenants’ model responses to silently deviate from expected behaviour. The adversary needs no software privileges beyond what a normal tenant has. Model weights, application code, and API-level inputs remain unaffected and undetected.

The most dangerous property of shared GPU infrastructure is not that it can be breached from outside. It is that legitimate tenants can become attack vectors against each other without either side knowing.

Timing side-channels compound this. Side-channel attacks on LLM inference backends can infer details about one tenant’s workload by measuring resource contention or scheduling latency from another tenant’s position. High-security environments may need to dedicate GPUs to a single tenant at a time, not as a luxury but as the only reliable mitigation.

The supply chain risk specific to open-weights models

Self-hosted LLM security has a second dimension that shared-cloud discussions often skip: the model file itself is an attack surface. In February 2024, security researchers found a model on Hugging Face that opened a reverse shell the moment it was loaded. Malicious pickle files on public model hubs are the clearest case of a supply chain compromise, mapped under LLM03:2025 in the OWASP Top 10 for LLM Applications.

Backdoors are subtler and harder to detect. Hubinger et al. at Anthropic (arXiv:2401.05566, 2024) trained a model that wrote secure code when the year was 2023 and inserted exploitable code when the year was 2024. The backdoor persisted through safety training. Separately, Qi et al. (2024) demonstrated that safety alignment can be undone by fine-tuning with as few as ten adversarially designed examples, at a cost of less than $0.20. The UK AI Security Institute confirmed that safety guardrails can be removed with a few dozen training examples in a matter of minutes.

The GPAI Guidelines from the European Commission (2025) create an unintentional blind spot here: only significant modification to a model triggers provider obligations for the modifier. But the most dangerous modifications, those that strip safety constraints, require negligible computational resources and fall below any reasonable “significant modification” threshold. The regulatory framework does not yet cover the threat it most needs to address.

When single-tenant deployment becomes non-negotiable

The GPU memory residue problem, the inter-GPU covert channel, and the KV-cache integrity attack all share a common root cause: resource sharing. The only complete mitigation is to stop sharing. For workloads that process personal data under GDPR, handle material non-public financial information, or operate in healthcare or defence contexts, the risk calculus tips firmly toward dedicated infrastructure.

Confidential computing offers a partial hardware-level answer. NVIDIA’s H100 (Hopper architecture) shipped confidential computing support in July 2023, with general availability in 2024. The Blackwell architecture, announced in March 2024, extends these protections to encrypting inter-GPU traffic for large distributed models. OpenAI’s May 2024 infrastructure post listed accelerator-level confidential computing as its first category of secure infrastructure. These capabilities are real and improving, but they are not universally available on shared multi-tenant inference platforms, and they do not address supply chain integrity.

For AI model data isolation in production, the practical checklist looks like this:

  • Verify model provenance before loading: cryptographic hash against a known-good source, not just a filename match.
  • Run inference on dedicated GPU capacity, not shared multi-tenant pools, for any workload touching sensitive data.
  • Disable prefix caching or enforce strict cache partitioning per tenant if multi-tenancy is unavoidable.
  • Treat the model file as a dependency under your software supply chain policy, with the same scrutiny you apply to third-party libraries.
  • Audit GPU driver versions and apply NVKM patches on the same cycle as OS-level CVEs.

Network reach and where inference actually runs

One operational reality that gets lost in the security conversation: GPU inference latency is dominated by where the model runs relative to where the request originates. On-premises open source LLM deployments solve the isolation problem but can reintroduce latency if the compute is far from your users or your data pipeline. We run 44 points of presence across Europe and the Middle East, with direct peering to AWS, Azure, GCP, Oracle, and Cloudflare at all sites, which means inference workloads placed on our infrastructure stay close to the data they process and the applications that consume them, without the round-trip penalties that come from routing sensitive prompts across the public internet to a distant shared endpoint.

The open-weights model is not the risk. The shared execution environment is. Knowing which is which is the prerequisite for building an AI inference architecture that a regulated firm can actually stand behind.