Nvidia backstopped the value of its GPUs and called this a new financial asset class. When Tesla did this for the model S, no one decided Teslas or even robotaxis are the next commodity to trade on the CME.

In 2022, Tesla tied the value of a second hand Model S to that of a Mercedes S class. The idea was to underwrite the value of the car so that people buying them on finance would have lower monthly payments. The lender would have a guaranteed minimum future value of the car, allowing lower capital repayment and reducing the risk allowing a lower interest rate.

Tesla didn’t call this a new investable asset class.

Nvidia did the same thing last month for GPUs. But now they’re considered an asset class.

Nvidia claims that “software innovation allows an AI factory to produce more intelligence at lower cost throughout its life, extending its useful economic value.”[i] I don’t think Tesla made similar claims about their cars though arguably they could have. Well maybe not so much now unless Full Self Driving does actually get delivered but at the time they could have.

So, what makes GPUs an investable asset but not cars. What makes one depreciating asset a new tradeable commodity but not another?

Partly a rhetorical question, but I also got into some depth on this topic last week.

AI Compute: The Next Oil or the Next Casino

There’s increasing talk about compute, and AI factories in particular, becoming the next asset class. Are we building the next commodity market or the next virtual Vegas.

Flux by HMx LabsHamza

[i] https://blogs.nvidia.com/blog/nvidia-ai-factory-compute/?ref=cloudhpc.news

If compute became an exchange traded commodity tomorrow, would you manage to adapt how you use cloud capacity?

No?

Well, it’s a good thing that the CME proposals that were originally to slated start trading on Oct 5^th have been delayed then huh 😁

I am of course ignoring the fact that those wouldn’t have physically settled, and they were limited to GPUs only, but let’s pretend for a minute. What if we could exchange trade cloud capacity tomorrow. How does that change your use the cloud compute?

Would you need a trading desk to secure the compute you need? Could your supercomputer trade and secure its demands automatically? Fun questions to speculate on.

Might also not be as far away as you think if the big players keep pushing the narrative they are with making compute a tradeable commodity. It probably also won’t be something you can adapt to overnight unless you’re already able to run elastic multi cloud workloads efficiently.

Something to ponder on.

HPC Club: Multi Cloud Software Defined Supercomputing

Booking is now live for the next HPC Club event. Oct 14, Tower Bridge, London.

Flux by HMx LabsHamza

There was some really interesting stuff this week but first let’s get the headline grabbing boring stuff out the way.

Nvidia’s Vera Rubin seems to have finally gone from coming soon to actually in use. And not just by someone running a couple of benchmarks. A real Bonafide customer. Though neither CoreWeave (who are running it) nor Nvidia seem to be saying quite how many they have up and running. I’m going to be charitable and assume that we have at least a full NVL72 if not a few of them.

Of course, AMD can’t let that happen without also making some noise about Helios, their rack scale alternative, and sure enough HPE announced its buying about $1.2billion worth of them.

Before we get to the interesting new stuff, time to wave goodbye to some old stuff. Both AWS and Azure were busy sunsetting things last week, some of which might take you a minute to deal with. AWS Research and Engineering Studio will no longer be officially supported. It’s not going anywhere in a hurry, if you have it running it will stick around but if it goes wrong, don’t expect any help from your friendly AWS solution architect & friends. Amazon’s recommendation, naturally, is to move to Parallel Compute Service.

Microsoft are putting HPC Pack out to pasture too (I swear they announced this a couple of weeks back too but maybe I’m imagining it). Microsoft, of course, would like you to move to Azure Cycle Cloud Workspace for Slurm or whatever insane name they have for that this week.

If you’d like to explore your options for alternative schedulers though, you can start off with our scheduler selection tool. At least narrow down the short list a bit first to see what your options are.

Ok, interesting stuff! CERN have decided to include Signaloid in their openlab heterogenous architectures test bed. I’d never heard of Signaloid but CERN does some incredibly cool stuff and if they figured its worth a look, its definitely worth a look.  The claims are impressive to say the least. I can’t say I understand what exactly it does or how it works any more than before I started reading their web site but 2000x speed ups for Monte Carlo based calculations? This needs further investigation! I mean quantum computing can carry on taking its sweet time if this stuff works! Guess I’ve just found yet more toys to try and play with.

We’ve been busy at HMx towers last week too, Sahana has put together a few words on concentration risk, you know that thing your favourite regulator keeps asking you about.  Combine that with a little bit about multi cloud and you’ve probably got just enough information to start wondering how to deal with this stuff. Which probably means you want to come along to HPC Club to have a chat with some other HPC nerds about it. Which bodes well as we have a few spots left still. I wouldn’t hang about to book your place though!

All the News in Depth

Cloud and vendor releases for Supercomputing & HPC (and AI too if you change the filters) including all the VMs deprecated on Azure. Oh if you're wondering where all the Google release notes were for the last few weeks, I think that should be fixed now!

Is Vera Rubin finally a reality beyond closed door benchmarks and single machine showcases? CoreWeave seems to have some.

AMD wasn’t going to let that story out this week without their own about Helios (their rack scale alternative) going out too.

Both AWS and Microsoft Azure have decided you need to upgrade your HPC stack by announcing the retirement of AWS Research and Engineering Studio and Microsoft HPC Pack.

Now might be a good time to check out the Scheduler Selector tool if you need to weigh up your options. 

2000x speedups for your Monte Carlo sims…err yes please! And evidently CERN is sufficiently curious too and wants to try out Signaloid. Had never heard of them till I saw this but colour me curious!!

More detail from Signaloid here, but honestly it didn’t clarify much for me. Very tempted to just try this out on some option pricing. 

HMx Labs Updates

Making the most of the cloud? Its elastic you know... and you can use lots of them

Elastic Compute in the Cloud

Elastic compute in the cloud? An old idea but is it viable? How much work is involved?

Flux by HMx LabsHamza

Concentration risk it is becoming both more important and harder to identify (when it sits behind another vendor)

Cloud Concentration Risk: The Resilience Paradox

This article explores cloud concentration risk, linking Federal Reserve, PRA and Swiss regulatory perspectives with practical implications for financial institutions, including shared dependencies, multi-cloud resilience, exit planning and systemic risk.

Flux by HMx LabsSahana Christie

Small number of tickets still left for HPC Club

HPC Club: Multi Cloud Software Defined Supercomputing

Booking is now live for the next HPC Club event. Oct 14, Tower Bridge, London.

Flux by HMx LabsHamza

Off Topic

Will Quantum computing ever work? Hmmm

AWS wanting to shift its GPUs into an SPV is pretty interesting. I don’t necessarily agree with the conclusions of this YouTuber… I could equally well argue that this actually proves Nvidia’s point and that GPUs are becoming an investable asset class and AWS is taking advantage of that. Oh also he’s wrong about an asset having to be appreciating.

Mo Bitar has either been bought, is suffering from AI psychosis, or he’s just right… maybe I need to dig out HAL and see if Opus 5.5 can do any better than 4.6 did earlier this year in trying to create a new HPC data plane and scheduler

Know someone else who might like to read this newsletter? Forward this on to them or even better, ask them to sign up here: https://cloudhpc.news

For financial institutions, cloud technology has become an important part of the resilience equation. It provides access to scalable infrastructure, geographic redundancy and recovery capabilities. Yet cloud adoption significantly changes the nature of dependency.

As institutions move more compute-intensive workloads into cloud environments, the concentration question extends beyond individual firms and to the underlying infrastructure required to support them.

This is the essence of cloud concentration risk: how do institutions strengthen their own resilience without increasing their dependence on the wider ecosystem?

Traditional third-party risk asks whether an individual institution can manage its relationship with a supplier. Cloud concentration asks a broader question: what happens when that supplier becomes a critical dependency across the financial system?

The July 2024 CrowdStrike outage demonstrated how this may happen in practice. While CrowdStrike is not a cloud provider, the incident illustrated a broader principle: when technology is widely shared, a disruption at a common layer can create correlated impacts across organisations and sector[1].

For financial institutions, this shift raises several practical considerations:

1.     Cloud resilience is no longer just an IT issue.

 The PRA expects firms to consider how critical services would withstand disruption to material cloud arrangements [2]. The Federal Reserve's third-party-risk framework similarly expects institutions to understand critical dependencies and plan for disruption or termination [3]. In Switzerland, the SNB has highlighted the potential for common cloud dependencies to create simultaneous disruption across multiple financial institution[4]. 

The implication here is that resilience can no longer be assessed solely at the application, or infrastructure level. Institutions are now required to consider how their technology dependencies could affect the ability to operate.

2.  A second cloud provider does not automatically create resilience.

Multi-cloud can reduce certain forms of dependency, but it does not automatically eliminate concentration risk.

Two cloud environments may still rely on common identity services, networking, software, cybersecurity tools, subcontractors or other underlying infrastructure. Similarly, deploying workloads across multiple regions of the same hyperscaler can improve geographic resilience without eliminating provider concentration.

 The question to keep in mind is how independent those providers and underlying dependencies actually are. Apparent diversification can provide limited protection if the same technology or supply-chain dependency exists beneath both environments [5].

3. Exit plans need to be tested.

A credible exit strategy requires more than a contractual right to terminate a supplier relationship. 

 Regulatory expectations increasingly focus on whether firms can maintain critical services when a third party becomes unavailable [3]. That requires understanding data portability, application architecture, licensing, network connectivity, identity management and the time required to migrate.

A theoretical alternative that has never been tested may provide considerably less resilience and is not the same as an operationally viable one. 

4.  The biggest concentration risks may sit below the cloud provider.

Financial institutions increasingly need to understand dependencies beyond their immediate contractual relationships.

A bank may use different technology vendors that ultimately rely on the same cloud infrastructure. Multiple applications may depend on the same identity provider or software platform. Several suppliers may rely on the same subcontractor.

This means concentration risk analysis needs to extend across the technology stack and supply chain; not simply across the firm's list of direct vendors [6].

5. Cloud concentration can turn an individual outage into a systemic event.

The most important distinction is between firm-level resilience and system-level resilience.

Cloud adoption may make an individual institution more resilient to a server, data-centre or infrastructure failure. But if many institutions rely on the same underlying provider, a major provider-level disruption could affect multiple firms simultaneously.

This is the concern increasingly visible in the Swiss regulatory debate, where the SNB and FINMA have highlighted concentration among a small number of cloud and ICT providers as a potential source of systemic dependency [4] [5].

For financial institutions today, the relevant question is therefore not only how resilient the firm is in isolation, but how much of its resilience depends on infrastructure shared with the wider financial sector.

6. The regulatory expectation is shifting from managing suppliers to understanding dependencies.

Financial institutions are now expected to understand where their critical technology dependencies sit, how those dependencies could fail, and whether credible alternatives exist.

This does not mean regulators are demanding that institutions abandon hyperscalers or adopt a particular multi-cloud architecture.

Instead, the emphasis is on evidence. The PRA's updated supervisory statement sets out specific expectations for firms to map, test and demonstrate the resilience of critical third-party arrangements [2].

Can the institution identify its critical dependencies? Can it withstand a prolonged disruption? Can it recover or migrate critical services? And does it understand which dependencies are shared across its wider ecosystem?

What does this mean for financial institutions?

 Cloud concentration does not make cloud adoption inherently problematic.

Rather, a paradox exists: 

Cloud can make individual institutions more resilient while increasing the potential for correlated disruption across the system.

At the enterprise level, cloud can reduce exposure to individual infrastructure failures. Institutions can use multiple availability zones, geographic regions, automated recovery and scalable infrastructure to improve the resilience of critical services [7].

But these protections do not necessarily address concentration at the provider or ecosystem level.

If multiple institutions rely on the same hyper-scaler, identity provider, networking infrastructure, software platform or critical subcontractor, a disruption at that shared layer could affect several firms simultaneously.

In this scenario, each institution may have a well-designed resilience framework, but the firms may still be exposed to a common point of failure.

Understanding that trade-off is becoming central to how regulators and financial institutions think about operational resilience and financial stability. The Bank of England's new operational incident reporting framework requires firms to report significant disruptions promptly and demonstrate their ability to maintain critical services [8]. Meanwhile, the Federal Reserve's proposed third-party risk guidance seeks to strengthen expectations around managing dependencies throughout the vendor lifecycle [9].

This is where the distinction between individual resilience and aggregate risk becomes a critical point of contention.

The practical question for financial institutions is not simply whether their own systems can withstand disruption. It is whether the dependencies underpinning those systems are sufficiently independent, and whether the institution could continue to deliver critical services if a common provider or technology layer were unavailable.

The next stage of cloud resilience is not simply building stronger individual environments but understanding the resilience of the ecosystem on which they depend on.

References:

[1] https://www.techtarget.com/whatis/feature/Explaining-the-largest-IT-outage-in-history-and-whats-next

[2] https://www.bankofengland.co.uk/-/media/boe/files/prudential-regulation/supervisory-statement/2026/ss221-march-2026-update.pdf

[3] https://www.federalreserve.gov/frrs/guidance/interagency-paper-on-sound-practices-to-strengthen-operational-resilience.htm

[4]https://www.finma.ch/en/~/media/finma/dokumente/dokumentencenter/myfinma/finma-publikationen/risikomonitor/20251117-finma-risikomonitor-2025.pdf?sc_lang=en&hash=6CB0C57B5333208BA29F26542B3B76B8

[5] https://carnegieendowment.org/projects/cloud-reassurance-project

[6]https://www.federalreserve.gov/newsevents/pressreleases/bcreg20260911a.htm

[7] https://www.civo.com/blog/sovereign-cloud-for-financial-services-meeting-fca-and-pra-requirements-with-uk-infrastructure

 [8] https://www.bankofengland.co.uk/prudential-regulation/publication/2026/march/operational-incident-and-third-party-reporting-policy-statement

[9] https://www.federalreserve.gov/supervisionreg/srletters/sr2304.htm

We often think of supercomputers as monolithic and in continuous operation. Flipping bits across thousands of CPUs and GPUs and churning your data through RAM all while not melting your face off. Most centre directors won’t do much to dispel that idea either 😉

Honestly though, the reality is that many supercomputers don’t run a single large workload that consumes the entire machine. Well not once they’re done running their Top500 submission anyway 😆. Often, they will be used by a number of smaller jobs and utilisation may vary over time. The shape of that variation is often a function of the industry with some, such as financial services, having nice regular predictable patterns and others such as academia being much more capricious.

Your friendly cloud solution architect knows this. Of course.

There’s a certain amount of logic then, in potentially moving some of the workload to the cloud. But only if you limit your cloud capacity to when its actually being used. I mean it makes no sense to run your cloud 24x7 unless that matches your workload. 

You could even do that across multiple clouds. Selecting the vendor based on price, performance, suitability for a particular workload or data locality.

All sounds great right? And it is!

Suddenly though your supercomputer needs a way to control cloud resources. But that’s ok. Its 2026. Code is cheap. Claude or Codex can sort that out for you in pretty short order.

Problem with code, especially when it has to run real production systems that people depend on, is that it has to be maintained. And the cloud providers have this nasty habit of continually improving their offerings and providing new ones. Keeping up with that can end up being a full time job in itself. 

You could do that. Or you could just make that someone else’s problem. There are both commercial and open source solutions in this space to make your life a bit easier. So do you want to do some science (or financial risk or meteorology) or play dev ops?

Want to learn more? Come along to HPC Club.

HPC Club: Multi Cloud Software Defined Supercomputing

Booking is now live for the next HPC Club event. Oct 14, Tower Bridge, London.

Flux by HMx LabsHamza

AMD gave us more details about its latest CPUs (codenamed Venice) including a comprehensive list of SKUs. There’s updated version of the 9755 we tested last year, the 9756 a 128 core 4GHz part which I’d like to get my hands on to see how performance has evolved over the last three generations, Genoa to Turin and now Venice.

More interestingly though there’s a 256 core part with the same boosted clock speed and same L3 cache per core all for only an extra 100W of TDP. That sounds pretty interesting for high density compute( for end of day risk runs for example). There’s also a couple of new 5GHz SKUs which could be potentially work well for more real time HPC applications (such as intraday financial risk).

Staying on the CPU theme for a minute, SiPearl has started shipping its ARM based CPUs that are powering Jupiter, Europe’s first exascale class supercomputer. Rhea1 will form a new CPU workload specific section of Jupiter and the chips have an interesting design that incorporates 64GB of HBM in addition to the usual DDR memory lanes. For the AI kids out there, this is the stuff you need for real work 😁. Or more concretely, workloads that require large amounts of fast memory. Remember that memory wall we talked about? Yea solid attack on that right there. It’s not the first system to attempt this either, Fugaku (Japan Top500 candidate) did this some years ago. It remains a relatively underexplored architecture though and I suspect that’s being not helping by Top500 race as it won’t secure you the number 1 spot (but probably is rather good for real work).

Sticking with alternatives to the US semiconductor hegemony, Huawei and Ali Baba have been busy coming up with alternatives not only to Nvidia GPUs but also the interconnects needed for putting the super into supercomputing and the storage to go with it. It’s not like I’m hearing any big western companies talking about installing the latest Huawei system, but still, I wonder if that changes at all.

Next up, changing tack completely, Googe seems to be doing some kind of magic. I’m sure I’ve probably completely misunderstood this, because surely this isn’t possible… but they have proposed changes to the Linux kernel that will allow a hypvervisor’s guest VM to continue running even while the host is patched and even rebooted. WTAF? 

In updates from us at HMx towers, I stopped dallying around long enough last week to actually put the booking form for HPC Club live, so if you want to come along and hear about how to create software defined supercomputers in the cloud (or just control cloud resources agnostically across multiple providers) then I wouldn’t hang about. Places are filling up pretty quickly.  We’ll have a limited number of our new T shirts to give away too.

Lastly, if you’ve ever wondered how I trawl the digital world for supercomputing and HPC news every week, wonder no more because it doesn’t matter. Fernanda has come up with a much better way, it makes my life easier and you can get a complete feed of everything HPC without my filter over at The Daily Flop.

Have a good week all.

All the News in Depth

Cloud and vendor releases for Supercomputing & HPC (and AI too if you change the filters)

We get more details around AMD’s next generation CPUs including a list of SKUs with core counts, clock frequencies and cache sizes

Staying with CPUs, this time with a Euro sovereign twist to them, SiPearl is actually shipping its ARM based chips for JUPITER now

Talking of an alternative to the US semiconductor giants, China is poised to provide alternatives not just to GPUs networking too

I’ll be honest, I don’t understand this. It sounds like magic… but it also sounds fascinating! Updating the hypervisor host and rebooting it while the guest keeps running!?

A comprehensive collection of all HPC and supercomputing news over at The Daily Flop

HMx Labs Updates

Booking for the next HPC Club is now open and the site has been updated with all the details including the agenda and speakers. HPC Club Site. Direct Luma booking link in case your firewall hates HPC Club

HPC Club: Multi Cloud Software Defined Supercomputing

Booking is now live for the next HPC Club event. Oct 14, Tower Bridge, London.

Flux by HMx LabsHamza

Software Defined Supercomputing & The Cloud - October 2026 - HPC CLUB

HPC Club event on Software Defined Supercomputing & The Cloud. Join us for an evening of discussion and networking with industry experts. 14 October 2026 @ 17:00, London, UK.

HPC CLUB

Software Defined Supercomputing & The Cloud · Luma

Need a supercomputer for a short period of time? A few hours, days maybe? Spin one up dynamically in the cloud, run your jobs and let it spin down. No ongoing…

HPC Club

I’ve often dropped comments about creating a financial market for compute. I finally write out many of my thoughts around this, how what I’m talking about compares to what Nvidia wants to do in this space and how I think products from Kalshi, Polymarket and even Silicon Data fall short.

AI Compute: The Next Oil or the Next Casino

There’s increasing talk about compute, and AI factories in particular, becoming the next asset class. Are we building the next commodity market or the next virtual Vegas.

Flux by HMx LabsHamza

Know someone else who might like to read this newsletter? Forward this on to them or even better, ask them to sign up here: https://cloudhpc.news

Nvidia (Jensen Huang specifically) says “AI Factory Compute is becoming an investable asset class” [1].  I’ve been talking about something similar for close to a decade at this point [2]. You’d expect me to cheer this on, right?

Wrong.

Nvidia want to fund the purchase of their GPUs. I want to be able to treat renting computers (cloud or neocloud), like a commodity such as crude oil. 

These are not the same thing. 

I want to give users of compute the same kind of optionality and security that airlines have for purchasing jet fuel or farmers have for selling wheat. 

Nvidia wants a way to allow companies to borrow money to buy their GPUs.

We can also get into all the other chatter about compute markets including price indices and prediction markets.

But let’s break this down. 

Grab a coffee and settle in, this is a bit long. Or get your favourite AI to turn it into a podcast for you instead. Or just read my previous post on this topic which is effectively a TLDR[3]

Why do we want compute markets?

Before we get into the what, let’s talk about the why for a moment. Why do we need a market for compute, either in the way Nvidia is referring to it or what I’m referring to. Again, the two are quite different.

Markets for other commodities such as wheat, oil or electricity developed (initially and in part at least) from the requirements of both the producers and consumers of those commodities.

Regardless of if you’re a farmer growing wheat, an oil company pumping oil out of the ground or a power station you face the same uncertainty. What price will I get for my produce in 3 months? In 6 months? In a year?

Similarly, but on the other side of the trade, if you run a flour mill, an oil refinery or AI factory you’ll appreciate a level of certainty of the prices of your manufacturing inputs.

I want to be able to trade cloud VMs in much the same way (though in many respects it would actually be more similar to how electricity is traded).

Commodity markets allow the exchange of both futures contracts and options to enable this. The farmer and the miller can agree a price for wheat in 6 months time once its been harvested. Both gain certainty in exchange for a potential upside or downside in price. This certainty can also enable increased investment within the business. The ability to define your cost base or your revenues allows more confidence in other expenses (or an earlier pullback in costs and investments). It may even allow either side to secure loans on the basis of a more certain future income. Price certainly isn’t just a luxury but rather something many parts of our economy now depend upon to function.

Nvidia is doing something similar. Sort of. They aren’t worried about uncertainty in the price of new GPUs in 6 months. They seem to be able to set pretty much whatever price they like on that right now.

What they are a little more worried about is the resale price of those GPUs in 5 years once they are used and the initial buyer wants to sell them. But why does Nvidia care about the resale price? Surely that becomes a problem for the purchaser of said GPUs.

They care because the buyers of the GPUs will sometimes want to borrow money to buy them. Whoever lends the money to buy those GPUs though will want to know what they will be worth at the end of the loan period just in case the buyer doesn’t pay them back. If the bank that lent the money to the neo-cloud doesn’t get reimbursed, they want to know how much they will get on the open market for 5-year-old GPUs. The interest rate they set on that loan will then be a function of how much risk they are carrying. 

What Nvidia is trying to do, is to set a floor on the value of those GPUs by promising to pay at least 25% of the new price. This reduces the potential risk for lenders and thus increases the chances of them offering a loan and reducing the interest rate that is charged on it.

This isn’t all that novel either. Tesla has, in the past, tied the deprecation of its Model S to that of a Mercedes S[4] class to allow prospective customers to secure loans and reduce their monthly payments. This is essentially the same idea, just at a very different scale.

It’s really not clear to me what the new investable asset class is here. Are we talking about potentially trading those minimum guaranteed value GPU back debts like bonds in the future? Are we creating a paper GPU class akin to paper gold? Or are we simply creating a way for Nvidia to reduce the risk taken on by private credit in an attempt to quash the cries of circular financing without impacting Nvidia’s sales?

I grant you there is a similar desired outcome (future price certainty for a product), yet very different mechanism to achieve it and distinct end goals. The first allows two counterparties to trade and agree the price of a commodity in the future. The second is designed to facilitate the sale of goods today (using debt based financing) by backstopping a future value.

That’s not all commodity markets do

This is, of course, somewhat of a simplification of the nature and purpose of financial products in today’s world. A baker and a miller don’t need the Chicago Mercantile Exchange (CME) to create a standardised futures contract simply to agree a forward transaction between themselves. Why do we need the CME (and standardised contracts) in the middle? You can already purchase compute from AWS to be delivered at a future date. Why do we need to create compute market? Banks can already loan money to neo-clouds to buy GPUs, why does Nvidia want to create a new asset class?

Tesla tying the value of a Model S to a Mercedes S class didn’t create a new “investable asset class”, so why does Nvidia doing the same thing for its GPUs turn into a story about financial markets for AI compute?

The answer to both are a couple of critical functions served by modern financial markets, namely price discovery and liquidity.

If you’re new to the world of finance, let me explain what I mean by price discovery. If you’re an old hand, feel free to skip ahead a little. Despite what it sounds like, price discovery is not simply the ability to look up the price of something. It is not being able to pay Reuters and Bloomberg their rather expensive market data fees just to have the most up to date price for NVDA on the NASDAQ.

Rather, price discovery is the process by which we arrive at what that number (the price) is. Genuinely free and unmanipulated markets excel at putting a price on things. The exact mechanism by which we arrive at this number varies by product and the exchange but in reality, it is in fact never a single number. Though, for our purposes today and, for most reporting it is often simplified as such. The function of the marketplace is quite simply no different to your (at this point probably fictitious) local market. You’ll have a number of people offering something for sale, several people prepared to buy and when the two sides happen to agree on a price, the transaction takes place. Financial market places just allow this to happen at a scale and speed that you’re not used to and capture every bid, offer and transaction in the process. This is price discovery. All of those bids, offers and transactions are in fact the price(s) of the product.

And we need it because without this, who’s to say what a barrel of oil or a bushel of wheat is worth in 3 months time. With a significantly large number of participants price discovery is essentially a consensus mechanism. A way for to us to agree on the price of something.

The phrase “significantly large number of participants” above is a veritable Atlas holding up the sky though. If the only market participants are Nvidia selling GPUs and a small number of neo-clouds wanting to buy them the situation doesn’t really change. Especially with the information asymmetry that would exist in a scenario such as this (Nvidia sees all the bids and offers but each neo-cloud sees only the offer and their own bid).

To arrive at a better price consensus, we need more market participants, more transactions. More liquidity. This is the second important function financial products serve.

However, in order to do this, we first need something else very important. Fungibility. 

Is it fungible?

What does it mean for something to be fungible? The dictionary definition is kinda boring so let’s tell a little story instead. Let’s imagine you have the Mona Lisa hanging over your fireplace. Not a print. The original. If you were to sell it, you’d hold an auction of some description and we’d have a number of bids on it and ultimately the price at which it actually sold would give us its market value. Simples. That information is also pretty useless. Another Mona Lisa to sell doesn’t exist and if it did that would have materially affected the value of the one you just sold. 

Now let’s repeat the above exercise with a single share of NVDA. Or your $1 (USD) bill. The sale price of either of those is incredibly useful information as there are literally billions of other shares or dollar bills that are exactly the same.

Currencies and exchange traded stocks are the most fungible assets in existence. One off items such as rare art are at the opposite end of the spectrum and completely non-fungible. 

Yes, I know I could have used NFTs as an example here, I mean the word fungible is right there in the name… but I didn’t want to debase all the effort I’m putting into writing this by legitimising those as an asset :laugh.

If we’re talking about brand new GB300 MGX compute trays I think you could probably argue that these are pretty fungible. (Technically you’d be wrong due to chip to chip variation in performance but let’s ignore that for a moment). If we’re just talking about selling brand new GB300s as futures contracts then it’s a pretty fungible asset class.

But we’re not. We’re talking about a loan structured to use the GB300s as collateral and a guaranteed minimum value backed by Nvidia. We’re talking about the price of second had GB300s. While the resale market for chips isn’t quite as fickle as for your one of one custom specified BMW M3 with aftermarket rims it still doesn’t quite sit at the same level of fungibility as a new product. GPU lifetimes are directly impacted by their operating temperature and the number of dynamic pages of memory that have been retired/ offlined.

Nvidia’s blog states:

“NVIDIA DSX AI factories can run the world’s broadest range of AI models, modalities and algorithms — language, vision, speech, biology, physical AI and robotics. One NVIDIA AI factory can serve many customers and many workloads. That makes it flexible and fungible.”

This appears to be confusing fungible with compatible. These are not the same thing. I can substitute soy milk in my latte but it’s not fungible with cow’s milk (Editor’s note: Thanks NK!). An Intel AWS 64 vCPU VM in eu-west-1 may be compatible with an Intel Azure 64 vCPU VM in westeurope for some workloads but they are not fungible.

What of fungibility of compute in the way I refer to it? How easily can you swap using one cloud VM for another? Turns out, that even if you take the exact same VM type and size from one of the big three hyperscalers and run it in different regions you can see a fairly large variation in performance.

The chart above shows the performance of the same VM type and size on a financial risk analytics benchmark (COREx) across numerous regions. Not really a straight line is it.

Even this version of compute that you’d think should be fungible, isn’t. And that’s before we even consider things such as data locality and legal jurisdictions. That leaves little hope for the same CPU or GPU providing the same level of performance when it has been integrated by a different ODM, running with a different network architecture, different hypervisor, different cooling solutions, different ambient operating temperature… need I go on?

Then standardise everything to be fungible

The oil that comes out of the ground in West Texas is not the same as that being pumped out in Saudi Arabia which is different again to what is in the ground in Venezuela. Yet we still trade oil futures contracts on the CME right? What gives? If those aren’t fungible either but we’re happy to trade oil by the barrel on an exchange, why can’t we do the same with compute (in any flavour)?

The simple answer is that we can. The longer answer is that there’s a degree of information asymmetry to solve for first but that’s relatively easy in the grand scheme of things.

Whilst the oil price is often simplified to a single dollar value per barrel in the news, it actually trades as standardised futures contracts for something rather specific. The quoted headline price is generally the price for Brent Crude (from oil fields in the North Sea, UK) or WTI (from oil fields in West Texas). Crucially that is not the price of Venezuelan heavy oil (harder to refine than WTI or Brent) or even Saudi oil. There are other exchange and contracts for some varieties of oil such as the Gulf Mercantile Exchange and these generally track the WTI or Brent Crude. A similar situation exists for oil that is not even exchange traded.  Its price will generally track (at a discount) one of the headline futures contracts. 

In other words, oil is not a completely standardised market where all traded crude oil has to be the same. It is possible to apply a discount to a well agreed price based on the cost of refining the crude oil. 

The exact same approach can apply to compute. Exchange traded compute, in any flavour, does not require a standardisation of compute. This is often cited as a reason for why compute markets are not viable. This simply isn’t true. What is required is the ability to value (or price discovery) of one type of compute relative to another. How much better is one VM than another (or one particular H100 card than another).

Given the chart I shared above showing the varying performance of the same cloud VM type across regions, it shouldn’t surprise to you learn that quantifying this is actually relatively easy. In fact, not only is it quantifiable, it is quantifiable for your exact workload and use case. Whilst the chart above used a standardised benchmark for the comparison, the exact same graph can be produced for your own code.

Which gives rise to a really interesting situation. The impact and variation on performance across different types of compute or regions for you may not be the same as it is for me. Guess what helps everyone figure out what each of those is worth. Yep. Free markets.

None of that brings more money into the game.

In the year 2024 the CME traded close to 250 billion barrels of oil (based on an average daily volume of 983,000 contracts for 1000 barrels each[5]).

What was the total volume of oil that was actually delivered (into Cushing the refinery that is stipulated in the futures contract)? 250 billion barrels? Nope. Not even 20 billion In fact not even 2 billion barrels. 

A mere 317 million barrels[6]. Close to 800 times the actual quantity of oil delivered and refined was traded on the financial markets.

To be clear, this doesn’t mean that some oil was just never delivered. It means that the futures contract for that oil changed hands multiple times before it finally settled. In other words, the original buyer, A, sold to B who sold to C and so forth till someone bought it that actually wanted the oil and not to just resell the futures contract.

This massive increase in liquidity was enabled by transforming oil from a commodity that is produced by one party and consumed directly by another to a standardised well defined product (fungible) such that it became possible for people interested in gaining exposure to the oil price to easily purchase, and resell, the futures contract with no intention of ever taking physical delivery of the oil.

If price discovery is essentially a process of consensus, the accuracy of the price can be considered to be a function of the number of participants. Increasing the potential number of participants by reducing the number of options for sale (standardisation) therefore increases liquidity and price accuracy. 

There are valid arguments that purely speculative market participants are simply skewing the price and I certainly have a lot of sympathy for that point of view. There are many factors that impact the propensity of a market to become too frothy or overly exposed to speculative transactions, one of them is the link to physical delivery.

Why we need to tie futures contracts to an eventual physical delivery

The physical delivery of the oil has to take place at some point[7]. These products are not completely divorced from the reality of the physical oil market. They are not a way to gain exposure to the price but never have to actually supply the oil or actually recieve it when the contract expires. This isn’t a derivative (or prediction market!) contract that settles purely based on price movement.

And while this may seem academic, it is in fact rather important in grounding the prices of commodities in reality.

During my time on the trading floors of various banks I came across multiple stories of trucks pulling up in front of the bank attempting to deliver coffee beans or pork bellies because a trader forgot or was unable to roll over a commodity contract before it expired. Or having to fire up a power station because the electricity traders were unable to exit a position. I’m sure at least some of these were just urban myths but it really wouldn’t surprise if the odd one was true.

More importantly, there are actual real world documented examples we can look at instead of relying on anecdotes and urban myths. (Though there is just something funny about a truck full of pork bellies pulling up in Canary Wharf or Wall Street and expecting to offload them).

On April 20^th 2020, the price of a WTI oil futures contract became negative[8]. You could be paid to take the oil. A collapse in demand due to COVID-19 and a lack of storage capacity meant that expiring contracts for May 2020 had nowhere to go. If you could take away the oil rather than actually deliver it to Cushing you’d be paid to do so.

We see similar situations play out even in the domestic electricity market when overproduction (due to high levels of wind or sun combined with base load generation that is slow to change) leads to negative prices for consumers. You are literally paid to consume electricity in certain regions and time periods.

This hard coupling to a physical product tends to keep prices in check to some degree.

While the exact nature of the financial product Nvidia is proposing isn’t clear, it does at least appear to be tied to a physical transaction of GPUs. This is not something that can be said for the compute futures contracts being proposed by the likes of Kalshi[8] or Polymarket. Even more reputable indices such as those on Bloomberg by Silicon Data track only pricing with not only no physical delivery but also no market depth (how much compute is available at that price, is it one GPU or one thousand). In fairness, this is in no small part because how much compute is actually available is generally a closely guarded secret that neither cloud providers nor neo-clouds will reveal. Something a real physically delivered compute market could solve.

A compute market, as per my definition of it, would resemble in some regards the market for electricity where physical delivery relates to the ability to use a specific computer in a specific time window.

Why even bother?

Historically financial markets have evolved to meet the needs of the market participants, starting with the producers and consumers of the actual physical products. The evolution usually starts with relatively simple constructs such a futures contracts (as outlined above) and culminates in increasingly complex derivative products as the requirements progress from being those of the producers and consumer to being those of the investors and speculators.

We go from something relatively simple, such a standardised future delivery contract or a loan to purchase a home or GPUs for a data centre and eventually end up with collateralised debt obligations (CDOs). You know those famous incomprehensible financial constructs that were blamed for the 2008 financial crash.

It is rather telling that we have an influx of financial products designed to be able to invest and speculate on compute and data centres but not directly enabling the use of that compute by the people that need it.

None of the current crop of companies or products are focusing on enabling compute financial markets are doing anything to enable the physical delivery of that compute, to make that easier, to increase compatibility (allowing greater standardisation and fungibility).

Some of the largest users of compute (outside of frontier AI labs) are supercomputing clusters. You’d think if you wanted to enable them to use compute more easily, to be able to benefit from price discovery and certainty that financial products are supposed to provide you’d want to do something for them to actually be able to use that compute. There’s not much going on in that space though.

And it’s not because it’s a solved problem either. Far from it. Most users of compute are tied to a single region or a small number of regions, often with a single cloud provider. Adopting multi cloud, multi region compute is still a challenge for a whole host of reasons both technical and legal. If all anyone can use is AWS us-east-1 it doesn’t really matter what other compute you might want to trade on the financial markets.

And without that link back to physical delivery all we’re really building is another casino.

[1] https://blogs.nvidia.com/blog/nvidia-ai-factory-compute/

[2] https://cloudhpc.news/adventures-in-high-performance-computing/

[3] https://cloudhpc.news/compute-futures-are-here-sort-of/

[4] https://qz.com/70450/the-only-good-thing-about-teslas-new-financing-is-how-much-a-mercedes-is-worth

[5] https://www.cmegroup.com/media-room/press-releases/2025/1/03/cme_group_reportsrecordannualadvof265millioncontractsin2024drive.html

[6] https://www.cmegroup.com/openmarkets/energy/2025/Why-Growth-in-US-Crude-Exports-is-Synonymous-with-Growth-of-NYMEX-WTI.html

[7] https://www.cmegroup.com/education/courses/introduction-to-crude-oil/crude-oil-fundamentals/delivery-of-wti-futures.hideSubnav.educationIframe.html.html?hideAddThisExt=y&hideFooter=y&hideHeader=y&hideRightRail=y

[8] https://www.eia.gov/todayinenergy/detail.php?id=43495&mod=article_inline 

[9] https://news.kalshi.com/p/compute-forward-curves

We’ve all been there. The regulator just asked for a rerun of three months of risk, or your model training run just failed and you need to start again. Either way, you’ve got a metric ton of compute to run and everyone wants it yesterday. But shockingly no one delivered another 50 racks into your data centre overnight. Tough spot huh?

This is the exact scenario your friendly cloud solution architect wants you to think about when she comes to visit. And she’s not wrong.

Problem is, it’s never that easy is it. Especially if you need (or want) to be able to use multiple clouds. I mean, it’s not like the CSPs had a nice meeting and decided to standardise the APIs to make your life easier. Want to run on multiple clouds? The work increases, at best linearly, with each cloud you add. (Except, that’s not quite true, we all know code complexity doesn’t increase linearly with quantity. If only.)

The dream up of spinning up supercomputers on a whim, using compute across multiple providers for either capacity or resilience seems to remain possible yet harder than it should be. 

Want to hear from someone that’s lived through this? And has a solution? And its free and open source?

Guess you better book your spot at the next HPC Club then (also free!). 

It’s also the only way you’ll be able to get the best T shirt in supercomputing 😁

HPC Club Site

Software Defined Supercomputing & The Cloud - October 2026 - HPC CLUB

HPC Club event on Software Defined Supercomputing & The Cloud. Join us for an evening of discussion and networking with industry experts. 14 October 2026 @ 17:00, London, UK.

HPC CLUB

Direct booking link at Luma

Software Defined Supercomputing & The Cloud · Luma

Need a supercomputer for a short period of time? A few hours, days maybe? Spin one up dynamically in the cloud, run your jobs and let it spin down. No ongoing…

HPC Club

The most interesting story last week wasn’t details on a new CPU or accelerator, a new product version or cool new startup with a solution in the supercomputing space. It was just an idea, a thought experiment. Anyone working in HPC for more than a hot minute (so non of you AI-come-lately types then 😆 … I’m kidding, relax already!) knows that raw compute hasn’t been the problem for quite some time. The memory wall is all too real. Jack Dongarra even talked about it in his closing remarks at ISC 26. If modelling memory (even if that’s only in the L3 cache) as something other than a linear block can solve that, I’m game to try it out.

The DOE (USA) is in a real rush to get some real-world science use out of quantum computing and has put up a cool $215m (what’s that, half an NVL144 rack these days?) in a competition. Shame we can’t get some of that if we manage to get financial risk analytics working on quantum huh. 🤣

Nvidia had a couple of interesting announcements (and neither of them are about GPUs). First up they presented DSX, which, strictly speaking, is a little boring because it’s just about getting various data centre utilities to talk to each other so they can all operate at the right level and use less power. Overall, that’s kinda cool though, right? I have to say I’m surprised Nvidia didn’t just try and solve that by throwing a swarm of agents at it and getting them to just control all the knobs in the DC. I am quite glad they didn’t though!

The second release is also power related, but this time around integration with the grid to redirect compute to where power is available. Again, also kinda cool. If/ when it works it will be at least anyway.

We also had Cornelis and Delos Data both release products to provide an alternative to Nvidia’s now closed networking based on its Mellanox acquisition. I’ll admit, I do have my fingers crossed some of this stuff works out.

A little less notice than we normally like to provide but we have finally set a date for the last HPC Club for this year. October 14^th and it will take place in London. We should have the booking link live on Wednesday morning so keep an eye out for that if you’d like to come along, If you want one of the fancy new T shirts then you’ll definitely want to come along (and maybe try and bribe Mugheesa to make sure she orders one in the right size for you).

Have a good week all.

All the News in Depth

Cloud and vendor releases for Supercomputing & HPC (and AI too if you change the filters) including new Z4D VMs from Google.

Anyone working in HPC is no stranger to the memory wall, so this is an interesting solution / thought experiment

DOE lines up some serious cash to accelerate quantum computing adoption in real world use

Nvidia gets DC infra to communicate to help save power

Couple this with a standard for getting DCs to talk to each other and the grid…

Supercomputer interconnects other than the old Mellanox gear that Nvidia now owns start picking up

HMx Labs Updates

The next HPC Club will take place on 14 Oct in London. 

HPC Club: 14 Oct 2026

The next HPC Club will be in London on 14 Oct 2026. Mark your calendars, book your babysitter

Flux by HMx LabsHamza

And we have some new T shirts to give away too. The only way to get one is to come and snag one in person

New HPC Club T Shirts

All new HPC Club T-Shirt design just landed

Flux by HMx LabsHamza

Off Topic

Scaling LLMs. I guess we all kind of knew this instinctively but now MIT has maths that says it too.

If you’ve already seen the original video on enshittification by Norwegian Consumer Council this is a great follow up!

Just in case you’ve been living under a rock and haven’t seen the original

The modern life of a software developer getting you down? You’re not alone

Know someone else who might like to read this newsletter? Forward this on to them or even better, ask them to sign up here: https://cloudhpc.news

I’ve alluded to new designs for HPC Club T shirts a few times this summer… I think I’ve teased you for long enough. Here’s the first one!

OpenAI can suck it! IYKYK 🤣

The only way to get hold of one of these is going to be by coming along to the next HPC Club event on 14 Oct or winning one on the random occasions I run silly competitions.

HPC Club. 14 Oct 2026 @ 17:00 in London

A bit less notice than we try and give people normally I’m afraid but hopefully still plenty of time for you to mark your calendars, book the babysitter or get your night out pass stamped.

We’ll be talking about software defined supercomputing, and in particular about being able run multi cloud compute clusters that you can create and destroy on a whim. Why you might want to and how you can.

Venue details and sign up link coming soon.

Your weekly supercomputing and HPC news update, and its short and bitter this week. You could argue this is because I was otherwise occupied last week and spent a large proportion of the weekend behind the wheel so didn’t have time to do it justice.And you might have a point. I prefer to think it’s because there wasn’t much that was genuinely interesting so I’m keeping it short rather than wasting your time with the regular news cycle everyone else already covered 😁

First up, unless you’ve been under a rock all week (and I have but this still made enough noise that I couldn’t miss it), it seems we now have a solution to the Navier Stokes problem. I won’t get into the furore around who actually solved it (see the Off Topic section for more if you do care), what I care about is, will this mean I can run less compute for my CFD? Does my weather forecast, my turbine blade or F1 car rear wing design suddenly get cheaper? As best as I can tell (and I could well be wrong here) the answer seems to be no. (Ok it makes some of the troubleshooting easier when it all blows up in your face because you know the math isn’t the problem anymore). Which makes this all a big meh really.

The only other interesting thing was a press release from d-Matrix around its up and coming (yet to be taped out) Ai inference accelerator. Yea yea, this again confirms we live in a heterogenous silicon world, but I suspect you’re tired of me beating that particular drum. No, what’s more interesting about this, is that it will live inside an Nvidia NVL144 rack. Yep, an Nvidia rack with someone else’s accelerator inside it. Things that you go hmmm…

Not a massive update from HMx last week either, but if you like parallels between AI and other things, I wrote a take comparing AI to digital photography.

May your FLOPs be error free this week. Adios.

All the News in Depth

Cloud and vendor releases for Supercomputing & HPC (and AI too if you change the filters)

Nvidia racks with 3^rd party accelerators in them? Yep that’s a thing now.

You proved Navier Stokes and won a million bucks. Whoopee for you. What does it mean for those us actually trying to model fluid flow???

HMx Labs Updates

A few thoughts on the impact of AI on software engineering and a slightly different comparison to the usual narrative

Vibe Coding & Photography

Are LLMs to software engineering what digital cameras were to photography?

Flux by HMx LabsHamza

Off Topic

I don’t want to get into it, but Primeagen (and Fireship and others) did

He also has an opinion on the end of programming. Wouldn’t normally have included this one but since I wrote about this topic too…

For completeness some of the input that inspired the comparison to photography

https://www.youtube.com/watch?v=C1ZHQyjrVMs

https://www.youtube.com/watch?v=pVMM23kUVH8

https://www.youtube.com/watch?v=qdG7kygCdsU

Know someone else who might like to read this newsletter? Forward this on to them or even better, ask them to sign up here: https://cloudhpc.news

We often compare creating software and the arrival of LLMs with the horse and carriage and the arrival of the car. I think that’s a flawed analogy. And I think I have a better one.

I’d like to claim some form of superintelligence here but the truth of it is that it’s not even my own idea but a bit of an amalgam of a few ideas from people in the photography and software communities. I think LLMs might be for software creation what digital cameras have been for photography.

Film photography is like creating software without LLMs. Taking pictures with old film cameras required you to understand how to load and process the film (or use the services of someone else who that for you). You had to understand how to expose the film correctly without any live feedback on a little screen and you wouldn’t know if you’d got it right for hours at best and possibly days to weeks at worst once the film was developed. A significant part of taking a photograph involved technical skills around the operation of a camera, a light meter and dealing with film. There were entire professions that did this and never pressed the shutter button to take a picture. All this before we even start thinking about what the picture is even of.

Without getting into a complete history of the evolution of digital photography, I think we can agree that modern digital cameras (think of the phone you’re reading this on or in your pocket) make it such that getting those basics wrong is close to impossible. You’d have to try pretty hard to take a picture that is incorrectly exposed and you’d know about it before you pressed the button.

We have more photographs (real ones, not even AI generated ones) in existence today than we ever had. Many more of the photographs we take are of no interest to anyone but ourselves. Yet we still pay people to be photographers. It’s still a viable career.

The work of a photographer shifted. A photographer still understands how to correctly expose a photograph (or when to deliberately not) but the amount of effort in that is far lower than it used to be. Instead, the work shifted to the content of the photograph. How its framed, the composition, the lighting, the subject and most importantly, the story it tells. This was always important. Great photographs even from the film era still needed this.

I think creating (and I used the word creating very deliberately) software is in the same boat. LLMs (and vibe coding and tools such as Lovable in particular) have taken away much of the skill that was needed in creating software. In much the same way anyone can take a competent picture with their phone today, anyone can create software using these tools. In much the same way digital cameras have shifted where the effort of a photographer goes, LLMs will (have?) shift the effort of software creators. Just because you can take a picture on your phone doesn’t mean anyone else wants to see it. Just because you create a new game using Codex and Astra doesn’t mean anyone else will want to play it. And that might be just fine.

Photography today is in an interesting place. There’s a revival of interest in film photography. People are paying inordinate prices for old digital cameras to obtain a “filmic” look to their photographs. Modern cameras (and your phone) come with built in modes to make your photographs look like they’re old.

I’m sure part of this is just the cyclic nature of fashion and trends but a part of it, at least from the photographers, is chasing the process. A desire to make photography slower, more deliberate. Removing the work that went into taking a photograph took away something from the final output too.

I think we’re seeing the same with software. The slow and difficult process of creating software wasn’t just a barrier but promoted deliberation, more refinement before ever typing the code. Sometimes the limiting factor isn’t the ability to write the code but to refine the idea.

The photo? I’ll let you guess how it was taken and how old it is.

The most classical supercomputing aligned news (even if it is for an AI system technically) from last week must be the selection by EuroHPC of an AMD based supercomputer for the replacement of LUMI. AMD has dominated the Top500 for some time now and seems to be cementing that lead even for AI capable systems. At least for those that are owned or operated by classical HPC/ supercomputing institutions. Maybe FP64 is kinda important after all huh. Who would have guessed 😁 Especially if you’re running converged classical and AI workloads.

CERN moved to Debian (from RHEL)! Before we start the distro wars again (probably coupled with AI ideologies) the details here are important and make this a fairly boring and eminently practical and sensible decision. The move is specifically for its computes that act as controllers. The upgrade cycle is around 15 years. 3 year LTS releases can stay at home! Combine this with RHEL9 dropping support for anything below x86-64-v2 and RHEL10 x86-64-v3. Many of the control boards at CERN don’t meet that requirement and it's far simpler to just use a distro that will support them rather than upgrade a lot of very bespoke hardware. Put your pitchforks away please.

In other Linux related news, Amazon Linux 2027 preview was released last week and early testing of the 7.3 kernel show improved performance on AMD EPYC CPUs for certain types of workloads. So that’s good news.

IBM also released its latest quantum chip, Nighthawk. Lots of impressive sounding improvements there but still relatively little in terms of what I can actually do with it back herein the real world.  We haven’t forgotten about this either and are still plugging away on our little side quest to see how viable it is to run financial risk analytics (MC based at least) on a quantum machine.

Azure delivered another little mini gem in the form of a public preview of its multicloud interconnect. No doubt driven by regulatory concerns around concentration risk and the subsequent demands from its customers, but it does mean we are slowly creeping into a a multicloud world.  Just need to do something about those pesky egress costs 😉

Have a good week y’all.

All the News in Depth

Cloud and vendor releases for Supercomputing & HPC (and AI too if you change the filters)

EuroHPC Goes AMD for its AI Supercomputer. AMD Press Release.

CERN moves to Debian! Or watch the presentation here.

IBM releases Nighthawk, its latest Quantum computer. HPC Wire has a more in depth explanation.

Multicloud compute is slowly getting more and more real (Azure)

HMx Labs Updates

If you didn’t guess already, HPC NErD was a CERN last week.

I’ll have to go digging in my camera SD cards to see if I can find another little puzzle for later this week.

Off Topic

Nothing to see here, just capitalism doing what capitalism done when no one is around to regulate. Gotta keep that bubble inflated.

Well of course I was going to include this one… its finance folks talking tech (or about that at least)

Fireship somehow manages to sound anti AI while still making the AI thing sound pretty far out. I mean, I thought it was pretty cool.

Fortunately, Cal Newport has a pretty down to earth take on things which had me back to thinking, meh, it’s just LLM stuff.

Know someone else who might like to read this newsletter? Forward this on to them or even better, ask them to sign up here: https://cloudhpc.news

Hot Chips. The silicon conference as opposed to the calorie laden but rather tasty potato based food. That was the was the main source of supercomputing news last week. We naturally had the AI/ GPU related updates from the usual suspects but we also had insights into CPUs from Intel, Fujitsu and ARM.

Let’s talk Intel first, although it’s possibly the least exciting update its probably also the most relevant one for most of us. Xeon7, code named Diamon Rapids, will give us more cores than originally anticipate. A full 256 of them in fact. But that’s yer lot in terms of threads or logical CPUs too I’m afraid. For some incomprehensible reason, Intel, in their infinite wisdom decided that Hyperthreading (or SMT to give it its unbranded name) isn’t needed anymore. Oops. Slated for a 2027 release but if you want to wait for something with SMT you’ll need to hold out for Coral Rapids.

Sticking with CPUs and supercomputers for a bit longer, Fujitsu provided more details on its 144 core Monaka ARM v9 architecture chips. The previous generations powered Fugaku but with ARM’s increased popularity we might see these more widely used? They’re built on a 2nm process and have 2 SVE2 256bit execution units so could be pretty handy for your SIMD workloads. So long as you port them to ARM.

Talking of ARM, the company rather than the ISA this time, they also released more details on their confusingly named new CPU, AGI. As the name implies ARM seems to be chasing AI money here claiming that the CPU is targeting agentic workloads. Honestly, I still have no idea exactly what demands an agentic workload has on a CPU. Surely this is IO constrained anyway? What makes agentic special here?

Since we’re firmly into AI territory now anyway, Nvidia also provided more details on their NVL72 rack scale GPU solution. I had a funny thought here. As we see more rack scale deployment,  are we about to see what happened in the consumer space with devices becoming smaller, more power efficient but also less repairable and upgradeable in the data centre space? DIMM failure? Time for a new rack. Hmm…

And of course, OpenAI gave us details of Jalapeno, their new inference engine. I’ll let you read the link below for the details on that one.

In more fun news, AWS EC2 was 20 years old last week. Happy Birthday! And Azure will give us 248 and 372 vCPU sized machines to celebrate 😁. But Microsoft giveth with one hand and taketh away with the other. HPC Pack, their faithful but aged scheduler is being retired.

Things from us at HMx have been pretty quiet still last week… I haven’t made any progress at all on my piece about compute markets I’m afraid so this week you’ll just have to have more fun guessing where HPC NErD is again.

Have a good week y’all.

All the News in Depth

Cloud and vendor releases for Supercomputing & HPC (and AI too if you change the filters)

Intel Diamond Rapids… no Hyperthreading but you do get 256 cores.

ARM shares details on AGI, its first foray into the CPU market

Fujitsu’s new ARM CPU

A closer look at Jalapeno, OpenAI’s new inference engine

More details on the NVL72

Happy Birthday EC2

HMx Labs Updates

If you didn’t guess (might have been a bit hard) last week HPC NErD was at Neuchatel at a temporary exhibit on the measurement of time. A new HPC Club T shirt if you can guess where he is this time.

Off Topic

How’s your token spend going? Getting much in return?

What is AI coding doing to you?

Know someone else who might like to read this newsletter? Forward this on to them or even better, ask them to sign up here: https://cloudhpc.news