Amritanshu Jain Sells Inference Without Owning the GPUs

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 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 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. 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 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. 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 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 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 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 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.

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 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 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.