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

推荐订阅源

雷峰网
雷峰网
博客园 - 聂微东
酷 壳 – CoolShell
酷 壳 – CoolShell
宝玉的分享
宝玉的分享
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
罗磊的独立博客
Hugging Face - Blog
Hugging Face - Blog
T
Tailwind CSS Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
IT之家
IT之家
博客园_首页
博客园 - 三生石上(FineUI控件)
博客园 - 叶小钗
Apple Machine Learning Research
Apple Machine Learning Research
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
量子位
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
人人都是产品经理
人人都是产品经理
美团技术团队
小众软件
小众软件
Jina AI
Jina AI
S
SegmentFault 最新的问题
博客园 - Franky
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com

Swift for Visual Studio Code comes to Open VSX Registry | InfoWorld

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 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 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 Building AI apps and agents with Microsoft Foundry Designing front-end systems for cloud failure No, AI won’t destroy software development jobs Diskless databases: What happens when storage isn’t the bottleneck Vibe coding or spec-driven development? The agentic AI distraction Vibe coding or spec-driven development? How to choose Cloud providers are blinded by agentic AI
Capacity markets could reshape cloud computing
2026-05-15 · via Swift for Visual Studio Code comes to Open VSX Registry | 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.