← All speakers
On this page

Charles Frye is a member of technical staff at Modal, where he develops and explains the infrastructure behind modern AI applications. A computational neuroscientist turned machine-learning educator and infrastructure engineer, he specializes in the relationship between GPU hardware, model inference, evaluation, and production software.

From neuroscience to machine-learning systems

Frye studied biology and computational neuroscience at the University of Chicago before pursuing doctoral research at the University of California, Berkeley’s Redwood Center for Theoretical Neuroscience, supported by a National Science Foundation Graduate Research Fellowship. His first-author research on neural-network optimization showed that methods designed to locate stationary points can instead converge on gradient-flat regions, producing misleading conclusions about the geometry of deep-network loss functions.

He later worked in developer relations and education at Weights & Biases before becoming an instructor with Full Stack Deep Learning. There, he taught engineers to approach machine-learning products as complete systems, encompassing data, accelerators, deployment, interfaces, and monitoring. His askFSDL assistant grounded its answers in course materials, demonstrating how retrieval, contextual information, and user feedback make language models more useful in practice.

By early 2023, Frye was investigating the operational demands of running GLM-130B on one machine. He argued that proprietary and open-weight models serve different needs: hosted systems offer convenience and enterprise support, while accessible weights provide control over deployment, customization, and inference behavior. Open-weight model self-hosting becomes attractive when models meet an application’s capability requirements and serving infrastructure becomes practical to operate.

Infrastructure work at Modal

At Modal, Frye has applied that perspective to GPU education, inference benchmarking, distributed infrastructure, and coding-agent execution. His architectural account of Modal describes the platform as a distributed computer, connecting container execution, image preparation, storage, caching, scheduling, and network I/O.

GPU performance, evaluation & agents

  • GPU performance follows bandwidth and arithmetic intensity. Frye primarily authored Modal’s GPU Glossary, an accessible guide to accelerators, memory hierarchies, CUDA, and performance bottlenecks. His explanation of GPU architecture for AI engineers emphasizes that modern hardware excels at parallelism and low-precision matrix multiplication, while sequential token generation can become limited by repeatedly moving model weights. Batching requests, generating multiple candidates, or verifying several tokens together can improve utilization without requiring proportionally more computation.
  • Evaluation should test whether software actually succeeds. Frye rejects assessments that mistake polished language for correct answers. His QArt codes project makes the distinction concrete: an artistic QR code succeeds only if a phone can scan it. Automated checks and repeated generation turn that requirement into an operational evaluation. For coding tasks, executable tests can similarly identify successful answers among multiple outputs from a smaller model.

Frye’s technical writing also extends to the subtleties of transformer memory. His analysis of KV-cache arithmetic intensity explains why attention does not always benefit from batching like ordinary shared-weight computation: each request carries context-specific cached information that must be loaded separately.

Read the topics behind these talks

5 conference talks

Key ideas

Scroll to read ↓

Moving beyond an API wrapper means understanding where inference runs, what its hardware spends time doing, and which operational responsibilities your application should own.

  • What comes after the API wrapper?
    0:00 ↗
  • From human-readable data to tensors
    3:52 ↗
  • Buying capability before optimizing cost
    10:16 ↗
  • What a managed API lets you control
    14:29 ↗
  • Open weights enable a different development model
    20:56 ↗
  • A convincing answer can still be wrong
    25:23 ↗
  • Capability requirements shape the market
    30:40 ↗
  • Language coverage, team knowledge, and specialization
    36:05 ↗
  • Moving inference onto the user’s device
    44:11 ↗
  • Quantization saves bytes; kernels realize the benefit
    53:08 ↗
  • The browser standardizes execution, not delivery
    58:01 ↗
  • Centralized serving trades latency for simplicity
    1:04:45 ↗
  • Scale to zero, then load the model again
    1:11:40 ↗
  • Owning hardware means owning its constraints
    1:17:51 ↗
  • Why loading a weight once should serve many inputs
    1:20:19 ↗
  • A latency deadline limits how long you can batch
    1:25:43 ↗
  • Specialized chips need a sufficiently stable workload
    1:27:00 ↗
  • Check the hardware model against a trace
    1:33:46 ↗
  • A container cannot hide every GPU dependency
    1:36:11 ↗
  • Choose the operational responsibility you want to own
    1:39:31 ↗

Key ideas

Scroll to read ↓

Inference supplies the bones of an AI application. Language interfaces, retrieval, structured outputs, agent memory, and production feedback turn those bones into a useful product.

  • Inference is only the beginning
    0:00 ↗
  • From query assistants to different kinds of products
    3:59 ↗
  • RAG supplies the context a general model lacks
    6:14 ↗
  • Context, conversation history, and learned knowledge
    12:27 ↗
  • Choose retrieval around the actual constraints
    17:48 ↗
  • Make generated text usable by other systems
    21:46 ↗
  • Why decoding control belongs near inference
    27:40 ↗
  • A function call can simply be a structured answer
    29:22 ↗
  • Agents retain memories and accumulate skills
    34:56 ↗
  • Give agent behavior an explicit architecture
    37:55 ↗
  • Production observations become engineering inputs
    41:03 ↗
  • Monitor the experience, not just the average request
    43:42 ↗
  • Observability depends on recognizing a failure
    48:11 ↗
  • Use the strongest evaluation evidence available
    50:39 ↗
  • Grow tests from failures and feedback from use
    53:31 ↗
  • The remaining engineering work
    55:01 ↗

Key ideas

Scroll to read ↓

Open models make self-hosting plausible, but useful speed depends on workload, precision and latency targets. Charles Frye walks through how to measure those tradeoffs.

  • When does running your own model make sense?
    0:16 ↗
  • Applications need sufficient capability
    3:22 ↗
  • Turn repeated performance questions into a database
    4:56 ↗
  • Read the results as configurations, not engine rankings
    6:37 ↗
  • Choose a latency target before reading throughput
    8:31 ↗
  • Model size does not determine serving speed
    9:36 ↗
  • Reverse the workload and watch throughput change
    10:45 ↗
  • Lower precision could widen the gap
    12:38 ↗
  • Try useful context before adding generated reasoning
    13:11 ↗
  • Take the measurements back to your own workload
    13:55 ↗
  • Find the throughput ceiling without confusing it with latency
    14:31 ↗

Key ideas

Scroll to read ↓

Using GPUs well means understanding why they favor throughput, how decoding wastes arithmetic capacity, and when generating more candidates can make better use of the hardware.

Key ideas

Scroll to read ↓

Useful LLM products depend on domain expertise, deliberate hiring, and a feedback loop that turns real user interactions into evaluations, better decisions, and production guardrails.

  • Six practitioners encounter the same problems
    0:24 ↗
  • Build a product advantage that survives better models
    3:23 ↗
  • Evaluation belongs inside an improvement loop
    6:06 ↗
  • Get real interactions into the loop
    10:01 ↗
  • Prototype for economics that may become possible
    11:57 ↗
  • Buying another shovel does not tell you where to dig
    14:52 ↗
  • Premature model ownership creates the wrong work
    16:23 ↗
  • Evaluation is a core engineering skill
    18:24 ↗
  • Hire for the next stage of the product
    21:00 ↗
  • Turn broad quality goals into testable criteria
    23:54 ↗
  • Choose an evaluator you can align and maintain
    25:41 ↗
  • Inspect recognizable failures with their execution context
    28:34 ↗
  • Turn reference-free evaluations into guardrails
    30:43 ↗
  • The surrounding system still needs maintenance
    32:32 ↗
  • A compelling demo can precede a product by decades
    34:17 ↗

References