> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aireserve.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Frontier model serving playbooks

> Versioned deployment blueprints for serving frontier open-weight models on dedicated GPUs.

These playbooks turn a model release into an auditable serving recipe: exact
weights, hardware, runtime, launch flags, functional checks, load tests, and
operating limits. They cover the full path from an empty GPU allocation to an
authenticated OpenAI-compatible endpoint.

> [!WARNING]
>
> These are vendor-verified reference recipes, not AI Reserve performance
> certifications. Each page names what upstream maintainers verified and what
> still needs qualification on AI Reserve. Do not advertise a throughput,
> concurrency, or full-context service level until your exact recipe passes the
> acceptance run on the hardware you will operate.

> [!NOTE]
>
> Every playbook opens with **0. Set up your shell**: paste one block, replace
> only `AIRESERVE_API_KEY`, and every later command runs as written. Commands
> print the API's error body instead of a bare status code, and each step
> checks that it created what it claims before you continue.

> **[GLM-5.3](/gpu-infrastructure/playbooks/glm-5-3)**
>
> Native FP8 on 8×H200 with vLLM, GLM reasoning and tool parsers, and a 1M-token architecture window.

> **[Kimi K3](/gpu-infrastructure/playbooks/kimi-k3)**
>
> Native multimodal MXFP4/MXFP8 on 8×B300 with SGLang and preserved thinking history.

> **[DeepSeek V4 Pro 0813](/gpu-infrastructure/playbooks/deepseek-v4-pro-0813)**
>
> The released V4 Pro checkpoint on 8×H200 with vLLM, DeepSeek V4 encoding, and DSpark.

> **[DeepSeek V4.1 Flash](/gpu-infrastructure/playbooks/deepseek-v4-1-flash)**
>
> The released V4.1 model on 8×H200 with a V4.1-capable vLLM image and optional vision.

## Status vocabulary

Every page uses the same evidence labels:

| Label | Meaning |
| - | - |
| **Available now** | The documented AI Reserve REST operation exists today. |
| **Manual today** | The operator must perform or automate the step inside the workload; AI Reserve has no managed resource for it yet. |
| **Platform gap** | A production capability is required but is not currently provided by the Compute API or official SDKs. |
| **Vendor-verified** | The model or engine maintainer documents this artifact, topology, or behavior. AI Reserve has not independently certified it. |
| **AI Reserve verified** | Reserved for a pinned model revision and image digest that passed functional, long-context, and load acceptance on the named topology. None of these recipes has that status yet. |

The Python and TypeScript examples use the same public REST API as curl, so
they are executable now. An official `gpu` namespace for those SDKs is a
documented platform gap; the playbooks never present a future `client.gpu`
method as if it already ships.

### Target SDK ergonomics

> [!WARNING]
>
> **Target contract—not released code.** The official Python and TypeScript
> packages do not yet include these methods. Use the runnable HTTP tabs in the
> model playbooks today.

```python Python SDK target theme={"dark"}
from aireserve import AIReserve

client = AIReserve()
quote = client.gpu.instances.quote(
    accelerator="H200_141GB",
    count=8,
    volume_id=volume.id,
)
instance = client.gpu.instances.launch(quote_id=quote.id, recipe="glm-5.3").wait()
endpoint = instance.connections().http(port=8000)
```

```typescript TypeScript SDK target theme={"dark"}
import { AIReserve } from "@aireserve/sdk";

const client = new AIReserve();
const quote = await client.gpu.instances.quote({
  accelerator: "H200_141GB",
  count: 8,
  volumeId: volume.id,
});
const instance = await client.gpu.instances.launch({ quoteId: quote.id, recipe: "glm-5.3" }).wait();
const endpoint = await instance.connections.http({ port: 8000 });
```

## Pick the serving runtime

There is no universal image that safely serves every frontier checkpoint.
Architecture support often lands in an engine nightly before a stable release,
and parser names, CUDA requirements, kernels, and launch flags remain
model-specific.

| Runtime | Use it for | Do not assume |
| - | - | - |
| **vLLM** | OpenAI-compatible serving, continuous batching, tensor/expert parallelism, prefix caching, and engine-native benchmarks. It is the primary recipe for GLM-5.3 and both DeepSeek models here. | A stable image supports a newly released architecture, or one set of flags works across model generations. |
| **SGLang** | High-performance serving where its model cookbook has the stronger verified topology. It is the primary recipe for Kimi K3 here. | A floating `latest` image is reproducible, or every documented hardware path has completed final verification. |
| **Transformers / PyTorch** | Loading validation, prompt-encoding tests, conversion, and maintainer reference inference. | A production HTTP server, scheduler, batching policy, observability surface, or service-level objective. |
| **ComfyUI** | Node-based image and video generation workflows. | General LLM serving. It is not the serving runtime for any model in these playbooks. |

## Baseline matrix

| Model | Canonical artifact | Primary reference | Vendor-documented baseline used here | Important boundary |
| - | - | - | - | - |
| GLM-5.3 | `zai-org/GLM-5.3` | vLLM | 8×H200 141 GB | Text only; 1M context consumes substantial KV capacity. |
| Kimi K3 | `moonshotai/Kimi-K3` | SGLang | 8×B300 288 GB | Open checkpoint supports text and images; do not claim self-hosted video. |
| DeepSeek V4 Pro 0813 | `deepseek-ai/DeepSeek-V4-Pro-0813` | vLLM | 8×H200 141 GB, 800K configured context | Text only; `deepseek-v4-pro` is a mutable hosted alias, not an artifact revision. |
| DeepSeek V4.1 Flash | `deepseek-ai/DeepSeek-V4.1-Flash` | vLLM nightly | 8×H200 141 GB | V4.1 Flash is the only released V4.1 checkpoint; there is no plain DeepSeek V4.1 artifact. |

The hardware above is a starting topology, not a concurrency promise. A model
that fits in aggregate HBM can still miss latency targets because KV cache,
temporary buffers, communication, and long prompts need headroom.

## The production path

Each playbook follows the same sequence:

1. Review the model license and pin the model revision and serving image.
2. Quote persistent storage and GPU capacity before creating anything.
3. Stage the checkpoint onto a persistent volume and verify the snapshot.
4. Launch the serving workload with its model-specific engine contract.
5. Poll the durable operation, retrieve the protected HTTP URL, and warm the model.
6. Test normal chat, streaming, reasoning, tools, and supported modalities.
7. Sweep realistic traffic until the target TTFT, TPOT, throughput, and error-rate objectives fail.
8. Add the missing production layer—replicas, traffic draining, metrics, alerts, and rollback—before accepting customer traffic.
9. Terminate compute and explicitly delete storage when it is no longer needed.

For the API's quote, operation, idempotency, and retry behavior, read
[Operations, pricing, and errors](/gpu-infrastructure/operations). For
connection and lifecycle semantics, read
[Connect and manage](/gpu-infrastructure/manage-instances).

## What “industry-standard” means here

A successful `200` response is only a smoke test. A production acceptance
record should include:

* the model commit, engine image digest, driver/CUDA version, GPU topology, and all launch flags;
* tested input/output length buckets and the maximum context admitted in production;
* p50, p95, and p99 time to first token, inter-token latency, end-to-end latency, and queue time;
* input/output token throughput, request failures, OOMs, GPU/host memory, and KV/prefix-cache hit rate;
* tool-call validity, structured-output validity, reasoning-history behavior, and modality checks;
* speculation enabled and disabled against identical prompts, including accepted draft length;
* replica count, health policy, authentication, load-balancing behavior, drain timeout, rollback target, and alert thresholds.

Keep the acceptance record beside the deployment configuration. Re-run it
after any model revision, engine image, driver, kernel, quantization, topology,
or launch-flag change.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.