Self-hosted container
Context keys
How a context key selects a benchmarked serving recipe.
A context key names the situation you are serving in. The container resolves it to a recipe: the model, its quantization, every serving knob, and the scheduler and controller configuration that was benchmarked for that situation.
Format
<model> : <quant> : <workload> : <hardware>For example:
qwen3-32b:fp8:chat:a100-80x1- model and quant identify what is served.
- workload describes the traffic shape the recipe was tuned for
(
chat,coding,agentic). - hardware is your declaration of the GPUs you run on. It is validated
against the detected hardware: a mismatch warns loudly but still runs,
unless you pass
--strict-hardware.
Available launch keys
| Context key | Plan |
|---|---|
qwen3-32b:fp8:chat:a100-80x1 | Free |
qwen3-coder-32b:fp8:coding:a100-80x1 | Free |
qwen2.5-0.5b:fp8:chat:l4x1 | Free (validation-sized) |
qwen3-100b:fp8:chat:h100x2 | Premium |
qwen3-coder-next:fp8:coding:h100x4 | Premium |
qwen3.6-27b:fp8:agentic:h100x8 | Premium |
A valid license key grants the premium tier. Without one, the container serves free-tier recipes only.
How it is used
docker run ... -e CF_CONTEXT_KEY="qwen3-32b:fp8:chat:a100-80x1" ...or as a flag when overriding the entrypoint:
carbonforge-runtime --context-key qwen3-32b:fp8:chat:a100-80x1