Omniscient Compute

Overview#

Modern AI workloads no longer fit inside one cloud. GPU capacity lives on neoclouds, sovereign regions hold regulated data, hyperscalers carry the bulk of supporting services, and regional operators frequently undercut the headline rate on specific SKUs. No single vendor sells the right combination at the right price in the right region, and no procurement team can hold tens of thousands of SKUs across twenty-five providers in their head. Omniscient Compute is the surface Yobitel built to make that problem tractable.

Omniscient Compute is a vendor-neutral compute search engine, operated end-to-end by Yobitel. The customer opens the marketplace, narrows the search by GPU family, region, term type, sovereignty pin, and price ceiling, and gets back a ranked list of providers and SKUs. Every result is annotated with a Composite Value Score — a single number that fuses benchmark quality, throughput, and dollar-per-token from InferenceBench so customers can compare a tier-1 hyperscaler quote against a sovereign neocloud quote in the same view. Pricing is refreshed every six hours.

Compared with manual cross-provider procurement — calling each vendor's pricing API, normalising units and currencies by hand, then cross-referencing each provider's compliance posture against a sovereignty requirement — Omniscient consolidates the question into one query. Compared with single-cloud FinOps tools, Omniscient is genuinely multi-provider; compared with bespoke in-house comparison tooling, Omniscient carries Yobitel's compliance metadata model and a FOCUS-aligned billing export.

Omniscient sits at the layer below Yobibyte in the Yobitel stack. Yobibyte calls Omniscient internally at admission and reconciliation, so every Inference and FineTune placement decision is grounded in current capacity and pricing. FinOps teams, platform teams, and procurement teams use Omniscient directly without ever adopting Yobibyte. Yobitel Communications, the UK-headquartered AI infrastructure company that operates Omniscient, indexes its own NeoCloud capacity alongside every other provider without preferential ranking.

Quick start#

The customer experience for getting a price-ranked, sovereignty-checked compute shortlist out of Omniscient takes minutes and no command-line setup. Sign in to the Yobitel console with your corporate identity provider, open the Omniscient marketplace at omniscient.yobitel.com (or under Marketplace in the main console navigation), and use the filter rail on the left to narrow the search. The standard filters are GPU family, region, term type, sovereignty pin, and price ceiling; the search runs against pricing data refreshed in the last six hours.

Results land as a ranked list. Every row shows the provider, the SKU, the per-GPU effective rate in USD, the term type, the sovereignty tags the SKU carries, and the Composite Value Score sourced from InferenceBench so a tier-1 hyperscaler quote is directly comparable to a sovereign neocloud quote. Click a row to open the per-provider detail panel — the panel shows the full price breakdown, the compliance posture, the freshness window, and the provisioning hand-off.

From the detail panel the customer either provisions directly through Yobitel (where the provider supports it) or copies the procurement detail for offline purchase. Search itself is free and unlimited; the value Omniscient bills for is the consolidated price stream and the FOCUS-aligned billing export that lands hourly in the customer's own object storage.

Surfaces and access modes#

Omniscient is reachable through several customer-facing surfaces. The Marketplace UI and the FOCUS billing export are live today; the CLI, the language SDKs, and the REST API are in active development and will be released into early access. The table below is honest about the status of each surface.

# PREVIEW — the omniscient CLI is in active development; the snippet
# below is the planned shape and will NOT run today. Sign up at
# /products/omniscient-compute to be notified when the CLI ships.

# omniscient login                                # one-time, like `aws configure`
# omniscient search compute \
#     --gpu h100 \
#     --region uk \
#     --term reserved-1y \
#     --compliance ncsc-official \
#     --max-price 1.80 \
#     --output table

Concepts#

Omniscient exposes a small set of concepts that map to how customers think about cross-provider compute. The mental model is provider at the top, with SKUs and regions inside, term types governing pricing, and compliance plus sovereignty tags governing what a regulated workload can see.

• Provider — a single source of compute capacity, classified by tier: hyperscaler (AWS, Microsoft Azure, Google Cloud, Oracle Cloud), neocloud (CoreWeave, Lambda, Crusoe, Yobitel NeoCloud, Scaleway), regional (Equinix Metal, Vultr, DigitalOcean, Hetzner, Latitude.sh), sovereign (UKCloud, Civo, regulated-region operators), and community (Akash, io.net, Render Network, Salad Cloud).
• SKU — a specific accelerator configuration. AWS calls it `p5.48xlarge`, GCP calls it `a3-highgpu-8g`, Azure calls it `Standard_ND96isr_H100_v5`. Omniscient surfaces all of them against the same underlying accelerator family so customers can compare like-for-like.
• Region — a geographic placement with a sovereignty tag attached. Omniscient indexes every public region from every indexed provider; sovereignty filters are applied per region.
• Term — how the capacity is purchased. On-demand, spot, reserved 1-year, reserved 3-year, or savings plan. Term influences the effective price and the discount-amortisation calculation that drives the Composite Value Score.
• Compliance Tag — the regulatory posture of a SKU. The current set includes NCSC OFFICIAL (UK), EU Data Boundary, FedRAMP-equivalent (US), HIPAA-eligible, ISO 27001-certified, SOC 2 Type II attested, and DORA-aligned. A workload pinned to a tag never sees non-eligible capacity.
• Composite Value Score — a single rank combining benchmark quality, throughput, and dollar-per-token. Inputs come directly from InferenceBench so the same model and accelerator combination has the same ranking across the index.
• Freshness Window — the maximum age of the price a customer is looking at. Pricing refreshes on a six-hour cadence; the freshness window is shown on every result row so customers can tell at a glance how recent the number is.
• Topology — the interconnect tier the workload requires. NVLink-fabric (all-units inside one 8-GPU node), InfiniBand-rack (units inside one rack, typical for distributed training), Ethernet-DC (units inside one data centre, tolerating ~10 microsecond extra hop), WAN (units across regions, latency-tolerant batch and serving). Omniscient ranks results by topology fit; if no provider in the indexed catalogue can satisfy the request at the strictest tier, the search returns next-best matches with the gap surfaced explicitly.
• Placement Profile — how the customer wants the result spread across the catalogue. `single-provider` packs the whole request on one provider for simplest billing and gang scheduling. `multi-provider-blend` spreads across two or three providers to combine reservation baselines with opportunistic spot. `multi-region` spans two or more regions for DR or latency-distributed serving, with the sovereignty boundary preserved per region. The profile drives ranking weights and the shape of the returned plan.

Distributed and multi-provider placement#

Most production AI workloads are not single-node. Training a 70B model needs 64 to 512 nodes wired with InfiniBand or NVLink Switch. Production inference often spreads across 2-4 regions for DR. Omniscient supports the search side of those workloads natively, with multi-node, multi-provider, and multi-region placement profiles as first-class filters.

The scope split is intentional and honest: Omniscient finds and ranks the capacity. Yobibyte (or the customer's own orchestrator such as KubeRay, Slurm, or a managed training service) actually runs the distributed workload. The two layers are decoupled — search and match in Omniscient, schedule and run in Yobibyte.

A common request is a 64-node H100 cluster for a 3-week training run. One sovereign neocloud may only have 32 nodes in the customer's region; one regional provider has 24; a hyperscaler has spot capacity for the remainder. The `multi-provider-blend` placement profile returns a plan that satisfies the 64 nodes from the three providers, preserving the sovereignty pin per node and surfacing the blended effective price.

Results are ranked not only by Composite Value Score but also by how strictly the requested topology is satisfied. A 32-node IB-rack request that fits inside one rack ranks above one that spans two racks at a higher Composite Value Score, because rack-spanning materially changes NCCL latency for collective communications.

• Cluster sizes searchable from 1 up to 2,048 nodes.
• Interconnect tiers ranked: NVLink-fabric > InfiniBand-rack > InfiniBand-row > Ethernet-DC > WAN.
• Placement profiles supported: single-provider (default), multi-provider-blend, multi-region.
• Gang availability filter: `--gang` returns only plans where the full cluster is provisionable at once, never partial.

# PREVIEW - Omniscient CLI is in active development; this is the planned shape.
# 64-node H100 cluster, single provider, InfiniBand rack, 3-year reserved, UK sovereign:
# omniscient search compute \
#     --gpu h100 \
#     --min-nodes 64 \
#     --interconnect ib-rack \
#     --placement single-provider \
#     --region uk \
#     --term reserved-3y \
#     --compliance ncsc-official \
#     --gang \
#     --max-price 1.95 \
#     --output table
#
# Same workload blended across providers when no single provider has 64:
# omniscient search compute --gpu h100 --min-nodes 64 --interconnect ib-rack \
#     --placement multi-provider-blend --region uk --term reserved-3y \
#     --compliance ncsc-official --gang --max-price 2.10 --output plan

Search query reference#

The customer-facing filter set is the same in the Marketplace UI and the Preview CLI / SDK / REST surfaces. The table below lists the filters customers use; all filters are optional and combine with AND semantics.

Provider coverage#

Omniscient indexes more than 25 providers across five tiers. The table below summarises what the customer can expect by tier — representative providers, SKU coverage, and the regions covered. Every tier refreshes on the same six-hour cadence; the cadence is identical regardless of provider class, so a hyperscaler quote and a sovereign neocloud quote share the same freshness window.

Limits and quotas#

Limits are split into two groups: limits that apply to the live Marketplace UI and FOCUS export today, and limits that will apply to the Preview CLI, SDKs, and REST API once they reach early access. Both sets are raisable on request.

Observability#

Omniscient surfaces freshness, coverage, and availability as first-class signals so customers can tell at a glance whether a result they are looking at is current. Inside the Marketplace UI, every result row carries a per-provider freshness timestamp showing when the price was last refreshed; the workspace-level dashboard shows the last successful refresh per provider and surfaces any indexed region that has gone missing.

Customers running Yobibyte alongside Omniscient see the same signals propagated through Yobibyte's hosted Grafana — freshness lag per provider, missing-region alerts, and last-crawl timestamps. The alert below is the one most teams add first; it pages when a provider's pricing has drifted more than 24 hours stale, which is the threshold at which spend forecasts start to disagree with the real bill.

groups:
- name: omniscient-freshness
  interval: 60s
  rules:
  - alert: OmniscientProviderPriceStale
    expr: |
      (
        time()
        - omniscient_provider_pricing_last_refresh_seconds
      ) > 86400
    for: 15m
    labels: { severity: page }
    annotations:
      summary: "{{ $labels.provider }} pricing > 24h stale"
      runbook: https://docs.yobitel.com/runbooks/omniscient-freshness

  - alert: OmniscientSovereignCapacityEmpty
    expr: omniscient_search_zero_results_total{compliance="ncsc-official"} > 0
    for: 30m
    labels: { severity: warn }
    annotations:
      summary: "NCSC-OFFICIAL searches returning zero results for {{ $labels.gpu }}"

Cost and FinOps#

Search itself is free. What Omniscient bills for is the value downstream of search: the consolidated price stream and the FOCUS 1.1-aligned billing export that lets customers reconcile cross-provider spend against the same schema. The export is hourly, lands directly in the customer's S3, Azure Blob, or GCS bucket, and carries every column the FOCUS specification requires.

The columns below are the FOCUS fields Omniscient populates on every line item. Downstream tooling — Cloudability, Apptio, Vantage, or a customer-built BigQuery or Snowflake lakehouse — consumes the export against the FOCUS schema without bespoke transformation.

Security and compliance#

Compliance posture is a first-class attribute of every SKU in the index. The customer pins a workload to a compliance tag, and Omniscient guarantees that non-eligible capacity never appears in the result set; a downstream provisioning hand-off cannot mix eligible and non-eligible SKUs. The tag set is published, versioned, and surfaced on every result row.

Sub-processor transparency is part of the same surface. Each indexed provider has a sub-processor manifest published and tracked by Omniscient; changes are versioned and surfaced via the workspace alert channel so customers with regulatory notification obligations can satisfy them mechanically. Customer-controlled audit-log streaming sends every search, every export delivery, and every provisioning hand-off to a customer-owned destination (S3, Azure Blob, GCS, or a syslog endpoint).

• NCSC Cloud Security Principles — per-SKU mapping; UK OFFICIAL-tier regions filtered at index time.
• G-Cloud framework — listed under Cloud Software (Lot 2) and Cloud Support (Lot 3).
• EU Data Boundary — every result tagged eu-data-boundary is restricted to EU capacity at search time.
• GDPR and UK DPA 2018 — per-provider sub-processor lists; standard DPA template provided.
• FedRAMP-equivalent — Moderate-baseline-aligned controls surfaced via partner regions in the US.
• HIPAA — BAA-eligible SKUs labelled at the result row for healthcare workloads.
• ISO 27001:2022, ISO 27017, ISO 27018 — per-provider attestations attached to each SKU.
• SOC 2 Type II — current attestations available under NDA per provider.
• Sub-processor transparency — versioned manifests, workspace-channel notifications on change.
• Customer-controlled audit-log streaming — every search, export, and provisioning event delivered to a customer-owned destination.

Migration and alternatives#

Most teams reach Omniscient after a single-cloud deployment outgrows the bill, or after a manual cross-cloud price comparison breaks down at scale. The comparison table below sets the alternatives the customer is realistically weighing; the code block underneath shows the manual incumbent workflow that Omniscient consolidates. The code is honest about what the customer does today — calling each provider's pricing API individually and reconciling the shapes by hand — and the bullet at the end of the section sets out why that manual workflow is the thing Omniscient replaces.

# Manual incumbent workflow — what cross-provider compute procurement
# looks like today without Omniscient. Each provider exposes a different
# pricing API with a different shape; results have to be reconciled by hand.

# 1. AWS — reserved-instance price for p5.48xlarge (8x H100 SXM5) in London
aws pricing get-products --service-code AmazonEC2 --region us-east-1 \
  --filters 'Type=TERM_MATCH,Field=instanceType,Value=p5.48xlarge' \
            'Type=TERM_MATCH,Field=location,Value=Europe (London)' \
  --query 'PriceList[0]' --output text | jq '.terms.Reserved'

# 2. AWS — current spot price history
aws ec2 describe-spot-price-history \
  --instance-types p5.48xlarge \
  --availability-zone eu-west-2a \
  --product-descriptions "Linux/UNIX" \
  --max-results 5 --output table

# 3. Azure — ND-H100-v5 retail prices in uksouth (anonymous API)
curl -s "https://prices.azure.com/api/retail/prices?\$filter=serviceName%20eq%20'Virtual%20Machines'%20and%20armRegionName%20eq%20'uksouth'%20and%20contains(skuName,%20'ND')" \
  | jq '.Items[] | {skuName, retailPrice, reservationTerm}'

# 4. GCP — a3-highgpu-8g SKU pricing via Cloud Billing Catalog API
curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://cloudbilling.googleapis.com/v1/services/6F81-5844-456A/skus?pageSize=200" \
  | jq '.skus[] | select(.description | contains("A3"))'

# 5. CoreWeave / OVHcloud / sovereign UK — no structured public API; scrape or
#    request a partner price feed and rebuild the comparison spreadsheet.

# Each of the above returns a different shape, in a different unit. Provider
# quotes that arrive in non-USD must be normalised to USD by hand before the
# comparison is meaningful. Omniscient Compute consolidates every step of this
# workflow into one ranked query against a canonical SKU schema.

Troubleshooting#

The errors below cover the failure modes seen most often during onboarding and the first weeks of running searches against Omniscient. Each row is the Omniscient-shaped error code, the cause the customer most commonly hits it for, and the customer-facing fix. The full runbook library is at docs.yobitel.com/runbooks.

Where Omniscient Compute fits in the Yobitel stack#

Omniscient is the layer below Yobibyte in the Yobitel stack. Yobibyte calls Omniscient at admission and reconciliation time, so every Inference, FineTune, and AIApplication placement decision is grounded in current capacity and pricing — a workload Yobibyte schedules has, by construction, been priced and sovereignty-checked against the live Omniscient index. InferenceBench supplies the benchmark and economics data that drives the Composite Value Score so the ranking a customer sees in the Marketplace UI is the same ranking Yobibyte uses internally.

The Yobitel AI Applications suite — MediQuery and the rest of the vertical applications — sits on top of Yobibyte and consumes Omniscient indirectly through it. Yobitel NeoCloud is itself one node in the Omniscient index without preferential ranking; if a customer's workload is better served on a competing neocloud or hyperscaler, that is what Omniscient returns.

Practically, the question 'which compute should this workload run on?' is the same question whether asked by a FinOps team in a procurement meeting, by a platform team scripting a CI hand-off, or by Yobibyte's admission webhook. Omniscient is the answer surface for that question across all three contexts. FinOps and platform teams reach Omniscient directly through the Marketplace UI today, and through the CLI, SDKs, and REST API when those surfaces leave Preview.

Distributed workloads reach Omniscient in one of two ways. Customers using Yobibyte get Omniscient placement decisions automatically: when a Yobibyte `Inference` or `FineTune` declares a multi-node requirement, Yobibyte queries Omniscient for the cluster plan at admission time and the resulting placement carries through to the data plane. Customers running their own orchestrators (KubeRay, Slurm, in-house) reach Omniscient directly through the Marketplace UI today and through the CLI, SDK, or REST API once those Preview surfaces are GA. Either path returns the same plan, ranked the same way, against the same indexed catalogue.