DEV Community: Prateek Navani

Where your cloud storage bill actually goes: storage vs egress vs requests

Prateek Navani — Mon, 21 Sep 2026 06:30:03 +0000

I have looked at enough cloud bills to know the pattern by now. Someone's storage volume barely changed month to month, but the bill went up anyway, sometimes by a lot. Nine times out of ten, the actual data sitting in storage was never the problem.
Cloud storage billing is not one number. It is at least three separate charges stacked together, and most people only ever look at the first one. Let me break down where the rest of that bill actually comes from.

Why does your bill keep changing even when your data is not growing?

Because storage capacity is only one of several billing dimensions on a typical invoice.
Storage capacity: the straightforward per-GB-per-month charge
Egress: the cost of moving data out of the provider's network
API requests: charges for every PUT, GET, LIST, and DELETE operation your applications make
Retrieval fees: apply specifically to cold storage tiers when you actually access that data
Cloud bills in 2026 commonly run 30% to 40% over what teams originally forecasted, and the overshoot almost always comes from data access charges, not storage volume growth.
Which of these usually causes the biggest surprises?
Egress, by a wide margin. It is the line item most people underestimate when they first set up a storage bucket, and the one that grows fastest once real traffic or automated processes start moving data around.

What exactly are you paying for on the "storage" line?

This part is genuinely simple. It is a per-GB, per-month rate, and it varies mainly by which storage tier you choose.
Provider
Standard tier storage rate
AWS S3 Standard
$0.023 per GB per month
Google Cloud Storage Standard
$0.020 per GB per month
Cloudflare R2
$0.015 per GB per month
Wasabi
$0.00699 per GB per month
Backblaze B2
$0.006 per GB per month

Does moving to a cheaper cold storage tier actually save you money?
Only if you rarely touch the data. Cold tiers like Nearline, Coldline, and Archive charge separately for retrieval, ranging from roughly $0.01 to $0.05 per GB depending on the tier, plus early deletion penalties if you remove data before a minimum retention period, typically 30, 90, or 365 days. If your data gets accessed more than once a month on average, a standard or cool tier often ends up cheaper once you count retrieval fees honestly.

What is egress, and why does it usually cost more than people expect?

Egress is the fee charged for data leaving a provider's network, whether that is to the internet, to your users, or to another cloud entirely. Ingress, meaning data coming in, is free everywhere. Egress is where providers make a meaningful share of their margin.
Provider
Standard internet egress rate
AWS S3
Around $0.09 per GB
Azure Blob Storage
Around $0.087 per GB
Google Cloud Storage
$0.08 to $0.12 per GB
Oracle Cloud Infrastructure
$0.0085 per GB after 10TB free monthly
Cloudflare R2, Backblaze B2, Wasabi
$0, no egress charge

A team moving 10TB out to the internet in a single month on a standard hyperscaler can expect to pay somewhere around $1,100 to $1,200 in egress alone, often more than the underlying storage cost for that same data.
Are there real ways to avoid egress fees entirely?
Yes, and this is worth taking seriously if your workload is genuinely egress heavy. Zero-egress providers like Cloudflare R2, Backblaze B2, and Wasabi remove this cost dimension completely. Putting a CDN in front of storage that does charge egress also helps significantly, since transfer from origin storage to a CDN edge is often free or discounted compared to serving content directly.
What are "requests," and how do they quietly add up?
Every API call your application makes to read, write, or list objects in storage carries its own small charge, usually priced per thousand or ten thousand operations.
AWS charges roughly $0.005 per 1,000 PUT requests and $0.0004 per 1,000 GET requests
Google Cloud charges around $0.05 per 10,000 Class A operations and $0.004 per 10,000 Class B operations
LIST operations are typically billed at the more expensive PUT rate, not the cheaper GET rate
An application generating 10 million PUT requests in a single month pays roughly $50 in request fees alone, entirely separate from whatever storage or egress it uses.
When do request costs actually become a meaningful line item?
Mainly for applications writing or listing large numbers of small objects, things like backup jobs, logging pipelines, or sync tools that touch thousands of files repeatedly. Structuring your storage key namespace to minimize unnecessary LIST calls is one of the simplest ways to keep this cost dimension under control.
So which of the three actually drives most of your bill?
It depends entirely on your workload, which is exactly why the raw per-GB storage rate is such a misleading number on its own.
Egress usually dominates for internet-facing applications, media delivery, or anything moving data between clouds
Storage cost dominates for large archival datasets with genuinely low access frequency
Request costs dominate for applications generating huge volumes of small objects or frequent writes
Real-world total spend commonly runs two to five times higher than the raw storage rate once all of this gets counted together, and at high volumes with heavy egress, total costs between providers can differ by more than seven times for functionally similar service.

How do you actually audit your own bill instead of guessing?

A short, practical process works better than trying to memorize every provider's pricing page.
Pull 30 days of access logs before assuming a cold tier will save money
Break your last invoice into storage, egress, and request line items separately, rather than looking at the total
Check whether you are regularly paying to move data out of the same cloud storage provider you also pay to keep it in
If egress is your biggest line item, seriously evaluate a zero-egress provider or a CDN in front of your current setup
Doing this once tells you which of the three dimensions is actually worth optimizing, instead of cutting storage costs while egress quietly keeps climbing in the background.

Where this leaves you

The per-GB storage rate on a pricing page is the least useful number for predicting your actual bill. Storage, egress, and request costs behave completely differently, scale with different parts of your workload, and often move in opposite directions depending on how you structure your setup. Breaking your invoice into those three categories, rather than treating it as one number, is the fastest way to find out what is actually driving your costs and where there is real room to bring them down.
Frequently asked questions

Is egress always the most expensive part of a cloud storage bill? Not always, but it is the most commonly underestimated. For workloads that rarely serve data externally, storage and request costs can matter more. For anything user-facing or cross-cloud, egress usually ends up being the largest and most volatile line item.
Are zero-egress providers actually cheaper overall, or just cheaper on that one line item? It depends on your access pattern. Zero-egress providers sometimes charge a slightly higher per-GB storage rate, but for any workload where data leaves the bucket frequently, the removed egress cost usually outweighs that difference by a wide margin.
Do request costs matter for smaller teams, or is this mainly an enterprise problem? They can matter surprisingly quickly, particularly for applications with automated processes like backups, syncing, or logging that generate large volumes of small requests. It is worth checking request volume even at smaller scale, since the cost per operation looks tiny until it is multiplied by millions of calls.

H200 in India: availability, pricing and data residency

Prateek Navani — Fri, 18 Sep 2026 05:44:39 +0000

Not too long ago, getting your hands on an H200 usually meant going through a global cloud provider, paying in dollars, and hoping your data residency requirements did not become a problem later. That situation has genuinely changed. In 2026, the H200 is available directly through Indian providers, billed in rupees, hosted on Indian soil.
I have gone through what is actually available, what it costs across different routes, and what data residency really means for this specific chip, since a lot of the advice floating around still assumes it is 2024. Let me walk through where things actually stand right now.

*Is the H200 actually available in India right now, or is it still hard to get?
*
Genuinely available, though not universally. H100 supply across India is healthy at this point, but H200 access is still a bit more selective, offered by a smaller set of providers who have specifically brought the newer hardware online.
E2E Networks: A publicly listed Indian provider with data centers in Delhi NCR, offers H200 alongside H100 and A100
CloudPe: Running H200 with Indian data residency and INR billing as part of its GPU cloud offering
Yotta and Tata Communications: Both empaneled under government infrastructure programs and offering H200-class capacity
Several smaller regional hosting providers that advertise H200 access at lower entry price points, worth checking specs closely since some list H100 under similar marketing language
Which providers should you actually check first?
Start with providers that explicitly confirm H200 SXM or PCIe configuration in writing, rather than vague language like "latest generation GPU." That distinction matters more than it sounds, since some smaller providers use generic marketing copy that does not always match the actual hardware you get provisioned.

*How much does H200 access actually cost in India?
*
This is where the range gets genuinely wide, depending on which route you take.
Access route
Approximate cost per GPU-hour
IndiaAI Mission subsidized pool (eligible teams)
Roughly ₹83 to ₹92
India-native specialist cloud, flat INR pricing
Roughly ₹250 to ₹400
Hyperscaler on-demand (Mumbai region)
Roughly ₹950 to ₹1,150

That is close to a tenfold difference between the cheapest and most expensive legitimate way to access the exact same chip.
Why is there such a big gap between these prices for the same hardware?
Because you are not just paying for the GPU. Hyperscalers bundle in enterprise tooling, global region coverage, and compliance certifications for dozens of jurisdictions, and that infrastructure cost gets folded into the price whether you need all of it or not. Subsidized government pricing exists specifically to lower the barrier for startups and researchers. India-native specialist clouds sit in between, running leaner infrastructure focused specifically on GPU access rather than a full enterprise cloud stack.

*What does data residency actually mean for your workload, and do you legally need it?
*
Less than most people assume, at least for now. The DPDP Act governs how personal data belonging to Indian citizens gets processed and stored, and its implementing rules have been rolling out in stages through 2025 and 2026. For most AI workloads, training on public or synthetic data, and inference that does not touch personal data, there is currently no blanket requirement that compute physically sit inside India.
So who actually needs an India-hosted setup right now?
A more specific group than "everyone."
Regulated fintech or healthtech pipelines processing Indian citizens' personal data at meaningful scale
Government contracts that include explicit data residency clauses
Larger platforms that will fall under stricter rules once the "significant data fiduciary" provisions are fully notified
If you do not legally need it, is there still a reason to choose a domestic H200 setup?
Often, yes, even without a compliance requirement forcing the decision. Running on an h200 gpu cloud hosted inside India typically means lower latency for Indian users, INR billing that removes currency exposure from your monthly costs, and a much simpler compliance conversation with enterprise customers or auditors who ask about data location before signing anything. It also protects you against having to migrate later if the DPDP rules tighten further once fully notified.

*What should you actually check before committing to a provider for H200 access?
*
A short list, but each item genuinely matters.
Confirmed H200 SXM or PCIe specification in writing, not vague "high-end GPU" language
A clear pricing model, since flat hourly rates are usually easier to budget against than tiered or usage-based structures
Explicit data residency guarantees, including which physical data center your workload runs in
Whether DPDP compliance documentation is included by default or sold as a separate add-on
Minimum commitment terms, since some providers require multi-month contracts even for on-demand style pricing
Where this leaves you

The H200 is no longer something Indian teams need to access exclusively through global clouds priced in dollars. Domestic availability is real, pricing genuinely varies by a wide margin depending on the route you take, and data residency matters more for some workloads than others. Check actual hardware specifications in writing, compare the full price range before committing, and choose based on whether your specific workload actually needs domestic residency, rather than assuming it does by default.

**Frequently asked questions
**1. Is H200 access in India as reliable as going through a global hyperscaler?
For most workloads, yes. Established Indian providers running H200 have matured significantly over the past year, with published uptime SLAs and dedicated support teams. The bigger differentiator now is pricing and data residency, not reliability.

Do I need to prove eligibility to access subsidized IndiaAI Mission compute? Yes, this pricing is not automatically available to every commercial workload. Startups, researchers, and academic institutions typically need to register through the programme and meet its eligibility criteria before accessing the subsidized rate.
Will DPDP rules eventually force all AI workloads to stay in India? Not based on what has been finalized so far. The Act focuses on personal data specifically, with cross-border transfers still allowed except to a restricted list of countries, rather than a blanket data localization mandate. That said, rules are still being clarified, so this is worth monitoring rather than treating as permanently settled.

DDoS mitigation provider comparison: capacity, time-to-mitigate, pricing

Prateek Navani — Thu, 17 Sep 2026 06:43:33 +0000

I have watched more than one team pick a DDoS provider based purely on a big capacity number on a marketing page, only to get genuinely caught out months later by a smaller, faster attack that number was never protected against. Capacity matters, but it is not the whole story, and providers spend a lot of effort making sure that headline figure is the first thing you see.
Let me walk through how the major providers actually compare once you look past the marketing numbers, across capacity, how fast they actually respond once an attack starts, and what you genuinely pay across the market in 2026.

What is a DDoS attack, and why does the provider you pick actually matter?

If you are not entirely sure what is DDoS attack behavior actually looks like in practice, here is the short version. An attacker floods a target with overwhelming traffic or malicious requests, aiming to exhaust its resources so real users cannot get through. The provider sitting in front of your infrastructure is what decides whether that flood ever reaches your servers at all.
Volumetric attacks (Layer 3/4), which flood raw bandwidth capacity
Protocol attacks, which exploit weaknesses in how connections are established and maintained
Application-layer attacks (Layer 7), which mimic legitimate traffic to exhaust application resources directly
Why can't you just look at network capacity and call it done?
Because a service that can absorb an enormous volumetric attack is not automatically well protected against a fast, low-volume application-layer attack that behaves like real user traffic. Detection speed and behavioral analysis matter more for these attacks than raw absorption capacity, and providers increasingly compete on that speed, not just their headline Tbps figure.

How do the biggest providers compare on raw capacity?

Here is where things stand across the market's main players.
Provider
Network capacity
Dedicated DDoS scrubbing capacity
Cloudflare
388+ Tbps
Distributed across the entire anycast network
Tencent EdgeOne
400+ Tbps
25+ Tbps dedicated
Akamai Prolexic
Part of a 4,000+ PoP platform
20+ Tbps dedicated scrubbing

The architecture differs meaningfully behind these numbers. Cloudflare absorbs attack traffic at every point of presence simultaneously through its anycast network. Akamai's Prolexic routes traffic through dedicated scrubbing centers instead, which supports very high sustained scrubbing capacity but involves a more complex traffic path than absorbing everything at the edge.
Does a bigger headline capacity number always mean better protection?
Not necessarily. You cannot realistically outbuy the largest botnets on capacity alone, so the more useful buying principle is choosing a provider whose capacity comfortably dwarfs any attack you could plausibly face, rather than sizing your choice to your own current traffic levels. Beyond that threshold, detection speed and how well a provider handles application-layer attacks usually matter more day to day than an even larger capacity number.

How fast do these providers actually mitigate an attack once it starts?

In 2026, always-on edge mitigation with no detection delay has become the baseline expectation, and the strongest providers now measure mitigation in seconds rather than minutes.
Some edge providers report initiating mitigation in under 3 seconds on average
Cloudflare's anycast model absorbs volumetric attacks across its entire network simultaneously, without a separate detection step
Akamai's Prolexic scrubbing center model can sustain extremely large attacks, though the more complex traffic path can mean a marginally different response profile compared to at-the-edge absorption
Does time-to-mitigate matter more for some attack types than others?
Yes, significantly. For a pure volumetric flood, sheer absorption capacity often determines the outcome regardless of a few seconds of detection time. For a fast, low-volume application-layer attack designed to look like normal traffic, detection speed and behavioral analysis quality matter far more than how large the provider's network is on paper.

What does this actually cost across the market in 2026?

The spread here is genuinely wide, from completely free to well into six figures annually.
Provider or tier
Typical cost
Cloudflare Free / AWS Shield Standard
Free
Cloudflare Pro
Around $20 per month
AWS Shield Advanced
Around $3,000 per month, sold as a committed annual contract
Azure DDoS Protection
Around $2,944 per month
Akamai Prolexic
Enterprise contract, commonly $100,000 or more per year

A basic small-business protection stack can realistically run under $30 a month. A large enterprise contract with dedicated security operations support can run well past six figures annually.
Why is there such a massive gap between the cheapest and most expensive options?
Because the price is not just buying bandwidth. Entry-level and free tiers cover baseline volumetric protection well, but behavioral Layer 7 protection and active response, the pieces that matter most against sophisticated, adaptive attacks, are frequently sold as paid add-ons even on plans that advertise unmetered DDoS absorption. Enterprise contracts at the top end are paying for dedicated security operations teams actively tuning defenses in real time, along with contractual mitigation guarantees, not simply a bigger pipe.
So which provider actually fits which kind of business?
The right answer depends heavily on your scale and how much a successful attack would actually cost you.
Small to mid-market sites wanting fast setup and low cost are usually well served by Cloudflare's lower tiers
Large enterprises where downtime carries real contractual or revenue consequences tend to land on Akamai Prolexic for its SOC-led, actively tuned defense
Organizations with compliance requirements often need a provider offering a written, contractual mitigation SLA, which narrows the field considerably
Teams already running on AWS or Azure frequently choose the native option for tighter integration, even at a premium over third-party alternatives
Businesses serving both global and China-based audiences often look toward providers like EdgeOne, which bundle CDN, WAF, and DDoS protection with genuine mainland China presence
What should a smaller team actually prioritize when picking a provider?
Always-on protection included at the base tier, and a clear understanding of what is actually included versus sold separately. Read the fine print on behavioral Layer 7 protection specifically, since it is one of the most common places where an "unmetered" or "unlimited" DDoS plan quietly excludes the protection that matters most against modern attacks.

Where this leaves you

Capacity numbers make for an easy comparison on a pricing page, but they answer the wrong question for most buyers. The better questions are how fast a provider actually detects and responds to an attack, and what is genuinely included at your price point versus sold as a separate add-on later. Get clear on both before signing anything, and the provider that looks most impressive on paper is not always the one that will actually protect you at 3 a.m.

H200 in India: availability, pricing and data residency

Prateek Navani — Fri, 11 Sep 2026 05:52:46 +0000

Is the H200 actually available in India right now, or is it still hard to get?

Genuinely available, though not universally. H100 supply across India is healthy at this point, but H200 access is still a bit more selective, offered by a smaller set of providers who have specifically brought the newer hardware online.
E2E Networks: A publicly listed Indian provider with data centers in Delhi NCR, offers H200 alongside H100 and A100
CloudPe: Running H200 with Indian data residency and INR billing as part of its GPU cloud offering
Yotta and Tata Communications: Both empaneled under government infrastructure programs and offering H200-class capacity
Several smaller regional hosting providers that advertise H200 access at lower entry price points, worth checking specs closely since some list H100 under similar marketing language
Which providers should you actually check first?
Start with providers that explicitly confirm H200 SXM or PCIe configuration in writing, rather than vague language like "latest generation GPU." That distinction matters more than it sounds, since some smaller providers use generic marketing copy that does not always match the actual hardware you get provisioned.

How much does H200 access actually cost in India?

This is where the range gets genuinely wide, depending on which route you take.
Access route
Approximate cost per GPU-hour
IndiaAI Mission subsidized pool (eligible teams)
Roughly ₹83 to ₹92
India-native specialist cloud, flat INR pricing
Roughly ₹250 to ₹400
Hyperscaler on-demand (Mumbai region)
Roughly ₹950 to ₹1,150

What does data residency actually mean for your workload, and do you legally need it?

Less than most people assume, at least for now. The DPDP Act governs how personal data belonging to Indian citizens gets processed and stored, and its implementing rules have been rolling out in stages through 2025 and 2026. For most AI workloads, training on public or synthetic data, and inference that does not touch personal data, there is currently no blanket requirement that compute physically sit inside India.
So who actually needs an India-hosted setup right now?
A more specific group than "everyone."
Regulated fintech or healthtech pipelines processing Indian citizens' personal data at meaningful scale
Government contracts that include explicit data residency clauses
Larger platforms that will fall under stricter rules once the "significant data fiduciary" provisions are fully notified
If you do not legally need it, is there still a reason to choose a domestic H200 setup?
Often, yes, even without a compliance requirement forcing the decision. Running on an h200 gpu cloud hosted inside India typically means lower latency for Indian users, INR billing that removes currency exposure from your monthly costs, and a much simpler compliance conversation with enterprise customers or auditors who ask about data location before signing anything. It also protects you against having to migrate later if the DPDP rules tighten further once fully notified.

What should you actually check before committing to a provider for H200 access?

A short list, but each item genuinely matters.
Confirmed H200 SXM or PCIe specification in writing, not vague "high-end GPU" language
A clear pricing model, since flat hourly rates are usually easier to budget against than tiered or usage-based structures
Explicit data residency guarantees, including which physical data center your workload runs in
Whether DPDP compliance documentation is included by default or sold as a separate add-on
Minimum commitment terms, since some providers require multi-month contracts even for on-demand style pricing

Where this leaves you

Frequently asked questions

Is H200 access in India as reliable as going through a global hyperscaler? For most workloads, yes. Established Indian providers running H200 have matured significantly over the past year, with published uptime SLAs and dedicated support teams. The bigger differentiator now is pricing and data residency, not reliability.
Do I need to prove eligibility to access subsidized IndiaAI Mission compute? Yes, this pricing is not automatically available to every commercial workload. Startups, researchers, and academic institutions typically need to register through the programme and meet its eligibility criteria before accessing the subsidized rate.
Will DPDP rules eventually force all AI workloads to stay in India? Not based on what has been finalized so far. The Act focuses on personal data specifically, with cross-border transfers still allowed except to a restricted list of countries, rather than a blanket data localization mandate. That said, rules are still being clarified, so this is worth monitoring rather than treating as permanently settled.

When should you upgrade your GPU to RTX PRO 6000?

Prateek Navani — Wed, 09 Sep 2026 05:20:07 +0000

There is a specific kind of frustration that comes from watching a training run crash with a CUDA out of memory error for the third time in a week. You tweak the batch size, you quantize a little harder, you free up cache, and it works again, until the next model you try is just slightly too big and the whole cycle repeats.
At some point, that becomes a pattern worth paying attention to. I have watched a lot of developers spend months working around memory limits before finally admitting the problem was never the config, it was the card. Let me walk through the actual signals that mean it is time to upgrade, and the ones that mean you are not there yet.

*What is the clearest sign that your current GPU is actually holding you back?
*
Repeated CUDA out of memory errors that survive every fix you throw at them.
You have already cut batch size and it barely helps
You are quantizing models that you would rather run at higher precision
The same job that worked on a smaller model now fails on anything larger
If you are doing all three regularly, this is no longer a configuration problem.

*Is a CUDA out of memory error always about needing more VRAM?
*
No, and this is worth ruling out first. A lot of OOM errors come from an oversized context window, an unnecessarily large KV cache reservation, or memory fragmentation from tensors that never got cleared. Fixing those config issues solves a real share of OOM errors without touching hardware at all. The upgrade signal only kicks in once you have tried the standard fixes and you are still hitting the wall.

*How much VRAM do you actually need for the work you are doing?
*
More than most people expect, especially once training enters the picture.
Workload
Rough VRAM need relative to model size
Inference
1.2 to 1.5 times the model size
Training or fine-tuning with full gradients
6 to 8 times the model size

A 24GB card that comfortably runs inference on a mid-sized model can still run out of room the moment you try to fine-tune that same model with full precision gradients.
Why does training need so much more memory than inference?
Because inference only needs the model weights and a bit of overhead. Training adds gradients and optimizer states on top of that, and those add up fast. This is exactly why a card that feels generous for running models can still feel tight the moment you start training or fine-tuning on it regularly.

*What other signs point to a real hardware upgrade rather than a config fix?
*
A few patterns tend to show up together once a card is genuinely undersized for the work.
Permanent quantization, where 4-bit precision stopped being a choice and became the only option that fits
Queuing on a shared machine, where your team waits in line for GPU time instead of working in parallel
Multiple resident models, like an embedding model and an LLM that both need to stay loaded for a RAG pipeline
Moving from experimentation to production, where reliability and headroom matter more than they did during prototyping
Is queuing on a shared GPU actually a hardware problem?
Yes, and it is one people underestimate. If your team is regularly waiting for GPU time because one card cannot serve everyone, that is a capacity problem, not something a smarter script will fix. More memory per card, or simply more cards, is the actual solution.

*Why does the RTX PRO 6000 specifically solve these problems?
*
Because it removes the exact ceiling that causes most of the signals above.
Spec
What it solves
96GB ECC GDDR7 VRAM
Fits larger models without forced quantization, and holds multiple resident models at once
NVLink support (multi-GPU)
Pools memory across cards instead of leaving them siloed
ECC memory
Protects long training runs from silent memory corruption
Data center EULA
Removes licensing friction for team or production deployment

*What can you actually do on the RTX PRO 6000 that you could not do before?
*
A single card can run a 70B parameter model at FP8 precision without quantization tricks. Pair two of them with NVLink and you get 192GB of pooled memory, enough for full unquantized 70B inference and genuinely serious fine-tuning work that would have needed a multi-GPU server rack not long ago.

*When does it not make sense to upgrade yet?
*
Plenty of situations, and it is worth being honest about them before spending this kind of money.
You are still prototyping small models and have not actually hit a real ceiling
The config fixes for context length and KV cache actually solve your OOM errors
Your workload is bursty rather than constant, and renting occasionally would cost far owless than ning

*Could a config fix or renting solve this before you spend on new hardware?
*
Often, yes. If you have not already tried capping context length, quantizing the KV cache, or clearing fragmented memory, do that first. And if your need for extra VRAM is occasional rather than constant, renting an RTX 6000 pro instance for the weeks you actually need it is usually cheaper than buying one outright, at least until your usage pattern becomes consistent enough to justify ownership.
There is also a quieter cost worth counting here, and it has nothing to do with the GPU itself. Every hour your team spends rewriting training scripts around memory limits, babysitting quantization settings, or waiting for a shared machine to free up is an hour not spent on the actual project. That cost rarely shows up on a budget sheet, but it adds up faster than most teams expect once memory constraints become a daily annoyance instead of an occasional one.

**
**
The upgrade decision usually comes down to one honest question. Are you spending more time working around memory limits than actually building? If config tweaks and quantization tricks have started feeling like a full time job on their own, that is the real signal, not marketing copy or a bigger number on a spec sheet. Once you are there, the extra memory and headroom stop being a nice-to-have and start being the thing that gets your actual work done.

AI startup funding in India 2026: what's actually happening and why it matters

Prateek Navani — Mon, 07 Sep 2026 05:13:27 +0000

If you have spent any time on startup Twitter or LinkedIn this year, you have probably noticed something. Everyone is suddenly talking about AI funding in India. Not in the vague way people talked about it two years ago, when "AI startup" just meant a wrapper around someone else's model. This time there is real money behind it, real GPUs being deployed, and a genuine shift in where investors want to put their capital.
I have been tracking the funding numbers and infrastructure announcements closely this year, and the pace of change has been hard to keep up with. So let me walk you through what is actually going on, why it is happening now, and what it means if you are building something in this space.

*Why is AI funding suddenly the biggest story in Indian startups?
*

Because the numbers are impossible to ignore.
Indian AI startups raised around $676 million in just the first half of 2026
Deal volume jumped nearly 90% year on year, touching a six month high of 57 deals
Overall startup funding in India actually dropped over the same period
That last point is what makes this interesting. While most sectors saw investors pull back a little, AI moved in the opposite direction. And the deal count matters more than the total. It tells you this is not two or three massive checks skewing the picture. More investors are backing more AI companies, not just bigger ones.
How big is this jump, really?
Here is a comparison that puts it in perspective:
Period
AI startup funding in India
2020 to end of 2025 (cumulative)
Roughly $1.8 billion
First half of 2026 alone
Roughly $676 million (nearly a third of the five year total)

That is the kind of acceleration that makes even cautious investors sit up and pay attention.

What is actually driving this, beyond hype?

Mainly three things:
Government backing for AI compute through national programs
A maturing startup pipeline finally ready to deploy serious capital
A global shift in venture money, where AI has become the default bet, not a side one
The government piece is worth understanding properly, because it changes the actual economics for founders.

*What is the IndiaAI Mission and why should it matter for your GPU bill?
*
The IndiaAI Mission is a government backed program built around subsidized compute access. It has empaneled tens of thousands of GPUs that startups and researchers can access at a fraction of commercial cloud pricing.
How much cheaper is subsidized compute, actually?
GPU access route
Rough cost per GPU hour
IndiaAI Mission subsidized pool
Around $1
Commercial global hyperscaler (comparable hardware)
$2.50 to $4.00

For a team training a mid-sized model, that gap can be the difference between a $400,000 training run and a $1.2 million one. That is not a small optimization. That is the difference between a startup surviving its seed round or burning through it before finding product market fit. It is also why so many founders now spend real time evaluating infrastructure early, instead of treating it as an afterthought.

*Where is all this new AI infrastructure actually being built?
*
On the ground.
Close to 30 large data centre projects were announced across India between March 2025 and April 2026
Together, they add an estimated 3.5 gigawatts of planned capacity
Multiple states are building at once, not just one hub
Which cities are turning into AI infrastructure hubs?

Region
What is happening there
Andhra Pradesh and Telangana
AI focused campuses in Visakhapatnam and Hyderabad
Maharashtra
Most active market by number of projects
Chennai and Noida
Large enterprise led buildouts
Hyderabad, Pune, Chennai
Microsoft launching and expanding cloud regions through 2026

Global hyperscalers and Indian conglomerates are building at the same time, which is part of why this cycle feels different from previous ones.

*If there is this much money around, why do founders still struggle with infrastructure?
*
Because funding and compute access are two different problems. Having one does not automatically solve the other.
GPUs are still in high demand globally. Subsidized pools help, but they are limited. Commercial GPU pricing from global hyperscalers is still steep for early stage teams working with Indian budgets.
This is usually the point where a founder realizes that finding the right AI startup cloud GPU setup is not a side decision. It shapes how many experiments you can run, how fast you can iterate, and how long your runway actually lasts.
So how are most early stage teams making this decision?
Most teams end up comparing the same three things before committing to a provider:
GPU availability without long wait times
Predictable INR pricing, with no hidden egress or storage costs
Real compliance readiness, especially around the DPDP Act, not just a claim on a website
Teams that skip this comparison usually find out the hard way. Often after their first surprise bill, or a support ticket that takes days to resolve.

*Is this funding wave sustainable, or is it heading for a correction?
*
Honestly, it is a mixed picture. That feels like a more useful answer than pure optimism.
Reasons for confidence:
Deal count is up sharply, spreading capital across many companies, not just favourites
Government and private infrastructure commitments are already being built, not just announced
Reasons for caution:
Large mega deals stayed rare during the same period
Late stage funding actually slowed down noticeably
That combination usually means early and growth stage AI companies are attracting attention, while investors stay cautious about the largest checks until more companies prove they can scale revenue, not just raise rounds.
My honest read is that this is a real structural shift, not a short term spike. But not every funded startup will make it to its next round, and that is normal for any fast moving sector.

*Where this leaves founders right now
*
If you are building an AI product in India today, the funding environment is more favourable than it has been in years. But money alone will not fix a bad infrastructure decision made early on.
The founders who do well over the next year will be the ones who treat compute and infrastructure choices with the same seriousness as their fundraising strategy, not as a detail to figure out after the round closes.

Is the RTX PRO 6000 worth it for AI and rendering right now

Prateek Navani — Fri, 04 Sep 2026 05:03:35 +0000

I get asked about this card constantly, usually by someone comparing it to a stack of RTX 5090s or wondering why the price keeps moving every time they check. Both are fair questions, and the answer depends entirely on what you're actually running.
Let me walk you through what this card is, why its price has gone a little insane, and when it genuinely earns its cost.

Quick answer: the RTX PRO 6000 Blackwell is NVIDIA's flagship workstation GPU, built around 96GB of GDDR7 memory, the largest VRAM pool on any single desktop-class card. It's the right choice when you need to fit large AI models or heavy rendering scenes in one slot. It's the wrong choice if your workload fits comfortably on a cheaper card, since you'd be paying a steep premium for capacity you won't touch. Its price has climbed sharply through 2026, from roughly $8,565 at launch to $16,000 on NVIDIA's own marketplace by August, driven almost entirely by a GDDR7 memory shortage, not any hardware change.

What exactly is the RTX PRO 6000 Blackwell?
It's NVIDIA's top workstation card, built to hold large AI models and heavy rendering scenes that won't fit on a consumer GPU.
Here's what's actually inside it:
Spec
Detail
GPU die
Full GB202, 24,064 CUDA cores
Tensor cores
752, 5th generation, FP4 and FP8 support
RT cores
188, 4th generation
Memory
96GB GDDR7 with ECC
Bandwidth
1,792 GB/s
AI throughput
4,000 AI TOPS (FP4, sparse)
Power draw
600W
Form factor
Dual-slot, active dual-flow-through cooling

The number that matters most here is 96GB. That's double what its predecessor offered, and it's what lets this card hold models and scenes that would otherwise need to be split across multiple GPUs.
Why has the price nearly doubled since launch?
Because of a GDDR7 memory shortage.
Here's the actual timeline, and it's a rough one if you bought late:
When
Price on NVIDIA's marketplace
March 2025 (launch)
~$8,565
Early-mid 2026
Stabilized around 8,000–9,400 street price
June 2026
$13,250
August 2026
$16,000

That's close to a 90% increase in under a year and a half, on a card whose specs never changed. The driver is the same one hitting GPUs across the industry right now: GDDR7 supply can't keep up with demand, and this card uses more of it, in a denser clamshell layout, than almost anything else on the market. Third-party retailers vary too. PNY has listed it lower, around $11,360, while some boxed retail listings have pushed past $14,000.
If you're budgeting for one of these, get a live quote before you commit to a number. Anything you read today could be stale by the time you're ready to buy.

Which edition should you actually buy?

Depends entirely on where the card is going to live. Get this wrong and you'll end up with hardware that doesn't fit your deployment.
Edition
Cooling
Best for
Workstation
Active, dual-flow-through, 600W
Desktop towers, single or dual GPU setups
Max-Q
Configurable 300–600W
Dense multi-GPU workstations, up to four cards
Server
Passive, rack-mounted
Headless data center deployment, Linux only

All three share the same GB202 die, the same 96GB of memory, and nearly identical compute. The differences are the cooling and deployment environment, not raw capability. The most common mistake I see is someone buying the Workstation edition for a multi-GPU rack build, where the active cooling and form factor just aren't designed for that density.

Is the 96GB actually worth paying for?

Only if your model or scene genuinely needs it. If it doesn't, you're paying a large premium for memory that sits idle.
Here's the honest performance picture. On a 30B parameter model, this card pushes throughput close to what a four-card RTX 4090 rig manages, in a single slot. That's a real, meaningful advantage if you're trying to keep a workstation compact.
But for single-user, single-request inference on a model that fits comfortably on a cheaper card, like anything under 32GB, the advantage mostly disappears. A single RTX 5090, at roughly a fifth of the price, shares the same 1.79 TB/s memory bandwidth and handles those smaller models just fine. You're not paying for speed at that scale. You're paying for room to run something bigger.
The real value shows up specifically at the 70B to 120B range, where models are too large for a single consumer card but don't yet require a full multi-GPU cluster. That's the gap this card was built to fill.
**
How does it actually perform for rendering?**

Strongly, and this is where the card's second purpose earns its keep alongside AI work.
The 4th-generation RT cores and updated Tensor cores translate into real gains for creative and engineering workloads, not just AI. NVIDIA's own figures put it at roughly 2.5 times faster than the previous RTX 6000 Ada generation for AI training tasks, and about 4.5 times faster than a 64-core CPU for CFD simulation work. It's also ISV-certified across major CAD and DCC applications, which matters if your studio depends on validated driver support rather than best-effort compatibility.

For teams running mixed workloads, AI-assisted rendering, simulation, and interactive viewport work on the same box, this is genuinely one of the few cards built for exactly that combination.
Should you buy it or rent GPU time instead?
Given how volatile the price has been, renting is often the smarter starting point unless you already know you'll use this card constantly.
Here's what rental pricing looks like right now:
Provider
Rate
AWS EC2 (G7e, single GPU)
~$3.36/hr
RunPod (Community Cloud)
~$1.69/hr
Modal
~$3.03/hr
Northflank (GPU + CPU + RAM included)
~$3.00/hr

Run the math on your actual expected usage before deciding. At $3 an hour, you'd need roughly 5,300 hours of use, a bit over two years of eight-hour workdays, to match a $16,000 purchase price. If your workload is steady and predictable, ownership starts to make sense well before that point. If it's occasional or you're still validating whether you even need this much VRAM, renting lets you find that out without locking in a purchase at a price point that's been moving fast all year.

Who should actually buy this card?

It comes down to a short list of situations where the extra memory genuinely changes what you can do.
You're running local inference on 70B to 120B parameter models and want that on a single card instead of a multi-GPU setup.
You're doing mixed AI and rendering work on the same workstation and need one card that handles both well.

Your studio needs ISV-certified drivers for CAD or DCC software, where compatibility matters as much as raw speed.
You need multi-instance GPU partitioning, running several isolated workloads on one physical card.

If none of these apply, and your models or scenes fit comfortably on a cheaper card, that's a strong signal to look elsewhere first.
What mistakes do buyers make with this card?
A handful of these come up constantly, and all of them are avoidable with a bit of upfront math.

Buying for capacity you won't use. If your largest model fits in 32GB, you're paying a large premium for headroom that never gets touched.
Choosing the wrong edition for the deployment. The Workstation edition's active cooling isn't built for dense multi-GPU racks. Check your deployment environment before choosing.

Pricing off an old quote. This card's price has moved multiple times in a single year. Get a current number before finalizing a budget.

Skipping the rent-versus-buy math entirely. At today's pricing, renting can be the more rational choice until your usage pattern is proven out.

The bottom line

This card earns its price in one specific situation: when you need to fit a large model or a heavy rendering scene into a single slot, and splitting the work across multiple GPUs isn't practical. Outside that situation, you're likely paying for memory you'll never use.
Check your actual model size or scene requirements first, then decide between renting and buying based on how steady your usage will be. That order gets you to the right answer faster than any spec sheet will.

LLM fine-tuning 101: a practical guide for developers

Prateek Navani — Wed, 02 Sep 2026 06:34:08 +0000

A couple of years ago, fine-tuning a large language model meant a rack of expensive GPUs, a dedicated ML team, and a training bill with a lot of zeros in it. Well, now in 2026, a developer with one decent GPU and an afternoon can fine-tune a 7B model on their own data, using tools that are genuinely mature now instead of half-working research code.

I have gone through this process enough times to know where people usually get stuck, so let me walk you through it properly, starting from what fine-tuning actually means and ending with when you actually need serious cloud hardware to pull it off.

What does fine-tuning an LLM actually mean, in plain terms?

It means taking a model that already understands language, and training it further on your own data so it picks up a specific tone, format, or domain knowledge. You are not teaching it to talk. You are teaching it to talk the way you need it to.
Is fine-tuning always the right choice, or should you try something else first?

Try something else first, most of the time. The usual order that works well is:

Prompt engineering first, because it costs nothing and solves more problems than people expect
RAG (retrieval augmented generation) second, when the issue is missing knowledge, not missing behavior
Fine-tuning third, only once you have a clear, measured gap that prompting and retrieval cannot close
Fine-tuning for pure knowledge is usually the wrong tool. RAG handles that better. Fine-tuning is best when you need consistent formatting, a specific tone, or behavior that would take an enormous prompt to describe every single time.
What are LoRA and QLoRA, and why does everyone use them now?
They are the reason fine-tuning became accessible in the first place. Instead of updating every parameter in a model, which for a 7B model can require 80 to 120GB of memory once you include optimizer states and gradients, these methods only train a small additional set of parameters.
LoRA (Low-Rank Adaptation) freezes the original model and trains small added matrices instead, bringing memory needs down to roughly 16 to 24GB for a 7B model
QLoRA goes further, quantizing the base model to 4-bit precision and training only the adapters, pushing requirements down to around 8 to 12GB
That difference is what makes an RTX 4070 Ti or similar consumer card viable for fine-tuning a 7B model, something that would have required a rented A100 not long ago.

How much GPU memory do you actually need for common approaches?

Approach
Approximate VRAM needed for a 7B model
Typical hardware
Full fine-tuning
80 to 120GB
Multiple A100s or H100s
LoRA
16 to 24GB
RTX 4090, RTX 5090
QLoRA
8 to 12GB
RTX 4070 Ti or equivalent

What does the actual fine-tuning workflow look like, step by step?

Once you get past the theory, the practical steps stay fairly consistent across projects:
Prepare and clean a dataset, usually formatted as instruction-response pairs
Pick a base model, commonly something like Llama 3, Qwen, or Mistral
Configure training settings, particularly LoRA rank and learning rate
Monitor training and validation loss, and stop early if validation loss starts climbing

Merge the trained adapters back into the base model
Evaluate the result against your actual target metric, not just training loss
That last step trips people up more than any other. A fine-tune with beautifully low training loss that does not improve your actual target task has still failed.

How much data do you really need to fine-tune a model well?
Less than most people assume. Somewhere between 500 and 2,000 well curated examples is usually enough for a focused task. Data quality matters far more than raw volume. A smaller, cleaner dataset consistently beats a large, messy one.

What toolchain should you actually use in 2026?

The ecosystem has settled down quite a bit, which makes this easier than it used to be.
Unsloth, for speed on a single consumer GPU
Axolotl, for YAML-driven, multi-GPU production pipelines
Hugging Face TRL, when you want full control over the training loop, now unified with support for SFT, DPO, and other training objectives in one library

Which one should a beginner actually start with?

Unsloth, in almost every case. It handles a single 7B model comfortably on consumer hardware, keeps memory usage low, and gets you a working fine-tuned model without needing to configure a complex multi-GPU pipeline first.

When does fine-tuning stop being a single consumer GPU job?
Once you move past 7B to 8B models into the 30B to 70B range, or once you need to serve a fine-tuned model in production with long context windows and multiple models resident at once. That is a very different memory problem than training on your laptop.
This is usually the point where developers start looking at h200 gpu cloud for inference / fine tuning instead of trying to force a larger job onto consumer hardware. A single H200 carries 141GB of memory, enough to hold a 70B model in FP16 with real headroom left over for KV cache, something the previous generation H100 usually cannot do without dropping to FP8 quantization.

What does the extra memory on an H200 actually unlock?

Card
VRAM
Best suited for
H100
80GB
70B models at FP8, standard production inference
H200
141GB
70B models at FP16, long context serving, multi-model colocation

If your fine-tuning or inference workload involves long context windows, RAG pipelines that keep an embedding model and an LLM resident together, or you simply do not want to compromise on precision, the extra memory pays for itself fairly quickly.
How much does this actually cost to run in the cloud?
More than most people expect on hyperscalers, and noticeably less on specialist GPU clouds.

Specialist providers currently price H200 access somewhere around $2 to $4.50 per GPU hour, depending on demand and whether you go on-demand or spot
Hyperscalers like AWS, Azure, and GCP often land closer to $10 to $11 per GPU hour, and frequently require renting a full 8-GPU node rather than a single card

Should you fine-tune locally or rent cloud GPUs?

For 7B and 8B models with LoRA or QLoRA, local hardware is usually fine if you already own a decent consumer GPU. Once you move into 30B+ territory, or need production-grade inference with long context, renting becomes the more sensible option, both financially and practically.

Where this leaves you if you are just starting out

Fine-tuning in 2026 is genuinely approachable. You do not need a research team or a five-figure budget to get real results on a focused task. Start with LoRA or QLoRA on a small, clean dataset, evaluate against your actual target metric, and only reach for bigger hardware once your model size or production requirements actually demand it. That order will save you both time and money.

Machine learning roadmap: how to start a career in AI/ML

Prateek Navani — Mon, 31 Aug 2026 07:13:01 +0000

I get some versions of this question a lot. Someone wants to get into machine learning, they open YouTube, and within ten minutes they have watched three different people recommend three completely different starting points. One says start with math. Another says just build projects with ChatGPT and figure it out later. A third jumps straight into transformers and attention mechanisms.

No wonder so many people give up before they really start. So let me lay out an actual roadmap, the kind I wish someone had handed me instead of a pile of scattered tutorials.

Why do so many beginners get stuck before they even start learning?
Because they skip the boring part and go straight for the exciting part.

Jumping into neural networks or large language models without understanding regression, classification, or how a model actually gets evaluated is like trying to learn advanced grammar in a language before learning the alphabet. It feels productive in the moment, but it falls apart the second something goes wrong and you do not know why.

Is machine learning the same thing as AI?

Not exactly, and this trips up more beginners than you would expect. Machine learning is one part of the broader AI field, specifically the part where systems learn patterns from data instead of following rules someone wrote by hand. Understanding the difference between ai and ml early on will save you a lot of confusion later, especially once you start reading job descriptions that use both terms almost interchangeably.

What do you actually need to learn before touching neural networks?
Two things, and neither of them is optional.
Basic math: linear algebra, a bit of calculus, and enough probability and statistics to understand how models make decisions and where they go wrong

Programming fundamentals: Python, along with NumPy and Pandas for handling data
You do not need to master these in isolation for months. You need enough to understand what is happening inside an algorithm, not enough to teach a university course.
How much math do you really need, and can you skip it?
You can skip going deep, but you cannot skip it entirely. Most people need just enough linear algebra to understand how data gets represented as vectors and matrices, and just enough statistics to understand concepts like variance, correlation, and probability distributions. Skipping this step entirely usually catches up with you the moment you try to debug a model that is not learning properly.

What comes after the fundamentals?

This is where the actual "machine learning" part starts.
Data handling: pulling data from APIs or SQL databases, cleaning it, and doing basic exploratory analysis
Core algorithms: supervised learning like regression and classification, and unsupervised learning like clustering
Model evaluation: understanding accuracy, precision, recall, and why a model that looks great on paper can still fail in production
Most beginners rush through this stage because it feels less exciting than deep learning. That is usually a mistake. This is the stage that teaches you how to think like an ML practitioner, not just how to call a library function.

Where does deep learning actually fit into this timeline?
Once you are comfortable with core ML concepts, not before. Deep learning, using frameworks like PyTorch or TensorFlow, is where you start building neural networks, working with image and text data, and eventually using transfer learning instead of training everything from scratch. Trying to start here skips the reasoning skills that make deep learning make sense in the first place.
How has this roadmap changed because of GenAI and LLMs?
Significantly, and this is the part that is different from a roadmap you might have seen even two years ago.

In 2026, a large share of real ML roles now expect at least some familiarity with large language models, retrieval augmented generation, and fine-tuning existing models rather than training new ones from scratch. Tools like LangChain and LlamaIndex, along with techniques like PEFT for efficient fine-tuning, have become genuinely common in job postings, not just nice extras.
This does not replace the fundamentals. It sits on top of them. Someone who understands core ML deeply and adds GenAI skills is in a much stronger position than someone who only knows how to prompt a model without understanding what is happening underneath.
How long does this actually take, from zero to job ready?
Here is a realistic breakdown, assuming consistent effort rather than occasional weekend study.

Stage
What you are focused on
Typical time
Fundamentals
Math basics and Python
2 to 3 months
Core machine learning
Algorithms, data handling, evaluation
3 to 4 months
Deep learning and projects
Neural networks, transfer learning, portfolio building
3 to 4 months
Job readiness
Interview prep, resume, applying
2 to 3 months

That puts most people at 8 to 12 months for a solid, job-ready foundation, and closer to 12 to 18 months if you are starting with little to no programming background.
Do certifications actually matter, or is it mostly about projects?
Projects matter more, but certifications are not useless. A certificate from something like DeepLearning.AI or a cloud provider's ML certification can support a career switch or fill a gap on a resume, but it will not replace a portfolio of real projects that show you can actually build and deploy something end to end.

What does the job market and pay actually look like in India right now?
Strong, and growing faster than most other engineering specializations.
Entry-level ML roles in India typically start around ₹6 to 12 LPA, depending on the company
Mid-level engineers with 3 to 6 years of experience commonly sit in the ₹18 to 25 LPA range at product companies
Specialized GenAI and LLM roles, including fine-tuning and RAG work, often pay a noticeable premium over general ML roles, sometimes 30 to 60 percent higher
Bengaluru and Hyderabad remain the strongest hubs for ML hiring and pay
The gap between generalist ML engineers and specialists with GenAI, MLOps, or production deployment experience has been widening. Skills matter more than the job title on your resume.
A few quick questions people keep asking about starting in ML
Do I need a computer science degree to get into machine learning? No, but you do need the underlying skills a CS degree would normally teach you, particularly programming and basic math. Plenty of people move into ML from other backgrounds through self-study and structured courses, as long as they do not skip the fundamentals.


![ ](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/ohp4ij2lb6fn2txsjdaf.webp)

Should I learn machine learning or focus on generative AI and LLMs directly? Learn machine learning first. GenAI skills are valuable, but they sit on top of core ML understanding. Skipping straight to prompting and fine-tuning without understanding the basics underneath tends to create a shallow skill set that struggles once problems get complex.

How many projects do I actually need before applying for jobs? Three to five solid, end to end projects are usually enough, as long as they show real range. One project involving data cleaning and a classic ML model, one involving deep learning, and at least one that touches deployment or a GenAI use case will cover most of what interviewers want to see.

Where this leaves you if you are just starting out
There is no shortcut that skips the fundamentals, no matter what a ten minute video promises. But there is a clear, structured path here, and it is shorter than most people assume once they stop bouncing between random tutorials.
Give yourself 8 to 12 months of consistent, focused learning, build real projects along the way, and treat GenAI skills as an addition to your foundation rather than a replacement for it. That combination is what actually gets people hired in this field right now.

CPU vs GPU

Prateek Navani — Mon, 24 Aug 2026 07:07:21 +0000

Someone asks this question almost every week: "Should I just use a GPU for everything?"
Well this article will address this question. SO there are three types of processing unit in the market currently and all of them have different use cases. The best example here would be bottles and a glass. Both can be used for drinking water but you cannot carry the glass everywhere. Similarly CPU, GPU and TPU each are different in the way they are formed and the purpose is different as well. Choosing the wrong processor for a workload will cost you in money as well as the speed.
Here is how CPUs, GPUs, and TPUs actually differ, and how to think about choosing between them.
Quick answer: A CPU (Central Processing Unit) is a general-purpose processor built for sequential logic, orchestration, and handling diverse tasks. A GPU (Graphic Processing Unit) is built for massive parallel processing, which makes it the default choice for deep learning, rendering, and most AI workloads. A TPU (Tensor Processing Unit) is a specialized chip, mainly from Google, built specifically to accelerate the matrix math behind machine learning at scale. None of them replaces the others. They handle different parts of the same job.
The core difference, in one table

CPU
GPU
TPU
Built for
Sequential logic, branching, orchestration
Massive parallel computation
Matrix-heavy machine learning math
Core count
Few, powerful cores
Thousands of smaller cores
Specialized systolic arrays
Best at
Running the system, managing tasks, general code
Training and inference at scale, rendering, simulation
Large-scale ML training and inference, especially on Google Cloud
Where you'll find it
Every computer and server
AI workloads, gaming, 3D rendering
Google Cloud, some specialized ML pipelines
Flexibility
Very high
High
Narrow, purpose-built

That table is a starting point, not the whole story. Here is what each one is actually doing under the hood.
CPU: the one that runs everything else
Think of the CPU as the project manager of your system. It does not do the heaviest lifting itself. It coordinates everything else, decides what runs when, and handles the countless small decisions that keep an application working correctly.
CPUs are built with a small number of powerful cores, each optimized for handling complex, sequential logic quickly. That makes them excellent at tasks with a lot of branching decisions, like running an operating system, managing a database, or executing business logic where step three depends entirely on the outcome of step two.
Here is the part people miss: CPUs are not "worse" at AI. They are simply the wrong shape for it. AI workloads are dominated by matrix multiplication, and a CPU has to do that math one operation at a time across a handful of cores. Even a powerful modern CPU can end up dramatically slower than a GPU on the exact same AI task, not because it is a weaker chip, but because the architecture was never built for that kind of parallel math.
Use a CPU when your workload involves:
Application logic and orchestration
Data preprocessing before it hits a GPU or TPU
Tasks with heavy branching or sequential dependencies
General-purpose computing where flexibility matters more than raw throughput
GPU: the parallel workhorse behind most of AI
GPUs were not built for AI originally. They were built to render graphics, which happens to require the exact same kind of math that neural networks need: thousands of small, simultaneous calculations.
Where a CPU has a handful of powerful cores, a GPU has thousands of smaller ones, all working in parallel. For AI training and inference, that architecture is a much better fit, because the work naturally breaks down into thousands of independent calculations happening at once.
This is why GPUs became the default hardware for deep learning, computer vision, and large language models. It is not that GPUs are simply "faster" in some abstract sense. It is that the shape of the hardware matches the shape of the problem.
Use a GPU when your workload involves:
Training or fine-tuning deep learning models
High-throughput inference at scale
Computer vision or generative AI
Rendering, simulation, or any heavily parallel numerical work
For most teams building or running AI products today, the GPU is where the majority of your compute budget goes, and for good reason.
TPU: purpose-built, and narrower by design
A TPU takes the GPU's parallel philosophy and narrows it even further. Instead of being built for a wide range of parallel workloads, it is built almost entirely for one thing: the tensor and matrix operations that power machine learning.
TPUs use what is called a systolic array architecture, which lets data flow directly through compute elements without the overhead of constantly reading and writing to memory the way a CPU or even a GPU sometimes does. The result is very high efficiency for the specific math that machine learning relies on.
The tradeoff is flexibility. A TPU is not going to run your operating system or handle general application logic. It is a specialist, and specialists are only valuable when the job actually matches their specialty.
Use a TPU when your workload involves:
Large-scale machine learning training, particularly within Google's ecosystem
Production ML pipelines where cost efficiency at scale matters more than flexibility
Workloads already built around frameworks that TPUs are optimized for
If your team is not already deep in an ecosystem built around TPUs, this is usually the third option you evaluate, not the first.
They are not competing. They are collaborating.
This is the part that gets lost in most comparisons. In a real AI pipeline, you are rarely choosing one processor and ignoring the others. You are usually using several together.
A typical production setup looks something like this:
CPU handles data loading, preprocessing, and orchestration.
GPU or TPU handles the actual model training or inference.
CPU again manages the output, logging, and whatever happens next in the pipeline.
The question is rarely "CPU or GPU." It is "which parts of this workload belong on which chip." Get that division right, and everything downstream gets faster and cheaper.
How to actually choose for your project
Skip the spec sheets for a minute and ask these questions instead:
Is the workload sequential or parallel? Sequential, branching logic points to the CPU. Highly parallel math points to GPU or TPU.
How much of your time goes to matrix operations specifically? If most of your compute is matrix multiplication at scale, a GPU or TPU will outperform a CPU by a wide margin.
Are you locked into a specific cloud ecosystem? TPUs make the most sense inside Google Cloud. Outside that ecosystem, GPUs are usually the more practical, portable choice.
Do you need flexibility or efficiency? GPUs give you flexibility across a wide range of parallel workloads. TPUs give you efficiency, but only within a narrower set of tasks.
What does your current bottleneck actually look like? If you are not sure, profile it before buying more hardware. Teams frequently throw more GPU at a problem that was actually a data pipeline bottleneck sitting on an underpowered CPU.
A mistake worth avoiding
The most common mistake is not picking the wrong chip. It is assuming more of the same chip solves a problem that was never about raw compute in the first place.
If your GPU utilization is low, adding more GPUs will not fix it. The bottleneck is often upstream, in data loading, preprocessing, or orchestration, which is CPU work. Fix that first. It is usually cheaper and faster than scaling hardware that is already sitting idle waiting for data.
Frequently asked questions
What is the main difference between a CPU and a GPU?
A CPU has a small number of powerful cores built for sequential, logic-heavy tasks. A GPU has thousands of smaller cores built for parallel processing, which makes it far more efficient for AI, rendering, and other highly parallel workloads.
Is a TPU better than a GPU for AI?
Not universally. TPUs are highly efficient for large-scale machine learning specifically, especially within Google's cloud ecosystem. GPUs are more flexible and work well across a much broader range of AI and non-AI parallel workloads. The better choice depends on your specific pipeline and ecosystem.
Can you run AI workloads on a CPU?
Yes, but it is usually much slower for training and large-scale inference. CPUs work fine for small models, lightweight inference, or preprocessing steps, but they are not built for the matrix-heavy math that dominates modern AI at scale.
Do I need a TPU to train large language models?
No. Most large language model training happens on GPUs. TPUs are a strong option specifically within Google Cloud, but GPUs remain the more common and portable choice across the industry.
What should a small team choose if they are just starting with AI?
Start with GPU-based cloud compute for training and inference, and use CPUs for everything around it, like data preparation and application logic. TPUs are worth considering later, once you know your workload well enough to evaluate whether that narrower specialization actually fits.
The bottom line
CPUs, GPUs, and TPUs are not competing for the same job. They are built for different shapes of work, and the best infrastructure decisions come from matching the shape of your workload to the shape of the hardware, not from defaulting to whatever chip is trending.
Get that match right, and you spend less, wait less, and stop wondering why your bottleneck never seems to move even after buying more hardware.

CPU vs GPU vs TPU

Prateek Navani — Mon, 24 Aug 2026 07:07:02 +0000

Cloud hosting for small businesses: what to look for in 2026

Prateek Navani — Thu, 20 Aug 2026 05:13:30 +0000

Choosing a hosting provider used to be simple. You picked whoever was cheapest and hoped for the best. That approach does not work anymore.
In 2026, your website is often the first place a customer meets your business. If it loads slowly, goes down during a sale, or gets hit by a bot attack, you lose more than a visitor. You lose revenue and trust.
This guide breaks down exactly what small businesses should look for in a cloud hosting provider this year, without the jargon.
What cloud hosting actually means for your business
Cloud hosting spreads your website or application across multiple connected servers instead of one physical machine. If one server has an issue, another takes over. Your site stays online.
This is different from traditional shared hosting, where your site sits on a single server alongside hundreds of others. If that one server slows down or crashes, so does your site.
For a small business, the practical benefit is simple. You get infrastructure that can handle a bad day without going dark, and it can grow with you instead of forcing a painful migration later.
Why 2026 changes the checklist
A few things have shifted the priorities for small business hosting this year.
Small businesses are now a common target for cyberattacks, not just large enterprises. Attackers know smaller teams often lack dedicated security staff, which makes them easier targets.
Traffic patterns have become less predictable. A single social media mention or marketplace listing can send a short burst of traffic that looks like enterprise-level demand for a few hours.
Many businesses that moved everything to pay-as-you-go cloud pricing a few years ago got surprised by unpredictable bills. The lesson learned: elastic pricing works well for spiky workloads, but steady, always-on traffic is often cheaper and more predictable on a fixed-cost plan.
Keep these three shifts in mind as you evaluate providers. They should shape your decision more than a flashy features list.
Key factors to evaluate in 2026

Uptime and reliability Look for a provider that publishes a clear uptime guarantee, ideally 99.9% or higher, and backs it with a service level agreement. Ask what happens if they miss it. A vague promise with no penalty is not a real guarantee. Also ask how failover works. If one server or data center has a problem, does traffic move automatically, or does someone have to notice and fix it manually? Automatic failover is what keeps your site up during an actual incident.
Scalability without a rebuild Your hosting should let you add CPU, memory, or storage without migrating to a new plan or provider. Check whether scaling is instant or requires a support ticket and a wait. If you run an online store, pay close attention to how the provider handles checkout traffic specifically. A provider that handles general browsing well can still choke during a checkout rush if the database and concurrency limits are not built for it.
Security that is actually built in Ask what is included by default, not what is available as a paid add-on. At minimum, expect a web application firewall, DDoS protection, automated backups, and regular patching. A small business rarely has the budget or staff to build this kind of protection in-house. That is exactly why it should come from the hosting provider, not be treated as optional.
Pricing you can predict Cheap entry pricing is easy to find. Predictable pricing at scale is harder. Before signing up, ask what your bill would look like at double your current traffic, and get that answer in writing. Watch for hidden costs around bandwidth overages, backup storage, and support tiers. These are the line items that turn a $10 plan into a $100 surprise.
Support that responds when it matters Look for real response time commitments, not just a "24/7 support" badge on the homepage. Ask directly: what is the average time to first respond, and what is the average time to resolution? A provider that can typically resolve support issues in under two hours is a meaningfully different experience than one that takes a day to reply to a ticket.
Ease of use for a small team Most small businesses do not have a dedicated IT person. Your control panel, deployment process, and backup restore process all need to be usable by whoever is available, not just a specialist. If a feature needs a command line and a support call every time you use it, that is a sign the platform was built for larger technical teams, not yours. Common mistakes small businesses make when choosing hosting Picking the lowest advertised price: Entry-level pricing often excludes backups, SSL, or adequate resources. The real cost shows up on renewal or the first traffic spike. Ignoring the exit plan: Ask how hard it is to migrate away before you sign up, not after you need to leave. Data export limits and migration fees are worth knowing in advance. Assuming more features means better fit: A platform built for large enterprises can be harder to manage for a small team, even if it has more capabilities on paper. Match the platform to your actual technical capacity. Not testing support before committing:. Send a real question to their support team during your trial period. How they respond tells you more than any marketing page. When it makes sense to look beyond your current provider Many small businesses start with a simple, developer-friendly platform because it is quick to set up and easy to understand. That approach works well in the early stages. But as traffic grows or requirements around support, compliance, or regional data centers become more specific, it is worth comparing options. If you are using hyperscaler or global cloud service providers like AWS, Azure, GCP, DigitalOcean, etc. and looking for alternatives to them, focus on providers that keep the same simplicity but add stronger support response times, more flexible scaling, or better regional coverage for your customer base. The right move is not necessarily switching providers. It is confirming that your current one still fits your business as it stands today, not as it stood when you first signed up. Final thought The right cloud hosting choice in 2026 is not about who has the lowest sticker price. It is about who keeps your site online, keeps your data safe, and keeps your bill predictable as your business grows. Take the time to test support, ask about failover, and get pricing at scale in writing before you commit. That homework upfront saves a much harder conversation later.