惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
Visual Studio Blog
量子位
大猫的无限游戏
大猫的无限游戏
Hugging Face - Blog
Hugging Face - Blog
S
SegmentFault 最新的问题
Blog — PlanetScale
Blog — PlanetScale
月光博客
月光博客
Google DeepMind News
Google DeepMind News
小众软件
小众软件
WordPress大学
WordPress大学
宝玉的分享
宝玉的分享
MongoDB | Blog
MongoDB | Blog
B
Blog RSS Feed
博客园 - Franky
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
B
Blog
博客园 - 聂微东
The GitHub Blog
The GitHub Blog
Recent Announcements
Recent Announcements
Y
Y Combinator Blog
Microsoft Security Blog
Microsoft Security Blog
雷峰网
雷峰网
Jina AI
Jina AI
酷 壳 – CoolShell
酷 壳 – CoolShell

InfoWorld

AWS boosts CloudWatch Logs query limits by 10x to ease debugging for developers, SREs 21 LLMs tuned for special domains The new AI lock-in AWS adds Advanced Prompt Optimization tool to Bedrock Four cutting-edge tools for spec-driven development Anthropic puts Claude agents on a meter across its subscriptions Notion courts developers with a platform for AI agents and workflow automation Using continuous purple teaming to protect fast-paced enterprise environments A better way to work with SQL Server Evidence-driven workflows: Rethinking enterprise process design AWS debuts Graviton-powered Redshift RG instances to cut analytics costs SAP’s AI promises last year? Most are still rolling out First look: Lemonade serves up local AI with limitations GitLab CEO sees developer tool bill increasing 100-fold Red Hat adds support for agentic AI development What’s new and exciting in JDK 26 Kill the loading spinner with local-first data and reactive SQL A networking revolution at AWS Tokenmaxxing is super dumb Hands-on with React, Supabase, and PowerSync How to add AI to an existing product (without annoying users) Your AI doesn’t need another database What happens when engineering teams reorganize around AI agents Python isn’t always easy When cloud giants meddle in markets 12 model-level deep cuts to slash AI training costs The best new features in Python 3.15 Teradata launches platform for enterprise AI agents moving beyond pilots Three skills that matter when AI handles the coding MongoDB targets AI’s retrieval problem
Capacity markets could reshape cloud computing
2026-05-15 · via InfoWorld

An article from AI CERTs reporting on the Anthropic-SpaceX capacity arrangement caught my attention because it highlights a possibility the cloud market has been moving toward for years but has never fully embraced. The traditional assumption has always been simple: If you need elastic infrastructure at scale, you go to a hyperscaler such as AWS, Microsoft, or Google. They own the data centers, they understand multitenancy, and they know how to deliver computing as a repeatable service. The article suggests something different may now be emerging. Organizations with excess capacity may be able to act, at least temporarily, like cloud providers.

This is a meaningful shift. If access to compute, power, and networking can be packaged and sold by enterprises, AI infrastructure operators, telecoms, colocation players, and perhaps even large private data center owners, then cloud computing becomes less about who invented the model and more about who has available capacity right now. In other words, the market starts to behave less like a neatly segmented cloud industry and more like a dynamic exchange for compute resources.

The economics make sense

The positive side of this trend is easy to understand. The first and most obvious benefit is price. Non-hyperscale providers with excess capacity are often not carrying the same cost structures, margin expectations, or service packaging as the major cloud vendors. If they have unused GPUs, underutilized clusters, or stranded power and cooling resources, they may be willing to sell access at rates that are materially lower than the traditional cloud market. For enterprises under pressure to control AI and infrastructure costs, that matters.

The second benefit is efficiency. If capacity already exists somewhere and can be used by another party, we may be able to satisfy demand without immediately building new data centers, deploying more hardware, or consuming more incremental power than is already committed. In a market where new capacity takes time, capital, permits, and energy planning, repurposing existing excess supply is not just financially attractive, it is operationally smart. We have spent years talking about sustainability in cloud. One practical path to sustainability is making better use of what is already running.

The third benefit is optionality. Enterprises increasingly want alternatives to hyperscaler lock-in, especially for specialized workloads such as AI model training, inference, analytics, and bursty high-performance computing. If a broader market of capacity suppliers emerges, buyers gain leverage. They may not move every workload away from the major providers, but they will have more negotiating power and more architectural flexibility.

The operational challenges

The problem, of course, is that most organizations with excess capacity are not cloud providers. They may own infrastructure, but owning infrastructure is not the same thing as delivering cloud services. True cloud providers offer automation, provisioning, identity controls, billing, observability, policy management, resilience, service-level agreements, and mature multitenant architectures. Rank-and-file capacity suppliers typically do not.

That means a great deal of coordination has to occur in the background to make this work. Networking has to be integrated. Security controls have to be mapped. Data governance has to be enforced. Capacity has to be monitored and scheduled. Performance isolation has to be managed. Contracts, compliance responsibilities, and operational support boundaries have to be spelled out in painful detail. None of that is impossible, but none of it is free.

This becomes even more difficult when you consider multitenancy. Hyperscalers are built to let many customers safely and efficiently share infrastructure. A one-off capacity supplier may be set up for internal use, single-purpose use, or a narrow class of workloads. Converting that into something that behaves like a cloud service for outside tenants requires tools, expertise, and process maturity. In many cases, the buyer will end up doing part of that heavy lifting. That reduces the pricing advantage and introduces risk.

Excess capacity can be temporary

Another negative is duration. Excess capacity is excess only until the owner needs it back. That is the part many enthusiastic buyers will underestimate. You may enter into an arrangement because another organization has idle GPUs, spare compute, or available power headroom, but those assets are often strategic. At some point, the owner may decide it needs that capacity for its own workloads, new customers, or internal growth.

Then you have a migration problem. You move in, integrate systems, adapt security models, tune performance, and settle into operations, only to discover that the clock was always ticking. Now you have to move out. That means data movement, workload refactoring, revalidation of controls, downtime planning, cost overruns, and renewed security review. Temporary capacity can solve an immediate supply problem, but it can also create a deferred complexity problem that lands squarely on the enterprise customer.

Security concerns are especially important here. Every temporary hosting relationship expands the trust boundary. Data may reside in unfamiliar environments. Administrative access patterns may differ from internal standards. Logging, encryption, and incident response processes may not align cleanly. Enterprises can manage those risks, but only if they treat these deals as serious platform decisions, not opportunistic side arrangements.

A proven concept, despite risk

Still, I think the core concept has now been validated. The idea that enterprises can exchange or lease capacity outside the hyperscaler model is no longer theoretical. In certain cases, it may be a very viable option, especially for organizations that need lower-cost compute, specialized hardware access, or interim capacity while waiting for longer-term infrastructure plans to catch up.

The next interesting question will be market structure. Today, these arrangements are likely to be negotiated business to business, one deal at a time. That does not scale well. Over time, I suspect we will see intermediary systems emerge that function more like brokers or exchanges. Such platforms could discover available capacity, classify it, verify security and compliance characteristics, normalize service definitions, and automatically match buyers with suppliers. That would make the market far more efficient than manually brokering deals one by one.

If that happens, cloud computing changes again. It stops being defined solely by branded public cloud platforms and starts to include federated, brokered, and dynamically sourced capacity markets. Some of that capacity will come from hyperscalers. Some of it will come from specialized providers. Some of it may come from organizations that never intended to become cloud sellers but find themselves participating anyway because the economics are too compelling to ignore.

I would not overstate the maturity of this model yet. The operational, contractual, and security issues are real, and the lack of true cloud-native multitenant design among many suppliers is a serious limitation. However, the potential upside is also real. If enterprises can access lower-cost computing outside the hyperscaler ecosystem, and if excess capacity can be productized safely and efficiently, this could become an important new sourcing option.

I will keep an eye on this space. There may be real benefit here, especially for enterprises looking for a practical path to lower-cost computing and more flexible sourcing. At the very least, it is an interesting development. At best, it may be the beginning of a broader market where compute capacity itself becomes a tradable service, available from far more players than the cloud industry has traditionally allowed.