I Was Given the Hardware. Here Are My Guardrails
| ⚠️ |
|---|
Disclosure: Dell gave me a Dell Pro Max with GB10. I did not pay for it. I am not paid to write about it. Nobody at Dell sees these posts before you do.
| ⚠️ |
|---|
This paragraph is going appear in every piece in this series, not just this one. If you only read this far, you have the important part.
Everything below is me explaining why I’m starting a technical series with a housekeeping post and how I’m going to try to keep myself honest over the posts to come.
Why this needs saying properly
There’s a version of this series that would be easy to write and worthless to read. Impressive-sounding numbers, a lot of enthusiasm, no mention of what doesn’t work. You’ve read it before and probably last week, about something else.
The problem isn’t that sponsored content exists. The problem is that it’s often indistinguishable from independent content, so readers end up discounting everything. That’s bad for you and, ultimately, bad for the vendors too.
I spend the majority of my current working life in pre-sales. My entire professional value rests on customers believing me when I tell them something won’t work for them. If I burn that for a piece of hardware, I’ve made a spectacularly bad trade.
So here are the rules, stated in public where you can hold me to them.
The rules
1. Disclosure on every piece, not just this one. Not buried in a footer. Up top, in the first screen, every time. If a piece gets syndicated somewhere and the disclosure doesn’t travel with it, that’s my failure to fix.
2. Measurements, with method. Every number I publish comes with how I got it: the model, the quantisation, the prompt, the run count. If you can’t reproduce it, I haven’t published it properly. All of it goes in a public repo.
3. The negative pieces are already scheduled. Not “I’ll mention drawbacks if any come up.” Two pieces are already in the calendar: a ninety-day teardown called what I stopped using it for, and a later one called who should not buy this. They’re written into the plan before I know what they’ll say.
4. If it breaks, that’s the content. I’m going to attempt to bring the best content and I have to admit I am guilty of seeking perfection. Sometimes that perfection prevents me from getting content out on time and ultimately time passes where it is no longer relevant. With this series I am not going to quietly drop a workstream because it made the box look bad.
5. I won’t pretend to expertise I don’t have. I have twenty years in infrastructure and a Microsoft Security MVP. I’m not a machine learning researcher. Where I’m out of my depth I’ll say so, and where a sector’s regulation is involved I’ll name frameworks as things to verify rather than assert them from memory.
Treating this as an experiment, not a review
Rules are easy to write and easy to quietly abandon. So I want to add some structure that makes abandoning them visible.
Product reviews have a structural problem: the reviewer forms an opinion early, then assembles evidence that supports it. It’s rarely dishonest, it’s just how people work. You notice the things that confirm what you already think, and the contrary evidence never quite makes it into the draft.
The way out of that is to write down what you expect before you have the evidence, and then check.
That’s not a novel idea. It’s how science has worked for several hundred years, and it maps onto this project almost exactly:
- State the hypotheses up front, publicly, before the data exists.
- List the apparatus, the hardware, the software, the versions.
- Collect evidence over time, to a fixed method, including the evidence that’s inconvenient.
- Review against the hypotheses at the end and report which ones were wrong.
Step four is the one that matters. Anyone can make predictions. The value is in going back and saying “I was wrong about three of these”, which is exactly the thing a review with a foregone conclusion never has to do.
1. The Hypotheses
Six predictions, made in week one, with no data behind them.
H1 — The device will win on constraint, not capability.
H2 — Utilisation will be lower than I plan for.
H3 — Operational overhead will exceed electricity as a running cost.
H4 — Governance will be sporadic across the board.
H5 — Local inference and rapid development will be this devices strengths.
H6 — I will recommend against buying one, for most readers.
2. The Apparatus
Stated so you know exactly what produced every number, and so you can tell when a result is about the hardware rather than about my particular setup.
Hardware under test
- Dell Pro Max with GB10: 128GB unified memory, Cortex-A725 (20 cores), NVIDIA GB10, CUDA
- DGX OS (Ubuntu-based), ARM64
Comparison hardware Were possible I will attempt to make comparison to other devices/options available in the market at the moment.
Instrumentation
- Smart plug, continuous logging (Power)
- Sound meter at 1m, desk height (Noise)
- Thermal and utilisation logging on-device
Software — versions recorded with every result, because they date fast and a benchmark without a version number is an anecdote.
3. The Evidence
Collected continuously from day one, not gathered retrospectively when a post is due:
| What | How often | Feeds |
|---|---|---|
| Power draw | Continuous | The running-cost picture |
| Throughput per model | Every model tried | The capability picture |
| Noise and thermals | Under sustained load | The desk-reality picture |
Fixed method throughout: identical prompts, five runs, median reported, cold starts excluded, versions stated. Raw output goes in the repo whether or not it’s flattering.
4. The Review
When I get to the end of my planned content, I will come back to these six hypotheses and report on each one: right, wrong, or unresolved.
The hypotheses above will not be edited. If you find this post again in ten months and the predictions look suspiciously accurate, either I got lucky or you’ve caught me cheating, and both are worth knowing.
What this series is actually for
There’s a specific gap I want to fill.
The local AI conversation right now is happening in two places. One is vendor marketing and the other is the enthusiast community.
Neither is written for the people I work with every day: IT directors and CISOs in Entra-joined, Defender-covered, Purview-governed Microsoft estates, who have a real and increasingly urgent problem. Their business wants AI. Their data can’t leave the tenant, or the country, or the building.
That’s the audience. Whether a box on a desk genuinely helps them is the question. I don’t know the answer yet! The six hypotheses above are guesses, and I’ve committed to telling you which ones I got wrong.
What happens next
Next week: the three things this box is not. Not a gaming PC, not a Copilot+ laptop with ambition, not a replacement for your Azure spend. Clearing those out of the way makes the rest of the series possible.
Then the measurements start. What actually fits in 128GB of unified memory and whether the machine even has 128GB to begin with.
Disclosure, again: hardware gifted by Dell. No payment, no editorial control, no pre-publication review. Hypotheses fixed at publication and not subsequently edited. All measurement data and raw output: Local AI Repo.