We’re hiring a Product Manager to lead SiliconMark—what I often describe as the “CARFAX for compute.” We started with GPUs because the same chip can deliver very different real-world performance depending on the system, networking, cooling and configuration. But our ambition is much larger: to build trusted benchmarks for every layer of the compute stack—from chips and clusters to infrastructure, models, tokens and the economic value ultimately delivered. SiliconMark is already one of our fastest-growing products. We’re looking for someone who can own this vision end to end: benchmark design, methodology, scoring, certification, customer experience and go-to-market. This is an opportunity to help define how the entire compute economy measures performance, quality and value—not just what people claim to offer, but what every layer of the stack actually delivers. Apply here: #Hiring# #ProductManagement# #GPU# #AIInfrastructure# #Compute#

Why does neutrality matter in a compute marketplace? Because a platform cannot be truly independent if it owns the GPUs, favors certain inventory, or controls the relationships between buyers and providers. @computeexchange does none of those things. We do not own GPUs or operate data centers. We do not direct buyers toward proprietary inventory. And we do not claim ownership of the relationships created through our platform. Buyers and providers remain free to build and maintain their own direct relationships. Our business is NOT based on gatekeeping those connections. Our role is to make the market work better: • Help buyers query multiple providers • Automate RFQs and comparisons • Independently benchmark performance • Improve transparency across price, availability and quality We organize the market without competing in it—and enable relationships without trying to own them. That is how we are building Compute Exchange: a neutral infrastructure layer for the compute economy. #AIInfrastructure# #GPU# #Compute# #Marketplace#

1/ GPU reserve contracts and GPU futures can price the exact same future months differently. That disagreement isn’t just academic. It can reveal an arbitrage opportunity—or simply tell a compute buyer which way to hedge. 2/ Start with the physical market. If a 6-month H100 reserve costs $2.52/hour and a 12-month reserve costs $2.30/hour, what are months 7–12 actually costing? The answer is not $2.30. 3/ The math: 12 × $2.30 = $27.60 6 × $2.52 = $15.12 The remaining six months cost $12.48. Divide by six, and the reserve-implied forward price for months 7–12 is $2.08/hour. 4/ Now compare that with GPU futures covering the same six months. If the futures strip averages $2.25/hour, the financial market is pricing the same capacity $0.17 above the physical reserve-implied rate. That gap matters. 5/ A $0.17/hour spread sounds small. But over six months: • One GPU: approximately $745 • 100 GPUs: approximately $74,460 • 1,000 GPUs: approximately $744,600 Small pricing disagreements become meaningful at infrastructure scale. 6/ In theory, arbitrage should close the gap. Buy cheaper reserved capacity. Sell the more expensive futures. When futures settle against the spot index, the index exposure cancels, leaving the spread. But compute is not a frictionless commodity. 7/ A GPU contract represents specific hardware, in a specific location, from a specific provider. That creates basis risk, operational risk, utilization risk and—in the harder direction—fulfillment risk. This is why a persistent spread may not be “free money.” 8/ The participants best positioned to close these gaps are compute providers and large buyers. They already control physical capacity, understand utilization and can manage both sides of the trade. Financial traders alone may not be able to enforce convergence. 9/ For most AI companies, the lesson is simpler: You don’t need to execute the arbitrage. You need to read it. Compare: Reserve-implied forward rate vs. Futures strip + your expected provider basis Then choose the cheaper—or operationally safer—route. 10/ One more important point: a forward price is not simply a prediction of where spot prices will be. It also reflects scarcity, financing, access, flexibility, balance-sheet costs and market frictions. The curve is a price—not a prophecy. 11/ As GPU futures begin trading, we’ll finally be able to observe how the physical and financial compute markets interact. Where do the gaps emerge? Who closes them? How much is guaranteed access worth? Those answers will help define compute as an asset class. Full analysis:

1/ GPU prices can move dramatically—but most AI companies still have no way to predict what their compute will cost next year. Compute futures are designed to change that. Here’s how a company running 50 H100s could hedge its annual GPU bill. 🧵 2/ Starting October 5, pending regulatory review, NYMEX plans to list futures tied to Silicon Data’s H100 and B200 rental indices: • GPU1: H100 • GPU2: B200 • 1 contract = 730 GPU-hours • Financially settled—no GPUs change hands 3/ Why 730 GPU-hours? It represents one GPU running for an average month. That makes hedge sizing intuitive: if you continuously rent 50 GPUs, you can hedge one month by buying 50 contracts. 4/ Consider a company renting 50 H100s at: Silicon Data H100 Index + $0.15/hour It needs the GPUs throughout 2027 but fears rental prices could rise sharply. To hedge the full year, it buys 50 contracts for each month: 600 contracts total. 5/ Using Silicon Data’s September 7 implied forward curve, the illustrative 2027 strip averages $2.26 per GPU-hour. The company effectively locks in: $2.26 forward price $0.15 provider basis = $2.41 per GPU-hour 6/ Now imagine two very different outcomes: • The H100 index rises to $3.20 • The H100 index falls to $1.80 Without a hedge, the annual compute bill differs by more than $330,000. With the hedge, the net annual cost is approximately $1.057M in either case. 7/ If prices fall, the company would have been better off without the hedge. That isn’t a flaw—it’s the trade. Hedging means giving up the possibility of a cheaper year in exchange for protection against a much more expensive one. 8/ The strategy also works in reverse. A compute buyer worried about rising prices buys futures. A neocloud or infrastructure provider worried about falling rental revenue sells futures. The same market can create budget certainty for buyers and bankable revenue for providers. 9/ Futures don’t eliminate every risk. Companies still need to manage: • Basis risk between their provider and the index • Hyperscaler vs. neocloud pricing differences • Daily variation margin • Initial margin • Bid-ask spreads and early-market liquidity 10/ Until now, companies could reserve physical capacity—or remain exposed to future prices. Compute futures introduce a third option: Rent from the provider you choose while managing the market price separately. Our step-by-step practitioner’s guide: This is an illustration of contract mechanics, not a recommendation to trade. Futures involve leverage and daily cash requirements. Contract terms remain subject to the CME rulebook and regulatory review.

Compute futures are no longer just a concept. The next question is: how do you actually use them? Our new practitioner’s guide uses a 50-H100 GPU example to explain hedging, daily settlement and basis risk—step by step.

. @Silicon_Data and @computeexchange were both built after the ChatGPT moment. But I still wouldn’t call either company truly AI-native—yet. Being founded in the AI era doesn’t automatically make an organization AI-native. Giving every employee access to ChatGPT certainly doesn’t. I’ve been thinking about the organizational structures of both companies, and the exercise has made me realize that AI-native organizations will not all look the same. @Silicon_Data is organized around building the independent reference layer for the compute economy: data infrastructure, indices, benchmarking, research, product commercialization and market adoption. @computeexchange is organized around creating liquidity: sourcing, verification, pricing, matching, contracting and settlement. Agents can transform both companies—but differently. At @Silicon_Data, agents can accelerate data analysis, research, product development, content production and customer intelligence. At @computeexchange, they can automate inventory normalization, provider onboarding, RFQs, matching and transaction workflows. This has also changed how I think about organizational design. Traditional companies are built around people, roles and reporting lines. Knowledge is distributed across individual brains, inboxes, documents, Slack channels and meetings. In that sense, a human organization is web-based: every person is a node, and work moves through the relationships connecting those nodes. An agent organization may be fundamentally different. It is Brain-based. Instead of every agent holding a fragmented version of the company, agents can operate from a centralized institutional Brain containing shared knowledge, history, decisions, priorities, permissions and real-time operating context. Each Brain sits a task-ownership system. Instead of asking, “Whose job is this?” the organization asks: What needs to be accomplished? What context and authority does it require? Should a human, an agent or a human-agent team own it? What constitutes completion? Who remains accountable? Humans continue to operate through networks of relationships, judgment, negotiation and trust. Agents operate through centralized knowledge, shared context and structured task ownership. The task layer tells you what needs to happen, who—or what—owns it, and whether it has actually been completed. To me, becoming AI-native means continuously redesigning this boundary between people, agents, knowledge and work. We are still experimenting. I’ll share what works, what fails, and how the two organizations evolve.

1/ My X account was compromised today. From approximately 8:34 AM to 1:22 PM ET, the posts from this account were not mine. The account is now secure. 2/ The part that matters most: a cryptocurrency token using Silicon Data's name was created from my account by whoever had access to it. It has nothing to do with me or with Silicon Data. We have never issued a token, and we never will. 3/ If you saw those posts, please ignore them and don't share anything from that window. We'll share more once we've finished looking into what happened. 4/ One more thing: anything official from Silicon Data comes only from Please be cautious of any other accounts or messages claiming to represent us in the coming days.

Super fun 3-hour session with the @McKinsey team today talking about how enterprises around the world are actually consuming AI. We went from GPUs → tokens → open vs. closed source → enterprise use cases → ROI. And somehow, if you talk about AI consumption long enough, it always turns into philosophy: What is the ROI of compute? What is the ROI of labor? What is the ROI of human time? I’m definitely not qualified to answer the last two 😂 But I do think these are becoming real economic questions, not just philosophical ones.

I agree that we’re “underfollowed” on Twitter. It is great that at 40, I get to figure out how to be popular. I thought I retired from that game in third grade 😂 What should I be retweeting and sharing?

I love when people ask, “But what happens to your kids when you travel for work?” Obviously I leave them at the Bronx Zoo. Usually with the giraffes. Sometimes the lion den if they’ve been skipping cardio.

One of my favorite AI market paradoxes right now: 📈 Silicon Data GPU indices = bullish signal 📉 Silicon Data Token indices = bearish signal But they’re not contradictory. Compute is getting more valuable while intelligence is getting cheaper. Scarce infrastructure + rapidly improving model efficiency + fierce competition = higher GPU prices, lower token prices. The picks and shovels are appreciating while the output gets commoditized. Welcome to AI economics.

Excited to share today’s @SiliconANGLE exclusive on @ComputeExchange. AI compute is fragmented. We’re building the neutral market layer to bring it together — verified GPU inventory, RFQs, forwards, secondary sales, token commitments, and ultimately automated trading. We don’t own GPUs or take positions. We’re here to make compute more transparent, trusted and liquid.

Compute is becoming a tradable asset class. With CME futures launching on @Silicon_Data indices this October, we’re also opening up H100 and B200 index access for OTC trades, swaps and forwards — complimentary for eligible trading use. If you’re building or trading compute products, DM us. We want to help build liquidity.

Trust is infrastructure. As compute becomes a tradable asset class, independent benchmark calculation matters. Excited to appoint Syntax Data as calculation agent for Silicon Data’s indices — another step toward institutional-grade markets for compute.

Here’s our paper: And feel free to give SiliconMark a try: Our free tier allows you to benchmark and certify your GPUs at zero cost.

I’ve had a lot of conversations with people who want to finance and trade compute as an infrastructure asset. One question I keep coming back to: once you’ve financed a GPU server for five to ten years, how do you actually know what you own—and what condition it’s in—throughout those five years? How do you independently verify which physical GPUs and components are actually there? How do you know those servers are being properly operated and maintained when they may sit in a data center thousands of miles away? And how do you know the equipment you financed on Day 1 is still performing as expected on Day 1,000? Physical inspection doesn’t scale. Self-reporting isn’t enough. You need third-party verification. That’s what we’re building with SiliconMark. We work with infrastructure providers to track machines down to component-level UUIDs—GPU, CPU and the broader system—and build a persistent identity and performance history for the asset. You can know what the machine is, its expected depreciation curve, how it is actually performing, its thermal behavior and quality history, with timestamped records over its lifecycle. And because our tests are open-sourced, the results are reproducible and independently verifiable. Think of it as a digital service record for compute infrastructure, maintained by an independent third party. For equipment financing, knowing the original purchase price isn’t enough. You need to continuously know what the asset is, that it exists, how it has been treated, how it is performing, and ultimately what it is worth. If GPUs are going to become a financeable and tradable institutional infrastructure asset class, this verification layer is a fundamental building block. Third-party verification is the trust layer between the physical GPU and the financial asset.