Model Packaging Format

InfraMind uses a standardized container-based packaging format to define and deploy AI models across its compute mesh. Each model is bundled as an OCI-compliant image, accompanied by a structured manifest (model.yaml) and optional execution hooks. This format ensures that models are reproducible, portable, and independently verifiable across a diverse and geographically distributed network of nodes.

Every job dispatched in InfraMind must be executed inside an isolated container. This container includes the model weights, runtime environment, serving logic, and optional pre- and post-processing utilities. Containers are built locally, pushed to any supported registry (IPFS, HTTPS, Docker), and referenced by hash or URI in the model registration flow.

The model container must be self-sufficient. It should expose a callable inference interface without requiring external resources at runtime. Any necessary data files, vocabularies, embeddings, or checkpoints must be included inside the image.

The packaging structure is defined by three key components:

  1. A Dockerfile specifying the build process.

  2. A model.yaml manifest describing runtime, resources, schema, and behavior.

  3. Optional hooks/ directory with shell scripts for init, warmup, or health checks.

A basic Dockerfile:

FROM python:3.10-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .

EXPOSE 9000

CMD ["python3", "serve.py"]

This example assumes the model serving logic is implemented in serve.py and listens on port 9000. The image must accept a POST request at the specified port containing input in JSON format and return a structured JSON response.

The model.yaml is a required manifest. It is parsed and validated by the node agent before execution. This file defines how the container should be treated by the mesh.

Example:

name: summarizer-v1
version: 0.4.2
entrypoint: serve.py
runtime: python3.10
protocol: rest
port: 9000

resources:
  cpu: 2
  memory: 4Gi
  gpu: false

input_schema:
  type: object
  properties:
    text:
      type: string
  required: [text]

output_schema:
  type: object
  properties:
    summary:
      type: string

hooks:
  init: hooks/init.sh
  healthcheck: hooks/health.sh
  • name: model identifier

  • version: semver-compatible version tag

  • entrypoint: path to the executable script inside the container

  • runtime: language/environment the model is built for

  • protocol: communication interface (rest or grpc)

  • port: port exposed for inference requests

  • resources: compute limits requested at runtime

  • input_schema / output_schema: JSON Schema v7-compliant definitions of input/output

  • hooks: shell scripts that run at container boot or for health probes

The model must respond to a POST request (or gRPC method if specified) with a payload matching input_schema and return a response conforming to output_schema.

Example input:

{
  "text": "InfraMind is a decentralized compute protocol."
}

Example output:

{
  "summary": "InfraMind is a protocol for decentralized compute."
}

Hooks provide optional custom logic during model initialization or health checks.

hooks/init.sh:

#!/bin/bash
echo "[init] Downloading tokenizer..."
python3 download_tokenizer.py

hooks/health.sh:

#!/bin/bash
curl -s --fail http://localhost:9000/health

InfraMind nodes validate containers before accepting jobs. If the container does not respond on the specified port within a timeout period (default: 3 seconds), or if the schema fails validation, the job is marked as failed and re-routed. Repeated failures result in node penalties and reputation impact.

Developers can locally test the container using the CLI:

infra test --container ./summarizer-v1

This command launches the container, sends synthetic inputs matching input_schema, and validates responses. Schema mismatches, missing ports, or failed hooks are surfaced immediately.

After packaging and validation, the container must be pushed to a content-addressable storage location. Supported backends:

  • IPFS (preferred): docker save summarizer-v1 | ipfs add --wrap-with-directory

  • HTTP/HTTPS: Push to any CDN or static server

  • Docker registry: docker push registry.inframind.host/summarizer-v1

The container reference is registered on InfraMind with:

infra publish --model model.yaml --image ipfs://QmXab123...

This associates the model manifest and container hash with a globally routed endpoint. The endpoint is immediately available for use:

curl -X POST https://api.inframind.host/inference/v1/summarizer-v1 \
     -H "Content-Type: application/json" \
     -d '{"text": "The future of AI is sovereign."}'

All model packages are signed at registration with the deployer's private key, ensuring authenticity and auditability. The container hash, manifest digest, and associated endpoint ID are stored in the on-chain model registry.

The packaging format is intentionally minimal. It avoids framework-specific wrappers, cloud tooling, or proprietary configurations. If the model can run in a container, and it can speak REST or gRPC, it can be deployed on InfraMind.

This format decouples deployment from infrastructure. It makes compute location-agnostic. It allows models to be pushed to the mesh, verified independently, and executed anywhere without centralized control. It’s not just about wrapping a model — it’s about unwrapping its dependency on any one platform.

Last updated