A custom model is any model you supply rather than one drawn from a fixed catalogue: an open-source checkpoint you fine-tuned, a container that wraps your own preprocessing and inference code, or a model you built in-house. Deploying your own model is how an adult platform gets behaviour that general-purpose endpoints will not provide, and how it keeps its content policy under its own control.
Open-source and custom containers
Two deployment shapes cover most needs:
- Open-source checkpoints — you supply weights and a runtime configuration. Good for standard architectures and for models the platform can serve from a known runtime.
- Custom containers — you supply a container image that starts a server and answers inference requests. Use this when you need custom preprocessing, a non-standard runtime, or glue logic bundled with the model.
A custom container should read its configuration from the environment, expose a health endpoint, and shut down cleanly on signal. Keep the image immutable and pinned by digest so a redeploy does not silently change the code behind a version.
Versioning and routing
Treat every model as a versioned artifact. A version is a tuple of weights and runtime configuration; changing either produces a new version, never an in-place mutation of a live endpoint. This lets you:
- Roll forward with a weighted canary and compare output or latency before full promotion.
- Roll back instantly by routing back to the previous version.
- Pin a tenant to a specific version when reproducibility matters.
Route by model name and version, and keep old versions addressable until you are certain they are unused.
Capacity
Model size drives memory and concurrency. Plan capacity from the largest model that must be resident at once, not the average, and account for warm-up: a cold container pays a load cost before it can serve. Practical controls:
- Concurrency limits per endpoint to prevent a traffic spike from thrashing memory.
- Warm pools so latency-sensitive endpoints are not cold on the first request.
- Queueing with timeouts so overload degrades predictably instead of failing randomly.
- Separate pools for interactive and batch work, so bulk jobs cannot starve live traffic.
Scale on a signal that reflects load — queue depth or concurrent requests, not raw request count — and set a ceiling so autoscaling cannot run away.
Usage-based metering
Inference is commonly metered by usage rather than by a flat reservation, because consumption is bursty and model-dependent. Metering typically tracks compute time, tokens, or requests per model and version, so a customer can see which models drive consumption and attribute it to a workload. Keep metering per tenant and per endpoint so chargeback and capacity planning use the same numbers. This documentation describes the model; it does not cover account or billing mechanics.
Customer-controlled policy
The platform runs the model; the customer defines the policy. Concretely, that means:
- No platform-wide refusal of lawful adult prompts for custom models.
- Input and output filtering, if any, is configured by the customer, not imposed.
- Safety behaviour lives in the model, the prompt, or a customer-supplied guardrail container — all of which the customer controls and can audit.
This is a responsibility boundary, not an abdication: age, consent, likeness, rights, and applicable law remain the customer’s obligations. The platform guarantees only that it will not override lawful use with an undisclosed blanket filter.
Where AdultInfra fits
AdultInfra deploys open-source and custom-container models with private weights, versioned routing, and metered usage, so adult platforms can run the behaviour they need without fighting a default policy. To move a workload off a refusing provider, start with adult AI inference and bring one model.