Research

LLM inference systems and decisions under uncertainty

Most of my work is on systems for LLM inference: how GPUs are shared and spent, and how data reaches them.

I do the systems work in S3 Lab, the Scalable Systems Software Laboratory at Yonsei, advised by Prof. Jinkyu Jeong. Those projects are not yet public, so this page describes the questions I work on and my part in them, not their results. A second line of research studies decisions under uncertainty in organizations.

Sharing GPUs among LLM workloads

July 2026 – present

S3 Lab, Yonsei University
Advisor: Prof. Jinkyu Jeong

  • LLM serving
  • GPU scheduling
  • Operations research

When several inference workloads share one GPU, how much of it should each receive, and when should it change hands?

I work on scheduling layers that sit beneath LLM serving engines and divide a GPU among concurrent workloads. Because demand is uncertain, I treat each allocation as a decision under uncertainty, combining systems mechanisms with models from operations research.

My part The problem formulation, the scheduling policies, and a native serving engine.

In progress; not yet public.

Causal performance analysis for GPU programs

July 2026 – present

S3 Lab, Yonsei University
Advisor: Prof. Jinkyu Jeong

  • Causal profiling
  • CUDA
  • Performance analysis

Profilers show where a GPU program spends its time. Which optimization will actually make the whole application faster?

I build tools that estimate how much an application would gain if one region of its GPU code ran faster, by experimenting on the running program rather than attributing time after the fact. The aim is to know which optimizations are worth making before making them.

My part The profiler, the binary instrumentation beneath it, and the experiments that check its predictions against real optimizations.

In progress; the tooling is not yet public.

Moving data from storage to GPU memory

July 2026 – present

S3 Lab, Yonsei University
Advisor: Prof. Jinkyu Jeong

  • NVMe
  • GPU memory
  • I/O systems

As models and data outgrow GPU memory, which processor should control the movement of data from SSDs into the GPU?

I study the design space of direct storage-to-GPU I/O, and build what is needed to compare alternative designs, including those of published systems, on the same machine.

My part The Linux driver and GPU library the comparisons run on, and the measurements.

In progress; not yet public.

AI and ordering decisions

October 2026 – present

  • Newsvendor model
  • AI-assisted decisions
  • Experiments

When does AI assistance actually reduce the cost of a business decision?

Using the newsvendor ordering problem, I study when AI that reads documents and sales history, and asks managers for missing information, reduces decision losses. The work combines a mathematical model with controlled experiments and regression analysis.

My part The decision model and its AI system, the pilot experiments, and the software for the study with participants.

Pilot experiments complete; a study with human participants is in preparation.

Open source

2026

SGLang upstream pull requests

Submitted July 2026 · open as of October 2026

  • A fix that lets the copy-engine-free transfer of per-expert token counts handle any length up to 512, while keeping the exact fast paths. The case study covers the failure, the design, the tests, and one microbenchmark.
  • A consecutive-prefill budget that limits decode starvation, with tests for speculative decoding, active chunks, and mixed batches. Serving benchmarks are still pending.

hw-codesign

Released · PyPI v0.1.4

  • A Python CLI, MCP server, and agent plugin that turn typed hardware briefs into KiCad candidates, firmware, BOMs, and 3D reviews.
  • Published wheel, source, container, and standalone artifacts.
3D CAD render of the generated RP2040 USB candidate: a green two-layer board with a USB-C connector at one end, a debug header at the other, and the RP2040 between them. Opens the interactive 3D review.
Fig. 1 The RP2040 USB candidate from the public demo, rendered from its generated KiCad files. It is a candidate, not fabricated hardware: of 48 recorded gates, 44 pass, sourcing fails, and supplier availability, the Zephyr build, and physical qualification are blocked.
  1. Brief

    A plain-language request is lowered into a typed spec for one of 13 supported board families.

  2. Candidate

    The run emits KiCad files, firmware, a bill of materials, a 3D assembly, and a review bundle with hashes.

  3. Gates

    Every gate records pass, fail, or blocked. A missing tool or missing physical evidence is blocked, never a pass, and blocks release.