How to Deploy Allam in Production

How to Deploy Allam in Your Application

Allam is SDAIA’s Arabic large language model — a 34-billion parameter transformer trained on over 100 billion Arabic tokens drawn from the Arab world’s largest curated corpus. Released in 2024, it represents Saudi Arabia’s flagship sovereign AI asset and the most capable open Arabic language model available. For developers building applications that serve Arabic-speaking users — whether in government, finance, healthcare, or consumer products — Allam is now the baseline to beat for Arabic NLP tasks.

This guide walks through every deployment option, from the easiest managed API path to self-hosted inference on Saudi compute infrastructure, along with the compliance and UI considerations you need to ship production-grade Arabic applications.

Understanding Allam’s Architecture and Why It Matters

Allam is built on the IBM Granite architecture, developed jointly by SDAIA and IBM Research. The 34B parameter count places it in the same category as Meta’s Llama 3 34B, but with a critical difference: the training corpus is dominated by Modern Standard Arabic (MSA) and Gulf dialect Arabic, supplemented by English and multilingual scientific text.

Key architectural facts:

• 34B parameters, dense transformer (not MoE)
• Context window: 4,096 tokens in the base model; extended context variants in development
• Training data: 100B+ Arabic tokens, 70B+ English tokens
• Quantization: Available in FP16, INT8, and GPTQ 4-bit for deployment
• License: Allam Community License (open for research and commercial use within SDAIA guidelines)

The model performs particularly well on tasks where Arabic morphological complexity matters: named entity recognition across Arabic dialects, Arabic legal document summarization, Arabic math and reasoning benchmarks (ArabicMMLU, Arabic Hellaswag), and Quranic/classical Arabic understanding.

Option 1: SDAIA Managed API

The fastest path to production is the SDAIA Allam API, managed through the National Center for AI (NCAI) developer portal.

Step 1: Register on the SDAIA Developer Portal

Navigate to ai.gov.sa/developers and register with a Saudi Business Registration Number (CR Number) if you are a Saudi entity, or your commercial entity’s credentials if you are a foreign company operating in KSA. SDAIA currently prioritizes onboarding for:

1. Saudi government ministries and agencies (fast-track, typically 2-3 business days)
2. Saudi private sector companies (standard onboarding, 5-10 business days)
3. International companies with MCIT-registered Saudi presence (10-15 business days)
4. Research institutions (academic pathway, requires university MOU)

You will receive an API key and a rate limit tier assignment. Entry tier is 100,000 tokens/day; enterprise tier negotiated directly with SDAIA.

Step 2: API Authentication and Basic Request

Allam API follows a standard REST interface. Authentication uses Bearer tokens:

POST https://api.ai.gov.sa/v1/allam/completions
Authorization: Bearer <your-api-key>
Content-Type: application/json

{
  "model": "allam-34b",
  "prompt": "اشرح مفهوم الذكاء الاصطناعي بأسلوب بسيط",
  "max_tokens": 512,
  "temperature": 0.7
}

Response latency on the managed API averages 800ms–1.5 seconds per request for prompts under 512 tokens. For high-throughput applications, request batch processing access through your SDAIA account manager.

Step 3: Pricing

SDAIA’s managed API pricing (as of early 2025) is structured as:

• Input tokens: SAR 0.03 per 1,000 tokens (~$0.008)
• Output tokens: SAR 0.06 per 1,000 tokens (~$0.016)
• Government entities: 60% subsidy available through SDAIA’s national AI program

Compare this to self-hosted inference: running Allam 34B in FP16 on 2x NVIDIA A100 80GB GPUs costs approximately SAR 8,000–12,000/month in cloud compute on AWS (Bahrain region) or STC Cloud, depending on reserved vs. on-demand pricing.

Option 2: Hugging Face Deployment

Allam is available on Hugging Face as sdaia/allam-1-34b-instruct, making it accessible to developers who prefer the standard ML ecosystem over the SDAIA portal.

Step 1: Access the Model

The model is gated on Hugging Face — you must request access at huggingface.co/sdaia/allam-1-34b-instruct. Access is granted within 24–48 hours for most requesters who agree to the Allam Community License.

Step 2: Load and Run Locally or on Cloud GPUs

from transformers import AutoTokenizer, AutoModelForCausalLM
import torch

model_name = "sdaia/allam-1-34b-instruct"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype=torch.float16,
    device_map="auto"
)

Minimum hardware for FP16 inference: 2x A100 80GB or 4x A6000 48GB. For INT8 quantized: 1x A100 80GB is sufficient for most prompts. GPTQ 4-bit: runs on a single A100 40GB with acceptable quality degradation.

For production deployments in KSA, prefer STC Cloud (Riyadh region), Alibaba Cloud Saudi, or AWS Middle East (Bahrain) to keep data within or adjacent to the Kingdom.

Step 3: Serving with vLLM

For production serving, vLLM offers the best throughput per GPU dollar for Allam:

python -m vllm.entrypoints.openai.api_server   --model sdaia/allam-1-34b-instruct   --tensor-parallel-size 2   --dtype float16   --max-model-len 4096   --port 8000

Throughput benchmarks: approximately 400–600 tokens/second on 2x A100 80GB with vLLM, compared to 80–120 tokens/second with naive HuggingFace inference.

Arabic Tokenization Requirements

Arabic NLP has specific tokenization challenges that will break your application if not handled correctly.

Critical Tokenization Issues

1. Diacritics (Tashkeel): Arabic text may include diacritical marks (harakat) that significantly change meaning. Allam handles diacritized text but performs best when diacritics are either fully present or fully absent. Mixed diacritization reduces coherence. Normalize your input using the camel-tools library:

from camel_tools.utils.normalize import normalize_unicode
text = normalize_unicode(user_input)

2. Arabic-Indic vs. Western Numerals: Arabic text commonly mixes ١٢٣٤٥٦٧٨٩٠ (Arabic-Indic) and 1234567890 (Western). Allam handles both, but normalize to Western numerals for numerical reasoning tasks.

3. Connected vs. Isolated Forms: Arabic letters change shape based on their position in a word. This is handled at the Unicode level — ensure your pipeline uses UTF-8 encoding throughout and never converts Arabic text through intermediary ASCII encodings.

4. Tokenizer Vocabulary: Allam’s tokenizer has a vocabulary of ~48,000 tokens with strong Arabic coverage, averaging 1.3–1.5 Arabic characters per token for MSA (compared to 3–5 characters per token for Arabic in GPT-4’s cl100k tokenizer). This means Arabic prompts consume roughly half the tokens you would expect from GPT-4 pricing — a significant cost advantage.

Prompt Engineering for Arabic

Structure your system prompts in Arabic for best results. English system prompts with Arabic user content produce measurably lower quality responses. A solid base template:

أنت مساعد ذكاء اصطناعي متخصص في [domain].
تجيب دائماً باللغة العربية الفصحى الواضحة.

Arabic Right-to-Left UI Considerations

This is the area most developers underestimate. Arabic RTL layout requires changes throughout your frontend stack.

Step 1: HTML/CSS RTL Mode

Set dir="rtl" on the root element and use CSS logical properties:

<html dir="rtl" lang="ar">

.chat-container {
  direction: rtl;
  text-align: right;
  font-family: 'IBM Plex Arabic', 'Noto Naskh Arabic', sans-serif;
}

Step 2: Streaming Text Display

When streaming Allam completions token by token, right-to-left text rendering creates a visual problem: tokens appear left-to-right on screen until a full word is formed. Buffer at the word level, not the character level, for Arabic streaming UI. Accumulate tokens until a space character appears before rendering to DOM.

Step 3: Mixed Arabic/English Content

Many Allam responses will mix Arabic and English (code, proper nouns, URLs). Use the CSS unicode-bidi: embed property for inline Latin content within Arabic paragraphs to prevent bidirectional text rendering issues.

Benchmark Comparisons: Allam vs. GPT-4o for Arabic

Based on published benchmarks and practitioner reports from KSA-based developers:

The pattern is clear: for Gulf-dialect content, government and legal Arabic, and Islamic/religious text, Allam outperforms GPT-4o significantly. For complex reasoning, multilingual tasks, and code generation, GPT-4o maintains an edge. Most production Saudi applications use Allam as the primary model with GPT-4o as a fallback for edge cases.

Fine-Tuning Allam on Proprietary Arabic Data

For enterprise applications requiring domain-specific performance (banking compliance, healthcare records, government case files), fine-tuning Allam on your proprietary data yields 15–30% benchmark improvement on domain tasks.

Step 1: Data Preparation

Minimum dataset size for meaningful fine-tuning: 10,000 instruction-response pairs. Ideal: 50,000–100,000 pairs. Format your data as JSONL:

{"instruction": "لخص هذا العقد القانوني:", "input": "[contract text]", "output": "[summary]"}

Step 2: Fine-Tuning Infrastructure

Use LoRA (Low-Rank Adaptation) to reduce GPU memory requirements. Full fine-tuning of 34B parameters requires 8x A100 80GB. LoRA fine-tuning runs on 2x A100 80GB:

from peft import LoraConfig, get_peft_model

lora_config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    task_type="CAUSAL_LM"
)

Typical fine-tuning time: 24–48 hours for 50K examples on 2x A100. Estimated cost on STC Cloud: SAR 3,000–5,000 per fine-tuning run.

Step 3: PDPL Data Residency for Fine-Tuning

If your training data includes personal data of Saudi residents (names, IDs, health records), the Saudi Personal Data Protection Law (PDPL) requires that this data be processed within KSA or in countries with SDAIA-approved data protection frameworks. Do not send training datasets to cloud providers outside approved jurisdictions. Use:

• STC Cloud (Riyadh): Fully KSA-resident
• AWS Bahrain with KSA data residency commitment: Conditionally approved
• Microsoft Azure KSA North (Riyadh): Approved

Integration with Saudi Government Portals

If you are building applications that integrate with Saudi government platforms, Allam has pre-negotiated API access to several national platforms:

1. Absher (national ID and civil services): SDAIA API integration approved; requires government entity onboarding
2. Etimad (government procurement and contracts): Allam can be used for contract analysis; procurement entity credentials required
3. Tawakkalna (health and vaccination records): Health data integration requires NDMO data classification approval
4. Saudi Business Center: Commercial registration data extraction; standard API access

For government integrations, route all API calls through the Saudi Government Cloud (G-Cloud), not commercial cloud providers. SDAIA provides a G-Cloud deployment package for Allam upon request through the official procurement channel at ncai.gov.sa.

Deployment Checklist

Before going to production with an Allam-powered application in KSA:

1. Confirm API key tier is adequate for expected token volume
2. Implement Arabic input normalization (camel-tools or equivalent)
3. Validate RTL rendering across target devices (Android Arabic locale, iOS Arabic locale, Windows/Edge Arabic mode)
4. Ensure inference infrastructure is KSA or Bahrain resident if processing personal data
5. Register the AI application with SDAIA’s AI application registry (required for public-facing applications under NDMO AI governance policy)
6. Implement content filtering appropriate for Saudi regulatory environment (no generation of content prohibited under Saudi Communications and Media Commission guidelines)

Allam represents a genuine competitive advantage for applications serving Arabic-speaking users, and its alignment with Saudi government systems makes it the default choice for any Vision 2030-aligned technology product.

Monitoring and Observability for Allam in Production

Running Allam in production requires the same observability infrastructure as any production LLM deployment, with a few Arabic-specific additions.

Latency Tracking

Track the following latency percentiles per request: p50, p90, p99, and p999. Arabic generation can be slower than English generation per token due to the morphological complexity of Arabic words — a single Arabic word can correspond to multiple English words, and the model may spend more computation on word-level coherence. Establish baselines during load testing before go-live.

Quality Monitoring

Arabic output quality is harder to monitor automatically than English output because most standard text quality classifiers are not trained on Arabic. Practical approaches:

1. Automated keyword filtering: Maintain a list of required concepts that should appear in Arabic responses for specific query types. Absence of expected Arabic keywords signals model degradation.
2. Human-in-the-loop sampling: Route 1–3% of production traffic to human Arabic reviewers for quality scoring. This is particularly important during the first 60 days of a new deployment or after any model version update.
3. Cross-language comparison: For high-stakes responses, optionally generate an English translation via a secondary model and apply English-language quality classifiers to the translated output.

Rate Limit and Cost Monitoring

On the SDAIA managed API, rate limits are enforced per API key. Set up alerting at 80% of daily token budget to avoid unexpected throttling. Monitor cost per active user metric weekly — Arabic morphological complexity can cause token counts to vary significantly across user types (a highly literate MSA writer generates fewer tokens than a Gulf dialect user typing the same semantic content, due to vocabulary differences).

When to Use Allam vs. When to Layer Models

Allam is not always the right model for every component of an Arabic application. A practical model selection guide:

The most robust production architectures use Allam as the default Arabic model with a routing layer that escalates to GPT-4o or Claude for queries requiring exceptional reasoning depth or non-Arabic content. This hybrid approach provides 80–90% cost savings versus running all traffic through premium international APIs, while maintaining quality across the full distribution of user queries.