Matt Suiche
Cybersecurity Researcher
Hello! My name is Matt Suiche. I am an independent researcher, advisor, and investor. I previously served as the Head of Detection Engineering at Magnet Forensics. Our organization was passionately dedicated to justice and protecting the innocent, a mission we embarked on more intensely after the 2022 acquisition of my cybersecurity start-up, Comae Technologies.
My professional journey began as the Chief Scientist and Co-Founder at CloudVolumes which was acquired by VMware (NASDAQ:VMW) in 2014, before founding Comae. In addition, I’m proud to have initiated the cybersecurity community project, OPCDE.
My life-long fascination with learning and understanding complex systems first led me to cybersecurity. My teenage years were spent immersed in reverse engineering, which ignited a profound curiosity about technology that continues to this day. I’ve since explored various fields including operating systems architecture, programming languages, virtualization, modern web application development, and generative art. Furthermore, I’ve delved into numerous domains such as privacy, surveillance, forensics, blockchain, and community development among others.
Latest
The internet was built with a missing piece. In 1994, when the HTTP specification reserved status code 402 for “Payment Required,” the architects knew money would eventually flow as freely as data. Three decades later, that vision is finally materializing—not because humans demanded it, but because AI agents need it.
The 402 Awakening 🔗HTTP 402 sat dormant for years, a placeholder for a future nobody could quite figure out. Credit cards required human intervention.
Porting a CUDA Fast Fourier Transform (FFT) implementation to Mojo for the LeetGPU Fast Fourier Transform challenge presented an unexpected challenge: achieving bit-exact precision matching between CUDA’s sinf()/cosf() functions and their Mojo equivalents. This required PTX assembly analysis, cross-platform testing, and ultimately upgrading to Float64 precision for deterministic results.
Challenge Constraints 🔗 N range: $1 \leq N \leq 262,144$ (power-of-2 FFT sizes) Data type: All values are 32-bit floating point numbers Accuracy requirements: Absolute error $\leq 10^{-3}$, Relative error $\leq 10^{-3}$ Array format: Input and output arrays have length $2N$ (interleaved real/imaginary) Initial Problem: Accuracy Mismatch 🔗The initial Mojo FFT implementation failed correctness tests with a maximum absolute difference of 0.
Introduction 🔗This document analyzes AMD GPU support implementation in Triton’s Gluon framework, examining architecture-specific optimizations, performance characteristics, and implementation details relative to NVIDIA GPU support.
For background on Gluon and its motivation as a lower-level alternative to Triton, see my previous post: “Gluon: When Triton Isn’t Low-Level Enough”.
Background: GPU Programming Architecture Landscape 🔗The GPU programming ecosystem has evolved with distinct architectural approaches between NVIDIA and AMD, creating implementation challenges for cross-platform frameworks.
Introduction 🔗Byte Pair Encoding (BPE) tokenization is used in modern language models, but efficient training implementations are limited. OpenAI’s tiktoken handles inference well, while HuggingFace’s tokenizers supports training but has complexity and overhead. RustBPE is a Rust implementation that provides training capabilities with better performance.
RustBPE was developed by Andrej Karpathy as part of the nanochat project. This analysis covers the RustBPE implementation, including its architecture, performance characteristics, and Python integration.
Background 🔗I recently encountered the GPU MODE TriMul challenge while exploring GPU optimization. Coming from a systems engineering background without prior PyTorch or Triton experience, this challenge provided an opportunity to learn GPU performance engineering through a practical problem.
The Triangle Multiplicative Update (TriMul) is a core operation in AlphaFold2 and AlphaFold3—the protein structure prediction systems that earned the 2024 Nobel Prize in Chemistry. The operation’s O(n³) complexity creates severe performance bottlenecks in production, forcing AlphaFold3 to use batch size 1 during training despite having under 1B parameters.
GPU production constraints are creating infrastructure bottlenecks. Multi-GPU programming, particularly vendor-agnostic implementations, has become essential. In their GPU Mode presentation, AMD Research engineers Muhammad Awad, Muhammad Osama, and Brandon Potter introduced Iris—a Python library that enables fine-grained multi-GPU programming in Triton. Similarly to my previous Gluon blogpost, this post captures my understanding and interpretation of their work, serving as both technical documentation and personal reference for this emerging multi-GPU programming paradigm.
My Journey from PyTorch to Gluon 🔗After spending the last month diving into PyTorch, learning Triton, understanding CUDA, and even peeking at PTX/SASS assembly, I’ve come to a surprising realization: I’ve yet to meet anyone who’s actually writing raw CUDA code in production anymore. Everyone I’ve talked to – from ML engineers at startups to researchers at big tech companies – seems to have converged on Triton as their go-to solution for custom GPU kernels.
Another day, another zero-day. This time it’s CVE-2025-21043, a critical vulnerability in Android’s DNG image parser that’s been actively exploited in the wild. What makes this one particularly interesting is how it leverages an obscure feature of the DNG format—opcode lists—to achieve remote code execution.
Following our previous analysis of CVE-2025-43300 and the ELEGANTBOUNCER detection framework, let’s dive into how this vulnerability works and why it matters.
The Discovery 🔗On September 2025, Samsung just pushed a critical security update.
This tweet from Awni Hannun demonstrates in one line of MLX code the nondeterminism phenomenon detailed in Thinking Machines' research. We will explore the PyTorch equivalent that reveals a fundamental issue in AI systems, because I’ve found that tweet extremely helpful to understand what the original blogpost was about.
Here's a one-line code summary in MLX of the @thinkymachines blog post on non-determinism in LLM inference.
I'd guess the difference is larger the lower the precision, as you get larger affects from non-associativity of FP math.
The landscape of AI agents has been dominated by large language models (LLMs) like GPT-4 and Claude, but a new frontier is opening up: lightweight, open-source, locally-deployable agents that can run on consumer hardware. This post shares internal notes and discoveries from my journey building agents for small language models (SLMs) – models ranging from 270M to 32B parameters that run efficiently on CPUs or modest GPUs. These are lessons learned from hands-on experimentation, debugging, and optimizing inference pipelines.