Skip to main content

Glossary

Each entry defines one term and links to the page that describes it in depth.

A​

alpha​

A number, in seconds per megabyte, that sets how much the size of a checkpoint counts against the import time that it saves. The pipeline uses it when planning checkpoints and the router uses it when choosing one, so both must use the same value. See Cost model.

auto-expand​

A worker behavior that raises the memory limit of a container when usage approaches the limit. Growth stops at the max_memory set on @remote, or at the capacity of the worker if none is set. See Packages and resources.

C​

catalogue​

A JSON file, one per flavor, that lists every checkpoint the pipeline built and the packages that each contains. The router loads catalogues at startup to choose a checkpoint for each call. If none exist, every start is a cold start. See Flavors and catalogues.

checkpoint​

A saved copy of a running Python process, taken after the process has imported a set of packages. Restoring a checkpoint is faster than starting Python and importing those packages again. See Checkpoints.

checkpoint id​

The name of one checkpoint in a catalogue, for example checkpoint_3. The router sends it to the worker. A function can pin one with @remote(checkpoint_id=...). The same number can name different checkpoints in two generations or two flavors, so an id is meaningful only for one catalogue. See Checkpoints.

cloudpickle​

A Python library that serializes functions, including functions defined in a script. The client uses it to turn the function and its arguments into bytes, and the executor turns the bytes back into a function. Both sides must run the same Python minor version. See the FAQ.

cold start​

A delay that occurs when a function runs on a fresh interpreter that must import its libraries first. Readie shortens this delay. See Cold starts and restore.

container​

A running sandbox, as tracked by the worker. Logs and settings use "container" where this documentation uses "sandbox". See Sandboxes and Container lifecycle.

corpus​

A collection of example workloads that the pipeline analyzes to decide which packages belong in checkpoints. Each workload holds one or more code strings, a domain, a source (real code from Kaggle or Hugging Face, or code written by a model) and the resources it uses. The pipeline builds one corpus per flavor offline. See Building checkpoints.

D​

dependency closure​

A set of packages that contains a package, everything it imports, and everything those packages import in turn. The router prices a checkpoint by the closure of what a request needs, not only by the names that the request lists. See Cost model.

distribution​

A package as PyPI publishes it, such as scikit-learn, as opposed to the module that it provides for import, such as sklearn. A catalogue lists the distributions that the root filesystem of a flavor contains, and the router skips any requested package that is already one of them. See Flavors and catalogues.

E​

executor​

A Python program that runs inside every sandbox. It receives the pickled function over a unix socket, calls it, and returns the result. See Components and Executor protocol.

F​

flavor​

A hardware kind, cpu or gpu, that a worker and its checkpoints are built for. A GPU request goes only to GPU workers. See Flavors and catalogues.

G​

generation​

A complete set of artifacts for one flavor: the captured checkpoints, the manifest, and the catalogue. The command make generation captures one and builds the worker image that matches it. See Build checkpoints.

gRPC​

A remote procedure call framework that uses messages defined in protobuf files. Every Readie component except the executor communicates with its neighbors through gRPC. See Protos reference.

gVisor​

A sandbox technology from Google that intercepts the system calls of a program in user space instead of passing them to the host kernel. Readie uses it to isolate user code and to take checkpoints. It runs on Linux amd64 only. See Sandboxes.

I​

idle TTL​

A duration that a warm container may remain unused before the worker destroys it. The setting is SANDBOX_IDLE_TTL and the default is 5 minutes. The check runs every 30 seconds. See Container lifecycle.

M​

manifest​

A manifest.json file written when checkpoints are captured. It records, among other values, the executor command and the executor protocol version. The worker reads it and refuses artifacts that it cannot work with. See Building checkpoints.

O​

OCI spec​

A config.json file that describes a sandbox to the runtime, including its program, mounts, and settings. The pipeline and the worker generate it with the same Go code, because a checkpoint restores only into a sandbox of the same shape. See Sandboxes.

P​

placement​

A routing decision that selects the worker for a call. The router considers capacity, flavor, session affinity, and which checkpoint saves the most time. See Placement.

planner​

A pipeline component that decides which packages go into which checkpoints. The default is a greedy planner that keeps adding a package while the time it saves is worth more than its size cost. A fixed planner uses a set of packages that the user chooses. See Building checkpoints.

protobuf​

Protocol Buffers, a format for describing structured messages and services in .proto files. Code generators turn those files into Python and Go code. See Changing protos.

R​

registry​

A live list of workers and their status that the router maintains. Workers report to it through the RegistryService. It is held in memory, so a router restart empties it until workers report again. See Components.

restore​

An operation that brings a checkpoint back to life as a running process in a new sandbox. See Cold starts and restore.

rootfs​

A root filesystem that every sandbox sees, consisting of the operating system and the installed Python packages. It is read-only and shared, and each sandbox gets its own writable layer on top. A checkpoint restores only into the rootfs it was captured from. See Sandboxes.

router​

A service that receives calls from clients and decides which worker runs them. It also maintains the registry. See Components.

runsc​

A command-line program that runs gVisor sandboxes. The worker calls it to create, checkpoint, and restore sandboxes. See Sandboxes.

S​

sandbox​

An isolated environment where a function runs, separate from the host machine and from the code of other users. In Readie, a sandbox is a gVisor container. See Sandboxes.

session​

A handle that pins a series of calls to the same warm container. State that one call leaves in memory, such as a loaded model, is available to the next call. Calls in a session run one at a time. See Sessions.

spec fingerprint​

A hash of the parts of a sandbox that a checkpoint depends on: the program, the mount list, the namespaces, and the runtime modes. The worker checks it before a restore, so a checkpoint is never restored into a sandbox of a different shape. See Sandboxes.

W​

worker​

A Go service that starts sandboxes, restores checkpoints, communicates with the executor, and reports its load to the router. See Components.

Symbols​

@remote​

A decorator from the readie package that marks a function to run on a Readie cluster instead of locally. It accepts options for memory, GPU, packages, and more. See the SDK reference and the Quickstart.