# Amritanshu Jain Sells Inference Without Owning the GPUs

> Simplismart's founder is selling software to application teams and GPU clouds while Nvidia backs the company. The hard test is whether claimed savings survive a customer's own latency, reliability and data-residency requirements.

- Published: 2026-11-02
- Author: Gene Dai
- Canonical: [https://digidai.github.io/2026/11/02/amritanshu-jain-simplismart-inference-software/](https://digidai.github.io/2026/11/02/amritanshu-jain-simplismart-inference-software/)
- Topics: Amritanshu Jain, Simplismart, AI Inference, GPU Economics, AI Infrastructure, Deep Investigation

---

![A broad paper circuit of workload cards passes through a software switch toward several abstract GPU capacity blocks, beneath the words The GPU Bill.](/images/articles/amritanshu-jain-simplismart-inference-software/cover-v1.jpg)

_AI-generated editorial illustration._

On October 27, Amritanshu Jain announced a $14 million Series B for Simplismart, the inference-software company he
co-founded in Bengaluru. Nvidia joined the round. The
[founder's own letter](https://simplismart.ai/blog/nvidia-backs-our-14m-series-b) made a more revealing claim than the
funding total: Simplismart would build software for other people's GPU fleets, not buy a fleet of its own. Jain wants
customers to spend less on running AI models, even though one of his new investors sells the processors on which many of
those models run.

That sounds contradictory only if a GPU-hour is the sole thing being sold. An application company buys a working
service: a model that answers quickly enough, stays available during a spike and keeps data where its contract requires.
A cloud provider buys a way to package idle or committed GPU capacity into a service customers can use. Nvidia sells
chips, but also
[Dynamo software](https://docs.nvidia.com/dynamo/knowledge-base/modular-components/planner/choose-a-planner-mode) for
routing and scaling inference. Jain's company sits among those interests. Its proposed value is to manage the tradeoffs
that no processor alone can resolve.

The financing is a fact reported by
[TechCrunch in a direct interview](https://techcrunch.com/2026/10/27/nvidia-backs-indian-startup-helping-companies-run-ai-models-with-fewer-gpus/).
The savings and growth figures surrounding it need narrower labels. Simplismart says it cut one customer's GPU serving
costs by 56%. An [AWS customer case](https://aws.amazon.com/solutions/case-studies/simplismart-ai-case-study/) describes
reductions of up to 40% in another setting. Neither publication gives a public, matched before-and-after workload with
enough detail to tell a buyer whether the result would repeat on its own models. Jain's story is about that gap between
a software promise and a bill an operator can defend.

## The decision to sell a layer, not a fleet

Jain and co-founder Devansh Ghatak started Simplismart in 2022 after working as engineers at Oracle and Google,
respectively, according to
[TechCrunch's October account](https://techcrunch.com/2026/10/27/nvidia-backs-indian-startup-helping-companies-run-ai-models-with-fewer-gpus/).
The article says they met while studying at BITS Pilani. These are the public career details relevant to the decision;
they do not explain a private motive. Jain's own October letter supplies the operating choice: make a platform that
turns third-party capacity into inference services rather than finance the capacity itself.

The distinction matters because the two companies would carry different risks. A GPU cloud that owns or leases large
blocks of processors must fill expensive inventory. The October 29
[General Compute profile](/2026/10/29/finn-puklowski-alternative-chips-balance-sheet/) examines that chip-financing
problem. Simplismart's published plan exposes it to a different test. It needs to improve how customers use capacity
they already own or rent, then persuade both the application team and the infrastructure provider that its control layer
is worth another contract. Lower GPU consumption per request could help an application while reducing a cloud provider's
billable hours. Higher utilization and more workloads could offset that effect, but the offset is a commercial
hypothesis, not a measured result for this round.

Jain writes that cloud providers can use Simplismart to offer managed AI services under their own brands. That is closer
to selling the machinery of a cloud product than selling a single inference API. The provider keeps the customer-facing
brand and GPU supply. Simplismart supplies deployment, scaling and orchestration, according to its description. A buyer
must still ask which party controls routing, logs, support and pricing. The answer cannot be deduced from a funding
announcement.

That creates two sales, not one. The application team needs a lower cost for answers that meet its service target. The
infrastructure provider needs enough paying workloads to justify reserving machines, maintaining a catalog of models and
answering support tickets. If the first buyer consumes fewer GPU-hours, the second could initially bill less. The
provider could still gain if easier onboarding fills otherwise idle machines or attracts customers that would have used
another cloud. That arithmetic depends on utilization and contribution margin, neither of which the October announcement
discloses. A reseller should ask whether Simplismart is paid per request, per machine, as a platform subscription or
through another arrangement, because each model changes the incentive to reduce capacity. No public document reviewed
here sets out a universal contract. The buyer therefore has to test the commercial arrangement as carefully as the
serving code.

TechCrunch identified Dallas Venture Capital as the lead investor, with Nvidia, Accel, Shastra VC and Micromax also
participating. It reported a roughly $100 million valuation including the new funding, citing its reporting on the deal.
Those details show that investors financed the software approach. They do not establish that an operator has already
built a profitable inference cloud with it. Jain's stated next step is more ambitious: schedule work across regions and
time zones while meeting response-time and data-residency constraints. The October letter presents that as work still to
be built.

## Inference software between model and processor

Inference begins after a model has been trained. A user sends a request; software allocates compute, runs the model and
returns an answer. The workload varies sharply. A short text classifier, a long-context agent, a voice transcription and
a video generator consume different memory, time and capacity. The fastest setup for one may waste money on another. The
cheapest setup may break an application whose user abandons it after a slow response.

Simplismart says its platform handles model deployment, fine-tuning, scaling and monitoring in a customer's own cloud,
on premises or through its own service. TechCrunch describes the product as software between the model and the
infrastructure that adjusts latency, throughput and GPU consumption to a customer's requirements. That is an
interview-based description of the product, not our test of a running instance. The company's own
[comparison guide](https://simplismart.ai/blog/top-ai-inference-platforms) separates an inference engine, a raw GPU
cloud and an operating platform. Its rankings favor Simplismart and should be read as sales material; the guide also
says it did not run one standardized benchmark across all ten products it compared.

A buyer could deploy an open-source inference engine such as vLLM, contract directly with a GPU provider, use a managed
model API, or buy a platform like Simplismart. Those choices allocate work differently. A raw GPU contract leaves the
customer with model serving, autoscaling, observability and incident response. A managed API gives up much of that work
but also some control over model version, hardware and data location. A platform promises control without forcing the
customer to assemble every component. Whether it actually reduces labor and outages depends on the migration and the
workload, not only on tokens per second in a demo.

The issue is acute for companies selling AI features to other businesses. Their customer may require a fixed response
time, a data-residency boundary or a private deployment. An inference bill that looks low at average traffic can rise
when the team reserves capacity for a peak. A cheap batch price is irrelevant to a live video editor that needs timely
frames. A buyer needs the distribution of request sizes, output lengths and concurrency before it can judge a promise of
efficiency.

Nvidia's participation gives Simplismart access to a powerful ecosystem. It is also a reminder that this layer is
contested. Nvidia sells GPUs and publishes Dynamo, which includes a planner for scaling inference against latency
targets. Public documentation describes throughput-based and load-based controls, and distinguishes prompt processing
from token generation. Simplismart has to demonstrate value beyond what an application team can build with that stack or
buy from another managed provider. The funding itself does not answer where that boundary lies.

## Testing the 56% GPU savings claim

TechCrunch reports Simplismart's statement that AI video company InVideo reduced GPU serving costs by 56% with its
software. That is a named customer claim, not a public cost audit by InVideo. The report does not publish the model,
processor mix, request volume, before-and-after period, output quality or whether the saving includes Simplismart's fee.
Without those, 56% cannot be applied to another company's spend. A migration could preserve quality and cut waste, or a
different workload could have little headroom left.

The AWS case offers more engineering detail, but its denominator is different. AWS describes Simplismart using EC2 P5
and P4d instances, EKS and warm pools to shorten scale-up. The case says customers could scale in roughly 60 to 70
seconds rather than five to six minutes, and reports infrastructure costs lower by up to 40%. AWS engineers helped
develop a custom autoscaler. This is a useful description of one architecture and a partner-reported outcome. It is not
a controlled trial against Nvidia Dynamo, a generic cloud setup or the InVideo workload.

The case also reports an eightfold increase in GPU hours deployed over three months and sixfold business growth in six
months. Those numbers can coexist with a lower cost per unit of service. They can also reflect more customers or
workloads. Without revenue, margin and workload definitions, they cannot tell whether total GPU spend fell. This is why
the [founder's own 14x annualized revenue run-rate claim](https://simplismart.ai/blog/nvidia-backs-our-14m-series-b)
needs its own label. TechCrunch says the undisclosed eight-figure figure is based on recent usage, not contracted
recurring revenue, and excludes amounts passed through to infrastructure providers. It is neither audited annual revenue
nor evidence of customers renewing at the same rate.

A buyer can test a saving with a simple ledger: hold model version and output-quality threshold fixed; replay the same
request mix at the same concurrency and peak schedule; count total GPU-hours, software fees, cloud egress and operator
labor; then compare p50 and p95 latency, failure rate and accepted outputs. If an improvement comes from using a smaller
model, the evaluation must disclose the quality change. If the platform shifts a task to a cheaper region, the test must
account for data residency, network latency and transfer cost. A single percentage with none of these terms is a lead
for procurement, not a budget line.

Even the unit called a GPU-hour can mislead. A reserved GPU that waits for a burst is a cost when no request arrives. A
shared machine that completes two tenants' work may look highly utilized while one tenant waits behind the other. If
software compresses requests into fewer active hours but requires more standby capacity for a strict response target,
the customer's invoice may barely change. A useful denominator is the all-in cost per accepted output at a specified
service level, accompanied by total monthly spend. The first catches efficiency; the second catches a business that
grows its request volume after each output becomes cheaper. Both numbers are necessary to interpret a claim that the
software cut costs while the provider sold more capacity.

## Customers show deployment, not a universal result

The strongest independently identifiable deployment in the current public record is Yotta. Its
[own newsletter](https://yotta.com/newsletter/yotta-spark-edition-Nov-2025.html) says Simplismart's platform underpins
the serverless inference layer of Shakti Studio. Yotta is a commercial partner and wants customers for that service; its
description nevertheless establishes more than a logo on Simplismart's sales page. It describes where the software sits
in an actual provider offering. It does not publish a customer bill, latency distribution or uptime history for the
service.

The October letter lists HeyGen, Higgsfield, InVideo, Shiprocket, Apna and Ema as production customers. TechCrunch
repeats a customer list and says more than half of Simplismart's revenue comes from the United States despite more
customers in India, attributing that statement to Jain. A named production customer is a better lead than an anonymous
pilot, but neither the letter nor the report establishes what workload each customer runs, what it pays, or what changed
after deployment. A buyer should ask for a case matched to its own workload, not treat the logos as interchangeable
proof.

AWS has its own interest in presenting a successful case. Its article explains its warm-pool architecture and quotes
Ghatak, Simplismart's CTO, on sub-70-second scale-up. It does not separate the value supplied by AWS engineers, AWS
products, Simplismart's code and a customer's own changes. The right reading is narrower: a documented partner
configuration performed better on the case's reported measures. It does not show that Simplismart alone produced a 40%
saving.

The case is also a warning against assigning all the improvement to an abstract algorithm. A warm pool spends capacity
in advance so that a new worker can start sooner. An autoscaler then decides when to add or remove that capacity.
Kubernetes, cloud instances, model-server code and a provider's engineering work all participate in the result described
by AWS. The 60-to-70-second figure answers a startup-time question for that configuration. It does not answer how long
an end user waited for its first token, whether the standby machines were billed through a quiet week, or whether the
improvement survives a different model. Procurement should request the exact topology behind a reference case, including
which pieces come from the platform and which must be operated by the buyer. This would turn a marketing percentage into
a reproducible migration plan.

These limits are normal for an early infrastructure company. Customers rarely publish sensitive serving contracts or
model traffic traces. But the limits change what an analyst can responsibly say. The public record supports a funded
company, identifiable deployments and plausible mechanisms for better utilization. It does not support an industry-wide
efficiency rate or a prediction that every customer can cut its GPU bill in half.

![A layered workload queue crosses a large approval threshold before entering several differently sized capacity blocks, with one route held back by a regional boundary.](/images/articles/amritanshu-jain-simplismart-inference-software/workload-boundary-v1.jpg)

_AI-generated editorial illustration. The boundary represents a buyer's latency and data-location constraints, not
Simplismart's actual system._

## Nvidia is an investor and a competitor

Nvidia's investment is the feature that makes this financing more than another AI infrastructure round. TechCrunch
reports that the chipmaker participated and that the teams have worked on integrations around Dynamo. Jain argued in the
interview that more efficient inference can make Nvidia hardware attractive to more customers and expand demand. That is
a founder's view of the incentive. There is no public analysis in the report proving that lower GPU-hours per task raise
Nvidia's sales.

Dynamo's
[official planner guide](https://docs.nvidia.com/dynamo/knowledge-base/modular-components/planner/choose-a-planner-mode)
shows why the overlap matters. It can scale prefill and decode workers to hit time-to-first-token and inter-token
latency targets. It can combine a predictable capacity floor with reactive response to bursts. Nvidia's
[architecture notes](https://docs.nvidia.com/dynamo/dev/knowledge-base/concepts/system-architecture/disaggregated-serving)
also acknowledge costs: separating worker pools can introduce transfer or fragmentation overhead, especially at low
concurrency. Software optimization is not magic. A workload's shape determines whether a technique helps.

Simplismart's likely differentiation is broader operations across customer-controlled environments, workload types and
cloud-provider branding, as described by Jain and the company. That is an inference from its stated product scope, not a
benchmark. Nvidia's docs do not test Simplismart; Simplismart's site does not publish a matched
Dynamo-versus-Simplismart result. A serious buyer could find both useful: one as an engine and planner, the other as the
service layer around procurement, deployment and monitoring. It could also decide the extra platform is unnecessary. The
overlap must be priced, not waved away because an investor appears on the cap table.

The comparison also needs to name its level of abstraction. Dynamo's published planner can make decisions about worker
pools and latency objectives. Simplismart describes a platform that packages deployment, access and management for
customers or cloud partners. Those are not necessarily substitutes in every deployment. A provider might use Dynamo
inside a Simplismart-managed service; another might assemble its own control plane around Dynamo and avoid a platform
fee. TechCrunch reports collaboration on integrations, but the public sources do not specify which customer uses which
combination or publish a stable interface contract. Calling the two companies competitors is therefore a statement about
overlapping purchase decisions, not evidence that one product replaces every feature of the other. A buyer should write
down the functions it needs, identify the party that maintains each one, and price both a combined and a self-managed
option.

There is another strategic asymmetry. Nvidia can distribute software to the buyers of its chips. A small platform vendor
needs cloud partners and application teams to choose it even when those buyers already have Nvidia software,
cloud-native services and internal engineers. Simplismart's AWS case says AWS engineers helped build an autoscaler,
illustrating how much engineering may still sit outside the startup's product. A customer should ask what remains
supported if that integration changes or a vendor relationship ends.

## Idle GPUs are not a global pool

Jain's letter moves from current deployments to a proposed scheduling network. It imagines matching demand with idle
capacity across regions and time zones. The need is real enough: a capacity reservation can sit idle while another
region faces a queue. But capacity is not fungible just because both machines have GPUs. Models differ in memory
requirements, drivers, kernels and performance. A customer contract may forbid moving data out of a jurisdiction. A slow
transfer could erase a lower compute price. A provider may lack permission to resell unused capacity.

The founder explicitly names latency and data-residency boundaries in his letter. That caveat prevents the idea from
being a simple global auction for whichever GPU is cheapest. To make it work, the platform would need to know the model,
data location, task deadline, capacity price, network charge and failure policy before placing a request. It would need
a reliable way to move or stage model weights and customer data, if movement is permitted at all. Some buyers will
insist on on-premises deployment precisely to prevent such movement.

The current evidence supports a roadmap, not an operating global market. Yotta identifies a provider deployment. AWS
describes a specific cloud architecture. Neither source shows cross-region scheduling on multiple unrelated fleets with
published service levels. The missing proof is consequential because the imagined network is where Simplismart's
platform could become more valuable than a tool that tunes one cluster. It is also where integration, compliance and
support complexity rise.

Consider an application serving users in India and the United States. The cheapest available GPU at a given hour may be
in a third region. A scheduler that moves their requests there might reduce a compute charge but violate a contractual
data boundary or increase response time. The correct optimization could be to leave capacity idle and pay more. This is
an illustrative procurement example, not a reported Simplismart customer. It shows why the buyer must define the
allowable tradeoffs before believing a claim about worldwide utilization.

## Who answers when inference fails?

An application customer sees one failure: an answer arrives late, incorrectly, or not at all. The supporting stack may
involve a model developer, Simplismart, a cloud provider, Nvidia hardware and network services. Their contracts can
assign different responsibilities. The model developer may change weights. The cloud provider may guarantee a machine
but not a useful model response. A platform may optimize p95 latency without guaranteeing that an AI answer is correct.
The application remains accountable to its own users.

The AWS case gives a concrete scale-up contrast, from minutes to roughly a minute. A minute can still be too long for an
interactive spike. Warm capacity costs money during quiet periods. A buyer should ask how much standby capacity was held
for the reported result and whether that cost is included in the savings percentage. If the system switches models or
locations during load, the buyer also needs to know whether the application gets notice, whether output quality is
rechecked and which party can roll back.

Jain said to TechCrunch that customers need inference at the speed and cost their own applications require, rather than
the absolute fastest or cheapest service. That is a useful framing because it forces a target. A voice assistant may
need low time-to-first-response; a nightly batch job may tolerate hours if it can finish cheaply. A video generation
service may accept a longer wait but cannot accept a corrupted output. The platform should be measured against those
business constraints, not a universal performance league table.

Data control is part of this failure chain. Jain's letter says customers may run within a chosen cloud or on premises.
The choice can give a buyer control over location, but software still needs permissions to read telemetry, deploy models
and change capacity. A buyer should document which logs leave the environment, who can operate the control plane, how
incidents are disclosed and how the service can be removed. Neither the funding letter nor TechCrunch's report publishes
a complete contract for every deployment. These are tests to run, not allegations of an undisclosed problem.

## A buyer's inference evidence matrix

The public record contains several different kinds of evidence. Mixing them produces a false confidence level. The table
below is an editorial buying framework, not a test we ran and not a score assigned to Simplismart.

| Claim or choice                           | Public evidence today                                      | Missing buyer proof                                                         |
| ----------------------------------------- | ---------------------------------------------------------- | --------------------------------------------------------------------------- |
| $14M Series B and software-first strategy | Jain's dated letter and TechCrunch reporting               | Final terms beyond reported round; no implication of product performance    |
| Yotta serverless deployment               | Yotta's own description of Shakti Studio's inference layer | Contract scope, uptime, customer invoices and workload mix                  |
| InVideo 56% GPU cost reduction            | Simplismart statement relayed by TechCrunch                | InVideo-authored baseline, same model/output quality, period and all-in fee |
| Up to 40% lower infrastructure cost       | AWS partner case and described warm-pool setup             | Baseline, customer distribution, non-AWS comparison and total bill          |
| 14x annualized run-rate growth            | Jain's letter; TechCrunch's usage-basis caveat             | Audited revenue, retention, margin and cohort maturity                      |
| Cross-region capacity matching            | Jain's proposed next step                                  | Live multi-provider trace, residency controls, SLA and failover evidence    |

A procurement team can turn that matrix into a pilot. First, select two real workloads: one steady and one with bursts.
Fix model version and quality thresholds. Run the incumbent stack and Simplismart on comparable traffic. Measure p50/p95
time to first response, total completion time, failures, utilization and all-in cost per accepted output. Include
engineer hours, standby capacity, support charges and egress. Then force a region outage or model rollback and observe
who does what. If the platform is supposed to make an AI cloud sellable, test a real tenant's onboarding and invoice,
not only a lab benchmark.

Before the pilot, the buyer should choose a failure threshold that would stop procurement. For example, it might require
that at least 99% of accepted requests meet a defined response deadline, with a named owner for failed requests and a
maximum monthly bill at the expected peak. Those are illustrative thresholds for a hypothetical buyer, not Simplismart's
advertised SLA. The team should run the same acceptance test after a model update and after a planned capacity
withdrawal. If a saving disappears when traffic bursts, the headline average is not the price of the service the
business needs. If the platform succeeds, the buyer still needs an exit path: exportable deployment settings, access to
logs, a documented rollback and a clear rule for who pays for unused capacity at termination. Those details decide
whether a lower unit cost becomes a dependable operating choice.

The matrix also prevents an unfair dismissal. A partner case can be valuable even without a randomized trial; it reveals
an architecture worth testing. A vendor claim can tell a buyer what to ask. Neither should be promoted to an
independently replicated result. The test that matters is whether the saving survives the buyer's own workload and
constraints.

## The round buys engineering, not proof

Jain's October letter says the new capital will go into the inference engine, orchestration platform, cloud partnerships
and North American growth. TechCrunch reports a team of 58 at the time of its interview and says the United States
accounts for more than half of revenue, according to Jain. These statements describe an organization trying to sell
across borders, not a mature multinational capacity exchange. A funding round can pay for engineering, sales and
support. It cannot create a customer's trust by itself.

The company's market has an unusual feature: a platform may save a customer money while making the underlying workload
larger. Cheaper inference can invite more requests, new features or wider deployment. That is Jain's stated growth
thesis, and it is one reason Nvidia might see an investment case. But the causal chain must be measured: lower unit
cost, useful product, greater adoption, profitable service and enough demand for processors. A 14x annualized run-rate
claim does not establish all five links.

The earlier TechCrunch report of talks around a larger possible fundraise is another reason to keep the financing record
precise. In the October interview, Jain declined to comment on that earlier report and said this
$14 million
Series B was closed and would not be extended. The public fact for this article is the announced $14 million
round. An uncompleted discussion should not be added to money raised, valuation or capacity already available.

An investor evaluating the round would need a different ledger from an application buyer. The buyer asks whether its
accepted output is cheaper and reliable. The investor asks whether the platform can retain enough of the savings to earn
a margin after cloud-partner support, sales and engineering costs. A high annualized run rate based on recent usage can
rise quickly as a customer experiments and then contract when a credit, pilot or workload ends. TechCrunch explicitly
distinguishes the reported usage basis from committed recurring revenue. Revenue retention, customer concentration and
gross margin would be stronger evidence for the durability of this model; the public record here does not provide them.

The next document worth reading will be a customer-authored outcome with a clear baseline: model and hardware, traffic
distribution, bill before and after fees, latency, failures and contractual constraints. A second would be a cloud
provider's evidence that Simplismart made idle capacity into a service customers actually bought. Until those appear,
the October financing establishes a sharply defined operating bet. Jain has chosen to sell the software around GPUs. The
customers still have to decide whether that software improves the bill they pay for answers that arrive on time.

## Continue reading

- [Finn Puklowski Puts Rival AI Chips on the Balance Sheet](https://digidai.github.io/2026/10/29/finn-puklowski-alternative-chips-balance-sheet/): Compare software orchestration with an inference cloud that finances its own alternative-chip capacity.
- [AI Credits Distort the Startup Headcount Plan](https://digidai.github.io/2026/07/07/ai-credits-startup-headcount-plan/): See how temporary compute discounts can distort a startup's long-term operating plan.
- [Nvidia and the $12.93 Billion Promise to Keep Hugging Face Open](https://digidai.github.io/2026/09/04/nvidia-hugging-face-open-platform-promise/): Examine Nvidia's role as both infrastructure supplier and software-platform competitor.
- [Andrew Feldman's Cerebras and Wafer-Scale AI Bet](https://digidai.github.io/2025/11/18/andrew-feldman-cerebras-wafer-scale-nvidia-challenge-deep-analysis/): Place the GPU economics beside a competing approach to AI inference hardware.