ML engineer resume skills: CUDA or Trainium?

What just changed in the ML hardware stack?

On 19 October 2026, AWS announced TorchNeuron, an open-source native PyTorch backend for its Trainium chips, with the public beta opening the following day. The pitch is blunt: point existing PyTorch code at Trainium with a single configuration change — calling .to('neuron') or setting device_map='neuron' — and skip the rewrite. Announced at the PyTorch Conference in San Jose and built by Annapurna Labs under an Apache 2.0 licence, it registers Trainium through PyTorch's PrivateUse1 extension point and lowers graphs through Torch-MLIR and StableHLO, dropping the older XLA layer. Amazon reckons roughly 85% of AI applications are written in PyTorch, while Nvidia still holds north of 80% of the data-centre accelerator market. That's the gap TorchNeuron aims at.

For anyone writing an ML engineer resume, the interesting part isn't the chip war — it's what the shift does to the value of your hardware experience. Annapurna pointed to more than 30 early customers, among them voice AI company Deepgram, which reported processing 70% more audio per dollar at production-grade accuracy. Amazon is also contributing code upstream to strip chip-specific ties out of PyTorch itself. None of this is unprecedented: PyTorch users could already move workloads to AMD GPUs or Apple silicon with a config switch, and a public beta is exactly where optimistic portability claims meet awkward real workloads. The direction of travel, though, is clear enough to plan a CV around.

Here's the bridge to your document. When one vendor effectively owned the toolchain, writing CUDA was enough to signal you'd done serious accelerator work. Now job ads name their silicon, and the keyword sets they screen on are splitting into at least four camps: NVIDIA, AWS Neuron, AMD ROCm, and Google TPU with JAX. A resume tuned for one camp reads thin to the others, and an automated first screen does not infer that CUDA skill transfers to Trainium. The rest of this piece covers which stack to name for which employer, how to phrase portability so a hiring manager believes it, and the exact keyword clusters worth putting in your skills block.

Which accelerator skills should you name per employer?

Name the stack the employer actually runs, using their exact spelling. Frontier labs and GPU clouds screen for CUDA, Triton, CUTLASS, NCCL and Nsight. AWS-native teams now screen for TorchNeuron, Neuron SDK, NKI, torch-neuronx and Inferentia. AMD shops want ROCm, HIP, RCCL and MIOpen; Google-side work wants JAX, XLA, Pallas and HLO. Framework and compiler teams look for torch.compile, TorchDynamo, Torch-MLIR and StableHLO. These aren't interchangeable synonyms to a keyword filter — they're separate strings. If a posting says Trainium and your CV says "custom accelerators", you've written something a human might appreciate and a parser will score as a miss.

The practical method takes about twenty minutes. Pull five to ten postings you'd genuinely accept, paste them into one document, and highlight every literal hardware, framework and library name. You'll see the clusters immediately, and you'll notice how many 2026 postings now hedge across vendors: ads that once said CUDA only are listing AMD, AWS Trainium, Google TPU and Qualcomm in the same breath, and inference roles routinely ask for vLLM, SGLang or TensorRT-LLM alongside the kernel work. Those shared terms — quantisation in INT8, FP8 and FP4, paged attention, KV cache management, speculative decoding — are the safest keywords you can carry across every camp.

Now the unpopular part: don't list all four camps. A skills block naming CUDA, ROCm, Neuron, TPU, Pallas, HIP and CUTLASS reads as keyword stuffing to a recruiter and collapses in the first technical screen, because nobody has shipped production work on four toolchains. Two camps you can defend beat four you can't. Pick your deepest stack, add the one your target employer runs, and relegate anything you've only touched in a side project to a clearly labelled line — "evaluated" or "ported a model to" is honest and still matches the string. Specificity is what survives verification; breadth is what gets caught.

How do you put CUDA on a resume so it reads as portable?

Write CUDA as evidence of hardware reasoning, not as vendor loyalty. The portable skills underneath it — memory hierarchy, tiling, operator fusion, occupancy, roofline analysis, collective communication, numerical stability across dtypes — are exactly what a Trainium, ROCm or TPU team is buying, so say them out loud in the same bullet as the tool. "Wrote fused attention kernels in CUDA; cut p99 decode latency 38% by eliminating three HBM round-trips" travels to any accelerator. "Expert in CUDA" travels nowhere. The second version tells a hiring manager you understand why the speedup happened, which is the only reliable predictor that you'll reproduce it on unfamiliar silicon.

Then add one concrete portability artefact. A single line about moving a model between backends does more for an AI infrastructure engineer CV than another framework name: a Triton kernel you ran on both CUDA and ROCm, a training job you moved from GPU to Trainium and re-profiled, a torch.compile graph you debugged by reading the lowered IR, a custom operator you reimplemented with NKI or Pallas. Open-source commits count double here — merged work in vLLM, SGLang, FlashAttention, Triton or PyTorch itself is independently verifiable, which is rare on a resume and recruiters know it. One link-free mention of the project and the merged scope is enough.

Avoid the two failure modes. The first is translating everything into vendor-neutral prose — "accelerator programming", "ML systems optimisation" — which reads beautifully and matches nothing. The second is leaving the CV frozen in 2023 CUDA terms when your target company builds its own silicon; if you're applying to chip companies, mirroring their compiler and runtime vocabulary matters as much as the kernel work, and the CV blueprint for AI chip startup roles breaks down how to frame GPU experience for an employer that isn't NVIDIA. Keep the specific tool name, keep the number, and make the transferable mechanism explicit in the same sentence.

Which PyTorch resume keywords do ATS filters match?

Filters match literal strings, so your skills section has to carry the exact tokens from the posting: PyTorch, torch.compile, FSDP, DTensor, TorchDynamo, vLLM, Triton, CUDA, Neuron, ROCm, JAX. Matching is not semantic — "deep learning frameworks" will not satisfy a search for PyTorch, and "AWS AI chips" will not satisfy one for Trainium. The safe pattern for ambiguous abbreviations is the spelled-out form followed by the short one, once per document: "Neuron Kernel Interface (NKI)", "Fully Sharded Data Parallel (FSDP2)". Universally written-short terms like CUDA, API, SQL or GPU need no expansion; spelling those out looks odd to the engineer reading after the filter.

Group the terms the way practitioners group them, because recruiters skim the block before they read a bullet. Four or five labelled lines work well: Frameworks, Accelerators and kernels, Serving and inference, Distributed training, and Tooling. Under serving, name what you've actually run — vLLM, SGLang, TensorRT-LLM, Triton Inference Server — and keep the distinction clear between Triton the kernel language and Triton the server, since conflating them is a tell that you've read about the stack rather than used it. Put dollar-or-millisecond numbers next to at least two of these lines when the achievement lives in experience bullets.

Keyword coverage is also the easiest thing to check mechanically. Paste the job description into a job-targeted analysis and you get back the skills the posting demands that your CV never mentions, which is far more useful than a generic score; for LinkedIn and Indeed ads, copy the text rather than the URL, since those sites block automated fetching. A free CV check also returns an ATS-compatibility rating and a category score for tech stack, so you can see whether your accelerator lines are being parsed at all before you spend an evening rewriting bullets nobody's filter ever read.

How should an AI infrastructure engineer CV be structured?

Single column, standard headings, text-extractable PDF — in that order of importance. Parsers harvest by looking for labels they recognise, so use Skills, Experience, Education and Projects rather than clever alternatives, and keep your stack in plain comma-separated text instead of a graphic, icon row or skills-rating bar. Two-column layouts are the quiet killer: a scanner reading left to right across the page interleaves your skills column with your job history and produces nonsense. If you've been handed a beautiful template with a sidebar, the sidebar is usually where your accelerator keywords go to die.

Order the content for a thirty-second scan by someone who has forty CVs to get through. A three-line summary naming your deepest stack and your strongest measured result; then the skills block; then experience in reverse-chronological order with one number in roughly every second bullet; then open-source work; then education. Two pages is fine for a senior ML or infra engineer, and a dense one-pager that hides the stack is worse than a clean second page. Guidance on structuring the stack section so a parser reads it is worth ten minutes before you apply anywhere competitive.

Then tailor per application rather than per vendor era. Keep one master document with everything you've ever shipped, and cut it down to the single posting in front of you — swapping the accelerator line, reordering the serving tools, and promoting whichever project matches their workload. Building the CV from your existing one in a layout that exports cleanly to PDF and Word removes the formatting risk entirely, which matters more in this niche than most: the people hiring for Trainium, ROCm and TPU work are filling brand-new teams fast, and the first filter is rarely a human.

Frequently asked questions