In 2023 we created the COREx benchmark. And now it’s not good enough. Time for COREx 2.0

We created it not because we thought we world needed yet another benchmark. Not because we felt we could create a better benchmark. No. We created it because there was no other benchmark for financial risk analytics workloads.

You could argue that the QuantLib benchmark already existed, but this was never really designed as a benchmark, simply test cases for the core quant library. But yes, sure I suppose I can concede that point. There is also the STAC A-2 benchmark, but this isn’t easily accessible to everyone. Critically, neither replicates a whole risk system.

So, we ended up creating COREx, something that replicated actual risk systems that run production. Not just the analytics library. Not just a single algorithm. A full risk system as it runs in the real world.

It was done on a shoestring budget and leant heavily on existing open source projects. Which is probably a good thing in the end. Importantly though, because there was no prior art, creating something was better than nothing.

It’s been 3 years. And now it’s no longer good enough.

It’s a single benchmark that is attempting to replicate multiple workload types within a broad category. 

What matters for intraday and realtime risk is not what is most important for end of day risk. Market risk calculations have a very different memory and IO profile compared to portfolio risk.

It’s time for COREx v2.0. 

Before we start work on this in earnest, I’d like some input from you. What matters to you in this space? Where are the results from COREx lacking for you?

Let me know.

It’s rather serendipitous that the week in which Nvidia chose to announce DSX Pod, designed to accelerate deployment of AI factories, is the same week in which Microsoft pulled out of its deal with Nscale to use its Loughton, UK data centre due to a lack of power.

The idea behind DSX Pod isn’t really new. It follows a familiar pattern trod by things such Huf Houses, pre-fabricated concrete, block based ship building or even modern aircraft construction. I’m not sure it’s particularly novel even within the context of supercomputing with container based supercomputers existing, even if they are somewhat niche.

I’m less interested in what this means for building new AI factories than I am in what it means for more classical users of supercomputing. Where you’d once have engaged, possibly a consultancy plus the likes of Bull or Atos to design, procure and install a supercomputer, can you now just place a call to an ODM and have a number of DSX Pods delivered and hooked up? Critically, will this actually be any cheaper?

Coming back to the power constraints, of course, Nvidia and partners have things within the DSX ecosystem to address this too. It looks very interesting though we are definitely talking about tech in the lab rather than in the field. Links below for more details.

The other announcement from GTC last week that caught my eye was cuDSS, a new CUDA based library designed to accelerate the sparse system equations often used in engineering simulations. There’s certainly a good story here and even practical real world use cases showing around 10x acceleration. That sounds amazing. I think it’s nowhere near enough.

While time to solution is an important metric in supercomputing problems, on its own it means very little. What constrained the time to solution? How concurrent is the problem? If we’re generous and assume that the 10x improvement is a genuine 10x in the limit case, i.e. this is the only way to buy further improvements in speed and the problem can’t just be made more concurrent, then in those use cases where time to solution is the key metric, this could be important. That’s a pretty small niche within a niche though.

More critically, for most commercial use cases the 10x speedup is not going to be enough to offset the additional cost of running on GPU vs CPU. I’ve seen this movie before. Moving financial risk analytics moving to GPU and then sometimes back to CPU compute. CPU based compute can cost as little as $0.01 per vCPU hour. At current prices we’re looking at around 100x that for a H100 for an hour. Even with a 10x speedup the commercials of moving that calculation to GPU based compute are going to be questionable, especially if it can be made more concurrent and use cloud compute on par for what you eat basis.

Before you throw your engineering team all in to migrate everything to cuDSS and order a new DSX Pod, maybe just run the math. Check if your workload can break down to run more concurrently first too.

Lastly a couple of updates from us at HMx Towers. We’re hiring! Further details in the link below. Secondly, I’m experimenting with being even less coherent in a post from last week as a precursor to perhaps sharing a little more about how we’re building out HMx Labs. Let’s see how that plays out.

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)

Lack of power continues to frustrate data centre rollouts

Nvidia DSX Pod and the rest of the ecosystem as well as third party take from HPC Wire

Karman over-provision GPUs in the power envelope

And Emerald AI goes the other way

Nvidia cuDSS and HPC Wire's take

HMx Labs Updates

We’re hiring! If you know someone who might be interested in coming joining us please point them my way, I’d really appreciate it!

Hiring: HPC Engineers

We have two open roles in HPC engineering. Do you know anyone that might be a good fit for us?

Flux by HMx LabsHamza

Not that many of my random thought are particularly coherent anyway, but I thought I’d try a little experiment with one that’s even less cogent. Depending on how well this works I might start sharing a little more in this vein, the gritty bits of building out HMx Labs. Frugality vs Profligacy.

Frugality or Profligacy

“We haven’t the money, so we’ve got to think” - Ernest Rutherford I’m not sure long I’ll stick with this, but I thought I might share some of the internal dialogue and thoughts that eventually turn into the slightly more refined ideas (which aren’t exactly

Flux by HMx LabsHamza

My baby sister got married last weekend, that’s pretty off topic right? 😁

Slightly back on track, we saw a huge number of cybersecurity vulnerabilities disclosed last week. Not particularly supercomputing adjacent, but how long till they are?

Fireship summary because, well, at least he makes it funny and otherwise you’d just cry

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 haven’t the money, so we’ve got to think” - Ernest Rutherford

I’m not sure long I’ll stick with this, but I thought I might share some of the internal dialogue and thoughts that eventually turn into the slightly more refined ideas (which aren’t exactly well formed anyway!!) that I do usually write about.

I first came across the quote above as an undergrad working on my Master of Engineering. The picture is from the finished report that still sits on shelf behind my desk.

More recently, I was speaking with a friend about frugality in running companies. I said I didn’t agree with the, Amazon popularised, frugality ideology whereas my interlocutor was very much for it. To the point of sleeping in churches to save a few bucks. 

Yet here I am, coming back to the quote above. Thinking about the impact of venture capital on startups and if we’re really helping at all by throwing money at problems. Heck we’re not even throwing money at problems anymore, not really, we’re mostly throwing money at kids in the hope they’ll come up with something that will end up with monopolistic pricing and outsized levels of wealth creation for the initial investors. Anyway, that’s a topic for another day.

It also had me thinking about something I read where the executive team of a company tried living on minimum wage and found that the challenges of managing their daily lives on that budget stripped them of the ability to create and operate effectively. I really wanted to find the details of that again to reference it but have spent quite a few tokens on it with no luck. In fact, it seems, it may have been entirely fictional?

I’m pretty sure people, employees, need to be comfortable enough at a personal level to not have to spend their mental energy ensuring they can pay rent or feed their families (even if that previous story does turn out to be a work of fiction not fact). But I do wonder if at a corporate level access to excessive resources simply stifles creativity?

Does too much money just give us rocket powered cars as marketing exercises? Conversely, Steve Jobs wasn’t exactly eating at the soup kitchen when he gave us the iPhone.

Yet the current AI tech boom has so many examples of problems being solved incredibly inefficiently because the money was available to do so.

Perhaps the answer isn’t really very clear cut.

We are hiring.

We have two open roles working on HPC/ supercomputing in financial services.

The complete details of each role, one at graduate level and one more senior, are in the job descriptions but I thought I’d share a bit more here.

Firstly, we’re hiring because we’re growing. We’re still a pretty small company so that means both roles will be more suitable to people who like to have a large impact, wear multiple hats and are comfortable working in environments where not everything is well defined.

You’ll still be coming into HMx Labs early enough to have an impact on what we do and how we work which is great for you but also means we’re going to be thinking carefully about if you’re a good fit in terms of culture and personality with the existing team. 

Given what we do (consult) and the rise of AI, the above coupled with your ability to communicate clearly and take responsibility are going to be as, if not more, important to me than your technical skills.

If this sounds like you, give me a shout. If it sounds like someone you know please send them my way. Anyone being referred by someone I’ve worked with before goes to the top of the pile.

Graduate HPC Engineer

Graduate HPC Software Engineer – Platform & Automation at HMx Labs — London Area, United Kingdom | LinkedIn Jobs

Apply for Graduate HPC Software Engineer – Platform & Automation at HMx Labs in London Area, United Kingdom. Full-time Entry level role. See responsibilities, qualifications, and similar jobs on LinkedIn.

LinkedIn Jobs

Senior HPC Engineer

HPC Software Engineer – Solution Architect at HMx Labs — London Area, United Kingdom | LinkedIn Jobs

Apply for HPC Software Engineer – Solution Architect at HMx Labs in London Area, United Kingdom. Full-time Entry level role. See responsibilities, qualifications, and similar jobs on LinkedIn.

LinkedIn Jobs

A good chunk of the HPC/ supercomputing news from last week comes to us courtesy of the OCP Global Summit which took place in San Jose. As always, all the details are down below but there’s a couple of interesting patterns that aren’t which I wanted to bring up.

I appreciate it may not be a stated goal of the OCP to attempt any form of standardisation of hardware specifications, non the less, we are in a rather interesting position with Nvidia’s latest releases to OCP of its Vera Rubin based updates for rack scale computing vis a vis the Helios architecture which built upon the double width racks provided by AMD. i.e. we have two very different, competing, hardware layouts for large scale accelerated compute. Which only gets more interesting with AMD similarly named, but completely different, single width Helion racks which were also announced last week.

Either way, we are definitely staring down the barrel of a unit of compute creeping from a 19 inch rack mount sled to the entire rack. Not only are we seeing increasing rack scale designs and deployments we are also seeing sleds that are tightly coupled to those designs. In a similar way (and for partially similar reasons including reduced sizes) as we see in consumer hardware ,we are seeing designs move from standardised parts to bespoke (even if open sourced) designs. Although the initial signs aren’t exactly promising, I’m hoping this doesn’t lead to the same kinds of levels of repairability and interoperability and lock in that we see in consumer hardware (think Macbook Pro).

And then you have all of the high speed networking standards and complexity layered on top of that. Topic for another day, I think.

Surely though, all of this has got to make your run of the mill Top 500 supercomputer or enterprise deployment cheaper and easier? So much of what was once completely bespoke to a literal single machine is now becoming defined in OCP standards. Plural. Choice is good thing, but sometimes the limitation can foster more progress. A 19” standardised rack size, MPI, HTTP none of them are perfect, but there being just one (commonly used) made a lot of things easier.

Intel has gone from being on its death bed to having not only strong CPU sales but back in the GPU market with its Crescent Island air cooled PCIE chips. These seems to be firmly targeted to the AI inference market with large VRAM sizes to boot. Couple this with Microsoft’s announcement of increased investment into Maia (their own AI inference accelerator) with the 300 coming in 2027 in even larger quantities than the 200 and it seem everyone wants to take a chunk out of Nvidia’s business.

Curiously, that was a topic that came up quite a lot at HPC Club last week. It seems the immediate question people had if given the opportunity to acquire cloud capacity across multiple providers easily was to then ask about how to use multiple architectures (including accelerators) easily. 

Lastly, it’s always fun to watch the AI bros slowly discover things the rest of the grownups in the room have known for around three decades at this point. Measuring utilisation at the CPU/GPU level is important for understanding how well your hardware is used or how well your software can make use of it. It’s worse than useless at understanding if your training run will complete or if you’ll deliver your risk reports on time. Not a single risk system I’ve ever come across has an observability stack that monitors utilisation as its primary goal. Sure, you have to be able to tie back to that, but progress on your actual task, how many portfolios and risk types have completed, how long they took compared to previous runs far closer to being front of mind. I have no doubt similar methodologies prevail across weather/ climate modelling, EDA etc.

Have a good week folks.

All the News in Depth

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

Nvidia open sources more of its data centre rack scale tech used for Vera Rubin

Microsoft goes deeper on its own accelerators with Maia 300

Intel looks increasingly less dead and even back in the GPU game

AMD gives Helion, confusingly similarly named to Helios, but a completely different rack architecture geared more towards enterprise and hyperscaler use rather than just AI training supercomputers (which is what Helios does)

It’s funny watching in the AI industry discover all the things the grown ups have been doing in serious HPC systems (and quite frankly probably lots of other spaces like basic IAM, security and software design) for the best part of two or three decades

HMx Labs Updates

A few thoughts about the intersection of creativity, art, code and AI.

Art, Code and AI

Some thoughts on how creativity, art, software development and how AI will shape it in the future.

Flux by HMx LabsHamza

HPC Club last week went rather well! If you missed it you can find details about ORB here (Flamur requests you give the repo a star please!) . We’re looking into making the presentation slides and recording available.

Off Topic

I had a lunch meeting with an AI startup earlier this week. I was more than a little surprised at their lack of vision or understanding of what causes AI pilots in the enterprise space to fail. I then came across this video in my feed that covered many of the same points I tried to make to the founders of that startup.

Sort of related to the piece above about AI but more directly visible, AI created interfaces

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 can’t play a musical instrument. I can’t draw. I can’t paint.

As a kid I always enjoyed physics, engineering and even math.

For the longest time I thought this meant I’m not creative. I placed myself in the “non creative” bucket because not only are my artistic abilities similar to those of a toddler with beetroot puree, but I didn’t “get” art either.

At the same time though, even as a child I would happily rip apart my toys to pull out the electric motors. Butcher my Meccano with a screwdriver to enlarge the holes to fit gears through them. And cobble the whole lot together to create a Frankenstein’s monster of a toy. At the age of 8.

(My girls get Hack Packs and Build Boxes from Crunch Labs instead. They don’t know how good they have it!)

And although I can’t look at the Mona Lisa or Sunflowers and appreciate the beauty in them, I can completely lose myself listening to Divenere (Ludovico Einaudi). (Yes, it happens to be playing as I write this, and I had to stop and just listen for a bit!)

A friend of mine recently said to me, “you forgot you’re an artist”. I don’t think I ever knew I am one. I think I still don’t consider myself as an artist. But I do consider myself as “creative” now.

I don’t know how widely photography is accepted as an art form but for the sake of this article let’s just pretend its universal. I can’t paint, but I can make a pretty good photograph. I’ve been paid for my work.

But the really interesting thing about photography, is that while it can be an art form, it is far far more widely used as anything but. Which what intrigues me in comparing it to writing software in an era of LLM coding.

I carry a real camera most days, I use it to take pictures that look beautiful. I also have an iPhone filled with mundane pictures of receipts, whiteboards and cars. Same person, same type of tool, two very different outcomes.

I think I see a similar division in software. Writing code can be a highly creative, almost artistic endeavour. There are those of us for whom there is beauty in the code itself, be that in its structure or the performance of a tight inner loop. But there is also a huge amount of code that is the equivalent of the photos in my iPhone. Far more in fact than there is code that is beautiful. Even within the same project.

I think it is far too late to delude ourselves that AI generated code will do anything but replace all of that second category. And I think that’s ok.

What I think we will struggle with, as an industry, for a while, is figuring out how to deal with that first category of code. Writing code that way, not just by hand, but taking the time to make it truly remarkable was always difficult to justify in a corporate environment. It will now become, to quote Rick Ruben (Diary of a CEO), indefensible.

In other areas and art forms, doing the indefensible to create something beautiful and amazing may not be the norm but it is very much done. I am a firm believe that in the era of AI where creating the average is easy, we need to make things that are unreasonably good.

What I don’t know yet, is how that idea translates to the actual code. When I spend an indefensible amount of time taking a photograph, the end user sees the photograph and can appreciate the beauty (or lack thereof) in it. When I spend an indefensible amount of time writing code by hand, does the user of the software perceive that difference?

I think the future of being a code artisan, of creating remarkable code that is a labour of love rather hinges on that question.

And if you write code by hand and don’t make it wonderful, why even bother. Just ask the genie to generate it.

If you’ve gone single vendor for your new supercomputer and are worried about how well the CPU section of your new machine with hold up with Nvidia’s Vera you can relax. Phoronix got hold of a couple of the new 88 core ARM CPUs and the initial suspicions about them hold up. They are rather impressive. Phoronix have run OpenFOAM and QuantLib benchmarks (plus a few others) and while it’s not a clean sweep, better across the board, I certainly wouldn’t be worried about running an Nvidia only stack from a performance perspective right now.

Of course, benchmark results on their own aren’t everything, it would be interesting to see how the Vera CPUs compare both when cost adjusted and for real world workloads but so far this looks quite promising. I am curious though how hard adoption will be for users. Moving to ARM isn’t always trivial especially when large parts of your workload still depend on 30 year old code compiled for Intel x86 and still run 32bit binaries 😁.

Nvidia gave us something else interesting this week too in the form of AICR v1.0, or AI Cluster Runtime to give it its full name. The idea here being to provide a mechanism to manage known good version combinations of GPU drivers, Kubernetes versions and every other part of the stack needed to go from racked hardware to working AI factory. It’s a nice idea and one that I’ve been approached with by other startups. Nvidia’s solution looks to be a little less comprehensive and of course is Nvidia specific but if you’re already running an Nvidia only stack and finding you’re battling broken clusters from version upgrade it might be worth a look. 

And if you’re looking for tips on improving reliability for your AI inferencing workloads then the piece from HPC Wire this week sharing some tips and how its distinct from cloud SaaS applications might be relevant.

I’ve talked a fair bit about compute markets in the last couple of weeks and HPC Wire put out an interesting but rather frustrating story with news of a National Compute Grid. This seems to address so many of my complaints about lack of deliverability and genuine utility for users. But it’s so lacking in detail as to be almost useless. I’m not even sure who’s running this and in which country (though I’ll assume it’s the USA) or how much compute they have or how its interconnected or what scheduler is used or… and breath… anyway, it sounds promising.

Upscale AI provided a bit more detail last week on Skyhammer, their vendor neutral scale out networking. We’ve consistently failed at this so far as an industry but it would be great to see something succeed here rather than being locked in to NVLink.

Lastly, its HPC Club this week and rather unusually we still have some spaces left this time so if you’d like to come along and nerd out about HPC with like-minded people with no one trying to sell you anything, come along.

All the News in Depth

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

Vera CPU seems to perform quite well. We don’t have any COREx benchmarks but Phoronix did run the QuantLib test cases and it seems to hold up in those.

An open source high speed network interconnect? Sounds promising… 

A couple of weeks ago I spoke to a stealth startup that was working on a way to configure AI Factory clusters easily. It looked interesting. I think Nvidia might take a bit of the wind out of their sails though (fortunately for them they can do much more)

This frustrates me due how little detail is actually provided but the idea sounds promising given everything I recently said about the lack of physical delivery in compute markets.

Looking at SRE for AI clusters and where it differes from cloud SaaS

HMx Labs Updates

HPC Club is this week! Shocking we have some spaces left still. If you’re interested come along

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

If you ignore everything, listen to this. Available everywhere else you get your podcasts too. Rick Rubin on AI

I’ve been thinking a lot about the impact of AI on art and how that compares and relates to its impact on software. I have a lot of thoughts I need to organise but I will share them soon. In the mean time, listen to Rick. Ignore the click bait headline about Jay Z. This is interesting for his takes on AI, indefensibility (which I refer to as making things unreasonably good but agree with) and life.

But also AI is making you basic. I knew it would turn everything beige (AI Predictions for 2025, March to Homogeneity & Mediocrity) but maybe didn’t think it would homogenise all humans too (just their output). 

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 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