Kernel Engineer (ML Accelerators)

About the role

You'll diagnose and resolve performance problems across Decart's ML systems, spanning research, training, and production inference. The largest share of the work is writing and optimizing kernels for TPU and Trainium. You'll also advise researchers on the performance cost of proposed model changes.

We're looking for engineers with a demonstrated record in large-scale systems engineering and low-level optimization.

Minimum requirements Bachelor's degree in Electrical/Computer Engineering, Computer Science, or a related field, plus 2+ years of relevant experience (or equivalent practical experience) 2+ years developing low-level software in C/C++ (Python proficiency a plus) Solid grounding in operating systems fundamentals (process/thread scheduling, synchronization, virtual memory), CPU/GPU architecture, and hardware/software co-design Working knowledge of PyTorch and machine learning algorithms, with a focus on engineering application Demonstrated ability to profile compute and memory behavior, diagnose bottlenecks, and validate improvements with rigorous measurement What we're looking for Production experience squeezing performance out of ML workloads on TPU, Trainium, GPU, or other accelerators You've authored kernels for an ML accelerator — not just consumed them Depth in computer architecture: you can reason about systolic arrays, memory hierarchies, and interconnect topologies from first principles Familiarity with compiler and toolchain internals (e.g., XLA, MLIR, Triton, or vendor stacks) Experience scaling training or inference workloads across multi-accelerator clusters You've read — or patched — the internals of an ML framework Projects you might work on Cut milliseconds off end-to-end token latency in DOS by restructuring attention and sampling paths for a new accelerator generation Design communication schedules that overlap compute with network transfer across multi-chip topologies Build analytical performance models to predict where the next 2x is hiding before writing a line of kernel code Trace a throughput regression from a framework-level symptom down to instruction scheduling in generated assembly — and fix it Port DOS's kernel suite to new hardware and close the gap to theoretical peak