مورد InferenceService

KServe turns a trained model into a production endpoint on Kubernetes. You describe what you want, and it handles serving, scaling, and routing for you. KServe is your serving layer. 🚀

Instead of writing raw Deployments and Services by hand, you create a single custom resource. The InferenceService is the one object that defines your whole serving setup.

You declare an InferenceService in a small YAML manifest, then apply it with kubectl. KServe reads that manifest and builds everything underneath.

The core of the spec is the predictor, which says how to load and run your model. It points KServe at the model and the runtime that should serve it.

The storageUri tells KServe where to pull the model from, like a GCS or S3 bucket. KServe downloads it into the serving container at startup.

The modelFormat field, such as sklearn or pytorch, lets KServe choose a matching serving runtime automatically. No custom server code needed for common frameworks.

You ship the manifest to the cluster with a normal kubectl command. KServe sees the new object and starts reconciling it into a running service. kubectl apply kicks it off.

After applying, you check status until the service reports READY. The READY column flips to True once the model is loaded and accepting traffic.

A ready InferenceService exposes a stable URL for predictions. Clients send requests there, and KServe routes them to your model behind the scenes.

You POST your input as JSON to the predict path of that URL. KServe forwards it to the model and returns the prediction in the response body.

Beyond predictor, the spec can add a transformer for pre and post processing and an explainer for insight. Each is optional and chains automatically.

You want KServe to serve a model. Which single object do you declare?

You learned that the InferenceService is KServe's single declarative resource. Set a predictor with a storageUri and format, apply it, and get a ready prediction URL. Nice work! 🎉