README.md

metadata

title: Serving a model on your own GPU
emoji: 🧭
colorFrom: blue
colorTo: gray
sdk: static
app_file: index.html
pinned: false
license: apache-2.0
short_description: Five questions between a model page and a model that runs

Serving a model on your own GPU

Five questions stand between a model page and a model that runs, and every one of them has an answer already sitting in the repo's metadata. This page is the index of the tools that read it — in the visitor's browser, without downloading weights and without running anything.

The question	The tool
Which model should I even try?	Find a model that fits
How much context can I actually serve?	What context will actually fit?
How do I run it correctly?	Does this model need a reasoning parser?
What did this quantized pack really compress?	How much of this pack is actually 4-bit?
Is the pack what it claims to be?	Does this pack keep what it claims?

Put a model in the box and every step opens with it already filled in — ?repo=owner/model is read by each tool, so a model travels with you through the chain instead of being retyped five times.

Why metadata is enough

A model repo publishes its architecture, its attention topology, its tensor index and its chat template before you download a byte of weights. Almost every serving failure — it will not fit, the context is too long, the answers come back empty, the pack is not what its name says — is decidable from that alone.

None of these tools loads a model, so none of them can tell you how good it is. They tell you whether it will work, and what it will cost.

Development

The list of tools lives once, in space-shared/tools.js, and is copied into each Space at deploy time. This page renders from that same registry rather than from its own copy — a landing page listing tools from a private list is the first place a rename goes stale, and the one page where a dead link costs the most.

./stage-shared.sh
./deploy.sh aleada/start-here

Built from the tooling behind the aleada W4A16 packs.