VARANASI

Compare compute costs and identify potential savings with transparent calculations.
One platform for AI workload reliability and cost optimization.
Detect configuration errors and GPU memory risks before deployment.
Investigate failures using technical evidence and NVIDIA-assisted analysis.
AI assists diagnosis. Deterministic engineering verifies the outcome.
Review proposed fixes, approve changes, and verify the results
Track validation results, cost estimates, evidence, and unresolved risks.
Every cost comparison comes with explicit assumptions and pricing sources
Combining deterministic checks, evidence-backed diagnosis, and human oversight.
Catch failures. Protect compute. Protect margins.

Inspiration

AI workloads can waste money when preventable configuration errors, dependency conflicts, or model-integration failures cause runs to fail. Even when workloads execute successfully, inefficient resource allocation and unsuitable model choices can increase operating costs.

We wanted to address both sides of this problem: preventing avoidable technical failures and improving the economics of running AI.

That led us to VARANASI, an engineering-first platform designed to validate workloads before launch, investigate failures using technical evidence, and compare deployment costs under explicit constraints. Our guiding principle is simple: verify before spending, measure before optimizing, and never trust a recommendation without evidence.

What it does

VARANASI combines two connected capabilities:

GPU RunGuard: Inspects supported workload configurations, checks dependencies and model-integration requirements, identifies known failure conditions, and validates proposed corrections through repeatable tests.
FinOps Engine: Estimates GPU and model-inference costs, compares feasible deployment alternatives, and identifies potential cost reductions while respecting resource, performance, and budget constraints.

The system uses deterministic rules for validation and financial calculations. NVIDIA Nemotron assists with ambiguous technical diagnosis, while Tavily retrieves relevant current documentation and public technical information.

Both workflows produce a shared Run & Cost Passport containing evidence, validation results, cost estimates, assumptions, proposed changes, and unresolved risks. Human approval remains essential before applying changes or making final deployment and pricing decisions.

How we built it

We designed VARANASI around a modular architecture with a developer-facing dashboard, a backend API, deterministic validation logic, a cost-calculation engine, and an auditable reporting layer.

Nebius Token Factory provides the intended runtime integration for an eligible NVIDIA Nemotron open-source model. Tavily supports live retrieval of relevant technical sources. Our deterministic components handle configuration checks, cost arithmetic, rule enforcement, and test-result evaluation independently of the language model.

The proposed workflow follows four stages: inspect and preflight, diagnose and investigate, correct and optimize, and verify and report. Proposed patches require developer approval, and supported tests must be rerun before a correction is marked successful.

We are keeping the initial implementation focused on a limited set of reproducible failure scenarios and cost-comparison cases so that the final demonstration can show actual results rather than simulated success.

Challenges we ran into

One of our main design challenges is combining technical reliability and financial optimization without making the system unnecessarily complicated. A workload may pass basic configuration checks and still fail at runtime, while a cheaper deployment configuration may not satisfy its memory, latency, throughput, or quality requirements.

Another challenge is separating reliable facts from estimates. GPU memory requirements may depend on runtime behavior, public prices can change, and retrieved documentation may not describe every deployment condition.

Our approach is to combine deterministic checks with evidence-backed diagnosis, clearly identify assumptions, and distinguish PASS, FAIL, and UNKNOWN results. We also designed the repair workflow to require human approval and controlled testing rather than allowing an AI model to modify critical configurations unchecked.

Accomplishments that we're proud of

We are proud of bringing two important engineering concerns into one coherent design: preventing avoidable AI workload failures and understanding deployment costs before committing resources.

Our most important design decision is to keep validation and financial calculations deterministic while using AI only where contextual reasoning can help. We also defined the Run & Cost Passport as a shared record of evidence, proposed changes, cost assumptions, and verification results.

Rather than relying on impressive claims or arbitrary savings percentages, we want our demonstration to establish what the system actually detects, what it successfully verifies, and what remains uncertain.

What we learned

Developing VARANASI has reinforced an important engineering principle: AI should assist a system, not become its single point of failure.

Configuration validation, financial calculations, budget limits, and test-result evaluation are better handled by predictable, independently testable software. Language models are useful for interpreting ambiguous errors and proposing possible explanations, but their recommendations still need evidence and verification.

We also learned that meaningful cost optimization requires more than choosing the cheapest available resource. A useful recommendation must account for workload requirements, applicable pricing, performance constraints, and the assumptions behind the comparison.

What's next for VARANASI

Our next milestone is to demonstrate a complete, reproducible workflow using a supported AI workload: detect a known failure, investigate it using relevant technical evidence, propose a minimal correction, and verify the result through independent tests.

We also plan to evaluate the FinOps Engine using documented prices and comparable workload assumptions, then report estimated savings without presenting projections as realized results.

Future development could expand the range of supported configurations, introduce additional regression tests, improve deployment-cost comparisons, and generate more detailed diagnostic reports. We also want to explore how consented, sanitized failure categories could help identify recurring developer onboarding and documentation issues.

Our long-term vision is to help teams make AI deployments more reliable, transparent, and economically sustainable.

Inspiration

AI workloads can waste money when preventable configuration errors, dependency conflicts, insufficient GPU memory, permission problems, or model-integration failures cause runs to fail. Even when workloads execute successfully, inefficient resource allocation and unsuitable model choices can increase operating costs.

We started with a simple question:

What if developers could validate an AI workload, investigate its failures, and estimate its operating cost before committing to an expensive deployment?

That question inspired VARANASI — Autonomous GPU RunGuard & FinOps Margin Engine. Our goal is to combine two important engineering concerns: reliable AI workload deployment and cost-aware resource utilization.

Instead of relying entirely on AI to make critical decisions, VARANASI is designed around deterministic validation, explicit constraints, transparent cost calculations, technical evidence, and AI-assisted diagnosis.

Our guiding principle is simple: verify before spending, measure before optimizing, and never trust a recommendation without evidence.

What it does

VARANASI combines two connected capabilities into one developer-oriented platform.

1. GPU RunGuard

GPU RunGuard is designed to inspect supported workload configurations, identify known failure conditions, and validate proposed corrections before deployment.

It examines inputs such as Dockerfiles, Python dependency files, runtime settings, model configurations, resource requests, and diagnostic logs. Deterministic checks identify known configuration problems, dependency constraints, missing settings, and model/API integration issues.

Where sufficient information is available, the system can estimate GPU memory requirements and compare them with declared resource limits. Estimates are distinguished from actual measurements, and tests that require real inference or GPU execution are identified separately.

2. FinOps Engine

The FinOps Engine is designed to estimate GPU and model-inference costs, compare feasible deployment alternatives, and identify opportunities to improve workload economics.

It uses explicit inputs such as applicable published prices, GPU quantities, expected runtime, token usage, and workload requirements. It can compare alternative configurations only when the available evidence supports the comparison.

The objective is not simply to select the cheapest resource. It is to identify a configuration that meets the workload's correctness, memory, latency, throughput, and budget requirements while potentially reducing costs.

3. Run & Cost Passport

Both capabilities contribute to a shared Run & Cost Passport containing technical findings, evidence links, proposed changes, validation results, cost estimates, calculation assumptions, and unresolved risks.

Every check is reported as PASS, FAIL, or UNKNOWN as appropriate. Untested behavior is not presented as verified.

How we built it

We designed VARANASI around a modular architecture that separates deterministic engineering from AI-assisted reasoning.

System architecture

Nebius Token Factory: Provides the intended runtime inference integration for a compatible NVIDIA open-source model.

NVIDIA Nemotron: Assists with interpreting ambiguous errors, examining technical evidence, and proposing possible explanations or corrections.

Tavily Search API: Retrieves relevant current technical documentation and public troubleshooting information.

Deterministic validation engine: Handles configuration checks, rule enforcement, supported compatibility checks, and test-result evaluation.

FinOps calculation engine: Performs cost calculations and compares deployment alternatives using explicit inputs and documented assumptions.

Controlled test runner: Executes supported validation and regression tests in a restricted environment.

Run & Cost Passport: Presents the results in an auditable report that developers can inspect and reproduce.

Four-stage workflow

Inspect and preflight: Analyze workload inputs and perform low-cost deterministic checks before expensive execution wherever possible.
Diagnose and investigate: Combine observed failures with relevant technical sources, using Nemotron to assist with ambiguous cases.
Correct and optimize: Generate a reviewable patch and compare feasible deployment-cost alternatives. Changes require developer approval.
Verify and report: Rerun relevant tests, record observed results, and generate the Run & Cost Passport.

We intend to demonstrate this workflow with a small set of reproducible failure scenarios rather than claim support for every GPU, framework, model, or deployment environment.

Our implementation and final demonstration will distinguish features that are operational from those that remain planned or unsupported.

Challenges we ran into

One of the main challenges is that an error message rarely provides the complete explanation. A failure may originate in application code, configuration, dependencies, permissions, resource limits, API assumptions, or runtime behavior.

Another challenge is separating technical feasibility from financial optimization. A smaller GPU instance or a less expensive model can reduce estimated costs but may fail to meet memory, throughput, latency, or output-quality requirements.

We also need to avoid making cost comparisons using outdated prices, unsupported assumptions, or incomplete usage information.

Our design addresses these challenges by separating deterministic checks from model-generated recommendations, requiring evidence for important findings, and recording the assumptions behind each calculation.

Proposed code and configuration changes are intended to remain reviewable, with developer approval before application. The verification engine—not the language model—must determine whether a supported test actually passed.

We recognize that static analysis cannot guarantee production reliability, public documentation may not cover every runtime condition, and a successful smoke test cannot prove that every workload will perform correctly under all operating conditions.

Accomplishments that we're proud of

We are proud of defining a unified approach to two related engineering concerns: preventing avoidable AI workload failures and understanding deployment costs before committing resources.

A key design achievement is the separation of responsibilities. Deterministic software handles calculations, constraints, supported validation rules, and test outcomes, while AI assists with ambiguous technical interpretation.

We have also established the Run & Cost Passport as the central reporting concept. Rather than presenting a generic AI-generated answer, the report is intended to connect findings with evidence, proposed changes, cost assumptions, and verification results.

Our planned evaluation focuses on measurable outcomes: detecting known failure conditions, identifying the correct cause, validating corrections, estimating costs accurately under stated assumptions, and avoiding false claims of successful resolution.

We will report actual implementation progress and measured test results in the final submission. We will not present projected savings, untested features, or planned integrations as completed achievements.

What we learned

The design of VARANASI reinforces an important engineering principle: AI should support a system, not become its single point of failure.

Configuration validation, financial arithmetic, budget constraints, and test-result evaluation benefit from predictable, independently testable software. Language models can help interpret ambiguous evidence and propose explanations, but their outputs require validation.

We also learned that meaningful cost optimization requires more than choosing the cheapest resource. Recommendations must account for workload requirements, applicable pricing, resource availability, performance constraints, and the assumptions behind each comparison.

Another important lesson is that uncertainty should be visible. If a feature has not been tested, the system should say so. If a price or resource requirement is estimated, the report should identify it as an estimate.

This approach is intended to make VARANASI more transparent, maintainable, and useful than a system that relies on confident but unverified AI recommendations.

What's next for VARANASI

Our next milestone is to demonstrate a complete, reproducible workflow using a supported AI workload: detect a known failure, investigate it using relevant technical evidence, propose a minimal correction, and verify the result through independent tests.

We also plan to evaluate the FinOps Engine using documented prices and comparable workload assumptions, then report estimated savings without presenting projections as realized results.

Future development could expand the range of supported configurations, introduce additional regression tests, improve deployment-cost comparisons, and generate more detailed diagnostic reports. We also want to explore how consented, sanitized failure categories could help identify recurring developer onboarding and documentation issues.

Our long-term vision is to help teams make AI deployments more reliable, transparent, and economically sustainable.

Measuring potential cost savings

For a GPU-backed workload, estimated cost can be represented as:

$$ C_{\mathrm{GPU}} = \sum_i N_i H_i P_i + C_{\mathrm{other}} $$

Here, (N_i) is the number of GPUs of type (i), (H_i) is expected billed runtime, (P_i) is the applicable GPU-hour price, and (C_{\mathrm{other}}) represents other included costs.

For API-based model inference, an illustrative cost calculation is:

$$ C_{\mathrm{API}} = \frac{T_{\mathrm{in}}R_{\mathrm{in}}}{10^6} + \frac{T_{\mathrm{out}}R_{\mathrm{out}}}{10^6} $$

Here, (T_{\mathrm{in}}) and (T_{\mathrm{out}}) represent token counts, while (R_{\mathrm{in}}) and (R_{\mathrm{out}}) represent the applicable rates per million tokens. The actual billing units and pricing terms must be verified for the selected service.

Estimated cost reduction is calculated as:

$$ \Delta C = C_{\mathrm{baseline}} - C_{\mathrm{candidate}} $$

A positive result indicates a potential cost reduction under the specified assumptions. It does not prove realized savings until the alternative has been evaluated under comparable conditions.