Our Riyadh deployments follow a pattern refined across multiple Saudi engagements. Phase 1 — Infrastructure assessment (week 1-2): we evaluate whether the client's existing data center can support GPU workloads. Most Saudi enterprise data centers (Mobily, STC, Elm-operated facilities) have adequate power and cooling for modest GPU additions — a 4×A100 node draws 6.5kW, well within standard rack allocations. For larger clusters (8×H100 or multi-node), we assess power density (H100 nodes need 10.2kW per server), cooling capacity (GPU clusters generate significant thermal load), and network bandwidth (NVLink for intra-node, InfiniBand for inter-node). Where existing infrastructure is insufficient, we evaluate KSA-region cloud options: STC Cloud (Saudi-sovereign, NDMO-compliant by default), AWS via Bahrain (closest hyperscaler region, 15ms latency to Riyadh), Azure UAE (Dubai-based, adequate for non-government workloads), and Oracle Cloud Jeddah (OCI has strong GPU availability). For truly air-gapped environments — common in government and defense — we deploy fully offline model serving with vLLM or TGI on bare metal, with no network interface cards connected to external networks. Phase 2 — Model selection and benchmarking (weeks 2-4): this phase is critical and where most DIY deployments fail. We benchmark open-weight models against the client's actual data and use cases, not synthetic benchmarks. Our standard evaluation matrix tests: Jais 13B and 30B (by G42 — purpose-built for Arabic, outperforms multilingual models on Arabic text classification and generation by 15-20% in our testing), Llama 3 8B and 70B (strong multilingual capability, excellent for bilingual Arabic-English), Mistral 7B and Mixtral 8×7B (best inference speed for given quality — Mixtral's MoE architecture keeps costs low), Command R+ (strongest for RAG workloads — built-in citation and grounding), and Qwen 2.5 (strong Arabic and multilingual, competitive with larger models at smaller parameter counts). We test on 500+ representative samples from the client's actual data — measuring accuracy, latency, throughput, and cost per inference. Phase 3 — Deployment and optimization (weeks 4-8): the production deployment stack includes model serving (vLLM for throughput-optimized LLM serving, NVIDIA Triton for multi-model serving including both LLMs and traditional ML models), model optimization (GPTQ or AWQ quantization reducing model size 4× with minimal quality loss, KV cache optimization for long-context workloads, continuous batching for throughput maximization), orchestration (Kubernetes with GPU scheduling via NVIDIA GPU Operator, auto-scaling based on request queue depth, graceful model loading and unloading), security (TLS encryption for all inference traffic, RBAC with per-model access controls, audit logging of every inference request with request hash and user identity — critical for NDMO compliance), and monitoring (custom Grafana dashboards tracking latency percentiles P50/P95/P99, GPU utilization and memory consumption, token throughput and queue depth, model output quality metrics using automated evaluation). Phase 4 — Knowledge transfer and handoff (weeks 8-10): we train the client's team on model operations — how to update models, tune parameters, diagnose performance issues, and extend the system with new use cases. We provide runbooks for common scenarios: model update procedures, GPU failure recovery, capacity planning guidelines, and escalation paths. For clients requiring ongoing support, we offer managed operations at a monthly retainer.