Home/Selected work/Unity GPU analytics

Research computing · Project leadership · 2025

Unity GPU Efficiency Analytics

Metrics and reporting tools for understanding whether requested GPU resources were actually used across a large shared research-computing cluster.

PythonDuckDBSlurmStreamlitHPC
Scale665K job logs
Team4 contributors
Data sourceSlurm + GPU telemetry
AudienceUnity stakeholders

A requested GPU is not necessarily a used GPU.

Scheduler records show what a job requested; telemetry shows what happened after the job began. Resource decisions require both.

The project analyzed Unity cluster jobs to distinguish efficient use from long-running or repeated underutilization. I led a four-person team, coordinated with Unity staff and faculty mentors, and translated the analysis into reports intended for operational decisions.

My role

Project management, metric design, Python analysis, stakeholder reporting, and prioritization of actionable patterns with the research-computing team.

Rate and duration belong in the same measure.

Average utilization alone can hide the difference between a brief setup phase and hours of idle allocation. The workflow derives job-level measures from requested GPUs, elapsed time, compute utilization, memory utilization, and GPU type.

Compute

GPU compute usage

Observed processing utilization relative to the allocated resource.

Memory

GPU memory usage

Memory consumption compared with available GPU memory.

Duration

GPU-hours

Requested GPU count multiplied by job runtime.

Waste

Unused GPU-hours

Duration-weighted underutilization summarized by user or PI group.

Core fields used in the analysis
CategoryFieldsAnalytical use
RequestGPUs, GPU type, CPUs, memoryAllocated capacity
TimeSubmit, start, end, elapsed, time limitWait and duration measures
TelemetryGPU compute and memory usageObserved utilization
OrganizationAccount and userGroup reports and targeted outreach

From scheduler database to an operational report.

01Query Slurm data
02Derive efficiency metrics
03Aggregate patterns
04Report and prioritize
01

Validate jobs

Filter relevant CPU/GPU jobs, normalize dates, and handle unavailable recent windows with explicit fallback logic.

02

Calculate

Compute wait times, GPU-hours, memory and compute efficiency, balance, and request-versus-use discrepancy.

03

Summarize

Create user, PI-group, GPU-type, and time-window reports rather than relying on individual outliers.

04

Communicate

Surface patterns through a Streamlit dashboard, command-line reports, and configurable outreach templates.

Analysis designed to support an intervention.

CoverageGPU + CPU

Separate analytics modules for both resource types

ReportingPI level

Group summaries connect job patterns to stakeholders

ActionOutreach

Configurable thresholds identify repeated underutilization

The public code supports wait-time analysis, efficiency plots, PI reports, CPU group statistics, and personalized outreach generation. The main practical contribution was connecting resource metrics to a repeatable reporting process instead of ending with a static exploratory notebook.

Individual results do not belong in a portfolio.

Cluster-level findings are intentionally summarized.

Job logs can contain usernames, account affiliations, job names, and workload details. This page therefore documents scale, methodology, and public tooling without publishing user-level rankings or operational outreach lists. Utilization also cannot by itself determine scientific value; some workloads legitimately reserve memory or compute unevenly.

Next case studyPolicy Retention Modeling