Start with a job that finishes
Package the scoring or transformation code with its model and dataset inputs. Request the CPU, memory, and accelerators it actually needs, and write results to the configured output storage. When the job finishes, inspect its status, logs, and recorded artifacts.
The batch-scoring example loads a model from a prior run, applies it to a CSV dataset, and saves a result file with predictions. The same workload shape can generate embeddings or transform data when your container supplies the corresponding code. It does not require an always-running model server.
Inspect the result of a scoring job
The Iris example makes the handoff concrete: a source-run UUID identifies model.joblib, the job reads four measurements from each CSV row, and the scoring code adds prediction and prediction_class columns to results.csv.
The result is saved under the run's outputs and logged as a CSV artifact named scoring-results. Someone reviewing the batch can open or download that file from the same run rather than looking for an unrelated export.
Add parallelism when one job is not enough
If the work can be partitioned, define the partitions and pass their input and output locations as parameters. Polyaxon mapping can create executions from that list, while workflow concurrency and queue controls bound how much work runs at once.
Your application owns the partition boundaries and how results are combined. A dataset is not automatically sharded by submitting it to a queue. Keep a single job when it meets the batch window; add mapping or a DAG when parallel execution or dependent processing stages justify it.
Map a component over parameter sets · Control shared compute
Distinguish a complete batch from a partial one
Give each partition a distinct output location and record the expected inputs and results in a manifest. If a collection step depends on workers, require the appropriate successful upstream states before publishing its output. Validate record counts and other workload-specific completeness checks in that step.
When a worker fails, inspect its run and retry with an explicit output policy. Overwrite a partition safely, create a new batch version, or otherwise make repeat execution safe for the destination. Restarting a Polyaxon operation does not undo writes to an external database or remove duplicate predictions.
Make recurring batches inspectable
Record the model version or source run, input dataset revision, image, and parameters alongside each batch. Log the result files and manifest so someone investigating a prediction can identify the work that produced it. Use artifact versioning when other workflows need a named dataset output.
Once one complete batch is working, add a cron or interval schedule. Configure dependency on the previous execution when overlapping batches would conflict. Scheduling determines when a run starts; your workflow must still verify that its input data is ready.
Use an endpoint when the application needs immediate answers
Batch jobs fit periodic exports, dataset backfills, offline scoring, and processing that can wait for a completed result. They are a different operating model from an application making low-latency requests to a model service.
Choose the request-serving path when callers need an available endpoint. Choose batch work when the inputs and completion criteria can be defined as a finite job or workflow, and size its compute to the required completion window.