EXPLAIN ANALYZE SELECT focus FROM brij_raj_kishore;

══ Physical Plan ════════════════════════════════════════════════════════════
LLMInferenceAccelerate                           ▏ ◄ primary focus
├─ PyTorchOOTBackend  [dispatch · kernels · device mem · streams]
│    └─ OpInfo coverage → ran Llama & BERT end-to-end
├─ CUDAParityHarness  [self-built correctness framework]
├─ vLLMServing        [device plugin .to() / streams · in progress]
└─ FPGA / Xilinx      [hardware-level execution]

QueryEngineRoots      [Spark → Velox → Gluten]   ▏ foundation · 5× faster, native
   └─ same instincts:  kernels, native code, hardware, profiling

Proof:      18 PRs merged across 8 upstream repos
Optimizer:  "make it correct, then make it fly."   ⚡

Contributing to the LLM & data engines I accelerate — click any logo to see all my PRs there:

The fastest way to know how I write and review code: read the diffs. Real PRs — correctness bugs, performance, features — in the engines that power production Big Data and AI. Every ✅ Merged was approved by that project's own maintainers.

✅ Merged · 🔄 Open · ❌ Closed without merge

Volume is cheap. Here's the kind of problem I actually chase down — the bug that hides behind a green CI run — across both the query-engine and LLM/GPU sides:

Currently building the systems layer that makes LLM inference fast on custom hardware as Senior MTS @ Zettabolt — from the PyTorch dispatcher down to the FPGA:

• 🧩 PyTorch OOT device backend — operator dispatch, kernel registration, device memory management, and streams for a custom accelerator
• ✅ Full OpInfo operator coverage — ran Llama & BERT inference end-to-end on the custom device
• 🛡️ CUDA-parity testing framework I built — validates backend operators against the CUDA reference in CI
• 🚄 vLLM serving — extending the device plugin to vLLM (device .to(), streams, operator/kernel integration)
• 🎯 GPU / CUDA correctness & numerics across backends (see the device-guard and fp16 bugs above)
• ⚡ 100× PageRank speedup integrating NVIDIA CUDA (C++) with TigerGraph — GPU-acceleration instincts that transfer straight to inference
• 🔌 FPGA / Xilinx — pushing execution into hardware

The foundation that makes me good at it — 5+ years deep in production query engines: I drove a 5× Spark speedup (Neuroblade SPU, since acquired by AWS) — 2× over Apache Gluten — by offloading Scan/Filter/Aggregation to hardware via Velox; delivered another 5× on AMD EPYC integrating AMD AOCL with Gluten/Velox; and built ZettaProf, a Spark profiler that cut debug time 60%. LLM inference acceleration demands the exact same instincts — native code, kernels, hardware, relentless profiling. I'm bringing query-engine rigor to the transformer stack.

🎓 M.Tech CS, NIT Nagpur  ·  🌍 Noida, Delhi/NCR, India  ·  Upstream (forks I work in): pytorch/pytorch · vllm-project/vllm · apache/gluten · facebookincubator/velox · apache/spark

Everyone uses AI now. The interesting question is what you build with it. I engineer the harness: 79 files · ~7,000 lines of domain-specific skills, subagents, and enforcement hooks that make an agent trustworthy inside a million-line C++ codebase.

The problem it solves. An LLM loose in a huge C++ codebase does two things badly: it invents citations, and it has no idea which files are dangerous to touch. Both are fatal when the output is an upstream patch. So the harness is built around verification and blast radius, not autocomplete.

The two largest skills are the ones behind my day job: cuda-parity-review (782 lines) — diffs an out-of-tree backend against an in-tree reference to catch divergence — and opinfo (566 lines), which drives standardized operator test coverage on a custom accelerator.

Why this is on my résumé and not just a hobby: the same instincts — verify before you trust, know your blast radius, automate the loop — are what let me land 18 merged PRs in codebases I didn't write.

LLM / Inference   PyTorch (OOT device backend · dispatch · kernels · OpInfo · streams) · vLLM serving · CUDA-parity testing · NVIDIA CUDA · cuGraph Languages   C++ · C · Python · Scala · Java Bare Metal / Hardware   FPGA (Xilinx/AMD) · AMD EPYC/AOCL · GDB · Valgrind · uProf · CMake · Ninja Query Engines (foundation)   Apache Spark · Velox · Gluten · Hive · Hadoop · Kafka · Arrow/Parquet Cloud & Observability   AWS · Microsoft Fabric · Azure Data Factory · Docker · Linux · Flamegraph · Grafana · Netdata

Open to conversations on Big Data infrastructure, accelerated computing & LLM systems.