We Moved Computing to the Cloud. Could AI Bring It Back?
Summary
New local AI computers are powerful enough to share across a team. Here is when owning that capacity can make sense, when the cloud still should, and the managed-infrastructure business in between.
I'm not someone who gets excited about computer hardware.
I don't follow every new processor or GPU launch. More memory or a faster chip doesn't interest me unless it solves a real problem.
For me, hardware is a tool. What matters is what we can build with it, how much it costs, and whether it makes business sense.
The October 2026 announcements from Microsoft and NVIDIA caught my attention anyway. Not because of the chips. Because of the business options they create.
For years, the default advice was simple: don't buy servers, move to the cloud. Powerful AI models can now run on a computer that sits in an office. That raises a practical question.
What if a company brought some of its computing back inside the building? And what if that created a market for businesses that set up and manage those machines?
How cloud computing changed the business
Before AWS, Microsoft Azure, and Google Cloud became the default, many companies ran their own servers. They bought hardware, networking gear, storage, and cooling, and they hired people to keep it running. That was a large investment before a product had customers.
Cloud computing changed the sequence. A company could launch an application without buying servers first. It rented capacity and paid for what it used. Startups could grow without a data center. Established companies could scale an application without a procurement project.
Today, businesses use the cloud for almost everything, from a website to a large AI model. Cloud computing did not eliminate data centers. It moved much of that work into facilities the cloud providers operate.
For many workloads, that is still the right trade. The economics are no longer the same for every workload.
What changed
On October 7, 2026, Microsoft opened preorders for two devices built with NVIDIA technology.
Surface Laptop Ultra starts at $2,599. Microsoft says supported configurations can run AI models exceeding 120 billion parameters locally, with up to 128 GB of unified memory. Memory varies by configuration, and the GPU can address less than the total. The starting price is not the high-memory machine.
The Surface RTX Spark Dev Box is $5,999. It is a compact computer for local AI development, with 128 GB of unified memory and the same class of model-size claim. Microsoft is taking U.S. preorders, with shipping beginning in November 2026.
NVIDIA's DGX Station for Windows is a different machine. Announced in May 2026 and expected from PC makers in the fourth quarter, NVIDIA says it can run models of up to one trillion parameters, with up to 748 GB of coherent memory. It should not be confused with the $5,999 Dev Box.
| Machine | Price | What the vendor says it can run | What it is |
|---|---|---|---|
| Surface Laptop Ultra | From $2,599 | Models exceeding 120 billion parameters, in supported configurations, with up to 128 GB of unified memory | A laptop. The entry configuration is not the 128 GB model. |
| Surface RTX Spark Dev Box | $5,999 | Models exceeding 120 billion parameters, with 128 GB of unified memory | A compact desk computer for local AI work |
| DGX Station for Windows | Price not published | Models up to 1 trillion parameters, with up to 748 GB of coherent memory | A deskside system expected from PC makers in late 2026 |
Microsoft also cites up to 1 petaflop of AI performance for the Surface machines. That figure is a theoretical FP4 number that uses sparsity. It is not a measure of how fast a document summary or a code review will finish.
Model size, by itself, does not tell you whether a system is useful. Speed, memory, software support, and how many people share the machine all matter.
The shift is still real. AI computing that once required a large cluster can now run on a smaller system. That gives a company another place to put the work.
What if 10 employees shared one AI computer?
Imagine a company with 100 employees. Today, many of them use ChatGPT, Claude, GitHub Copilot, or another cloud AI service. The company pays for subscriptions, usage, or both.
Now imagine a different setup. The company buys 10 powerful AI computers. Each one serves a group of 10 employees over the internal network. People keep their normal laptops. The expensive hardware is shared, the way a file server or a build machine already is.
When someone asks an assistant to summarize a document, review code, or search internal knowledge, the request goes to that shared system. Useful work for a local model includes:
- Writing and reviewing code
- Searching company documents
- Summarizing meetings and reports
- Analyzing internal financial data
- Automating routine business tasks
For requests the local model handles, the company is not paying an external AI provider per token. A token is a small piece of text. Many cloud AI services bill by how many tokens they process.
One computer may not keep up if all 10 people run heavy tasks at once. The company has to measure real usage before it decides how many machines to buy. A local model may also be weaker than the best cloud model. Both limits belong in the decision.
The idea is still worth pricing. Instead of buying AI capacity separately for every employee, a company can share it like any other office resource.
Run everyday AI tasks locally. Use cloud AI when needed.
Employees
Existing laptops
- Documents
- Code reviews
- Internal search
Shared AI
Company network
- Local AI models
- Routine requests
- Shared capacity
Cloud AI
Approved fallback
- Advanced models
- Extra capacity
- Cloud services
Cloud requests must follow company security policies.
Three Questions Before You Buy
Is usage steady? Is model quality good enough? Is the total cost lower?
Also consider security, reliability, and maintenance.
Would it actually save money?
Take one AI computer at $6,000, close to the Dev Box price, and plan to use it for three years.
$6,000 divided by 36 months is about $167 a month for the hardware. Split across 10 employees, that is about $17 per person per month.
| Line | Illustrative cost |
|---|---|
| Hardware, $6,000 over 3 years | About $167 per month |
| Same hardware, shared by 10 people | About $17 per person per month |
| Electricity, maintenance, software, security, support, and a spare | Extra, and often larger than the hardware line |
| Cloud AI bill | Lower only for the requests the local system actually handles |
The hardware line sounds affordable. It is not the total cost. The company still pays for power, upkeep, software, security, and someone who answers when the machine stops. It may need a second machine so one failure does not stop the team.
Usage decides the comparison. If people rarely use AI, the machine can cost more than a cloud subscription. If the company sends thousands of requests a day, owning capacity starts to look different. A cheaper local model is a poor purchase if it cannot finish the work.
Local AI will not always be cheaper. The useful change is that a company can now run the numbers, with a second option on the table.
Own the routine, rent the spike
A lower hardware price is not a strategy. A company needs a rule for where each workload goes. Three questions are enough to start:
- Is the usage steady, or does it spike?
- Does the data need to stay on the company network?
- Will a capable local model do the job, or does the task need the strongest cloud model?
| Pattern | Where it belongs |
|---|---|
| Steady, internal, and a local model is good enough | A shared machine the company owns |
| Bursty, global, or dependent on the best available model | Cloud AI or cloud hosting |
| A mix of steady and unpredictable AI workloads | Local AI for routine work. Cloud AI for approved requests that need extra capacity or a stronger model. |
That last row is the one I expect most offices to land on. Routine work stays on the local system: search, summaries, a first pass at code review, and questions about internal documents. Cloud AI handles approved requests that need extra capacity or a stronger model.
A full queue does not send every request to the cloud. Restricted data stays on the company network. Cloud fallback follows the company's security and data-handling policy.
Companies already split other tools this way. They own laptops. They rent burst capacity. AI can follow the same split. Own the routine. Rent the spike.
If you are already deciding which AI work should call your own systems and which should stay in a chat window, the same boundary shows up in Private RAG Systems Without External APIs and in the path from AI model consumer to AI application builder.
Why stop at AI? What about application hosting?
The second opportunity is quieter. We often assume an internal application belongs on AWS, Azure, or Google Cloud. Many should. Not every one does.
Consider a small financial advisory firm. It might run a reporting tool, a service that processes uploaded documents, a dashboard of business performance, and an assistant that searches research files. Some of that can run on a capable computer in the office. Businesses have hosted internal applications on local servers for decades. What changed is how much work a smaller machine can do, including local AI next to the application.
Local hosting brings the old questions back:
- What happens when the power goes out?
- What if the office internet fails?
- Who installs security updates?
- Where do backups live?
- Who responds when the machine stops?
Those questions matter more for anything a customer touches. A $6,000 computer is not a substitute for infrastructure that has to stay up, serve people in many regions, or grow quickly. For a system that needs high availability, global access, or fast scaling, the cloud is still the better default.
For a quiet internal tool, local hosting can be a real option again. Choose the location from the application's needs. The cloud should be a decision, not a habit.
A business opportunity: managed AI infrastructure
Most small and mid-sized companies do not have AI infrastructure engineers. They may want local AI. They do not want to own the care of the machines.
A provider could manage this infrastructure for businesses.
- Help the customer pick hardware that matches real usage, not a spec sheet
- Install approved models and keep them updated
- Connect employees over the company network
- Watch capacity, apply security updates, and keep backups
- Send an approved request to a cloud model when policy allows extra capacity or a stronger model
The customer buys or leases the hardware and pays a monthly fee to have it managed.
Managed IT providers already do a version of this for company-owned infrastructure. AI adds a workload those firms can support, and it adds a reason for a new firm to exist. The operating model looks like the shared platform team I describe in How Software Engineering Teams Should Look in the AI Era: one group builds the shared capability, and everyone else uses it.
Picture a provider serving 50 small companies. Each customer has one or more local AI machines. The provider watches them from a central platform: usage, approved models, updates, and a path to cloud AI for approved requests that need a stronger model or more capacity.
The provider does not need to train a foundation model or build chips. The value is making local AI infrastructure ordinary to operate.
That business is more interesting to me than the hardware launch. The companies that make this easy may capture more of the value than the companies that only sell the box.
What this means for AWS, Azure, and Google Cloud
The cloud is not going away. Providers solve problems that are expensive for one company to solve alone: global infrastructure, flexible capacity, managed databases, security services, and deployment options that already work.
A desk-sized computer does not replace that. It does let a company be more selective.
Some AI requests can run locally. Some internal applications can run on hardware the company owns. Other workloads stay in the cloud. A request can start on the local system and use a cloud model when policy allows it and the task needs a stronger tool.
This is not a contest between cloud computing and local computing. It is a chance to use each one where it fits.
Small, shared computing will become more common
I don't expect every company to build a data center. I do expect more offices to have a small shared computer for AI, the way they already have shared storage and a network.
One machine might serve a group of about 10 people. A larger team might have several. Remote employees can connect through the company network, with the same security expectations as any other internal system.
IT teams already manage laptops, networks, storage, and security tools. Shared AI computing can become another service they provide, or another service they hire out.
The valuable companies in that market may not be the ones selling the hardware. They may be the ones that help a business use it without hiring a specialist for every machine.
Final thought
AWS, Azure, and Google Cloud made it easy to rent computing power instead of buying servers. Local AI hardware gives companies another option. It is early. These machines still have to prove themselves on real work, with real concurrency, real model quality, and a real support plan.
For years the advice was: don't buy servers, move to the cloud.
The next phase can be more specific. Rent what you need to scale. Own what you use every day.
Not every workload belongs in the cloud. And not every workload belongs on a computer in the office. The opportunity is knowing the difference.
References
Related reading
Private RAG Systems Without External APIs
Mid-sized teams can build secure, self-hosted AI assistants with open-source models, vector stores, and RAG — without routing proprietary data through third-party APIs.
From AI Model Consumer to AI Application Builder
A practical guide for .NET engineers moving from chat prompts to RAG, MCP servers, agents, and agentic workflows — with security patterns, architecture diagrams, and platform mental models.
How Software Engineering Teams Should Look in the AI Era
The traditional model repeats the same roles across siloed domain teams. The AI-era model connects specialized squads through an Efficiency Team building shared MCPs, RAG pipelines, agents, and agentic workflows.