Michael Hospedales · Software Engineer · Miami, FL

Building for the web by day. Running a newsroom that writes itself by night.

I'm a software engineer in Miami. I build production web interfaces with React, Next.js and TypeScript — and I run autonomous AI systems on my own NVIDIA DGX Spark, including The Agentic Daily, a newsroom that researches, drafts and publishes without a human in the loop.

See what I'm buildingAbout me

Now

Updated August 26, 2026

  • Running The Agentic Daily: an autonomous newsroom that researches, drafts and publishes an edition every day from my DGX Spark
  • Measuring whether my model evaluations are real — noise floors, replicates, and the improvements that did not survive them
  • Growing the homelab: vLLM and llama.cpp on Grace Blackwell, and everything that needs a second look on aarch64

Building

All projects →

The Agentic Daily

active

An autonomous newsroom running on my own hardware: a roster of editorial personas that research, draft, judge and publish a daily edition without a human in the loop.

Python · TypeScript · Astro · vLLM · llama.cpp · NVIDIA DGX Spark · cron

AI writing pipeline

active

A local LLM on my NVIDIA DGX Spark that drafts blog posts and opens pull requests I review before publishing.

NVIDIA DGX Spark · vLLM · llama.cpp · GitHub PRs · Zod · CI

Homelab AI infrastructure

active

An NVIDIA DGX Spark on my desk: local models, self-hosted services, and infrastructure as a learning practice.

NVIDIA DGX Spark · vLLM · llama.cpp · Qwen 3 · Gemma · Linux · self-hosting

Field notes

All notes →

Downloading one new file from a Hugging Face repo invalidates the path to all the others

Fetching a newly published mmproj moved refs/main to a fresh snapshot directory containing only that one file, while 93.6 GB of weights stayed in the previous snapshot. Any launcher resolving through refs/main — which is the recommended practice, since snapshot hashes change on every re-pull — then fails its own existence check on weights that are plainly on disk. The fix downloads nothing: a second hf download with the original include pattern relinks the existing blobs into the current snapshot.

Dropping --kv-unified silently turns a 262144-token server into a 65536-token one

llama-server divides the context size by the slot count unless --kv-unified is set: n_ctx_seq = n_ctx / n_seq_max. There is no error and no warning. The same command line that asks for --ctx-size 262144 --parallel 4 serves 65536 per sequence, and the only evidence is one line in the boot log. Long prompts then fail or shift in ways that look like a model problem rather than a configuration one.

GGML_ASSERT(layer.nextn.hc_head_norm) — two MTP pull requests disagree about one tensor name

A published Qwen3.8-Flash-Next MTP head loads against PR #27739 and aborts against PR #27836 with "MTP block missing nextn.hc_head_norm". The head is not damaged and no tensor is missing: the same three hyper-connection tensors are exported as top-level output_hc_norm/down/up by one PR and expected as blk.N.nextn.hc_head_norm/down/up by the other, because a standalone head file has no trunk to collide with and a grafted head does. The published merge script filters to blk.* and silently drops all three. Rename them instead of dropping them.

Writing

All posts →

I grafted a speculative decoding head into a 90 GB model file

The model card advertised a 4B multi-token-prediction head. No published GGUF contained it, and the architecture had no code path to run it. Both halves arrived within 36 hours from two different strangers, in incompatible forms — so I merged the head into the target file myself. It went from 27.75 to 43.30 tok/s, and three of my four mistakes along the way were about verification, not tensors.

The kernel kills your inference server first, and by default

An 87 GiB model got OOM-killed with nothing in its own log. The process that triggered it was a 27 MB dashboard service. The reason my inference server was the kernel first choice was not its size — it was a systemd user-manager default that scores every terminal-launched process to die before any system service. Then restarting it killed my editor.

Tokens per second told me the wrong model was faster

A 125B model decoding at 26.6 tok/s looks unremarkable beside a 31B at 29.3 — until you notice the 31B is running a drafter, so its number is a forward-pass rate multiplied by an acceptance length. Per forward pass the big model was 3x faster. Here is how to decompose the number, and what the bandwidth arithmetic says is still on the table.

Come say hello

No project or budget required — I like talking about interesting problems, shop talk on agentic systems, and the occasional war story from shipping.

Get in touch