Compute
Run an approved Core ML model over a batch
Run an approved Core ML model over typed inputs and read the actual predictions, with measured performance where the run produces it. This is not a training service.
What you get
Real predictions from your own model, plus the numbers that tell you whether the run is worth repeating.
- One prediction per sample in
data/part-*, carryinglithi_resultand, where the model emits one,lithi_confidence. - Samples the model could not accept in
failures/part-*, with a typed code and a next action. - Measured performance in
metrics.jsonwhere the run produces it, such as sample counts and timing. provenance.json, binding the model asset digest to the predictions, so you always know which build produced them.
The model digest matters more than it looks. Two builds of "the same" model give different predictions, and only the digest tells you which one you are reading.
What you need
An approved model asset and typed inputs that match its declared interface.
Register the model as an input asset first, so it is versioned and referenced rather than pasted into a request. The workflow reads the model's declared input and output descriptions, and it will refuse a batch whose shape does not match.
Fifty samples is enough for a first run:
sample_id,path,width,height,color_space
CM-0001,samples/receipt-01.jpg,1024,768,rgb
CM-0002,samples/receipt-02.jpg,1024,768,rgb
CM-0003,samples/receipt-03.png,640,480,rgb
CM-0004,samples/grayscale-04.jpg,1024,768,gray
CM-0005,samples/tiny-05.jpg,32,24,rgb
Declare sample_id as your item_id_field. Sample four is grayscale and sample five is far below the model's input size, so both test whether the run refuses cleanly or silently rescales.
Run it
- Inspect locally:
lithi inspect ./coreml-fixture. Confirm the formats and dimensions, so a shape mismatch surfaces on your machine and not in a paid run. - Read the workflow:
lithi workflow explain <workflow-id>, and confirm your model's input format is one it accepts: supported input and output formats. - Reference the registered model version explicitly in your parameters. Never rely on whichever build happens to be newest.
- Quote it:
lithi quote --workflow <workflow-id> --input ./coreml-fixture/manifest.csv. The quote gives a maximum charge and an expiry, and authorizes nothing. - Approve the quote separately, then submit with
lithi batch submitand track withlithi status <job-id>.
Read the result
Open result-manifest.json, then reconcile the counts. Predictions plus failures plus abstentions should equal the fifty samples you submitted.
Check provenance.json next and confirm the model digest is the version you intended. Predictions from an older build look completely normal and will quietly contradict everything you concluded last week.
Then read the two awkward samples. The grayscale and undersized inputs should either be converted under a rule the workflow declares, or refused with a typed code. Silent rescaling is the outcome to look for, because it produces confident predictions from an image the model never really saw.
Read the measured performance beside the predictions, not instead of them. Timing tells you what a larger batch will cost you in time; it says nothing about whether the predictions are right.
Where it stops
You get predictions and measurements from a model you already have. This is not a general training service.
Nothing is trained, fine-tuned, distilled or improved here, and no model is promoted, registered as production or deployed anywhere. Bring your model in and take predictions out: how model and build assets are accepted.
No predictions are written back into an application, a database or a device. Nothing is filed and nothing is sent.
Accuracy is a property of your model, and it is not promised by the run. A confidence value is the model's own output, so calibrate it against a labeled set of your own before you let a threshold decide anything.