QuantaSHI - Intelligent Energy Triage

Smarter workload decisions. Lower energy. Greener tomorrow. Quantum-inspired scheduler that cuts energy & carbon for AI inference on IBM Z/LinuxONE.

Comment
  • QuantaSHI*

Cover Page Project Title: QuantaSHI - Intelligent Energy Triage for Computing Subtitle: Smarter workload decisions. Lower energy. Greener tomorrow. Team: [Your Team Name] Event: Hactoberfest X BFIT / IBM Z - LinuxONE Track Date: October 2026 1. Abstract (150 words) QuantaSHI is an energy-aware scheduler for AI inference workloads. It decides whether to RUN, DEFER, or assign a request to an energy-efficient server based on carbon intensity, urgency, and deadlines. We simulate 6 heterogeneous servers and 100 virtual users with Poisson arrivals including burst. Power is estimated using linear model P = P_idle + (P_max-P_idle)*U, distinguishing estimated (simulated) from measured (wall meter per MLPerf Power). Compared to round-robin baseline on same 4250 requests (10 min), QuantaSHI reduces missed deadlines from 0.8% to 0.0% with 0.4% energy saving, and up to 1.7% saving under burst. The architecture includes Data Ingestion, Feature Engineering, Context Analyzer, Multi-Objective Decision Engine, Optimization Layer (quantum-inspired QUBO/QAOA via Qiskit), Explainability Module, Dashboard, and Feedback Loop. It runs pure Python, compatible with IBM Z/LinuxONE, no GPU required.

2. Problem Statement Data centres consume high energy. AI inference requests come randomly and many are not urgent. Current schedulers like round-robin do not check carbon intensity or deadlines, leading to wasted energy and missed SLOs.

3. Objectives

  • Simulate 5-6 servers in Python (IBM Z compatible)
  • Model queues, processing time, utilization, deadlines
  • Estimate energy using idle/max power
  • Compare baseline vs QuantaSHI fairly
  • Explain why a decision was taken
  • Keep scope for quantum-inspired optimization

4. Literature Survey - Existing Solutions Map Solution Target Method Results Limitation Fan et al. 2007 (Google) Power provisioning CPU utilization → power linear model 5K machines, 145W measured vs 213W nameplate No carbon, no SLO MLPerf Inference Power v1.0 Benchmark SPEC PTDaemon wall meter 1994 perf + 862 power results, <1% error Needs certified meter Sprout Carbon-efficient LLM Generation directives L0/L1/L2 + LP optimizer 60% carbon saving, 90%+ quality retained Needs GPT-4 evaluator, multi-model EcoServe Carbon-aware serving Reuse, Rightsize, Reduce, Recycle + ILP 40-66% carbon saving, 3.51x embodied saving Needs 56-core CPU + A100 HeatCache 2026 Thermal-aware Heat buffer as AIO loops 18% energy saved, 81% less throttle Needs liquid cooling MiP-EAS DPU scheduling Mixed-precision + DVFS + RL 23% power saved, 1.4x throughput Needs DPU hardware 5. Methodology & Architecture

Diagram Modules:

  • Data Ingestion: Azure VM traces, carbon intensity (WattTime), workload logs
  • Feature Engineering: Extract U, queue length, arrival rate, tokens, priority, deadline, carbon
  • Context Analyzer: Detects burst, carbon diurnal pattern (low midday 100g, high evening 350g)
  • Multi-Objective Decision Engine: Score = α_Energy + β_Carbon + γ_Deadline Penalty
  • Optimization Layer: Classical rule-based + Quantum-inspired QUBO/QAOA (Qiskit simulator, 6 qubits for 6 servers, superposition evaluates many assignments)
  • Explainability Module: Logs "Request X assigned to Server Y because energy 0.001kWh vs 0.0018kWh, carbon 85g, latency 45ms < SLO"
  • Action Layer: RUN / DEFER / THROTTLE / RESIZE
  • Monitoring Dashboard: Energy, Load, Task Status, Carbon
  • Feedback Loop: Adjust weights α,β,γ from past results

6. Realistic Workload and Server Behavior

Workload: 100 virtual users, Poisson arrival λ=5/sec normal, λ=25/sec burst (300-360s), total 4250 req in 10 min. Sizes: small 50% (20-50 tokens, 0.02s), medium 35% (100-200, 0.05s), large 15% (400-800, 0.12s). Priority high 30% SLO 0.3s, low 70% SLO 1.5s. Based on Azure Functions trace + ShareGPT.

Servers: 6 heterogeneous - 2 normal (120W/300W), 2 fast (150W/400W, 1.2x speed), 2 eco (100W/250W, 0.8x speed). Queue per server FIFO, capacity unlimited but latency tracked. Utilization = busy_time/sim_time.

Energy Assumptions: P_i(t)=P_idle+(P_max-P_idle)_U, U=0.6 when busy. E_total=ΣP*Δt + idle. E_per_req=E_total/N. This is ESTIMATED, not measured at wall.

7. Implementation Tool: Python, SimPy concept (pure Python, s390x compatible), FastAPI, Pandas, Matplotlib. Runs on IBM Z/LinuxONE Docker. Quantum Part: QUBO mapping x_ij=1 if request i to server j, minimize Σ Cost_ij x_ij. Solved via QAOA using qiskit_aer simulator (6 qubits). Called quantum-inspired because we use classical solver mimicking quantum.

8. Results - Baseline vs QuantaSHI

Same workload, same servers:

  • Baseline Round-Robin: Total 0.1338 kWh, Energy/1000 req 0.0315 Wh, Avg Lat 0.083s, p95 0.267s, Miss 0.8%, Util 9.4%
  • QuantaSHI: Total 0.1333 kWh, Energy/1000 req 0.0314 Wh, Avg Lat 0.166s, p95 0.44s, Miss 0.0%, Util 9.5%
  • Saving: 0.4% energy, 100% reduction in missed deadlines
  • Under heavy burst (20→160 req/s): Baseline miss 84.5%, QuantaSHI miss 55.3%, 1.7% energy saving
  • With server sleep (10W sleep vs 100W idle): Projected 20-25% saving like HeatCache.

9. Differentiation Based on Evidence We do NOT claim invention of carbon-aware scheduling (Sprout/EcoServe already 40-60%). Our evidence-based difference:

  1. No GPU needed - pure Python, IBM Z/LinuxONE compatible, while others need A100/SPR/liquid cooling.
  2. Explainability - logs why RUN/DEFER per request, others only report %.
  3. Balances energy + SLO together, tested under burst.
  4. Honest distinction: simulated estimate vs wall measured per MLPerf.

10. Conclusion QuantaSHI shows small energy saving with better reliability using simple rule-based quantum-inspired scoring. Future work: add sleep mode, integrate real carbon API, test QAOA on real IBM Quantum hardware.

11. References

  1. Fan, Weber, Barroso - Power Provisioning for Warehouse-sized Computer, ISCA 07
  2. MLPerf Inference Power v1.0 - MLCommons + SPEC PTDaemon
  3. Sprout - Green Generative AI with Carbon-Efficient LLM Inference
  4. EcoServe - Designing Carbon-Aware AI Inference Systems
  5. HeatCache - Thermal-aware Energy-efficient LLM Inference, arXiv:2609.12449

Appendix Code: quantashi_simple.py, http://simulation.py, dashboard FastAPI

Built With

  • 20-25%-projected-like-heatcache/ecoserve.-differentiation:-no-gpu-needed
  • 6-qubits)-results-on-4250-requests/10min:-baseline-rr-miss-0.8%
  • balances-energy+sla
  • clearly-labeled-as-simulated-estimate-vs-mlperf-wall-measurement-smart-policy:-checks-carbon-intensity-(diurnal-100-350g-co2)
  • deadline-?-run-on-eco-server-or-defer-low-priority-explainability:-logs-why-it-chose-run/defer-quantum-inspired:-maps-assignment-to-qubo
  • ecoserve-47%)-into-simple-prototype.-tech:-simpy-concept
  • explainable
  • fastapi
  • many-are-not-urgent.-current-round-robin-schedulers-waste-energy-and-miss-deadlines.-solution:-simulates-6-heterogeneous-servers-(ibm-z/linuxone-compatible
  • miss-drops-84%?55%-+-1.7%-saving.-with-sleep-mode
  • pandas
  • poisson-arrival-with-burst-(azure-trace-inspired)-energy-model:-p-=-p-idle-+-(p-max-p-idle)*u-(fan-et-al.-google)
  • pure-python)-realistic-workload:-100-virtual-users
  • quantashi-is-an-intelligent-energy-triage-system-for-ai-data-centers.-problem:-ai-inference-requests-arrive-randomly
  • quantashi-miss-0.0%-with-0.4%-energy-saving;-under-burst-160-req/s
  • runs-on-linuxone.-we-don't-claim-invention-of-carbon-aware-we-integrate-proven-ideas-(sprout-60%
  • solved-via-qaoa-(qiskit-simulator
  • urgency
Share this project:

Updates

Submission history