← Investor Overview
VajraCloudAI Platform Layer
VajraCloudAI Platform Layer
VajraCloudAI Platform Layer
VajraCore is our name for the AI orchestration and model-serving layer that sits between our bare-metal GPU infrastructure and the compliance applications banks actually use. We do not build this layer from scratch: we plan to license it from a third-party AI infrastructure platform. As of this writing, we have not selected or contracted a vendor: several platforms in this category are under evaluation. This document describes the capabilities we require from that layer and how we expect it to work, not the confirmed specification of any single vendor's product.
VajraCore is the software layer that sits on top of our bare-metal GPU servers and makes running AI models operable without requiring a large in-house infrastructure engineering team. It needs to provide a single, cohesive environment for developing, deploying, and serving AI/ML models: from a data scientist's notebook through to a production API a bank's core banking system calls.
The underlying principle guiding this choice is bringing the AI stack to the data, instead of the other way around. For VajraCloudAI, this means: instead of shipping a bank's sensitive customer data to an offshore cloud to run AI analysis, the AI platform runs on our infrastructure inside Nepal, where the data already sits. This principle holds regardless of which vendor we ultimately license.
Whichever platform we license, we need it to provide four distinct functional layers:
A GPU-backed, browser-accessible notebook environment where data scientists build, fine-tune, and test AI models: a development desk for AI engineers to get a dedicated GPU allocation and write model code without server setup.
Where a bank's AI engineers (or ours) would build and fine-tune KYC/AML models specific to Nepali transaction patterns.
Containerised, independently deployable units of functionality. Each AI capability (identity verification, sanctions screening, AML monitoring) needs to run as a separate, independently scalable service, so the KYC engine can scale independently of the AML engine based on load.
Our three compliance workloads (KYC, sanctions, AML) each deploy as separate services, scalable independently.
Once a model is built and containerised, we need it exposed as a secure REST API endpoint: the interface a bank's core banking system calls to request a KYC assessment. This includes automatic authentication, rate limiting, versioning, and monitoring, so the bank's IT team just calls an HTTPS endpoint with the AI complexity invisible to them.
This is the API the bank's CBS calls when a new customer is onboarded. The bank sees a simple REST endpoint; the platform handles everything behind it.
An object storage system, running on our own infrastructure, for datasets, trained model weights, and batch transaction files: functionally similar to AWS S3, but on-soil.
Nightly transaction batch feeds from bank CBS land here. Data stays inside Nepal: not in an S3 bucket on AWS.
This is the core technical question: when a KYC request comes in, how does the platform route it to the right GPU, and how does it manage multiple simultaneous requests? This is standard territory for AI infrastructure platforms in this category: the specific implementation depends on which vendor we select, but the pattern below is common across serious contenders in this category:
Platforms in this category are typically built on Kubernetes as the container orchestration engine. GPU-backed workloads run as containers, which means GPU allocation, scheduling, health checking, and restart-on-failure are handled natively, with a management layer on top that makes it operable without deep Kubernetes expertise on our side.
A service mesh (commonly Istio or an equivalent) handles load balancing and networking between services. In practice this means: when multiple KYC requests arrive simultaneously, the mesh routes each to the next available GPU, distributes load evenly, and handles retry logic if a service is temporarily unavailable, automatically and without manual configuration.
We need the platform to support both static GPU allocation (a model always has a dedicated GPU) and dynamic allocation (a model gets GPU resources on demand, releasing them when idle). For our banking use case:
The KYC and AML inference engines need a dedicated GPU slice reserved at all times, so there's no warm-up delay when a bank's CBS makes an API call. Response needs to be immediate.
For fine-tuning workloads, the platform should claim GPU resources dynamically and release them when done, so idle GPU time isn't wasted.
Development workspace sessions that sit idle should be automatically culled after a set period, releasing GPU resources back to the pool. This matters for our cost efficiency: GPU resources shouldn't be tied up by an engineer who walked away from their notebook.
For high-performance compute workloads (training or fine-tuning a model across multiple GPUs) we need an orchestration add-on that distributes the job across multiple workers automatically (Ray is the common open-source framework for this pattern), with configurable minimum and maximum worker counts so the cluster auto-scales with queue length.
This is the specific flow for VajraCloudAI's primary use case: a bank's CBS calls our KYC API with a new customer record, and gets a risk assessment back. The steps below describe the pattern we're designing around; exact tooling depends on the vendor selected.
A trained KYC model is packaged into a container using the platform's standard tooling. Platforms in this category typically support multiple model serving frameworks (e.g. BentoML, MLflow). The container is pushed to an internal image registry.
The containerised model is deployed to a specific site (e.g. our WorldLink colocation site) on a selected compute plan. The platform handles pulling the container image, scheduling the workload on an available GPU node, and starting the inference server.
Once deployed, the platform needs to automatically generate a REST API endpoint for the model. The bank's CBS calls this endpoint with the customer data (JSON payload). The endpoint should be authenticated, rate-limited, and versioned.
The model processes the incoming customer record on the GPU allocated to this service. For a typical KYC document verification request (text analysis, field extraction, risk classification), we expect inference time on an NVIDIA L40S or A100 to be under a few seconds, an estimate based on GPU spec and workload type, not yet benchmarked on a selected platform. The result (risk score, recommendation, reasoning) is returned as a JSON response to the bank's CBS.
We need proactive health checks and resource monitoring across the entire AI stack. If the KYC service fails, the orchestration layer should restart it automatically. Performance metrics (request latency, GPU utilisation, error rates) need to be visible in an admin dashboard.
We're structuring our evaluation of VajraCore vendors around these lifecycle phases:
Configure which workloads run at which sites: WorldLink (training hub) vs. Ncell sites (inference spokes). Done once, updated as the platform grows.
Deploy AI inference engines to distributed sites with minimal manual effort. This is the mechanism for our multi-site distributed GPU model.
Enterprise-grade identity management. Bank compliance teams need their own role-based access: they should see results without touching model code or infrastructure.
Deploy AI pipelines through the platform's app catalog and serve inference via its API layer: the two operational interfaces for running production workloads.
Native support for NVIDIA vGPU/MIG partitioning: maximises inference throughput per GPU, directly reducing cost per API call.
Proactive health checks across the entire stack, with an admin view of all running workspaces, services, and APIs.
Simplified updates across AI apps and platform components. Model versions need to update without downtime using rolling deployment.
Alerts need to connect to third-party ticketing systems, so if the KYC service goes down at 2am, it opens a support ticket automatically.
IT should become low-touch and largely automated, so multi-disciplinary teams can collaborate without needing deep infrastructure skills.
We don't want to need a large infrastructure operations team. The platform's automation should handle day-to-day management, freeing our team to focus on the compliance use cases, not on running Kubernetes.
The platform needs to manage composable components with plug-and-play capability, extensible across any AI use case and workload from cloud to edge.
KYC, AML, and sanctions screening are three independent composable components. Adding a new compliance workload (e.g. fraud detection) shouldn't require rebuilding the platform: it should be a new service added to the existing stack.
Fast provisioning on both hyperscalers and bare metal, so the same platform validated in Phase 0 (AWS) carries forward to Phase 1 (bare metal) without re-architecture.
Whichever vendor we select, we want the AWS validation in Phase 0 to directly validate what we then deploy on our Nepal colocation hardware in Phase 1, not a separate build.
The platform needs to auto-scale for both fine-tuning workloads and inference workloads, and support deploying inference engines to additional edge locations with minimal manual effort.
Phase 4 (2MW distributed) needs to be a natural extension of the same platform: adding more sites and more GPU nodes shouldn't require architectural changes, just provisioning additional nodes.
The table below separates what we require from this layer (true regardless of vendor) from figures that are estimates pending vendor selection and benchmarking.
| Capability | Requirement / Current Estimate | Status |
|---|---|---|
| Container orchestration engine | Kubernetes-based (industry standard for this category) | Requirement |
| Service mesh / load balancer | Required for automatic request routing and retry | Requirement |
| Distributed training framework | Ray or equivalent, for multi-GPU fine-tuning jobs | Requirement |
| Model serving frameworks | BentoML, MLflow, or equivalent | Requirement |
| GPU virtualisation support | NVIDIA vGPU / MIG partitioning | Requirement |
| Identity & access management | LDAP + RBAC + policy integration | Requirement |
| Storage backend | Object storage, S3-compatible, on bare metal | Requirement |
| Auto-scaling mechanism | Dynamic GPU allocation; min/max worker scaling | Requirement |
| Idle resource reclaim | Automatic cull after a configurable inactivity window | Requirement |
| Bare metal provisioning time | Target: under 30 minutes | Target, unconfirmed |
| Hyperscaler provisioning time | Target: under 15 minutes | Target, unconfirmed |
| Inference latency for KYC workload | Under a few seconds (our estimate based on GPU spec + workload type) | Our estimate |
| Max concurrent inference requests | Depends on GPU count and selected plan | Pending vendor selection |
| Minimum hardware for bare metal PoC | 3-node cluster (our Phase 1 plan) | Our plan |
| Certified GPU hardware | NVIDIA L40S, A100 (our target hardware) | Our plan |
The following need to be confirmed directly with a specific vendor before finalising architecture decisions or investor commitments. They apply whether we end up licensing any specific platform: