MODULE 4  ·  DAY 1

Packaging Models as OCI Artifacts

Versioned, signed, and ready for any registry.

Kitfile weights adapter config prompts one sealed ModelKit, pushable to any OCI registry

Gourav Shah  ·  School of DevOps & AI  ·  KitOps · ModelKit · ORAS

M4·01

What you'll learn

Pack, push, and pull models like container images.

12 34 Why an OCI artifact is the right home for a model, versioned and layered Author a Kitfile and pack a ModelKit with the kit CLI Push and pull across GHCR, Docker Hub, Quay, Harbor with one syntax Selective-pull just the weights; contrast KitOps with docker model
M4·02

1 · The problem with loose model files

M4·03

The problem with loose model files

Scattered files force every receiver to guess.

shared drive: weights Slack link: prompts README: "also grab v3" Receiver re-assembles by hand versions drift wrong prompt + wrong weights nothing signed
M4·04

2 · What is an OCI artifact (and why models fit perfectly)

M4·05

An OCI artifact is a layered blob store

One layered design stores any typed content.

Container image base OS layer app layer config layer same spec ModelKit model weights layer code / prompts layer manifest + config SHA-256 + signed
M4·06

3 · KitOps and ModelKit (CNCF + ORAS)

M4·07

A ModelKit is a sealed, labelled crate

Open it, and the contents match the manifest.

Kitfile (manifest) model weights .gguf code LoRA adapter (M3B) config quantization prompts system prompt
M4·08

KitOps, ModelKit & ORAS

One CNCF stack every registry already speaks.

kit CLI pack · push · unpack · ModelKit format ORAS OCI Registry As Storage: push and pull typed artifacts OCI distribution API the standard every registry speaks GHCR · Docker Hub · Quay · Harbor · Artifactory · registry:2
M4·09

4 · The Kitfile: your shipping manifest

M4·10

The Kitfile is your shipping manifest

Each YAML field maps to one OCI layer.

Kitfile manifestVersion: "1.0.0" package: {name, version, authors} model: {path: ./model/*.gguf} code: [{path: ./prompts.txt}] manifest annotation registry UI metadata model layer the weights blob code layer prompts / config
M4·11

5 · The full flow: Kitfile → registry → serving node

M4·12

The lifecycle: pack → push → pull → run

Workspace to registry to serving node.

workspace kit pack Registry acme-docs-model:1.0.0 serving node kit unpack runtime llama.cpp push pull weights are never "run" as a container, just unpacked and loaded by a runtime
M4·13

6 · Selective pull: the KitOps payoff

M4·14

Selective pull grabs only what you need

Pull just the layer you actually need.

ModelKit model (weights) code (scripts) datasets --filter=model --filter=code --filter=datasets Serving node weights only, skips gigabytes CI pipeline lint the inference scripts Data-science notebook analyse data, no weights
M4·15

7 · Multi-registry portability

M4·16

One artifact, every registry

Same command, any OCI-compliant registry.

ModelKit kit push <ref> GHCR Docker Hub Quay.io Harbor (private) Artifactory local registry:2
M4·17

8 · ModelKit vs a plain container image

M4·18

ModelKit / ORAS vs docker model package

Same idea, different reach across registries.

KitOps ModelKit docker model package CNCF · portable kit works anywhere any OCI registry typed layers: model/code/data selective pull (--filter) Docker-specific needs Docker Desktop Docker Hub primary single model blob no selective pull
M4·19

TO THE LAB

Ship your model like an image

model code config prompts Registry Serving node

Pack, push, pull, then selective-pull in the lab.

Next up: Lab: Pack & Push a ModelKit with KitOps  ·  Gourav Shah · School of DevOps & AI

M4·20