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

# Efficient serving

> How Mibyan pursues a lean serving footprint without reducing the quality bar to a hardware slogan

Mibyan is designed to make strong Arabic professional assistance practical on a deliberately lean serving footprint. That is an engineering goal, not a claim that a foundation model is magically small or that every workload belongs on the same machine.

The important distinction is between **model capability** and **system efficiency**. Users experience the latter: how quickly work starts, how consistently it streams, whether it recovers cleanly, and how much infrastructure is required to deliver an accepted result.

## What “lean” means here

We optimize the serving system as a whole rather than making an unqualified claim about a single hardware number.

| Layer                | Efficiency decision                                                     | User outcome                                                              |
| -------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| Public contract      | One stable model identifier                                             | Applications do not carry provider-specific model logic                   |
| Request handling     | Streaming-first, bounded request paths                                  | Earlier visible progress and less time spent waiting for a full response  |
| Routing boundary     | Runtime configuration stays behind the service                          | Serving can evolve without an API migration                               |
| Workload fit         | Arabic professional tasks have explicit templates and evaluation tracks | Less wasted output and fewer retries for the intended jobs                |
| Reliability controls | Budgets, limits, request IDs, retries, and structured validation        | Failures become observable and recoverable rather than silently expensive |

<Note>The public API does not publish a fixed GPU, RAM, quantization, or provider configuration. Hardware is a deployment variable; the public promise is the measured service behavior and the reproducible protocol below.</Note>

## Why this matters

The largest deployment is not automatically the best deployment. For a focused Arabic workflow, the useful measure is quality per accepted outcome: the quality that survives review, divided by the time, tokens, and operational cost required to create it.

This framing avoids two common errors:

* Comparing parameter counts while ignoring latency, retries, output waste, and human editing.
* Announcing a tiny hardware footprint without saying what concurrency, context length, quality setting, region, or failure rate it supports.

## Deployment profile: what we measure

Before calling a deployment profile “low-spec,” record the following alongside the result. This makes the claim auditable across environments.

| Measurement     | Why it belongs in the report                                                                             |
| --------------- | -------------------------------------------------------------------------------------------------------- |
| Runtime profile | CPU/GPU class, memory available to the service, quantization if applicable, and serving software version |
| Workload        | Prompt mix, language mix, context and output limits, tool use, and concurrency                           |
| Responsiveness  | Time to first token, p50/p95 completion time, and streaming continuity                                   |
| Reliability     | Success rate, timeout rate, retry rate, and recovery behavior                                            |
| Quality         | Acceptance rate, constraint satisfaction, human preference, and error taxonomy                           |
| Efficiency      | Tokens per accepted output and cost per accepted output                                                  |

## A responsible comparison

Mibyan should be compared with a frontier model on the same held-out Arabic workload, not by implying that either model is universally better. A frontier model can lead on breadth, multimodality, or difficult open-ended reasoning. Mibyan may be the better operational choice when Arabic terminology, structured business work, stable integration, and a lean controlled serving path are decisive.

The comparison must hold constant the prompt, context, output cap, temperature, tools, retry policy, region, and scoring rubric. See the [benchmark protocol](/models/benchmarks) for the full reporting contract.

## Operator checklist

1. Start with a representative held-out Arabic workload, not demo prompts.
2. Run a baseline with the intended concurrency and context limits.
3. Capture latency, reliability, and quality together; do not optimize one in isolation.
4. Classify every failure: timeout, missed constraint, bad Arabic, unsupported task, tool error, or factual error.
5. Compare accepted outputs—not just raw tokens or a single leaderboard score.
6. Publish a dated deployment manifest before turning an internal efficiency result into a public numerical claim.

<Warning>A lean serving design does not remove the need for human review, retrieval from authoritative sources, application-level validation, or rate and budget controls.</Warning>