Reference Design¶
Overview¶
A reference design publishes, exactly as it was run, a serving stack configuration whose behavior Rebellions confirmed on Rebel100™. Targeting agentic workloads, it records which software versions were installed, which arguments the stack was served with, and why each value was chosen.
The purpose of this series is reproduction and scale-out. Deploying the configuration described in a document as written should reproduce the behavior validated in that document, and taking the same configuration as the starting point is recommended when scaling up.
A reference design is not the following:
- Not a tutorial. For the usage of an individual feature, see Getting Started and the tutorials for each piece of software. This series covers one complete set of configuration.
- Not a benchmark. Serving performance depends on the workload, so evaluate a design on your own workload before sizing a deployment.
- Not a delivery specification. Hardware configuration is described only as a technical baseline.
Audience¶
| Persona | What this series provides |
|---|---|
| AI Engineer | The rationale behind model selection and the parallelism, KV cache, and speculative decoding arguments, and the impact of changing those values |
| System Administrator | Hardware, network, and storage requirements, the Kubernetes deployment topology, and the metrics to watch and failure modes during operation |
Status badges¶
Each component and statement carries a badge that marks its confidence boundary. Do not read a statement that carries no badge as Validated.
| Badge | Meaning |
|---|---|
| Validated | Behavior was confirmed in a validation recorded on the document's Validation and Limits page. An item that depends on the node count or the P/D layout is marked only when it was confirmed on the Target Configuration. |
| Default configuration | Behavior was confirmed in a validation, but its effect on performance was not evaluated. |
| Optional | Not included in the canonical deployment configuration, and can be enabled as needed. The impact is described separately. |
| Experimental | Behavior is not confirmed, or the interface may change. Use in a production environment is not recommended. |
| Unverified | The evidence for the value or the statement is not yet in place. It is updated as soon as the evidence is available. |
Among these, the distinction between Default configuration and Validated matters most. Confirming that a setting works is not evidence of its effect on performance.
Target Configuration¶
Each reference design defines one Target Configuration: the configuration recommended on the basis of the product adoption unit, and the reference point for scale-out planning. Validation is performed on the Target Configuration itself, so a design states a single configuration rather than a recommended one and a separately validated one.
The status badges mark how far each part of the Target Configuration was confirmed. A part that is in the Target Configuration but was exercised by no validation carries Unverified. An item decided within a single instance, such as a serving argument, a feature, or accuracy, is marked Validated or Default configuration when it was confirmed on a configuration with the same P/D split and the same per-role parallelism as the Target Configuration. A result confirmed on any other configuration does not back a badge.
Notation conventions¶
- Endpoints, host names, and credentials are written as placeholders in the form
http://<gateway>:80/v1.
Document structure¶
Each reference design consists of the following eight documents. The design's overview page links its own set.
| Document | Contents |
|---|---|
| Overview | Workload definition, configuration summary, validation approach, validation scope |
| Hardware | Server, NPU, network, and storage requirements, and the rationale for them |
| Software Stack and Versions | Components and their pinned versions |
| Deployment on Kubernetes | Deployment topology, resources, startup procedure |
| Serving Configuration | The canonical configuration of serving arguments and the rationale for each value |
| Client Integration | API usage and client and agent integration |
| Operations | Metrics to watch, failure modes, operational procedures |
| Validation and Limits | Validation method, accuracy results, known limits |
Available reference designs¶
| Design | Workload | Model | Status |
|---|---|---|---|
| Coding Assistant on Rebel100™ | Coding agent serving | MiniMax-M2.7 | Validated on the 4-node, 32-NPU Target Configuration (4P4D) |
For questions or feedback about a reference design, see Contact Us.