chinmay18.com

AI Software Engineer · Reliance Jio · Frisco, Texas

Chinmay
Shrivastava

I build high-performance backend and ML infrastructure, and I validate it against references instead of trusting it.

At Reliance Jio I lead backend architecture for a production 4G/5G analytics platform on an air-gapped Kubernetes/OpenShift cluster, where a typed-intent compiler cut P50 latency from 20 s to 1 s. Outside work: two changes merged into PyTorch core, two into Meta's bpfilter, open pull requests in vLLM and Stripe's agent toolkit, and systems projects with committed benchmarks.

GitHub LinkedIn Hugging Face Resume · PDF

Evidence ledger

Numbers that come with their sources

Each entry names what was measured, on what, and where the result lives. Caveats stay attached to the number.

upstream
4
Changes merged into PyTorch core and Meta's bpfilter
pytorch/pytorch #158985, #173183 · facebook/bpfilter #364, #369
measured
48ms
P95 steady-state sync drift between three browsers, Mustard Watch Party
3 Chrome clients · ~300 ms simulated RTT · 240 s · player-reported, single committed run · docs/measurements
measured
1.04–1.76×
Fused RMSNorm→FP8 kernel vs the torch.compile composite
A100 · FP16 · kernel time · six shapes · 4.9–7.2× vs eager · benchmarks/results/2026-08-25…
measured
2.7–6.7×
Training-step speedup after autotuning vs PyTorch-default FP32 eager
ResNet-50 2.71× · ResNet-18 3.84× · 6-layer Transformer 6.65× (2.55× vs TF32 eager) · A100 · benchmarks/results/2026-08-25…
production
20 s → 1 s
P50 latency after a typed-intent compiler took 59% of analytics queries off the LLM path
Reliance Jio 4G/5G analytics platform · wrong answers 17% → 4% · employer figures, 2025–26
adoption
6,982
All-time downloads of the medical-prescription OCR model on Hugging Face
chinmays18/medical-prescription-ocr · 652 in the last 30 days · 8,060 all-time dataset downloads · huggingface.co · fetched 2026-10-07

Single-author benchmarks, one machine per quoted number; none has been independently reproduced. The old figures that used to live here (97% KV-cache reduction, 4.06× speedup, 858 FPS) had no committed source and were retired.

Selected work

Three systems, each with a measured claim and its limits

The diagrams below are the same ones used in my GitHub profile README; the numbers they show are committed in each repository.

Distributed systems · live at mustard.watch

Mustard Watch Party

Video synchronization for watch parties, with a model-checked control protocol.

Clients connect over WebSockets, estimate a clock offset from the socket acknowledgment (NTP-style) and correct drift with predictive rate control; room state lives in Redis behind atomic Lua scripts. The 48 ms P95 is steady-state, player-reported drift across three Chrome clients at roughly 300 ms simulated RTT over a 240-second run. A separate audio-output measurement showed the player API understates true skew by about 45 ms at P95, so the number is quoted as player-reported, never as physical sync.

TLA+/TLC model checking exposed a stale-epoch bug after store resets, which led to ordered epochs; idempotency keys plus atomic updates give at-most-once application of control commands under duplication and reordering. The multi-instance path is exercised in a three-instance lab and nightly CI; production currently runs one backend instance. The Go and Rust relays are conformance studies rather than the production backend. At 10,000 local connections the Rust relay used 14.5 KB per connection against 40 KB for Go; the tail-latency comparison was inconclusive.

48 msP95 drift · scenario S2 (~300 ms RTT) · 3 clients · 240 s
14.5 vs 40 KBmemory per connection, Rust vs Go · 10k conns
TLA+at-most-once control application, model-checked
Live site Source Sync design TLA+ findings Go/Rust study
Diagram: three Chrome clients estimate a clock offset over the socket acknowledgement and correct drift with predictive rate control; room state lives in Redis behind atomic Lua scripts. Chart of steady-state P95 drift across the five scenarios of the servo impairment matrix (S0, S2, S3, S5, S6): 49, 48, 79, 29 and 86 ms, two later runs (S8, S9) being committed but not charted; relay memory 14.5 KB for Rust versus 40 KB for Go per connection. Diagram: three Chrome clients estimate a clock offset over the socket acknowledgement and correct drift with predictive rate control; room state lives in Redis behind atomic Lua scripts. Chart of steady-state P95 drift across the five scenarios of the servo impairment matrix (S0, S2, S3, S5, S6): 49, 48, 79, 29 and 86 ms, two later runs (S8, S9) being committed but not charted; relay memory 14.5 KB for Rust versus 40 KB for Go per connection.

GPU kernels · PyTorch custom ops

Fused LayerNorm / RMSNorm CUDA operators

Residual-add fusion, FP8 outputs and a deterministic backward, with no graph breaks under torch.compile.

The eager composite runs residual-add, normalization and an FP8 cast as three kernels with HBM round-trips; the fused version does all three in one. Parameter gradients use fixed-order reductions instead of atomic accumulation, which is where the determinism comes from. The modules register through torch.library.custom_op, so compiled graphs stay whole.

For dynamic RMSNorm→FP8 in FP16 on an A100 I measured 4.9–7.2× over the eager composite and 1.04–1.76× over the compiled composite across six shapes. Those are kernel-time comparisons, not end-to-end model speedups, and the compiled-composite win does not transfer to the H100, where the repository documents 0.70–1.20× and makes no claim. The non-FP8 fused-add ops sit at parity with compiled PyTorch.

4.9–7.2×vs eager PyTorch · A100 · FP16 · kernel time
1.04–1.76×vs torch.compile composite · A100 only
289tests · CI compiles sm80/sm90
Source A100 results Methodology
Diagram: the eager composite runs residual-add, normalization and an FP8 cast as three kernels with HBM round-trips; the fused version does all three in one kernel. Chart: dynamic RMSNorm to FP8 kernel time is 4.9 to 7.2 times faster than the eager composite and 1.04 to 1.76 times faster than the compiled composite across six shapes on an A100 in FP16. Diagram: the eager composite runs residual-add, normalization and an FP8 cast as three kernels with HBM round-trips; the fused version does all three in one kernel. Chart: dynamic RMSNorm to FP8 kernel time is 4.9 to 7.2 times faster than the eager composite and 1.04 to 1.76 times faster than the compiled composite across six shapes on an A100 in FP16.

Performance tooling · on PyPI as pytorch-autotune 2.0

PyTorch AutoTune

Times candidate training configurations on the target model and keeps the fastest.

The tuner benchmarks precision, compile mode, memory format and fused-optimizer combinations on the target model and batch, under a time budget. A winner has to beat the incumbent by more than 3%, the search never returns a configuration slower than the baseline, and the report records every trial together with compilation cost and the number of training steps to break even.

Against PyTorch-default FP32 eager on an A100 the tuned stack reached 2.71× on ResNet-50, 3.84× on ResNet-18 and 6.65× on a 6-layer Transformer; against plain torch.compile it was 2.0–6.1×. With TF32 matmuls enabled in the baseline, the Transformer gain falls to 2.55×. Rebuilding the winners in a fresh training loop reproduced the committed numbers within 1.5%. Earlier versions advertised a 4.06× T4 result and an energy figure; both were retracted in the changelog because nothing committed supported them.

2.7–6.7×vs PyTorch-default FP32 eager · A100
2.0–6.1×vs plain torch.compile
≤1.5%drift when re-measured from scratch
PyPI Source Benchmark artifacts
Diagram: the baseline is measured first, candidate configurations across precision, compile mode, memory format and fused optimizer run real training steps under a budget, the winner must beat the incumbent by more than 3 percent, and the report records every trial. Chart: 2.71 times on ResNet-50, 3.84 times on ResNet-18 and 6.65 times on a six-layer Transformer versus the PyTorch-default FP32 eager baseline; the Transformer gain is 2.55 times against an eager baseline with TF32 matmuls enabled. Diagram: the baseline is measured first, candidate configurations across precision, compile mode, memory format and fused optimizer run real training steps under a budget, the winner must beat the incumbent by more than 3 percent, and the report records every trial. Chart: 2.71 times on ResNet-50, 3.84 times on ResNet-18 and 6.65 times on a six-layer Transformer versus the PyTorch-default FP32 eager baseline; the Transformer gain is 2.55 times against an eager baseline with TF32 matmuls enabled.

Upstream record

Pull requests to projects I do not own

Status as of 2026-10-07. PyTorch lands changes through its merge bot, so the two PyTorch core entries link to the landing commits as well. Not listed: four other PyTorch proposals and five Metaflow proposals that were closed without landing, one Stripe fix superseded by the maintainers' own, and a torchtune documentation PR (#2889) open since July 2025 with no maintainer response since that August.

Upstream pull requests, status as of 2026-10-07
ProjectChangeRefStatusWhen
PyTorch core Enable the existing dynamic-shape support for foreach operations by default under torch.compile, with a test update. Landing commit. #158985 merged Jul 2025
PyTorch core Expose rearrange through the torch.func public API, with tests and documentation. Landing commit. #173183 merged May 2026
Meta bpfilter IPv4 Type-of-Service matcher: command-line parsing, BPF code generation and unit tests. #364 merged Jan 2026
Meta bpfilter IPv6 Traffic Class matcher with endianness-safe byte loads, plus tests. #369 merged Jan 2026
PyTorch Ignite Seven type-hint modernizations across the metrics module (Union[...] to X | Y) from a good-first-issue sweep; counted here as one contribution. #3484–#3490 merged Jan 2026
vLLM ERNIE 4.5 tool and reasoning parsers for the Rust frontend: a chunk-invariant state machine for the <response> wrapper, tested at every byte split. #52841 open · awaiting review Aug 2026
vLLM LoRA support for the audio tower and connector in GLM-ASR, including the token-count hooks the LoRA manager needs at engine init. #53149 in review Aug 2026
Stripe agent toolkit Python package: cap mcp below 2.0 (2.0 removed the client the package imports) and point the openai extra at the right dependency. #540 open Sep 2026
Stripe agent toolkit Make the Strands integration work with the strands-agents package; adds an async tool port and tests. #541 open Sep 2026
Stripe agent toolkit MCP stdio proxy replies with a JSON-RPC error when forwarding fails instead of letting the client hang for 60 seconds. #542 open Sep 2026

Also published: ChatGPT Spark on the Chrome Web Store. The full list of shipped tools is on the projects page.

Experience

Where the work happened

Nov 2025 → present
Frisco, Texas

AI Software Engineer

Reliance Jio Infocomm USA

  • Lead backend architecture for a production 4G/5G analytics platform; designed the typed-intent compiler that answers 59% of queries without an LLM (P50 latency 20 s → 1 s, wrong answers 17% → 4%; employer figures).
  • Deployed the backend and AI platform across a 13-node, air-gapped, IPv6-only Kubernetes/OpenShift cluster with AMD GPUs, integrating ClickHouse, Airflow, FastAPI and self-hosted vLLM for analytics and inference.
  • Built a root-cause engine over 240 telemetry fields and 80 RF diagnostic rules. Deterministic rule evaluation runs first and bounded multi-agent reasoning second; each answer carries a confidence score, and the engine abstains when evidence is thin.
Sep 2024 → Oct 2025
Boston, Massachusetts

Software Developer

Venture Development Center, UMass Boston

  • Ran a cloud-hosted multi-tenant platform with monitoring, alerting and incident-response tooling (99.9% uptime; employer figure).
  • Built a real-time telemetry dashboard with React and server-sent events (about 60% faster after profiling) and integrated a retrieval-augmented pipeline (85% answer accuracy on the internal evaluation set at 15% lower per-query cost; employer figures).
Jan 2022 → Jul 2023
India

Software Engineer Intern

Landmark Ventures

  • Built a React/Redux property-analysis dashboard with Chart.js that the whole team adopted; deal evaluation became about 3× faster (team-reported).
  • Cut weekly reporting from 8 hours to 1 by automating a pandas pipeline, and trained the team on Git workflows.
2023 → 2025
2019 → 2023

Education and credentials

MS in Computer Science, University of Massachusetts Boston · B.Tech in Computer Science, Lakshmi Narain College of Technology

Certified Kubernetes Application Developer (CKAD) AWS Certified Developer – Associate

Toolbox

What I reach for

Languages

  • C++
  • C
  • Python
  • CUDA
  • Rust
  • Go
  • TypeScript
  • SQL
  • Java

Backend & data

  • FastAPI
  • NestJS
  • WebSockets/SSE
  • ClickHouse
  • PostgreSQL/PostGIS
  • Redis
  • Airflow
  • REST APIs

Infrastructure

  • Linux
  • Docker
  • Kubernetes/OpenShift
  • AWS
  • CI/CD
  • Cloudflare · Vercel · Render

ML & performance

  • PyTorch
  • torch.compile
  • vLLM
  • ROCm
  • Hugging Face
  • NVIDIA Nsight
  • kernel fusion
  • benchmark design

Correctness

  • TLA+/TLC
  • reference-based tests
  • regression gates
  • protocol-conformance checks

Contact

Hiring for ML infrastructure or backend?

Open to ML infrastructure and backend roles in the Bay Area. Based in Frisco, Texas, and relocating.

Email me Resume · PDF
email
cshrivastava2000@gmail.com
github
github.com/JonSnow1807
linkedin
linkedin.com/in/cshrivastava
hugging face
huggingface.co/chinmays18
phone
857-339-9199