Alessandro Sangiorgi — GPU Performance Engineer

Serving DeepSeek-V4-Flash-0731 in Tensor Parallel Across Two DGX Sparks

Fri, 31 Jul 2026 00:00:00 +0000

DeepSeek published DeepSeek-V4-Flash-0731 today — the official release superseding the preview, “only re-post-trained” on the same architecture, but with a large jump in agentic capability:

Benchmark	V4-Flash-0731	V4-Flash (Preview)	V4-Pro (Preview)
Terminal Bench 2.1	82.7	61.8	72.1
Cybergym	76.7	38.7	52.7
DeepSWE	54.4	7.3	12.8
Toolathlon-Verified	70.3	49.7	55.9
DSBench-Hard	59.6	25.8	31.1

Notably it beats V4-Pro-Preview on every one of those, despite a much smaller activated parameter count — and it comes with a speculative-decoding module attached out of the box. I have two GB10 DGX Sparks wired together over ConnectX-7 for exactly this kind of thing, so this post is the tensor-parallel deployment recipe: what’s actually in the checkpoint, whether it fits, the launch flags, and the trap that will wedge a fresh multi-node deployment if you skip it.

Unboxing Two DGX Sparks, and Recovering One From a Kernel Panic on First Boot

Sun, 28 Jun 2026 00:00:00 +0000

I recently took delivery of two NVIDIA DGX Sparks (the GB10 units I later wired together for the small-message NCCL latency benchmark). The out-of-box experience is genuinely slick — right up until one of the two bricked itself on the very first software update and dropped me into a kernel panic. This post is the other half of the story: the setup flow, and exactly how I brought the dead one back.

Wiring Two DGX Sparks: One Script to Detect, Configure, and Validate the RoCE Link

Sun, 28 Jun 2026 00:00:00 +0000

You plug the ConnectX-7 stacking cable into two DGX Sparks, assign a couple of IPs, and… now what? Before you trust that link with any distributed workload, you want to know three things are true:

The link runs at line rate (~100 Gbps/rail), not pinned at ~13 Gbps by a firmware-throttle trap.
RDMA latency is in the single-digit microseconds.
NCCL collectives actually ride the RoCE fabric — not a silent TCP fallback that looks like it works but runs 50× slower.

Every one of those can fail silently, reporting a plausible-but-wrong number. And before you can even test them, you have to answer a surprisingly annoying question: which network device is the live one? On a fresh Spark the answer is not obvious, and it is not the same name on both boxes.

The Number Nobody Published: Small-Message NCCL Latency Between Two DGX Sparks

Thu, 25 Jun 2026 00:00:00 +0000

If you go looking for performance numbers on two NVIDIA DGX Sparks wired together over the ConnectX-7 stacking cable, you’ll find the same thing everywhere: bandwidth. NCCL bus bandwidth of ~24 GB/s. RDMA ib_write_bw of ~190 Gbps aggregate. iperf throughput. Forum threads about getting from a throttled 13 Gbps back up to line rate.

What you will not find — anywhere, as of this writing — is the number that actually matters for a latency-bound distributed workload: how long does a small-message collective take? Not a 1 GB all-gather that’s bottlenecked on bandwidth, but a few-kilobyte all-reduce whose cost is pure round-trip latency, the kind that lands on the critical path of tightly-coupled parallel execution and gets paid once per layer, per step, with no overlap.

From a Student Side Project to a Google Success Story

Wed, 24 Jun 2026 00:00:00 +0000

Google just published a Publisher Success Story about Sangiorgi SRL — the company I founded and still run from Sicily while working full-time at Red Hat. It’s a strange and wonderful thing to see your own origin story written up by the platform that made it possible. Here’s the longer version, in my own words.

It started as a way to learn

While I was studying computer engineering in Catania, I built WiFi WPS WPA Tester as a side project. I wanted to understand how WPS — the “press a button to connect” feature on home routers — actually worked, and how badly it could fail. The app let people check whether their own Wi-Fi network was exposed to the well-known WPS vulnerabilities of the time.

FLAG_MUTABLE PendingIntent in DeviceAsWebcam Allows Foreground Activity Hijack via fillIn() Injection

Sat, 18 Apr 2026 00:00:00 +0000

I reported a vulnerability in AOSP’s DeviceAsWebcam service where a FLAG_MUTABLE PendingIntent is used as the foreground notification’s contentIntent. An attacker app with user-granted NotificationListenerService access can extract the PendingIntent, inject arbitrary intent fields via fillIn(), and force-launch the system-UID DeviceAsWebcamPreview activity in the foreground — overlapping whatever the user was doing. The report was submitted on March 19, 2026.

The Vulnerable Code

The vulnerability is in DeviceAsWebcamFgService.java (line 134). The preview activity intent is created with only the component set — no action, no data, no extras, no flags, no categories:

Retrieving the ARP Table on Android SDK 30+ via Netlink

Wed, 08 Apr 2026 00:00:00 +0000

Starting with Android 11 (API level 30), Google removed the ability for apps to run ip neigh or bind netlink sockets. This broke every app that relied on reading the ARP table — network scanners, device discovery tools, local network diagnostics. The change was intentional: Google argued that exposing the neighbor table leaks information about other devices on the local network, which is a privacy concern.

The problem is that there was no replacement API. Apps that needed neighbor discovery — for example, to find smart home devices, printers, or other hosts on the LAN — were simply out of luck. So I wrote a native library that retrieves the ARP table via RTNetlink without binding the socket, shipped it as an Android library, and open-sourced it.

Blocking WiFi De-Auth Attacks in the Kernel with eBPF and XDP

Tue, 07 Apr 2026 00:00:00 +0000

802.11 de-authentication attacks are one of the oldest and cheapest WiFi denial-of-service techniques. An attacker sends forged de-auth management frames to disconnect clients from an access point — aireplay-ng sends 128 per attack command (64 directed at the AP, 64 at the client). Despite being a known problem for over two decades, the main defense is still 802.11w (Protected Management Frames), which requires both AP and client support and still degrades under high-rate floods.

Intercepting Android's ManagedProvisioning: A PendingIntent Vulnerability in AOSP

Mon, 06 Apr 2026 00:00:00 +0000

I found and reported a vulnerability in Android’s ManagedProvisioning component — the system app responsible for setting up enterprise-managed (work) profiles. The bug allows any unprivileged third-party app to intercept a privileged provisioning callback, leaking install timing, session metadata, and in some cases package details — all without any special permissions.

Google acknowledged the report, logged it for potential remediation, and classified it as low severity. Here’s the full breakdown.