Use prepared records with PyTorch

Choose the result your model code needs

Your PyTorch application owns the model, loader and final interpretation. Your agent keeps the task goal, context, planning and final decision. A supported client or Kit helper prepares the accepted artifact when the workflow provides one; Lithi returns a result for your application to validate before it becomes prediction or evaluation evidence.

Decide whether the Compute result will supply predictions, evaluation records or another declared output before you build a PyTorch loader. Define the model identity, input fields, label meaning and expected output schema in your own application. A result file is evidence for that contract; it is not automatically a training target or a quality score.

Use PyTorch in your own approved environment to prepare inputs or consume verified results. Do not put a paid Compute call inside __getitem__, an iterator or a collate function. Repeated reads, worker behavior or another training epoch must not silently submit new work.

This guide covers local data exchange. It does not make Lithi a PyTorch training cluster, gradient service or arbitrary Python execution endpoint. Your training and local device choices remain separate from the Compute job.

Try a finite synthetic loader

This example requires PyTorch. It reads two in-memory records with no network request, training step, GPU work or worker subprocess. The PyTorch data reference documents Dataset and DataLoader.

from torch.utils.data import DataLoader, Dataset
class Records(Dataset):
    def __init__(self, rows):
        self.rows = list(rows)
        ids = [row["item_id"] for row in self.rows]
        if any(not isinstance(key, str) or not key for key in ids):
            raise ValueError("Item IDs must be nonempty strings")
        if len(ids) != len(set(ids)):
            raise ValueError("Duplicate item IDs")
    def __len__(self):
        return len(self.rows)
    def __getitem__(self, index):
        return self.rows[index]
rows = [{"item_id": "sample-001", "text": "Hello"},
        {"item_id": "sample-002", "text": "Goodbye"}]
loader = DataLoader(Records(rows), batch_size=2, shuffle=False, num_workers=0)
batch = next(iter(loader))
assert batch["item_id"] == ["sample-001", "sample-002"]
print(batch["item_id"])

Prepare inputs before approving work

For a real dataset, define stable IDs, selected fields and the expected output schema. Validate missing values and duplicate IDs before exporting. Freeze the exact files, bytes and digests. Keep data-store credentials in your approved configuration, not in records or a copied task prompt.

Use the file workflow and the selected native job or batch contract. Review current access, availability and the quote before paid submission. Save the returned job identity separately from the local loader. Lithi handles admitted work; a loader iteration isn't another execution request.

Consume results deliberately

Retrieve and verify the accepted output before creating the local dataset. Join through the original item-ID mapping. Keep failed, abstained, missing and review-required records visible in a separate exception population. Do not turn a missing label into zero or treat successful parsing as a correct prediction.

Define tensor shapes, dtypes, label meanings and preprocessing in your own application. Record the model identity, input, result and transformation versions so an experiment can be reproduced. A successful parse is evidence that the format was readable; it is not evidence that the prediction or evaluation is correct.

Recover without resubmission

If a loader reports an unexpected schema or duplicate ID, stop and repair the local mapping. If a result download expires, renew access to the existing result. If the job's outcome is uncertain, read its current state before submitting anything new. A new epoch, batch size or shuffle order doesn't approve another paid job.

Next, download and verify the result before constructing a production loader.