Power, Compute, and Storage: The Co-Evolution of AI Infrastructure

1. Introduction: One Underlying Theme Behind a Series of News Items

Recent industry signals look scattered at first glance: construction of a unified national electricity market is accelerating, and regional power spot markets have moved into formal operation; open-source large models have made breakthroughs on vertical tasks such as financial modeling, with industry discussion shifting from “parameter scale” to “scenario deployment”; the storage supply chain is tightening in supply and demand with improving sentiment; meanwhile, some institutions have begun to express caution about valuation volatility in the AI sector, believing that capital-side clearing still needs time.

Placed together, these events point to the same technical proposition: as AI moves from “model demos” to “industrialized production,” three questions must be answered—where does the electricity come from, how is compute efficiently scheduled, and how is data stored and retrieved economically. This article follows three threads—power, compute, and storage—and discusses how the three coordinate.

2. Power: How Market-Based Trading Supports Compute Energy Consumption

2.1 From Planned Allocation to a “Power Supermarket”

The traditional power system is dominated by planned allocation, with no effective price signals on either the generation or consumption side. The core of power market reform is to turn electricity into a tradable commodity: generators bid, consumers bid, and time-of-use prices are formed through spot markets. The so-called “power supermarket” is essentially a multi-level trading system covering medium- and long-term contracts, day-ahead and real-time spot markets, and ancillary services. Regional markets moving into formal operation means trading is shifting from “pilots” to “normalized operation,” raising requirements for system stability and throughput accordingly.

For technologists, power trading systems are highly challenging engineering objects: they require second-level or even millisecond-level matching responses, concurrent processing of massive bid sheets, strict settlement consistency, and 7×24 availability.

2.2 Architectural Highlights of a Power Trading Platform

A typical power spot trading platform usually contains the following core modules:

• Bid access gateway: receives declarations from generators and retail electricity entities, requiring rate limiting, authentication, and anti-replay design;
• Matching/clearing engine: computes market clearing results according to bid and clearing rules (such as marginal clearing and uniform clearing price), a typically compute-intensive module;
• Settlement and allocation system: performs daily allocation and monthly settlement based on clearing results, involving consistency processing of massive accounting data;
• Market information publication: real-time push and subscription of data such as clearing prices and load forecasts.

The core logic of clearing can be expressed with simplified pseudocode:

# Minimal illustration of uniform marginal clearing (ignoring constraints and network congestion)
def clear_market(bids, offers):
    # bids: [(price, qty)] demand side, sorted descending
    # offers: [(price, qty)] supply side, sorted ascending
    supply = sorted(offers, key=lambda x: x[0])
    demand = sorted(bids, key=lambda x: -x[0])
    cleared_price, cum_qty = None, 0
    for (bp, bq), (sp, sq) in zip(demand, supply):
        if bp >= sp:
            cleared_price = sp
            cum_qty += min(bq, sq)
        else:
            break
    return cleared_price, cum_qty

Real clearing is far more complex: it must consider unit startup/shutdown constraints, transmission section congestion, network security checks, and more, typically solved with linear programming or mixed-integer programming solvers. This is also why power trading systems have extremely high requirements for compute elasticity—clearing computations tend to concentrate in specific time windows, presenting a clear “bursty” load pattern that naturally suits elastic scaling on the cloud.

2.3 The Electricity Ledger of a Compute Center

Data centers are an important source of new electricity demand. The per-rack power density of large-model training clusters continues to rise, and electricity costs account for a significant share of total compute costs. The industry commonly uses PUE (Power Usage Effectiveness) to measure data center energy efficiency, and further practices include:

• Participating in green power trading and green certificate procurement to optimize carbon accounting;
• Scheduling workloads based on price signals: arranging interruptible and migratable offline training and evaluation tasks during low-price periods;
• Source-grid-load-storage coordination: using energy storage and demand response to flatten the load curve.

The implementation of these capabilities all depends on the integration of price data, load data, and scheduling systems—a typical case of “energy digitalization.”

3. Compute: Large Models Shift from “Scaling Parameters” to “Scaling Scenarios”

3.1 Vertical Scenarios Become the New Arena

Recently, models in the open-source camp have made notable progress on complex reasoning tasks such as financial modeling, and community evaluations show they can compete with leading closed-source models on some tasks. Setting aside specific leaderboard rankings, the trend worth noting is that the evaluation system for AI competition is shifting from general benchmarks to scenario deployment capability.

Financial modeling is regarded as a “hard nut to crack” because it tests multiple capabilities of a model at once:

• Numerical reasoning: involves extensive calculation of financial indicators and sensitivity analysis, with high requirements for arithmetic stability;
• Long context: prospectuses, annual reports, and research reports often run to hundreds of thousands of words, requiring reliable long-document understanding;
• Structured output: modeling results need to land in spreadsheets or code, requiring strict format compliance;
• Traceability: conclusions must be traceable to source data, and hallucination suppression is a hard requirement.

3.2 A General Technical Path for Scenario Deployment

Regardless of which model is used, financial scenario deployment mostly follows a similar technical combination:

1. Retrieval-Augmented Generation (RAG): chunk enterprise knowledge bases, announcements, and financial reports into a repository, then inject retrieved context to reduce hallucination rates;
2. Tool calling and code interpreter: let the model generate and execute code for precise computation rather than “mental arithmetic”;
3. Constrained decoding and structured output: constrain output format via JSON Schema and similar means to ensure downstream systems can parse it;
4. Evaluation set construction: build regression evaluation sets around business definitions to continuously monitor performance drift across model iterations.

A simplified RAG processing flow:

def answer_with_rag(question, vector_db, llm):
    chunks = vector_db.search(embed(question), top_k=8)
    context = "\n".join(c.text for c in chunks)
    prompt = f"Answer only based on the following materials; if uncertain, answer 'insufficient information':\n{context}\nQuestion: {question}"
    return llm.generate(prompt)

3.3 General Capability Categories of Cloud-Based Large-Model Services

For most enterprises, building their own training clusters is unrealistic, and cloud-based large-model services are the more common path. Mainstream cloud providers (such as Baidu AI Cloud) generally offer capability categories including: model services and inference acceleration, prompt orchestration and agent development frameworks, enterprise knowledge bases and retrieval services, content safety guardrails, and monitoring, alerting, and metering systems covering call volumes. The key to selection is not “parameter size” but unit token cost, concurrent throughput, latency distribution, and integration cost with existing data systems.

4. Storage: Tiering and Optimization Under the Data Deluge

4.1 The Technical Logic Behind Tightening Supply and Demand

The direct reason for the improving sentiment in the storage supply chain is the structural change in data supply brought by AI: training corpora, inference logs, vector indexes, and model checkpoints are all expanding rapidly. For enterprises, the essence of the storage problem is finding a balance among performance, capacity, and cost.

4.2 Tiered Storage and Lifecycle Management

The common industry practice is to tier by access frequency:

• Hot data: high-frequency samples in training sets and vector caches for online services, suitable for high-performance block storage or local NVMe;
• Warm data: intermediate results of daily analysis, suitable for shared file storage;
• Cold data: historical archives and compliance records, suitable for infrequent and archive tiers of object storage.

Taking object storage as an example, lifecycle policies can be configured declaratively:

{
  "rules": [
    {"prefix": "raw/",        "days": 30,  "action": "transition to infrequent access"},
    {"prefix": "raw/",        "days": 180, "action": "transition to archive"},
    {"prefix": "checkpoints/","days": 7,   "action": "clean up old versions"}
  ]
}

4.3 Storage Optimization for AI Workloads

• Throughput first: data loading is often the training bottleneck, requiring parallel file systems working with data prefetching;
• Checkpoint engineering: breakpoint saving for large-model training involves terabyte-scale state; incremental checkpoints and asynchronous flushing can significantly reduce stalls;
• Vector retrieval: RAG on the inference side depends on vector databases and caches, and recall latency directly affects user experience;
• Optical interconnect: as electrical interconnects approach their limits in bandwidth and power consumption, the proportion of optical interconnects within data centers and between racks continues to rise—this is also the technical backdrop for recent capital market interest in optical communications.

5. Three-Thread Coordination: Implications for Technical Decision-Makers

1. Cost models must be “full-chain”: when evaluating AI projects, incorporate power, compute, and storage into the same cost table rather than looking only at GPU-hour unit prices;
2. Architecture should be “elasticity-first”: clearing computations, batch training, and offline evaluation are all bursty loads, and cloud elasticity naturally fits them;
3. Data should be “governance-first”: tiered storage and lifecycle policies should be established before data volumes surge; post-hoc migration costs far more than upfront planning;
4. Evaluation should be “business-aligned”: model capability should be judged by business evaluation sets, not general leaderboards;
5. Mapping to the investment perspective: some views hold that after a deep adjustment, market differentiation is more likely to converge and market breadth to expand, and a robust return framework represented by PB-ROE may be more advantageous. For technical teams, this is also a reminder: infrastructure investment should return to the fundamentals of input-output ratio.

6. Conclusion

Power market liberalization gives compute its “food” a price signal, large-model scenario deployment gives compute a clear monetization path, and storage tiering gives data assets an economic management approach. These three are not isolated technical topics but different facets of the same coin called AI industrialization. For developers, understanding this coordination chain has more long-term value than chasing single-point hype.