What’s your favourite benchmark? The one you instinctively turn to when you want to get a feeling for the performance of a system.

Thera are, of course, no right or wrong answers here (except LINPACK 😀, kidding!) just whichever one most closely resembles your real workload.

I don’t think it’s much of a secret that we work primarily in financial services and the benchmark data we have chosen to include in FLOPx (our cloud and metal performance comparison tool) is quite FSI biased. We’re looking to expand it. Both with additional benchmarks within the finance world but also more broadly with other HPC/ supercomputing relevant workloads.

The obvious missing data point is the QuantLib benchmark (regardless of my own feelings about it) but what else would you like to see?

Would having the results from the SPEC benchmark suite be useful or is that data widely and easily available such that there’s no additional value?

Anything from the Phoronic HPC test suite? OpenFOAM perhaps?

I’m sure you’d love to have them all, but we have to pay to run these ourselves and I haven’t stuck a “dot AI” at the end of our name yet so I’m not made of money 🤣

Answers on a postcard to HMx Towers please.

The silicon theme continues this week, but we do have some other non-hardware related supercomputing news too for once! Also HPC Club reservations are now open so if you haven’t booked yet I’d get on that pretty quickly 😉

CIQ, makers of Rocky Linux, have released an update to Fuzzball to become a fully fledged multi cloud workload management and HPC scheduling solution, putting it directly in competition with products such as YellowDog. It may also be a contender in some regards to using your own scheduler with Parallel Work’s ACTIVATE or FINOS’ new Open Resource Broker. The HPC scheduling space can sometimes feel like it consists of little more than Slurm but lift the covers a little and there are quite a few options! We’ll need to get our scheduler selection tool updated with Fuzzball and its new capabilities.

Staying on the software side of the news, AWS has also done something rather rare by giving us observability out of the box for PCS (Parallel Compute Service)! Anyone that’s been in HPC for more than a day will realise how useful and rare this sort of thing is. It takes the form of managed Grafana so should feel fairly familiar to most people. 

Diving back into the silicon news, we have Intel firmly back from the dead and now taking aim at the AI space with not only new CPUs but accelerators and partnerships too. Talking of Intel, we’ve just spent the past week benchmarking their CPUs for financial services workloads. The data will naturally be available via FLOPx but I’m wondering if a (short) white paper comparing the various models to highlight what (clock speed/ L3 cache) impacts performance in this space would be of interest? Let me know.

Lastly, Microsoft has decided its foray into ARM CPUs is worth continuing with and will be releasing new Cobalt 200 based VMs. The future is definitely looking much more heterogenous.

In the News

Updates from the big three clouds on all things HPC, change the filters to see AI updates too

Intel takes aim at AI

Fuzzball takes on YellowDog, Parallel Works, Slurm & Co

AI price hikes start hitting other tech

From HMx Labs

HPC Club is go!

HPC Club 08 July – Reservations Open

Want to come along to HPC Club on 8th July? Better book your spot now

Flux by HMx LabsHamza

Chocolate & Peanut Butter @ HPC Club

A little bit more detail on what’s coming up in the next HPC Club

Flux by HMx LabsHamza

Still hiring!

Hiring: HPC Engineer

We’re looking for another HPC software engineer! Know someone that might be interested? Fancy pointing them my way please? This video was brought to you by the letters H, M and X and the number 42. Have a good weekend everyone. 0:00 /0:03 1× Apply on LinkedIn

Flux by HMx LabsHamza

Hiring: Marketing & Business Development

We’re looking for someone awesome to come help us shape the future of HMx Labs

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

I've been building something in Waltz that I think changes how enterprise architecture teams interact with AI: instead of chatting with a model and getting a one-off answer, we gave seven AI analyst personas persistent access to the EA repository and let them work on a schedule.

Each persona has a distinct lens. A CTO persona focuses on infrastructure obsolescence. A Migration Architect looks for dependency cycles and shared-database cohorts. A TOGAF Enterprise Architect spots capability redundancy and standards drift. An Auditor reads what the other six produce and looks for agreement, gaps, and contradictions.

One persona spotted that a single end-of-life database is still serving six production apps. Another flagged three applications all providing the same capability to different business units, unaware of the others. The Auditor noted that two personas disagreed on the risk level of a shared integration layer and surfaced that as its own finding.

What makes this different from "AI generates a report":

These observations are structured, deduplicated, and lifecycled, not free-text that disappears after a conversation. If you dismiss a finding, it stays dismissed across future runs. If the same problem reappears, the system bumps the observation count and refreshes the wording rather than creating a duplicate.

Every finding is grounded in the EA repository. Every cited application, database, or capability is a real entity you can click through to. And every finding carries 1–3 recommended next steps phrased in actions you can actually take inside Waltz: open a Change Initiative, create an application group, request a data assessment.

The part I'm most pleased with: reverse lookup. From any application page in Waltz, you can see every persona finding that mentions it, bucketed by whether it directly affects that app, mentions it as part of a wider pattern, or is inter-persona quality assurance. The AI's work feeds into the operator's normal navigation, not a separate inbox.

This is a research snapshot, not a finished product.
Structured findings that persist, prescribe, and participate in the tool alongside the operator.

Curious what EA practitioners think. What would you want your AI analysts to notice first?

#EnterpriseArchitecture #AI #Waltz #TOGAF #DigitalTransformation #ITStrategy #ApplicationPortfolio #TechLeadership

HPC Club. 8 July. Reservations open now.

Want to speak to people who run the world’s largest super computers? Want to know how that knowledge translate to your own supercomputing or where AI works and where it doesn’t? In complex environments like hedge funds?

Lawrence Livermore National Laboratory x Man Group x HPC Club

Interested? Well book your spot now then!

Want a bit more detail? Should have read my post from earlier this week then 😁

Still here? Spaces are already half gone you know…

Lessons from LLNL in Supercomputing & AI - July 2026 - HPC CLUB

HPC Club event on CPUs, GPUs and silicon diversity. Join us for an evening of discussion and networking with industry experts. 26 November 2025 @ 17:00, Canary Wharf, London.

HPC CLUB

Chocolate and peanut butter. That’s how a friend likes to describe the worlds of HPC in academia and finance. Domains that feel completely distinct and that you perhaps wouldn’t think to combine, but actually, go together quite well!

Despite the very different technical starting points (classical MPI based supercomputing vs HTC on highly commoditised hardware) I see an increasing convergence of requirements and solutions. Since I’m already freely borrowing from the works of friends, I think what we’re seeing here is the convergent evolution of supercomputing across rather different domains.

I think, in large part, that is being driven by AI (and probably not for the reasons you think) but really, that process started before ChatGPT. More like 2008 or so with an increasing requirement around counterparty risk and other forms of portfolio risk calculation. This moved the game on from embarrassingly parallel compute to varying levels of additional complexity (depending on the bank) but essentially an acyclic graph of some form.

Increased AI adoption has significantly accelerated this convergence. Partly because running an LLM looks the same regardless of what your prompt contains. Partly because whilst banks used to enjoy a preferential status with technology suppliers due to their spend, these days unless you’re a hyperscaler or neocloud no one else comes close so academia and finance are more similar than different as far as big tech is concerned! And partly because, quite frankly, they always had more in common than first met the eye.

Both run shared supercomputers having to provide access to competing users. Both have surprisingly similar organisational and power structures. Both have compute that bottlenecks on IO before CPU even if they don’t like saying that out loud (and let’s be honest that’s been true for most supercomputing in the real world for a long time).

I’ve been trying to keep a foot in both worlds for a little while and I think it’s time that we put you all in a room together. The next HPC Club not only will we have Lawrence Livermore National Lab sharing their experiences but also a large hedge fund. Chocolate and peanut butter.

I’ll let you decide which is which.

Nothing for decades and suddenly tens of them come along at once. I think this must be the third week in a row that the interesting HPC/ supercomputing news is dominated by developments in silicon.

AWS has had Graviton for about 8 years, Microsoft Azure and Google Cloud both also decided to offer their own ARM based CPUs and even Meta has developed its own designs. Now ByteDance becomes the latest big tech company to plan to tape out its own custom chips. Though they are currently hedging their bets between it being an ARM or RISC-V architecture.

Meanwhile Phoronix has managed to get their hands on Nvidia’s Vera CPU. The selection of benchmarks results they’ve chosen is, shall we say, interesting. Not sure we’re likely to get our hands on any Vera kit any time soon to benchmark ourselves but we do currently have our mitts on some Intel CPUs and are considering if we include some of the Phoronix benchmarks in our analysis going forward. Specifically, the HPC related benchmarks and probably quanlib too. Maybe we should include SPEC too? All available for cloud or physical selection decisions via FLOPx.

A new startup, FuriosaAI, seems to have an alternative approach to accelerating inference, choosing to focus on high bandwidth data movement and tensor operations rather than a multitude of small cores. Sounds promising but modern GPUs sound awfully similar to that these days, no?

To address my concern from the previous two weeks about the difficultly in targeting multiple accelerator architectures it seems there are some people out there trying to solve this. I mean I kind hoped and assumed this would be case but hadn’t seen anything till last week in the form of ZML for one. I guess there may also be others, so if you know of any please do point me to them. I sincerely hope someone cracks this, not so much from a technical perspective, but more from a general adoption point of view.

TSMC seems to think efficiency might be the most critical metric its customers are now asking for. I’m actually surprised it took this long, given that the most bottlenecked resource seems to be the energy to power enough of these things. 

Lastly, we’re still hiring. We have open roles for both a HPC software engineer and marketing. Oh, and expect this to be the last issue of this newsletter branded as Quantum. A new look (but with the same content) coming next week!

In The News

Updates from the big three clouds on all things HPC. If you want the latest on AI too, just hit the buttons in the menu

Noteworthy by HMX Labs

 Silicon related shenanigans

https://www.reuters.com/world/china/bytedance-developing-custom-cpu-chips-support-ai-rollout-sources-say-2026-05-28/?utm_source=chatgpt.com

https://www.phoronix.com/review/nvidia-vera-benchmarks

https://www.hpcwire.com/2026/05/28/furiosaai-and-broadcom-team-up-to-build-rack-scale-inference-clusters/

An alternative to CUDA that works everywhere?

I think we broke the CUDA moat for good. Software built with ZML now runs transparently at max speed on: - CPU - NVIDIA GPUs - AMD GPUs - Google TPUs - AWS Trainium - Intel GPUs - Tenstorrent NPUs -… | Steeve Morin | 31 comments

I think we broke the CUDA moat for good. Software built with ZML now runs transparently at max speed on: - CPU - NVIDIA GPUs - AMD GPUs - Google TPUs - AWS Trainium - Intel GPUs - Tenstorrent NPUs - Apple GPUs (very experimental) That’s 8 different architectures. For instance, this screenshot is from 2 Intel GPUs working in Tensor Parallel mode, something Intel themselves only shipped in a very old vLLM fork. | 31 comments on LinkedIn

LinkedInSteeve Morin

ZML - Model to Metal

ZML is a production inference stack, purpose-built to decouple AI workloads from proprietary hardware.

ZML Logo

Is the focus finally going to change to efficiency too?

https://www.datacenterdynamics.com/en/news/energy-efficient-compute-is-most-important-attribute-for-customers-tsmc-claims/?utm_source=chatgpt.com

From HMx Labs

 New logo for this weekly newsletter incoming soon

Same Weekly Newsletter. New Name and Logo

I first started writing a weekly newsletter about HPC back in 2024. I figured it needed a name of some kind, but I didn’t really put much thought into it. I think I just Googled/ asked ChatGPT for some names that sounded cool. Wasn’t a great move as

Flux by HMx LabsHamza

Also we’re hiring not only for our marketing role but also an HPC software engineer now

Hiring: HPC Engineer

We’re looking for another HPC software engineer! Know someone that might be interested? Fancy pointing them my way please? This video was brought to you by the letters H, M and X and the number 42. Have a good weekend everyone. 0:00 /0:03 1× Apply on LinkedIn

Flux by HMx LabsHamza

Hiring: Marketing & Business Development

We’re looking for someone awesome to come help us shape the future of HMx Labs

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

We’re looking for another HPC software engineer! Know someone that might be interested? Fancy pointing them my way please?

This video was brought to you by the letters H, M and X and the number 42. Have a good weekend everyone.

Apply on LinkedIn

HMx Labs hiring HPC Software Engineer in London Area, United Kingdom | LinkedIn

Posted 9:23:04 AM. Despite the big talk from the like Messrs Altman and Amodei and product hype from Codex and Cursor…See this and similar jobs on LinkedIn.

LinkedIn

Despite the big talk from the like Messrs Altman and Amodei and product hype from Codex and Cursor the reality is that AI still can’t do the job of a junior engineer. At least not at HMx Labs. So we’re hiring.

You’ll be working directly alongside senior engineers and be exposed not only to clients but also projects in HMx Skunkworks 😉  The role is entirely HPC focused with a particular focus on our financial services clients. The role is hybrid in nature (London based) but does not have set days in the office.

At this point we can all agree that hiring processes are pretty broken, so here’s the deal. We won’t use AI or CV parsing and keyword tools to sift through the applications if applicants only bother to apply if they meet the criteria below and ensure their CV and/or LinkedIn profiles actually showcase their skills in these areas.

Think you can do the job and want to impress or skip a step, just apply directly with a link to a completed HMx Labs tech test in your GitHub

Anyone applying with a recommendation from someone that has worked with HMx Labs goes to the top of the pile too.

What are we looking for?

• You must have the right to live and work in the UK indefinitely
• At least one year of experience working as a software engineer. Paid full time employment.
• Knowledge and commercial experience with at least one of the following languages: Java, C#, Python (with OO), C++
• Knowledge and some commercial experience of one non managed memory language
• Ideally some exposure to HPC
• Ideally some experience working in financial services technology
• You must have at least one of the two (HPC or financial services)

Let’s see how this goes. Applications on the LinkedIn job posting or by email to jobs@hmxlabs.io

If we get inundated with applicants that clearly don’t match any of the criteria above I reserve the right to break out the AI (or maybmaybe just bash and grep) 😁

Up to £60k/year for the right candidate.

Post 5 in a series on architecture-led cloud migration with Waltz. Earlier posts covered the case study, the argument for enterprise architecture before infrastructure, assessing cloud readiness across an application portfolio, and where AI and machine learning fit in Waltz-based migration planning. This post goes deeper into the dimension that most often determines whether a migration wave succeeds or unravels: dependencies.  And how AI agents working over the Waltz model make a dependency-aware wave plan continuously defensible rather than a quarterly artefact.

Ask any experienced migration lead what derailed their last programme, and you will get the same answer in different words. It was rarely the application they were moving. It was something connected to it that nobody had fully mapped; a regulatory feed, a downstream consumer, a shared identity service, a batch scheduler, a firewall rule protecting an integration nobody had documented.

Hidden dependencies are where cloud migration plans go wrong, and they are precisely what a dependency-aware wave plan exists to manage.

Why wave plans built on preference fail

The default approach to wave planning combines three things: team preference, application priority, and technical readiness. All three are reasonable inputs. None of them, individually or together, is sufficient, because none reflects the structure of the estate.

An application can be a business-priority that is technically ready, and championed by an enthusiastic team, and still be a poor first-wave candidate.  Why? because moving it creates operational risk to five other systems that are not ready, or because it consumes from a source whose migration is six months out. The opposite is also true: applications that look unattractive on every other dimension make ideal early movers if they happen to sit at the edge of the dependency graph, with nothing depending on them and nothing they depend on that is in scope.

A wave plan that ignores the dependency graph is, in effect, a plan built on the assumption that applications are independent. They almost never are.

What "dependency" actually means

The word covers a range of relationships with very different migration implications. A useful classification has three axes.

Direction. Upstream dependencies constrain when an application can move; downstream dependencies constrain how, because anything that breaks affects somebody else.

Type. Synchronous API calls behave differently from asynchronous messaging. Batch feeds behave differently from real-time integrations. Shared data stores behave differently from shared infrastructure. File transfers, shared identity, shared certificate authorities, shared scheduling, shared monitoring.  Each has its own implications for whether and how the relationship can be temporarily bridged during migration.

Strength. A hard dependency means the consumer cannot function without the producer. A soft dependency degrades gracefully. Hard dependencies force tight sequencing or costly bridges; soft dependencies create manageable re-establishment windows. The distinction decides whether two applications must move together, whether one can move ahead of the other, and whether either can move at all without first remediating the relationship.

Modelling and feeding the graph

In Waltz, dependencies are modelled as relationships rather than notes. That distinction matters, because relationships can be queried, traversed, and reasoned about across thousands of applications; notes cannot.

A Waltz deployment built for migration planning captures logical flows (what data moves between which applications), physical flows (how each logical flow is realised: Kafka, SFTP, REST), interfaces with versioning and ownership, shared infrastructure dependencies modelled explicitly, and data classifications including residency and regulatory attributes.

The model is only as good as the evidence behind it, and no single source captures the full picture. CMDBs know what was registered; application teams know what they think they have; batch schedulers know what runs in what order; firewall rules know what was permitted to talk; static analysis knows what is configured; tracing knows what runs under load; network flow telemetry knows what moved across the wire.

In our deployments we wire several of these directly into Waltz, so the graph refreshes as evidence changes rather than as workshops are scheduled. The architecture team becomes the curator of the model, not its author, which is the only sustainable posture for a graph that will need to support wave planning for several years.

The interesting work is the reconciliation. A connection in network flow data with no documented integration is a question. A documented integration never seen in traffic is a different question. A scheduler job nobody recognises is a third. These discrepancies are exactly where hidden dependencies live, and they are the first thing the AI agents we deploy against Waltz are designed to surface.

From graph to wave: three sequencing decisions

Once the graph is in place, wave planning becomes a small number of repeated decisions. The standard heuristics still apply, non-production before production, small early waves, business calendar awareness, simpler workloads first whilst the hyperscaler playbooks cover the operational mechanics in detail. What dependency-aware planning adds is the structural constraint underneath: the order of moves is determined by the shape of the graph, and any heuristic that contradicts it pays for the contradiction at execution time.

Independent movers. 

Applications whose neighbourhood in the graph is stable across the proposed migration window: no hard upstream dependencies mid-migration, no downstream consumers affected beyond what their owners have agreed. They build programme confidence, exercise the landing zones, and validate the operational model. They populate the early waves.

Move-together groups. 

Tightly coupled systems that share state through a database, exchange synchronous traffic at low latency, or participate in the same transaction boundary. A trading-system order manager and its risk engine. A reconciliation engine and its position store. These move together or they create avoidable risk. The graph's job is to make these groups visible during planning, before they assert themselves as emergency coordination problems.

Move-after constraints. 

Applications that can move independently but only after a specific upstream is in place. A reporting platform after its data sources have settled. A downstream consumer after its strategic upstream is generally available in cloud. The cost of ignoring move-after constraints is a fragile cross-environment connection that usually works, until it does not, at which point the incident is somebody's.

A worked example

Consider a Customer Reference Data Service (CRDS) sitting at the centre of a financial services estate. CRDS holds canonical customer master data, consumed by thirty downstream applications across trading, risk, reporting, KYC, and onboarding.

A naive wave plan would assess CRDS on its own merits: well-owned, business-critical, technically supported, an early-wave rehost candidate.

The graph tells a different story. Of the thirty consumers:

·      Twelve use synchronous calls and six of those are themselves planned for early waves. 

·      Eight read CRDS via a nightly batch extract; these tolerate a boundary period. 

·      The remaining ten use a queryable API with tolerance for seconds of latency variation 

o   except one that sits on a regulatory reporting critical path. 

·      The most important point of all: CRDS shares a database with the upstream onboarding workflow, which is itself a migration candidate. 

That is not a dependency; it is a move-together group with a remediation prerequisite (data store separation) before either can move.

The wave decision changes accordingly. CRDS is not an early-wave independent mover. It is the heart of a move-together group whose data store must be untangled first. Six synchronous consumers become move-after candidates. The critical-path regulatory consumer needs a specific bridge, a read replica in the cloud landing zone — or cannot be scheduled until CRDS has moved. The remaining consumers can be scheduled independently provided the batch and tolerant flows are maintained across the boundary.

None of this is visible from the application-level readiness rating. All of it is visible from the dependency graph.

How AI agents work the graph

The previous post in this series covered where AI and machine learning fit in Waltz-based migration planning at a high level. Dependency-aware wave planning is where that capability becomes most concrete, because the graph is a rich, structured artefact that benefits substantially from agentic reasoning. We deploy AI agents that interrogate the Waltz model through precise entity queries, analytical pattern-finding across the portfolio, and semantic similarity for concepts the structured model does not express and through personas do four kinds of work that human teams find expensive at portfolio scale.

Surfacing problems. 

Agents continuously compare the graph against the evidence sources feeding it. Where network flow telemetry shows traffic the logical flow model does not, where a scheduler job has no corresponding integration, where two systems share a database that neither application owner has acknowledged, the agent raises it as a question with the supporting evidence attached. 

The volume of such discrepancies in a large estate is what makes manual reconciliation prohibitive; agents make it tractable. They also surface structural risks the graph reveals but humans rarely think to look for: cycles, single points of failure with high downstream fan-out, cross-jurisdictional flows lacking documented controls, dependencies on infrastructure that is itself in scope for migration with no settled date. 

Some of the most useful problem-finding uses semantic similarity rather than structural traversal. Two applications whose metadata suggest they handle the same data, with no documented flow between them, are a hidden dependency the structured graph cannot surface but a semantic query can, these are precisely the cases that turn into late-stage migration surprises.

Providing recommendations. 

Agents do not only respond to questions. Given the graph and a set of stated migration objectives such as: 

1.        Minimise hybrid period 

2.        Prioritise a particular business line 

3.        Complete by a specific date 

4.        Avoid cross-jurisdictional traffic during transition 

They continuously evaluate the current wave plan against those objectives and raise findings when it drifts. Where they are asked for a new plan rather than a check on an existing one, the output is not "here is the answer". It is "here is a plan that satisfies these constraints, here is what it costs, and here is what it depends on", with the working shown. The agent's value is that it explores the option space at a scale and consistency human planners cannot, presents its choices in a form that can be challenged, and does so continuously rather than only when somebody remembers to ask.

Working in role. 

The same graph looks different to different stakeholders. 

·      An architect cares about structural risks  like cycles, fan-out, principle drift. 

·      A CTO cares about transformation status and timeline risk. 

·      A CIO cares about cost and vendor concentration in upcoming waves. 

Agents tuned to a specific role's concerns produce findings shaped for that audience, on a cadence appropriate to it.  For example, daily for operational hygiene, weekly for portfolio-level concentration, monthly for architectural principle drift rather than dumping the same raw analysis on everyone. Findings persist across runs, are deduplicated so the same concern is not raised three times, carry the provenance of every query and entity that produced them, and can be acknowledged, dismissed, or escalated. The result is that the wave plan is under continuous, role-appropriate scrutiny rather than waiting for the next steering group to surface its problems.

Drawing conclusions aligned with migration objectives. 

The harder and more interesting work is reasoning at the level of programme objectives rather than individual moves. An agent with access to the graph, the wave plan, the readiness assessment, and the stated objectives can answer questions that are otherwise hard to evaluate. For example:

·      Given current progress, which objectives are now at risk? 

·      Which sequencing decisions taken in earlier waves are constraining options now? 

·      If we accept a six-month delay on objective A, which dependencies become non-binding? 

·      Where in the plan is the irreversibility, the points beyond which retreat is expensive?

These are the questions migration steering groups try to answer in quarterly reviews. Agents working over the Waltz model make them continuously available, grounded in the architecture rather than in opinion.

The agents do not replace architectural judgement. They make architectural judgement enforceable at portfolio scale, by ensuring every wave decision is checked against the graph and every objective is checked against the wave plan. The architect's role is what it should be: directing reasoning, not performing reconciliation.

Hidden dependencies and foundational services

Even with disciplined modelling, some dependencies are reliably missed. They can hide: 

·      in connection strings and configuration files (often the most authoritative source of integration information, and also often the least documented)

·      in firewall rules that have been in place for years and that nobody can remember why 

·      in batch schedulers that encode the ordering operations actually relies on, in shared infrastructure too universal to feature in application diagrams

·      in implicit assumptions about latency, location, and time that behave like dependencies when they break, 

·      in operational dependencies: shared on-call teams, shared deployment pipelines, shared change windows  

None of the above are in any application model at all. When they fail, they fail in predictable ways: hidden upstream services left behind, identity or certificate mismatches, DNS changes applied out of order, third-party allowlists blocking changed source IPs, data synchronisation delays, broken timing assumptions. None of this is exotic. All of it is preventable, if the graph has been built well enough to see it coming.

Some applications themselves are foundational i.e. a reference data service consumed by half the estate, an enterprise scheduler, a strategic API gateway. The graph reveals them by their downstream fan-out. They sit in wave zero or a dedicated early wave; they are not interchangeable with the rest of the portfolio.

Bridges and the limits of sequencing

Not every dependency can be resolved by sequencing. Some applications have to move ahead of their dependencies for example, a data centre exit deadline, a strategic platform decision, a regulatory window. The dependency model does not block the move; it prices it.

The pricing is the cost of the bridge. Hybrid connectivity, read replicas, dual-write patterns, event mirroring, identity federation, temporary network extensions.  All are valid migration techniques, and all are operational debt for as long as they are in place. The wave plan should be explicit about which bridges are being built, what they cost to run, and when they will be retired. A bridge for six weeks during a planned wave is a reasonable migration cost. A bridge that becomes permanent because the downstream never moved is an architectural problem the migration created. The graph is what lets you tell the difference at planning time, when you can still do something about it.

What this changes

The argument running through this series is that cloud migration is fundamentally an architecture visibility problem. Dependency-aware wave planning is where that argument becomes most concrete, because the dependency graph is the single piece of architecture that most directly determines whether a wave succeeds or fails.

The change a dependency-aware approach enables is not a different list of applications or a different total migration timeline. It is a different basis for sequencing. Applications are scheduled because of where they sit in the graph, not because of who shouted loudest at the planning workshop. Move-together groups are recognised as units. Move-after constraints are respected. Bridges are designed deliberately rather than improvised under pressure. AI agents catch the discrepancies, propose the trade-offs, and check the plan against the objectives continuously, rather than letting all of this accumulate to a quarterly review.

In the case study estate this series builds on, the documented outcomes included faster prioritisation across a large and diverse portfolio, better sequencing of migration waves based on real dependencies, and reduced risk of disruption caused by hidden interconnections. None of those were achieved by adding effort to the programme. They were achieved by directing the same effort against a better-shaped problem.

The migration plan stops being a list of applications and becomes a sequenced traversal of an architecture model, supported by agents that keep the model honest and the plan defensible.

That is the difference between a wave plan that looks reasonable in PowerPoint and a wave plan that survives contact with execution.

HMx Labs helps organisations use Waltz, augmented with AI agents, to map dependencies, design dependency-aware migration waves, and build evidence-based migration programmes that survive scrutiny from architecture, delivery, and governance teams alike. If you are planning a large-scale migration and want to move beyond preference-led wave design, get in touch.

I first started writing a weekly newsletter about HPC back in 2024. I figured it needed a name of some kind, but I didn’t really put much thought into it. I think I just Googled/ asked ChatGPT for some names that sounded cool. Wasn’t a great move as it’s called Quantum and very little of what it covers is about quantum computing (though it does get a bit of coverage now and again). Oops.

I’ve been meaning to fix that for the longest time, at least a year or so but couldn’t really come up with a good name. So, I kind of gave up.

Finally, I’ve just given it another name that I’ve spent ages deliberating over and may not be particularly original, but I think at least conveys what it’s about a bit better!

I figured if I’m going to do all that, I may as well give it a little logo which means I now need your help to pick one from the over 600 designs that were submitted to the competition for it! Don’t worry I’ve selected some of my favourites, so you don’t have to review all 600 😁

Help me choose my new design!

I’m running a logo contest on 99designs. Designers have submitted 679 designs so far. Please vote on your favorite as I’d love to receive your feedback.

99designs99designs

Oh also, if you’ve made it this far and are celebrating today, Happy Eid!

It seems to be mostly silicon related news from last week and we’ll kick off with a continuation of the topic of accelerator diversity that the Cerberas IPO from the last issue mentioned. We see this gaining further momentum as Google partners with Blackrock to deliver more TPUs and Ali Baba drops their new AI focused accelerator too.

All of that is well and good, but I still don’t understand what the end game is here, what’s the plan to get anyone to write their code to target your silicon? Or are we really planning to go old school and just target a single platform?

Continuing the silicon theme but in CPU form, we get some news on AMDs “Venice” processors with a touted 70% uplift in performance. We saw close to that in our own testing between Genoa and Turin so whilst a bold claim it may be credible. Meanwhile, Nvidia has decided it is a CPU manufacturer too and is targeting 200 billion in sales of its Vera CPUs. As a reminder these of the ARM flavour, meaning that adoption may be less than trivial for some use cases (I’m looking at you old quant libraries and obscure scientific libraries). 

Lastly, in news from us at HMx Labs we’ve finally set a date for the next HPC Club. July 8^th. Mark your calendars get your night out passes now, I promise it will be worth it! We’re also still hiring so if you know a good HPC Nerd or two please point them my way especially if they’re any good at writing code or marketing/ business development.

In The News

Updates from the big three clouds on all things HPC.

Noteworthy by HMX Labs

Accelerator silicon diversity seems to be continuing unabated

https://www.reuters.com/business/google-blackstone-create-new-ai-cloud-company-wsj-reports-2026-05-19

https://www.reuters.com/world/asia-pacific/alibaba-unveils-new-ai-chip-push-domestic-alternatives-2026-05-20

But we still need CPUs

https://www.reuters.com/world/china/nvidia-says-its-forecast-200-billion-cpu-market-includes-china-2026-05-23/

AMD begins production ramp of 256-core EPYC Venice — first 2nm HPC chip claims 70% performance leap

Intel’s competing P-core Xeon won’t arrive until 2027 at the earliest.

Tom's HardwareLuke James

From HMx Labs

HPC Club is Live for 2026

Mark your calendars, book your babysitter, HPC Club is go for 2026.

Flux by HMx LabsHamza

Hiring: Marketing & Business Development

We’re looking for someone awesome to come help us shape the future of HMx Labs

Flux by HMx LabsHamza

Dear CSO: Turns Out, You Were Right

The state of software security is pretty bad right now and maybe, just maybe that hated approach the bank CSOs took was the right one.

Flux by HMx LabsHamza

Finally! We have a date for the first HPC Club for this year.

If you’d given up on me on actually getting another HPC Club off the ground, I don’t blame you. Partly it’s been due to a very busy start to the year but honestly a large part of it was also trying to figure out what we should focus the event on. I didn’t want to just organise something for the sake of it. If I’m going to ask for your time and make you attend in person, it needs to be worth your while.

To cap it off, some of the topics I wanted to talk about meant the real experts aren’t local and our budget didn’t really cover transatlantic flights… but I think we’ve pulled it off. Trust me, they have more FLOPs than you 🤣

More details soon but for now block your calendar and book the babysitter (or bring your kids, mine will probably be there).

No Selling. No Hype. Just real supercomputing.

HPC Club. 8 July. Be there and be square. 😁

I’m sorry. I was wrong. This is an apology to every CSO in every bank I’ve ever worked with in every. Turns out, you were right.

It might have taken a while, but time has certainly shown you to be correct. I probably didn’t complain to you directly, but I certainly swore under my breath in many a meeting, or security review trying to get a risk system live.

It turns out you were right when you mandated that every package (regardless of package manager or programming language) could only be sourced from an internal repository and to get something new into that repository it first required a security review, For every version.

It turns out you were right to mandate encryption with keys that never leave the premises no matter how secure the cloud providers promised their encryption schemes are.

It turns out you were right to require every binary, shell script or archive be vetted before crossing the bank’s firewall. 

Even if all of these processes did nothing more than add a little friction and delay (though I expect they do more than that), right now they are paying dividends. I now find myself wondering how to implement many of these same ideas within HMx Labs. Perhaps with a little less friction and bureaucracy but even so.

So, I have my humble pie and will duly eat it. And promise to be more amenable in future! To all my friends and colleagues writing code in a bank, maybe it’s time to cut our CSOs a little slack and get with the program.

P.S: If you don’t know why I’m writing this now you might want to quickly go and Google for Copy Fail, Copy Fail2, Dirty Frag, Shai Hulud, Mini Shai Hulud and quite a few others.

This is the fourth post in a series on architecture-led cloud migration with Waltz. Earlier posts covered the case study behind the approach, the argument that cloud migration needs enterprise architecture before infrastructure, and a practical model for assessing cloud readiness across an application portfolio. This post addresses a question that comes up in almost every conversation about that work: where do AI and machine learning fit in?

It is a fair question, and one that deserves a direct answer rather than a marketing one. The honest position is that AI and ML help meaningfully in some places, are oversold in others, and do not change the underlying architecture problem the readiness model exists to solve. This post sets out where they earn their place, where they do not, and how to think about adopting them without creating new problems in the process.

Start with what the model actually is

The readiness model described in the previous post is a structured human judgement. Applications are assessed across six dimensions: technical, operational, business, lifecycle, dependency, and regulatory using written criteria, captured in Waltz alongside the rest of the architecture context, and translated into a treatment decision through a defined rating scheme.

The work that goes into producing and maintaining that model is what AI and ML can accelerate. The judgement at the centre of it is not what they can replace. Holding that distinction firmly is the difference between using AI well and using it badly.

Where AI and ML genuinely help

Discovery: bootstrapping the first-pass assessment

The single most expensive part of building a readiness model is the first pass. Getting a baseline rating across hundreds or thousands of applications, when documentation is fragmented and the people who know each system are scattered, is months of work in a typical large estate.

Large language models are genuinely useful here. Pointed at an application's existing documentation. Confluence pages, README files, architecture diagrams, runbooks, ticket history, code repositories.  They can draft a first-pass assessment against your defined criteria. The draft will not be perfect, but it will be roughly right, and the human assessor moves from author to editor. That is a much faster role.

The pattern that works is to have the LLM produce a structured output: a draft rating per dimension, with the supporting evidence cited, and explicit gaps marked where evidence was missing. The reviewer then has a starting point, knows what to verify, and can see where their judgement is being asked to fill a gap rather than override the model. Done well, this turns a months-long inventory exercise into a weeks-long review exercise.

Another key factor is that the Waltz dataset includes dataflows, applications booksmarks (to code repos, confluence, sharepoint etc), process diagrams; all of which can provide the AI structured and authoritative input.

Extracting dependencies from unstructured sources

Dependencies are usually the worst-documented part of an estate. They live in connection strings, firewall rules, integration code, batch schedulers, log files, and tribal knowledge. Building a clean dependency graph from those sources is one of the slowest parts of any architecture programme.

LLMs are unusually good at reading heterogeneous text and extracting structured relationships. Combined with static code analysis, network flow data, and existing CMDB exports, they can populate a dependency graph in Waltz that would otherwise take months of interviews / surveys to assemble. The output requires validation, but you are validating a draft rather than building from nothing which is a leap!

This is also the area where AI most directly addresses a real risk identified in the case study and the earlier posts: hidden dependencies are where migration plans go wrong. Anything that improves the completeness of the dependency view materially improves the quality of the migration plan.

Surfacing inconsistencies in ratings

Once ratings exist across a portfolio, machine learning techniques can flag applications whose composite profile looks anomalous. If an application is rated Green on technical and operational readiness but Red on business readiness, is that genuinely the right answer or is it a sign that one team scored differently from another? Cluster analysis across rating vectors highlights outliers worth a second look.

This is unglamorous but it is exactly how a readiness model stays consistent over time. Without it, the model drifts as different teams apply slightly different interpretations of the same criteria. With it, drift is detectable and correctable.

Natural-language interrogation of the model

Once Waltz holds a rich, connected view of the estate; assessments, ownership, capabilities, data flows, dependencies, lifecycle states.  The question of who can use that view becomes important. Architects and engineers can navigate it directly. Senior stakeholders typically cannot, and they are the people whose decisions the model exists to support.

An LLM with appropriate access becomes a useful interface to the model. Queries such as "show me applications rated Ready with conditions where the conditions involve regulatory approval and the business owner is in division X" today require either bespoke reporting or someone fluent in the data model. An LLM bridges that gap. The model becomes accessible to people who would otherwise need a translator, which is how it earns its place in governance forums and steering committees rather than just in architecture team meetings.

Some early POC screens below:

Drafting migration and assurance artefacts

Once an application is selected for a wave, there is substantial paperwork to produce: migration runbooks, change records, risk assessments, communication plans, post-migration assurance evidence. Much of this is templated and can be drafted from the structured data already in Waltz combined with the application's documentation, and possibly even represented in Waltz in the Notes feature.

This is where programme capacity is otherwise consumed. Engineers spend disproportionate time writing documents that mostly reformat information that already exists in structured form somewhere else. Automating the assembly of those documents + citations with the human signing off rather than authoring, frees capacity for the work that requires judgement.

The post-migration assurance angle is particularly relevant given the case study's emphasis on jurisdictional landing-zone compliance. Cross-referencing intended landing-zone decisions against actual deployment evidence, flagging discrepancies, and drafting assurance narratives is exactly the kind of structured-text task LLMs are well suited to, that said, these has all been done with task specific code that covers the automation problem well.

Where AI and ML tempt but disappoint

The temptations are equally important to name, because they are where AI investment most often goes wrong in this kind of programme.

Predicting readiness from infrastructure data alone

It is tempting to imagine training a model on "applications that migrated successfully" versus "applications that did not" and using it to score new candidates. This rarely works in practice. The dataset is small, the failure modes are heterogeneous, the ground truth is noisy, and "success" is hard to define consistently across applications and business contexts.

More fundamentally, the entire argument of the readiness model is that infrastructure data alone is insufficient. A predictive model trained on infrastructure features reproduces the failure mode the readiness model exists to fix. Better infrastructure-feature classifiers do not solve a problem that is fundamentally about business, regulatory, and dependency context.

Fully automated rating

An LLM can draft a rating. It cannot own one. Ratings carry governance weight, they justify investment decisions, regulatory positions, and sequencing choices. A rating with no accountable human behind it is a rating that does not survive its first challenge in a steering committee or audit.

This is not a courtesy point. It is a governance requirement. The readiness model is defensible because every rating has a human signature on it and a documented evidence trail. Removing the signature to claim full automation removes the property that makes the model useful in the first place.

"AI-driven migration sequencing"

Sequencing is constrained by dependencies, regulatory windows, business calendars, change freezes, contractual obligations, platform readiness, and team capacity. Most of these are hard constraints, not optimisation variables.

Constraint-based scheduling techniques genuinely help here and have for decades. Branding them as "AI-driven sequencing" adds nothing technical and tends to obscure what the constraints are. The risk is that opaque optimisation produces a plan nobody can defend when the first constraint shifts, which it will.

Treating LLM output as authoritative

LLMs hallucinate, particularly about specifics: version numbers, ownership, dates, regulatory clauses, contract terms. Anything an LLM produces about your estate must be treated as a draft to be verified against authoritative sources, not as fact.

The discipline that makes the readiness model defensible is the same discipline that protects against LLM error: written criteria, traceable evidence, human sign-off. Programmes that skip that discipline because the AI "sounded confident" end up with a portfolio of plausible sounding but unreliable ratings, which is a worse position than a smaller portfolio of carefully verified ones.

A sensible adoption sequence

The pattern that works in practice is to introduce AI capabilities in an order that builds trust before it builds dependence.

·      Start with extraction. Use LLMs to draft application descriptions, ownership inferences, and dependency relationships from existing documentation. The output is reviewable, the cost of error is low, and the time savings are large.

·      Move to assessment drafting. Once the team is comfortable with extraction quality, use LLMs to draft first-pass readiness assessments against the defined criteria. Keep the human-in-the-loop pattern explicit: every rating is reviewed and signed off.

·      Add anomaly detection. Once a meaningful number of ratings exist, introduce ML-based consistency checks across the portfolio. This catches drift early and give the team confidence the model is being applied uniformly.

·      Expose natural-language querying. Once the model is reliable, open it up to senior stakeholders through an LLM interface. This is where the investment in the underlying model pays off in governance value.

·      Automate the artefact assembly. Last, automate the production of runbooks, change records, and assurance documents from the structured model. By this point the team has enough trust in the underlying data to delegate the assembly safely.

The order matters. Programmes that try to start at the end: automated artefact production from an LLM’s view of the estate, without the underlying model being trustworthy, produce confident-sounding outputs that will not survive scrutiny. Programmes that start at the beginning build the trust they need to use the more powerful capabilities later.

The architecture problem does not go away

The argument running through this whole series is that cloud migration is fundamentally an architecture visibility problem rather than an infrastructure problem. AI and ML do not change that. They change the cost of producing and maintaining the architecture view, which is significant; but the view itself, and the judgement applied to it, still has to exist.

Used well, AI makes a structured readiness model achievable in weeks rather than months, and maintainable as a living artefact rather than a frozen snapshot. Used badly, it produces a confident-sounding readiness rating with no defensible basis underneath it, which is exactly the failure mode the readiness model exists to prevent.

The right framing is not "what can AI do for cloud migration". It is "what does the migration programme need to do well, and where can AI accelerate that work without compromising the governance that makes it defensible". That framing puts the architecture model first and the AI tooling second.

HMx Labs helps organisations use Waltz to build evidence-based cloud migration programmes, and to integrate AI and ML capabilities where they accelerate that work without undermining its governance. Get in touch to discuss how this applies to your estate.

Whilst its immediate impact is going to be pretty limited for most of us, I guess the most important thing that happened in supercomputing last week was the Cerberas Systems IPO. At least as of Sunday evening, it seems to have been relatively well received. Whilst Cerberas may not have a particularly wide deployment yet and technical adoption is low; the financial markets at least seem to believe it has a future. 

Which poses some interesting questions for the technical amongst us to ponder upon as it is yet another sign of increasingly heterogenous compute environments with very little underlying support by way of multi architecture frameworks. Most HPC developers, RSEs and the like will rarely target more than a single architecture, and this worked fine in a world where the supercomputer you were going to run on sat in your building and that was all the choice you had. As we move to a world where supercomputers are in the cloud and software defined, that approach may not work so well. Or maybe the public inference use case will move to the edge and what remains (trainings, classical MPI workloads, converged LLM plus classical compute) will be like a lot of HPC workloads and target a very specific architecture.

The second story to catch my eye from the last week was HPC Wire’s article on Slurm vs Kubernetes. I do wonder if my piece  a couple of weeks ago had anything to do with that 😀. The article ends with a reference to Slinky, and whilst I think that Slinky (and its numerous counterparts in this space) are a good idea if you have to use Kubernetes (say it’s the only way to obtain compute capacity or the entire estate now runs K8) I really wouldn’t select it as an option unless I had that restriction.

Lastly, Next Platform’s piece on Multipath Reliable Connections for supercomputer networking is pretty cool! Definitely worth a read and I wonder if it might inspire similar solutions at a smaller scale too. The equivalent of what a Beowulf cluster is to a supercomputer if you will. Honestly, I’m even wondering what we could do with our tiny little HMx Labs test cluster.

In The News

Updates from the big three clouds on all things HPC.

Noteworthy by HMX Labs

Cerberas Systerms IPOs but what will it mean for your supercomputer?

https://seekingalpha.com/news/4593661-cerebras-systems-dips-on-second-day-after-55b-ipo-debut

With Its IPO Done, Cerebras Can Get Back To Pushing The AI Envelope

There will probably never be a better time for any AI-related company to go public than between righ…

nextplatformTimothy Prickett Morgan

https://www.hpcwire.com/2026/05/14/cerebras-ipo-signals-growing-pressure-on-the-gpu-scaling-model/

MRC – A new way to do supercomputer connectivity

OpenAI, Microsoft And Friends Build A Better, More Scalable Ethernet

Sometimes, to solve a particular system architecture problem, you have to invent a new technology. A…

nextplatformTimothy Prickett Morgan

HPC Wire’s take on the right scheduler for workloads… 

https://www.hpcwire.com/2026/05/15/slurm-vs-kubernetes-in-the-age-of-ai/

From HMx Labs

We’re still trying to hire for our marketing and business development role. Know anyone that might be a fit?

Hiring: Marketing & Business Development

We’re looking for someone awesome to come help us shape the future of HMx Labs

Flux by HMx LabsHamza

and related to that: AI art or not?

Human or AI Generated Images

Just a fun Friday anecdote about the image that accompanies our last job opening.

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

You probably think I have all it all together. Social media posts planned and written months in advance. Images to go with them carefully created and approved before being published. I’ll let you in to a secret. Not so much!

More often than not, I speak about what is top of mind or something that caught my interest in the previous couple of days. Far too often I will be writing the post an hour or so before you see it and at best, the evening before.

That mostly left me with a couple of choices if I was going to have an image to go with the text, stock photography (which I also sometimes use) or AI Generated. Usually this meant AI because as its a closer match to the text.

Last week though someone gave me some good advice (well the second or possibly even third someone actually). Use less AI generated imagery. Solid advice. Always found it hard to implement. This time though it was enough to make me try.

And boy was that a lot of work!

The two AI generated examples below took about 15 minutes of back and forth with an LLM to generate. The image at the top was about 4 or 5 hours of work and forced my poor sister Fatima to jump in her car and drive my camera back over to me on Tuesday night. (Side note: her photography is much better than mine!)

I scribbled three different versions of the text that I wasn’t happy with. My daughter decided she could do a better job and gave me her version too. In the end I cheated and wrote it on an iPad and traced it onto my notebook. NGL, I was low key worried that someone out there might also analyse my real handwriting and tell everyone I’m a psychopath. I blame Silicon Valley and there’s no way I can afford Banksy. 🤣

The photo was taken with a Canon 5D Mk III and 50mm F1.4 lensat F2.5 for the photography geeks.

Totally worth the effort. Will try harder, but can’t promise future images will have the same level of effort. Please tell me the top image is better! (or don’t).