India-hosted 70B-class open-weight AI with enterprise RAG, dedicated inference and optional Gravitas ETRM integration — designed for trading, risk, governance and regulated workloads.
No payment · No order · Capacity-planning waitlist
This is a capacity-planning waitlist, not a live service. Infrastructure has not yet been fully provisioned, pricing is indicative, no payment is collected and registration is not an order. There is no committed launch date. Demand from this list determines what capacity gets built and in what order.
We would rather say this at the top of the page than have it surface at contract stage. If you have a real workload, registering shapes what we provision. If you are browsing, nothing here asks you to commit.
For most enterprises the blocker is not model quality. It is that the questions worth asking involve information the organisation is not willing, or not permitted, to send outside its own boundary.
Trades, positions, forward curves, counterparty details, contracts, confirmations, risk reports, regulatory correspondence and internal policy. A model that cannot see these is limited to generic answers. A public endpoint that can see them creates an exposure that legal, risk and compliance teams must assess and approve.
Pilots stall at review. Teams route around the problem with redaction that removes the context the model needed, or the project is quietly shelved. Private infrastructure changes the control boundary, allowing the organisation to address the risk within an environment it can govern directly.
Durga Analytics builds ETRM systems and data governance platforms for energy and financial institutions. The confidentiality constraints described here are ones we work inside on client engagements, not ones inferred from a market report.
Access controls, usage visibility, model version management and documented data handling are intended to be part of the environment from the start, because that is what an internal review asks about first.
Inference is designed to run on infrastructure located in India, giving customers a clear primary data-residency model and simplifying deployment discussions around location, latency and cross-border data handling.
Where inference runs is a question every review asks early. A defined primary location makes that a short conversation rather than an open item, and specific residency commitments can be set out contractually for enterprise deployments.
For interactive workloads used by desks and analysts through the working day, round-trip distance is felt. Serving from India shortens that path for India-based teams.
Flat monthly plans in INR rather than per-token billing in a foreign currency, so a budget holder approves a number rather than a forecast that moves with usage and exchange rates.
Isolation is a spectrum, and being precise about it matters more than a reassuring adjective. What you get depends on the tier.
Workloads run on shared managed capacity with logically isolated tenants. Appropriate for prototypes, internal tools and evaluation. Not intended for your most sensitive material.
Reserved inference capacity and private retrieval namespaces, and at the Dedicated tier compute allocated exclusively to one organisation with an isolated model deployment and a private endpoint.
Dedicated physical or virtual infrastructure depending on requirements, including customer-specific networking and on-premises options, defined per deployment.
Not every plan is physically single-tenant, and we will not describe it that way. Where a deployment requires exclusive hardware, that is specified in the contract rather than implied by a tier name.
70B-class open-weight models served behind an OpenAI-compatible API, so existing SDKs, agent frameworks and internal tooling work without a rewrite.
70B-class models can support long-form document reasoning, summarisation, extraction and structured output for many enterprise internal workloads, subject to model selection, evaluation and workload-specific validation. Smaller and larger models can be served depending on the deployment and available capacity.
Open-weight models and an OpenAI-compatible API reduce model-layer lock-in and make migration materially easier. Application integrations you build on top still carry their own switching costs — true of any platform, and worth saying plainly.
For Dedicated and Enterprise deployments, model and version pinning is planned, so a model validated by your risk function does not change underneath a production workload without agreement.
Serving is designed to run across different accelerator generations and vendors, and across owned, colocated, partner or customer infrastructure. You are buying a managed environment, not a bet on one silicon roadmap.
A model is only useful on your material if it can retrieve your material. Document ingestion and retrieval are part of the platform rather than something you assemble yourself.
Contracts, master agreements, confirmations, policies, procedures, regulatory text and internal reference material, processed into a retrievable corpus.
From the Business tier upward, retrieval is intended to run in a namespace private to your organisation, so one customer's corpus is never a source for another's answers.
Retrieval-grounded responses that cite the source document, because an answer a compliance officer cannot trace back to a clause is not usable evidence.
Most AI infrastructure providers have no view on what a confirmation is. We build ETRM platforms, so the intended workloads here are specific rather than illustrative.
This is a human-in-the-loop design. Nothing here executes trades, and nothing is intended to. The model drafts, retrieves and explains; the governed system enforces what is valid; a person decides.
Generic providers sell compute capacity and leave you to build everything between a bare accelerator and a governed enterprise capability. That gap is months of engineering, and it is where most internal AI projects stall.
You buy an operating environment, not a GPU-hour. The intended components around the compute include managed model serving, retrieval and document ingestion, an API gateway, identity and access controls, observability and usage visibility, data isolation, model and version management, backup and recovery, high-memory analytical infrastructure where the workload needs it, optional trading and ETRM integration, and enterprise support.
Raw hardware sizing is a consequence of the workload, not the proposition. Specific GPU, memory and storage configurations are scoped per deployment at the Dedicated and Enterprise tiers.
A layered environment rather than a single service. Which layers are provisioned depends on the plan and the workload.
Architecture varies by plan and workload. Kafka, Spark, ClickHouse and PostgreSQL are components of the Gravitas Trading AI Cloud and Enterprise layers and are not provisioned for every subscription.
Two distinct product layers. The second is not simply an upgrade of the first, and it is worth being clear which one you need.
70B-class inference, API access, RAG, document processing, private model endpoints, multiple API keys, usage controls, reserved inference and dedicated compute where required. A private AI environment for enterprise workloads generally.
Everything above, plus optional Gravitas ETRM integration and the data infrastructure trading workloads need: PostgreSQL, ClickHouse, Kafka and Spark, with portfolio context, positions, market curves, trade lifecycle data, governed reference data, approvals and audit trails inside one private environment.
The distinction is deliberate. A Developer or Team subscription is shared managed inference — it does not include a full analytical data platform, and we will not describe it as though it does.
Confirmation checking, position and exposure queries, curve context, P&L explanation, master agreement search, trade narrative drafting for review.
Regulatory text analysis against internal procedure, policy search, control documentation review, evidence gathering with traceable sources.
Querying governed reference data, glossary and lineage questions, documentation generation, consistency checks across policy and practice.
Internal document Q&A, contract review support, credit and counterparty file summarisation, operational procedure retrieval.
A private 70B API for internal agents and tooling, without routing prompts containing proprietary code or customer data to a public endpoint.
Any workload where the answer depends on confidential material and the organisation needs to state where that material was processed.
These figures exist so early-access registrations tell us something useful about demand at each level. They are indicative, pre-launch, non-binding, and will change as capacity and costs firm up. Nothing on this page is purchasable today.
Developers, experiments and prototypes
Small internal teams
Production internal workloads
Regulated and sensitive workloads
Trading, risk and ETRM workloads
Dedicated nodes and bespoke requirements
All figures are indicative, exclude taxes, and are subject to change before launch. No plan is purchasable today and no payment is collected on this page. Usage limits apply on every tier — no plan is unlimited. A Dedicated tier means compute allocated exclusively to your organisation; whether that is a virtual allocation or dedicated physical hardware depends on the deployment and is defined in the contract, not by the tier name.
Some workloads are defined by their constraints rather than their throughput. Those are scoped as engagements rather than subscriptions.
Compute allocated to one organisation, an isolated model deployment and a private endpoint, with sizing driven by measured workload rather than a tier table.
India-hosted private cloud, colocation, partner data centres, or deployment onto customer on-premises infrastructure where policy requires it. Hybrid arrangements are in scope.
Data handling, residency, availability commitments, recovery objectives and networking arrangements are set out in the contract before production use rather than assumed from a marketing page.
Tell us what you would run and at what scale. This determines how much capacity we provision, which tiers get built first, and who we speak to first. No payment, no order, no obligation.
A pre-launch page is the wrong place for compliance claims. Here is the intended position, stated as intent rather than as an assurance we cannot yet evidence.
Prompts and completions will not be used to train models sold to other customers. Your material is processed to answer your requests, not to improve a product for someone else.
Deployment isolation differs between shared, reserved and dedicated tiers, as set out above. Better that you know which one you are buying than infer it from a reassuring word.
Private networking options are planned from the Business tier upward, with customer-specific arrangements available for enterprise deployments.
Data handling, retention, residency and access will be documented contractually before any production use. We make no certification or regulatory-compliance claims on this page, because none would be evidenced today.
No. Gravitas Private AI Cloud is in early access. Infrastructure has not been fully provisioned and nothing is available to buy. This page collects capacity-planning interest.
No. All figures are indicative and subject to change before launch. Anyone on the early-access list will see confirmed pricing before being asked to commit to anything.
There is no committed launch date, and we would rather say so than invent one. Timing depends on the volume and shape of demand this waitlist surfaces, because that determines what capacity is provisioned and in what order.
Inference is designed to run on infrastructure located in India, giving a clear primary data-residency model. Enterprise deployments can be scoped to specific locations contractually.
No. Developer and Team tiers are designed to use shared managed inference with logically isolated workloads. Dedicated tiers are intended to allocate compute exclusively to one organisation. Enterprise deployments may use dedicated physical or virtual infrastructure depending on requirements.
Compute allocated to one organisation rather than shared, with an isolated model deployment and a private endpoint. Whether that is a virtual allocation or dedicated physical hardware depends on the deployment and is defined in the contract, not implied by the tier name.
Open-weight models, with 70B-class models as the reference point. Smaller and larger models can be served depending on the deployment and available capacity.
Model and version pinning is planned for Dedicated and Enterprise deployments, so a model validated by your risk function does not change underneath a production workload without agreement.
Yes, that is the intended interface, so existing SDKs, agent frameworks and internal tooling work without a rewrite.
Yes. Document ingestion and retrieval are part of the platform. Retrieval scope and isolation vary by plan, with private namespaces intended from the Business tier upward.
No. Prompts and completions will not be used to train models sold to other customers. Data handling will be documented contractually before production use.
The OpenAI-compatible API is the primary integration surface, so most tooling connects without custom work. Deeper integration with enterprise systems is scoped per deployment.
On-premises and hybrid deployment are in scope for Enterprise Private Cloud engagements, sized and priced per customer.
Yes, for Dedicated and Enterprise deployments. The specific configuration is scoped against your workload rather than advertised as a headline specification.
These belong to the Gravitas Trading AI Cloud and Enterprise layers, not to every subscription. Which components are provisioned depends on the deployment and the workload.
Optional integration with Gravitas ETRM is planned as part of the Gravitas Trading AI Cloud tier, giving the model governed access to trade, position and curve context.
Additional capacity is added by moving up a tier or expanding a dedicated allocation. Because capacity is finite and provisioned ahead of demand, expansion timing depends on what is available — which is exactly what this waitlist is intended to inform.
Open-weight models and an OpenAI-compatible API reduce model-layer lock-in and make migration materially easier. Application-level integrations you build still carry their own switching costs, and we would rather set that expectation now.
Nothing. No payment is collected, it is not an order, and you are free to walk away at any point. It places you on the list and informs what capacity gets built.
Register a real workload and you shape what gets built — and see confirmed pricing before anyone else. No payment, no order, no obligation.