Hand off Polyaxon model artifacts to KServe

Train and evaluate a model with Polyaxon, then deploy an approved artifact through an existing KServe installation. KFServing was renamed KServe; older links may still use the historical KFServing name.

This workflow separates training from serving: Polyaxon records the training run and its artifacts, while KServe manages the InferenceService. It does not install KServe automatically or turn a Polyaxon service into a KServe deployment.

Prepare the serving environment

Before handing off a model, your platform team should have:

• A KServe installation and compatible serving runtime for the model format.
• A target namespace with its routing, authentication, and resource policies configured.
• A durable model location that the KServe workload can read using its own storage identity.
• A deployment identity permitted to manage the intended InferenceService resources in that namespace.

Polyaxon artifact access is not automatically inherited by KServe. Configure storage access separately, and use an immutable model location so retries and rollbacks refer to the same artifact. Keep the originating Polyaxon run and model version in your deployment record; see model registry versions.

Define the model handoff

For a TensorFlow SavedModel, the following illustrates the KServe resource shape. Replace the bucket and versioned path with your exported model location and configure its storage permissions. Select a compatible runtime and serving mode for your installed KServe version before applying the manifest.

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: polyaxon-model
spec:
  predictor:
    model:
      modelFormat:
        name: tensorflow
      storageUri: s3://your-model-bucket/approved-model/release-001/

The model directory must match the serving runtime's expected layout. Follow KServe's TensorFlow example and serving-runtime configuration rather than copying an old KFServing manifest unchanged.

Submit the manifest through your approved Kubernetes deployment workflow. A Polyaxon deployment job can invoke that workflow with a narrowly scoped identity, but the job's completion and the inference service's readiness are separate states. Do not give a training job cluster-admin access solely to enable model deployment.

Verify the deployed revision

Check that the intended InferenceService becomes ready, that its runtime loaded the expected artifact, and that a known prediction request succeeds through your configured ingress. Record the deployed artifact location and returned service address alongside the training run.

If readiness fails, inspect KServe's conditions, events, storage initialization, and model-server logs. A Polyaxon run marked successful only establishes that its own command finished; it is not evidence that the external serving controller completed a rollout.

Keep deployment ownership explicit

Choose one owner for updates and rollback, such as your deployment pipeline or GitOps controller. Avoid having multiple controllers overwrite the same resource. Stopping the submitting Polyaxon job is not a cleanup strategy for a separately created InferenceService.

Retain the previous manifest and model location, configure scaling and readiness according to your KServe installation, and enforce endpoint authentication independently of Polyaxon UI access. If you only need to run a serving container directly in Polyaxon, the TensorFlow Serving guide is a simpler deployment boundary.