Supported environments
- Azure
- Google Cloud
How the targets compare
Each row compares a capability of SageMaker (Inference) with its adaptation on each target. A dash means this profile does not state the capability for that target.Cloud Adapter
On Azure and Google Cloud
Your inference container
How inference runs
Your application sends a synchronousInvokeEndpoint request through its SageMaker Runtime client. The service adapter forwards the payload to your inference container in the customer’s Kubernetes cluster on Azure or Google Cloud, then returns the container’s response. The model and its input format stay yours; this mapping does not substitute Vertex AI, Azure Machine Learning or a different model.
Each configured endpoint addresses one model container. Requests naming a different endpoint, a production variant or a multi-model target do not silently run against the default model. Use one model and one endpoint per compiled module for this subset. Configure the client’s endpoint name to match the deployed endpoint; custom AWS endpoint aliases are not preserved automatically.
Prepare the model and serving capacity
Tensor9 maps the origin stack’s model, endpoint configuration and endpoint resources to a Kubernetes Deployment and Service using the model’s container image. The endpoint is the served resource; its model and endpoint configuration accompany that provisioning. They do not provide separate model-management or endpoint-management APIs. A model or configuration without an endpoint does not create an inference server. Keep the three resources in one module with one declared model image. Make that image pullable from the customer’s environment and provide the model files it needs. The container must start its inference server itself. This path does not append SageMaker’sserve argument or copy the model’s environment-variable map automatically; package or configure the required startup behavior and environment explicitly.
Unlike SageMaker hosting, this path does not unpack ModelDataUrl into /opt/ml/model before startup. The artifact URL is passed to the container; the container must fetch it with suitable credentials, or you must supply the files another way. An image expecting preinstalled model files needs adjustment.
AWS instance types, initial instance counts and production-variant weights do not configure equivalent capacity here. Size CPU, memory and any accelerators for the customer’s cluster, and validate startup, readiness and inference latency with the actual model. AWS execution roles and endpoint KMS keys are not applied unchanged; configure target identity and storage encryption.
Inference-only boundaries
This adapter covers synchronous requests to a provisioned model. It does not cover asynchronous or streaming inference, batch transform, weighted variants, multi-model routing or runtime endpoint management. Changes to serving resources go through the origin stack rather than SageMaker management calls. Notebooks, training and hyperparameter tuning remain on AWS. The SageMaker AI (Training and Notebooks) entry describes that separate scope. Inference is part of SageMaker AI too; the two index entries distinguish the capabilities Tensor9 adapts, not two unrelated AWS products.AWS reference
AWS documents the inference container contract and the InvokeEndpoint API. Those describe AWS behavior; the operation table above defines this adapter’s narrower scope.Service level agreements
Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider’s own SLA. Each origin-to-target pair has its own terms or an explicit pending status. See the SLA tables, measurement rules, and scaling conditions.SageMaker to Your inference container
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Runtime calls authenticate, resolve the endpoint and variant, translate headers and stream or relay the body to tensor9::1.0.0::emu::aws/1.0.0/sagemaker::incluster. Model execution is separately measured; endpoint lookup, routing, payload forwarding, streaming backpressure and response/error conversion remain adapter work. Control-plane rows record desired endpoint state and reconcile it independently.How the latency targets were chosen
Endpoint invocation translation: 5 ms monthly p99.InvokeEndpoint. Endpoint lookup, header/body translation and response mapping.
Endpoint configuration mutation: 20 ms monthly p99. CreateEndpoint, CreateEndpointConfig, CreateModel, DeleteEndpoint, UpdateEndpoint. Durable desired-state admission plus reconciliation scheduling.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Invocation capacity scales by endpoint and replica subject to bounded in-flight bytes. Qualification fixes payload size, response size, endpoint/variant distribution, streaming concurrency and connection reuse. Endpoint mutations serialize per endpoint while independent endpoints progress concurrently. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
The selected endpoint, variant, content types and custom attributes are preserved. A successful control mutation records complete desired state; a successful invocation returns exactly the target result or a typed failure. The adapter never routes to a different model merely to satisfy latency.Example and diagnosis
InvokeEndpoint with a 64 KiB request resolves one endpoint and relays the response. Target inference time is an explicit external span; local route lookup and both body transfers remain covered. UpdateEndpoint is measured as durable acceptance, with propagation readiness reported separately. Usetensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
Install and run
The documentation and SLAs are public. Downloading and running the Cloud Adapter binary requires an entitled customer account. SetT9_API_KEY as described in Install and Authenticate, then list the adapters your account may use with this origin: