Hosting open-weight models for clinical documentation, coding and patient messaging tools where prompts carry PHI: keeping inference inside the HIPAA environment, access logging, isolating GPU nodes and what a risk analysis must cover before clinical teams rely on it.
Running models in-house for banks and insurers so client data never reaches a hosted API: DORA ICT risk and exit expectations, model inventory for model risk management, capacity for peak periods and evidence auditors ask for.
Giving agencies a model endpoint inside their own authorization boundary: FedRAMP and NIST SP 800-53 control ownership when models run on agency hardware, procurement of GPUs, and sharing one inference service across departments.
For software vendors adding LLM features who would rather not add a model provider to their subprocessor list: serving customers from their own GPUs, per-tenant rate limits, SOC 2 scope and the uptime they can promise.
Running models next to plant systems for maintenance assistants and quality reports: on-premises or edge servers, OT network segmentation, models that work with no cloud connection and protecting design data and process IP.
Sharing campus GPUs as one model service for teaching, research and administration: student data rules such as FERPA, fair-share quotas between departments, keeping research data off commercial APIs and funding the hardware.
Serving models where nothing can be downloaded at runtime: transferring and verifying model weights and container images across the gap, offline documentation and chat templates, and patching an engine that releases every few weeks.
Keeping prompts and outputs under EU control by running open-weight models in EU facilities instead of US-headquartered APIs: GDPR transfer rules, choosing models whose licences allow it, and hosting options from on premises to EU providers.
For defense contractors who want AI on controlled unclassified information: why a model endpoint inside the CUI enclave keeps prompts in scope of their own controls, the NIST SP 800-171 requirements the inference servers must meet and the current CMMC phase-in status.
What the EU AI Act asks of an organization that downloads open-weight models and serves them to staff or customers: when it is a deployer or becomes a provider, the open-source exemptions for general-purpose models and their limits, AI literacy and log retention.
For SaaS teams whose SOC 2 report will cover an in-house model service: capacity monitoring and forecasting for GPUs under the availability criteria, backup and recovery of model artifacts and configuration, access control on endpoints and evidence to collect.
For engineering teams that cannot send source code to a hosted coding assistant: running Tabby or an editor plugin against models on vLLM or Ollama, GPU sizing for completion latency, SSO and LDAP, and licence limits on the free editions.
When GPUs are not available or not allowed: running quantized GGUF models with llama.cpp or Ollama on CPUs at branch offices, ships, plants or laptops, what model sizes and response times are realistic, and managing many small nodes.
Requirements to agree before building an internal model service: models and context lengths, concurrency and latency targets, GPU and accelerator support, OpenAI API compatibility, authentication in front of the engine, metrics, multi-node networking and upgrade cadence.
Questions for partners offering to build and run an in-house model platform: how they size GPUs, secure endpoints the engine leaves open, handle model updates and engine releases, monitor capacity and hand over operations, with answers that should worry you.
Breaking down the cost of serving models yourself against per-token hosted APIs: GPU purchase or rental, power and space, engineering and on-call time, utilization as the main driver, and the request volume at which self-hosting starts to pay.