ML Engineer · Distributed Training · LLM Systems · Computer Vision
I build things that work at scale -- and try to understand why they work at all.
I work in the space between clean research ideas and the messy reality of clusters that fail, data that drifts, and models that need to stay honest in production.
Day-to-day: cloud-scale ML infrastructure at a hyperscaler, distributed training systems, fault-tolerant checkpointing, LLM safety layers, and the occasional low-level kernel when something needs to be faster or more reliable. The majority of that work lives in private repositories. What you see here are the side projects I chose to open-source because they felt worth sharing.
Things I care about technically
- Large-scale pre-training infrastructure -- MoE routing, fault-tolerant checkpointing, tensor/pipeline parallelism
- LLM safety and observability -- keeping models (and the agents built on them) honest at inference time
- The hardware-software boundary: SIMD, CUDA, kernel-level optimization
- Novel architectures worth deploying, not just benchmarking
Things I care about less technically
- Code that impresses interviewers but breaks on week two
- Benchmarks that only win on synthetic data
- Documentation that describes the happy path and nothing else
Most of these exist because I needed to solve something concrete. I'd rather have a few things that are real than many that just look good on a profile.
| Project | What it is | Where it actually stands |
|---|---|---|
| Composed-MoE-Engine -- write-up → | Training runtime for large Mixture-of-Experts models at hyperscale. Fused Triton top-k router, composable 4D parallelism (DP+EP+TP+PP), strict forward-pass invariants, elastic fault tolerance, async two-tier checkpointing with automatic expert resharding, chaos testing. | Validated on real hardware, not just simulated: 80.1× (T4) and 58.7× (A100) kernel speedup, 348 tests, three hardware-only bugs found and documented. Multi-GPU (8×A100/8×H100) validation in progress.  |
| KANX -- write-up → | Kolmogorov-Arnold Networks library with PyTorch + TensorFlow backends, verified ONNX export, Docker + Kubernetes + Helm support, FastAPI serving. | pip install kanx · 5,000+ downloads  |
| guardrail-rs -- write-up → | Zero-Python LLM security layer written in Rust. Reverse-proxy that blocks prompt injection, redacts PII, and enforces policy with sub-millisecond overhead. Fails open by design, hot-reloadable config, Docker/K8s ready. | Active. Six real bugs found and written up honestly -- see the write-up. Complements GuardRail Studio. |
| FlashSpec -- write-up → | Adaptive speculative decoding engine with online bandit draft selection and Triton-optimised on-device verification. Preserves target distribution exactly. | pip install flashspec  |
| mcp-reliable | Runtime observability and reliability for the MCP ecosystem -- watches MCP servers while they're running: health checks, a traffic-observing proxy, schema/output drift detection, webhook + Slack alerting, and an agent-facing MCP interface so an agent can query its own tool reliability directly. CLI + REST API + dashboard, SQLite storage. | v1.0.0 · 195 tests, none mocked at the protocol level · architecture fully documented via ADRs. |
| ReliableAgent | Reliability-first orchestration framework for agentic systems. Plan → execute → critique → replan loop with guardrails at every boundary, full trajectory reconstruction, checkpoint/resume, quantitative reliability metrics. | v0.2.0 (June 19, 2026) · 140 tests |
| production-vlm-engineering | Reproducible pipelines for modern multimodal vision systems: efficient VLM adaptation, embedding-space drift detection, edge inference, robustness & safety. | Active. |
| RAG-Multimodal-Financial-Doc-Analysis-and-Recall | Multimodal RAG system for financial documents -- hybrid retrieval, VLM chart understanding, numeric grounding, full observability + CI-gated evaluation. | Active, finance-domain focused. |
| PromptCanary -- write-up → | Detects silent LLM drift.  |
v0.2.2 |
Not everything is a shipped tool -- some of it is just a question I wanted a real answer to.
- Does fine-tuning break a transformer's copy mechanism? Write-up →
| Project | Status | What was fixed / improved | Link |
|---|---|---|---|
| Triton | Merged | Fixed NaN handling in tl.argmin/tl.argmax (tie_break_left=False) in the interpreter so it matches JIT behavior |
PR #10699 |
| Megatron-LM | Merged | Fixed crash in get_grad_norm_fp32 when gradient list is empty (common with frozen layers / tensor parallelism) |
PR #5530 |
| TensorFlow | Approved by reviewers | tf.experimental.numpy.swapaxes now raises clear error on out-of-bounds axis instead of silent normalization or opaque XLA errors |
PR #122544 |
Not a comprehensive list. Just what I actually reach for.
Training & inference
PyTorch TensorFlow Triton ONNX TensorRT FSDP2 TorchElastic
LLM ecosystem
Transformers PEFT / LoRA vLLM LangChain FastAPI Triton Inference Server
Distributed & infra
NCCL Kubernetes Helm Terraform Airflow Ray
Observability
Prometheus Grafana OpenTelemetry Weights & Biases
Low-level
C++ AVX2 / SIMD CUDA pybind11
Data
PostgreSQL Qdrant MongoDB Spark Dask
Most of my interesting work happens in private repositories -- production systems at cloud scale where open-sourcing isn't an option. This GitHub is a public window, not the full picture.
That said: the repositories here are written to the same standard I use privately: tests, type checking, CI, real (if limited) benchmarks, and documentation that tries to admit what doesn't work yet. When something is experimental or incomplete, the README says so.
I'm especially interested in the kinds of failures that only appear at real cluster scale, the practical trade-offs in LLM safety systems, and whether architectures like KANs will eventually find meaningful production use cases.
My path into this wasn't linear -- it started in mechatronics, building things with real sensors, actuators, and control loops that fail in ways no unit test catches, and later working on ML systems within offshore energy's integrated control and safety systems, where a silent failure has real consequences. That's the actual root of the reliability obsession above, not something picked up from a style guide.
- Working on: the MoE engine's chaos scenario A -- sudden node failure under expert resharding, currently recovering ~85% of the time
- Reading: the Megatron-LM codebase and the FlexAttention paper
- Thinking about: whether MFU tracking gives you enough signal to catch silent training degradation early
|
|
Algorithms are how I warm up. Systems are where I live.
shorekeeper.mp4 |
 |
The idea that a machine could hold memory across time -- that the past could shape the present through nothing more than a weight matrix -- was the moment I understood why this field is worth a lifetime.
The equation is simple. What it implies is not.
Outside of work I'm usually reading something I don't fully understand yet, listening to music that has no business being that good, and occasionally wondering if the model actually converged or if I just got lucky. I like working with people who say "I don't know" without embarrassment and argue about architecture in good faith.
Open to interesting conversations about distributed training, LLM infrastructure, or any hard ML systems problem worth losing sleep over.