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:      12 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

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.