Systems Research Catalog

Research & Systems Dossiers

Six systems investigating bottlenecks from request admission down to memory-bandwidth saturation. Every dossier documents mechanism, hardware testbed, measured benchmarks, and explicit disconfirmed findings.

GCP L4 · RTX 4090 24GB · Apple M1 16GB

Clairvoyant: Predictive Request Scheduler for LLM Serving

Preprint: arXiv:2606.07248 · Stack Layer: Request Scheduling (L1)

Standard LLM serving proxies process incoming requests under First-Come-First-Served (FCFS), leading to head-of-line blocking when high-token generations stall short conversational queries. Clairvoyant is a backend-agnostic Go sidecar proxy that intercepts incoming HTTP/gRPC requests before GPU engines (Ollama, llama.cpp) with zero modification to upstream code. It evaluates a 19-feature XGBoost classifier exported to ONNX to infer generated token length in 0.029ms P99 (approximately 70,000× faster than generation time) and re-orders dispatch using Shortest-Job-First (SJF).

Hardware & Testbed Workload Scenario Metric Evaluated Observed Reduction Status
GCP L4 (24GB) Real trace replay (ShareGPT) P50 Queue Latency -83.6% Measured
Bare-metal RTX 4090 (24GB) Bursty synthetic arrivals P50 Queue Latency -70.0% to -76.0% Measured
Apple Silicon M1 (16GB) Edge LLM pipeline (llama.cpp) P50 Generation Latency -68.1% Measured
Offline Evaluation LMSYS-Chat-1M dataset Pairwise Ranking Accuracy 95.1% Measured
Critical Engineering Finding & Disconfirmed Result

Curated synthetic instruction datasets (Alpaca-style) are unusable for length-predictor training. Models trained on Alpaca exhibited severe prediction collapse because GPT-generated responses suffer from artificial brevity bias. The classifier learned to rank based on synthetic instruction patterns rather than natural token distribution. True predictive ranking required training on uncurated multi-turn human conversation logs (ShareGPT and LMSYS-Chat-1M).

Measured Live K8s Simulated Trace
Live GKE Cluster · Alibaba 32-Node Trace

Kube-Sentinel: Native Kubernetes GPU Scheduler Plugin (V2)

github.com/Aravind0403/Kube-Sentinel · Stack Layer: Cluster / GPU Scheduling (L2)

Kube-Sentinel is an enterprise-grade Kubernetes custom scheduler plugin that combines placement constraints, cost-aware scoring, and telemetry consistency checks. Implemented in Go directly against the Kubernetes Scheduling Framework (PreFilter, Filter, PreScore, Score, Reserve, PreBind, PostBind), it keeps protected latency-critical workloads off Spot capacity (cloud.google.com/gke-spot=true), filters strict per-pod cost ceilings (sentinel.cost/ceiling-usd), and couples with a Python sidecar for telemetry-confidence scoring with an automated circuit breaker providing neutral fallback scores.

Measurement Type Environment / Target Throughput / Latency / Coverage Provenance Rigor
Live Measured GKE Cluster (CPU Host Nodes) 1,252.6 pods/sec @ 0.98ms P99 Real cluster testbed, 210 passing tests
Live Measured GKE Cluster (NVIDIA L4 Nodes) 1,245.6 pods/sec @ 0.97ms P99 Direct scheduler-framework hook profiling
Live Measured Native Observation Matrix 39-Case Native Validation Valid, malformed, and unacceptable observation handling
Live Measured Daemon Termination Resilience 0 Failed Pod Bindings Real daemon failover, neutral fallback on active connection
Modeled Simulation Alibaba GPU Trace Replay (32 Nodes) 46.3% Cost Reduction ($64.44/hr vs $120/hr) Analytical simulation only; not measured on prod nodes
Core Distinction: Measured Latency vs. Modeled Savings

The 1,252.6 pods/sec scheduling rate and sub-millisecond P99 latency were empirically measured on live Kubernetes nodes. In contrast, the 46.3% GPU dollar savings is an offline simulation result derived from replaying Alibaba's 2018 cluster traces. I do not present this simulation as a verified production financial saving.

Measured Silicon (RTX 4090) Overload Trade-Off Disclosed
Physical NVIDIA RTX 4090 (24GB) · vLLM 0.7.2

Aether Control: Streaming Admission Gateway & Overload Control

github.com/Aravind0403/aether-control-llm-infra · Stack Layer: Serving Control Plane & Gateway (L3)

Aether Control is a streaming admission gateway managing concurrency, queueing, and overload ahead of an OpenAI-compatible inference backend (vLLM v0.7.2, Qwen2.5-1.5B). It provides streaming response forwarding, active-request concurrency caps, bounded queueing with deadline-based rejection, HTTP 429 backpressure, and client-disconnect cleanup. The gateway was evaluated across 48 paired runs (58,528 requests) on physical RTX 4090 silicon under Poisson arrival traces.

Serving Architecture Mode Light Load (10 RPS)
Attain% / E2E P99
Knee (35 RPS)
Attain% / E2E P99
Overload (48 RPS)
Attain% / E2E P99
Burst (10→48 RPS)
Attain% / E2E P99
Mode 1: Direct vLLM (Baseline) 100.0% / 1.08s 99.9% / 2.10s 96.1% / 2.57s* 100.0% / 1.74s
Mode 2: Forwarding Only (Proxy) 100.0% / 1.12s 100.0% / 1.98s 96.9% / 2.57s* 99.7% / 1.70s
Mode 3: Static Cap (36) 100.0% / 1.09s 83.4% / 1.53s 64.7% / 1.50s 79.8% / 1.34s
Mode 4: Bounded Queue + Deadline 100.0% / 1.13s 82.6% / 1.64s 52.9% / 1.65s 75.2% / 1.43s

*Values marked with an asterisk breach the 2.50s E2E SLO target (TTFT ≤ 250ms, E2E ≤ 2.50s, Qwen2.5-1.5B-Instruct, bfloat16, eager mode).

Documented Trade-Off: SLO Protection vs. Goodput Sacrifice

Under sustained 48 RPS overload, direct unconstrained vLLM breaches the 2.50s SLO (E2E P99 = 2.57s) while delivering 44.98 RPS target-compliant goodput. Mode 3 (Static Cap) strictly bounds admitted request latency to 1.50s P99 via HTTP 429 shedding, but sacrifices goodput from 44.98 to 30.27 RPS (a 32.7% goodput reduction, shedding 743.3 requests). Bounded Queue (Mode 4) smooths micro-bursts, reducing shedding by 55% at the capacity knee (+140 completions).

Step 4B Cross-Machine Compression Crossover
Physical Multi-GPU · Cloud Heterogeneous Nodes (Ampere → Ada)

HeteroDisagg: Hardware-Aware Disaggregated Serving

github.com/Aravind0403/HeteroDisagg · Stack Layer: Cross-Hardware Serving (L4)

Existing serving engines (vLLM, SGLang) assume homogeneous GPU clusters and symmetric tensor parallelism. HeteroDisagg disaggregates prefill and decode across disparate GPU microarchitectures through a 5-stage validation ladder on physical silicon. A dynamic Roofline Profiler measures real compute TFLOPS and memory bandwidth on each device, mapping high-TFLOPS GPUs to compute-bound prefill and high-bandwidth/$ GPUs to memory-bound decode. To bridge mismatched tensor-parallel degrees (e.g. prefill TP=4 to decode TP=1), HeteroKVConnector reshardens KV-cache blocks in flight with in-flight FP8 wire quantization and exact monotonic TCP framing.

Architecture Pipeline: Asymmetric Prefill → In-Flight FP8 Resharding → Commodity Decode
Prefill Node · Compute-Dense
NVIDIA RTX 3090 (Ampere SM 8.6)
Compute-Bound · High Peak TFLOPS
Generates KV Cache (FP16/BF16)
HeteroKVConnector Two-Phase Sync (ACKT → VALP) −50% Wire Bytes (FP8)
Exact Monotonic TCP Framing (recv_exact)
Decode Node · High Bandwidth
NVIDIA RTX 4090 (Ada SM 8.9)
Memory-Bound · 1,008 GB/s GDDR6X
100% Free-Running Token Match
Validation Stage Hardware Testbed Core Systems Focus Empirical Silicon Result
Step 0: Local Readiness Localhost (CPU) Protocol validity & fail-closed gates CPU end-to-end socket handoff; zero resource leakage
Step 1: Single GPU 1x NVIDIA RTX 4070 (Ada CC 8.9) Wire codec correctness on silicon Scaling, packing, and reconstruction verified on silicon
Step 2: Same-Host Handoff 2x NVIDIA RTX 4070 (cuda:0 → cuda:1) Physical multi-GPU process handoff Null-cache ablation proved consumption; FP16 err = 0.0, FP8 sim = 0.9994
Step 3: Controlled Study 2x NVIDIA RTX 4070 (Prompt Sweeps) Compression crossover (S ∈ [64, 1024]) 500 Mbps: FP8 wins at S=1024 (+25.73ms speedup, 1.104x)
Step 4B: Cloud Cross-Machine RTX 3090 (Ampere) → RTX 4090 (Ada) Cross-microarchitecture WAN execution 100% token match; 99.999% cosine sim; Δlogit ≤ 0.0439
Compression Crossover Frontier & Kernel Overhead

Isolated FP8 GPU quantization kernels add +11ms to +32ms compute overhead, making uncompressed FP16 strictly optimal over low-latency loopback links. However, over network-constrained links (500 Mbps) at sequence length S=1024, FP8 wire compression achieves an end-to-end handoff latency speedup of +25.73ms (247.73ms vs 273.46ms, 1.104x speedup). This establishes the exact empirical threshold where byte-reduction amortization overcomes kernel launch cost.

PyPI: trainsight-preflight v0.2.4 Measured Silicon (RTX 3090)
Physical NVIDIA RTX 3090 (24GB) · PyTorch · TRL

TrainSight: Training Input & Loss Contract Preflight Gate

github.com/Aravind0403/trainsight-preflight · Stack Layer: Training Data Contracts & Collator Guards (L5)

A training pipeline can compile valid PyTorch tensors that quietly violate your objective—for example, supervising prompt tokens or dropping the answer during sequence truncation. TrainSight adds explicit, tokenizer-aware preflight validation of SFT and multi-turn DPO contracts. It prevents four silent divergence modes before GPU execution: (1) Truncation Starvation (when prompt length exhausts the sequence budget, the answer is dropped and all labels become -100); (2) Empty Target Supervision (supervising only end-of-sequence delimiters <|im_end|>); (3) Collator Mask Leakage (collators failing to set labels == -100 over prompt or padding positions); and (4) Template Drift (mismatched chat tags altering delimiter token boundaries). Includes an in-memory batch reconciler that audits active loss positions directly on model-ready tensors.

Optimization Metric Random Batching (Baseline) Length-Grouped (TrainSight) Empirical Benefit
Padded Token Volume (1,000 GSM8K, B=4) Baseline (100% Padded Tokens) 74.24% ± 0.45% -25.76% ± 0.45% Fewer Padded Tokens
Useful-Input-Token Throughput Baseline (100% Throughput) 129.28% ± 0.65% +29.28% ± 0.65% Higher Throughput
Loss Mask Causal Integrity Subject to Collator Leakage 100% Verified Causal Mask Zero Misaligned Loss Positions (Labels != -100)
Preflight Inspection Execution N/A < 1.2s per 1,000 samples Sub-millisecond CPU overhead, zero GPU time
Empirical Boundary: Input Contracts vs. General Intelligence

TrainSight verifies that training inputs adhere to the mathematical loss objective. It guarantees that prompt tokens and padding do not leak into cross-entropy loss, and that sequence lengths fit within VRAM constraints. However, verifying input contracts does not guarantee factual accuracy, eliminate hallucinations, or prevent out-of-memory errors caused by optimizer states.

F1=1.0000 Accuracy Draft Manuscript
Branch: product_semiversion

ServiceScope: Pre-Deployment Blast-Radius Prediction

github.com/Aravind0403/ServiceScope-v2 · Status: Draft paper exists (Not submitted / Not accepted)

A static pre-deployment blast-radius analyzer for distributed microservices. Combines Tree-sitter polyglot AST parsing across 5 programming languages with a deterministic cross-layer manifest linker (Kubernetes manifests, Helm templates, Docker Compose). Confirmed F1=1.000 accuracy on Google's microservices-demo and OpenTelemetry's opentelemetry-demo, executing in a sub-500ms CI stage with <50ms manifest resolution.

Note on Git branch: Use the product_semiversion branch for active code; the main branch is legacy.