← All speakers

Bio, Work & Ideas

Philip Kiely

Conference affiliation: Developer Relations · Baseten · 2026

Philip Kiely is Head of AI Education at Baseten, an early employee of the model-inference company, and the author of Inference Engineering. He helps engineers understand how model architecture, GPU hardware, serving software, networking, and application design determine the speed and cost of production AI.

Kiely began publishing technical tutorials in 2019 while studying computer science at Grinnell College. He wrote for Smashing Magazine, Twilio, and other technology publications, published Writing for Software Developers shortly before graduating with an honors degree in 2020, and created Who Pays Technical Writers to connect writers with paid opportunities.

He joined Baseten in January 2022 as its tenth employee, working across developer relations, technical content, documentation, and education. As generative AI moved into production, he concentrated on inference: choosing hardware, deploying models, measuring bottlenecks, and balancing latency, throughput, reliability, and cost. His 2026 book Inference Engineering maps that discipline across model architecture, GPUs, serving runtimes, optimization, multimodal applications, and production infrastructure.

  • Inference performance depends on the workload. GPU type, batch size, sequence length, concurrency, and latency targets determine which configuration actually performs well. Kiely emphasizes representative benchmarks, tail latency, and the difference between throughput experienced by one user and total GPU output. His TensorRT-LLM workshop also addresses hardware-specific engines, quantization, deployment, and autoscaling constraints.
  • Open serving frameworks expand practical choices. Kiely works across TensorRT-LLM, SGLang, and vLLM, choosing among hardware optimization, extensibility, and model compatibility. His SGLang workshop connects runtime selection to speculative decoding, realistic benchmarking, inspectable implementations, and open-source contributions.
  • Real-time voice inference changes the optimization target. For Orpheus text-to-speech, roughly 83 tokens per second satisfies real-time playback; first-byte latency, simultaneous streams, and GPU utilization then matter more than additional token throughput. Kiely combines FP8 quantization, TensorRT-LLM, GPU-based audio decoding, and dynamic batching while accounting for connection reuse, network placement, and coordination across listening, reasoning, and speech systems.
  • Technical books can become reusable audio pipelines. Kiely built an AI-narrated audiobook of Inference Engineering using Rime’s Coda model and a custom clone of his voice. The project involved rewriting diagrams and tables for audio, segmenting the manuscript, correcting pronunciation, generating speech, and assembling audiobook files.

Read the topics behind these talks

4 conference talks

Key ideas

Scroll to read ↓

Build a GPU-specific inference engine, repeat the build with FP8, deploy it behind an API, and measure where throughput gains meet latency and serving constraints.

  • What does it take to make inference fast?
    0:16 ↗
  • The graph executor and the LLM runtime
    3:42 ↗
  • Build for the workload and the GPU
    7:16 ↗
  • Architecture, hardware, and precision determine the options
    15:18 ↗
  • Choose the optimization effort before distributing the model
    23:23 ↗
  • Provision the remote build environment
    31:19 ↗
  • Download, convert, build, and generate
    44:29 ↗
  • What conversion, building, and stopping each control
    49:46 ↗
  • Repeat the build with FP8
    56:02 ↗
  • Turn the build into a deployed service
    1:03:42 ↗
  • Measure the operating point, not just a fast response
    1:13:12 ↗
  • Load the streaming endpoint
    1:17:27 ↗
  • Separate engine limits from serving bottlenecks
    1:25:44 ↗
  • Scale replicas without losing the engine’s assumptions
    1:29:54 ↗
  • What remains yours to operate
    1:35:19 ↗

Key ideas

Scroll to read ↓

Deploy an OpenAI-compatible model server, diagnose CUDA graph coverage from its logs, and tune speculative decoding against the workload you actually expect to serve.

  • From a model to a running server
    0:25 ↗
  • A runtime built with a kernel community
    3:34 ↗
  • Package, deploy, and call the model
    5:35 ↗
  • Read the decode log before changing flags
    13:39 ↗
  • Match capture coverage to the workload
    20:21 ↗
  • Configure the draft, then tune its search
    24:23 ↗
  • Find the layer you can improve
    29:36 ↗
  • Specialization and the ability to unblock yourself
    35:23 ↗
  • Security, private inference, and engine compatibility
    37:57 ↗

Key ideas

Scroll to read ↓

Orpheus TTS shows how LLM runtimes, audio decoding, batching and client connections work together to deliver more concurrent speech streams with less startup delay.

  • What can LLM tooling do for a speech model?
    0:15 ↗
  • Reach playback speed, then optimize first audio and concurrency
    3:22 ↗
  • Optimize token generation and audio decoding together
    5:00 ↗
  • Batch the decoder without delaying the stream
    7:05 ↗
  • Measure simultaneous streams and first-byte latency
    8:28 ↗
  • Keep the client from erasing the runtime gains
    10:27 ↗
  • Budget latency across listening, thinking and talking
    13:02 ↗

Key ideas

Scroll to read ↓

Philip Kiely of Baseten examines the tradeoffs behind four-bit caches, learned memory compaction, and diffusion drafting—and the growing role of training in making inference faster.

  • Local inference and data center serving can favor different tradeoffs. A smaller cache may justify slower decode when memory capacity prevents a workload from fitting.
    2:43 ↗
  • Still uses fixed learned query vectors to cross-attend to the full KV cache and produce compact keys and values in one forward pass.
    10:42 ↗
  • DFlash proposes eight or 16 tokens together. Complete drafting time and target acceptance determine its benefit, rather than the duration of one drafting invocation.
    12:12 ↗
  • Continuous retraining can improve acceptance on live traffic, but requires data-use permission, storage, compute, data movement, and changes when the target model changes.
    16:11 ↗
  • Training increasingly produces inference optimizations, while hardware gains also depend on software support and efficient system-wide cache movement.
    3:42 ↗

References