AI Papers: A Deep Dive

Why Raw Profiler Data Made an AI Worse at Writing GPU Code

25 min · 26. Juni 2026
Episode Why Raw Profiler Data Made an AI Worse at Writing GPU Code Cover

Beschreibung

WHY RAW PROFILER DATA MADE AN AI WORSE AT WRITING GPU CODE Source: Optimizing CUDA like a Human: Micro-Profiling Tools as Expert Surrogates for LLM-Based GPU Kernel Optimization [https://arxiv.org/abs/2606.26453] Paper was published on June 24, 2026 This episode was AI-generated on June 26, 2026. The script was written by an AI language model and the host voices were synthesized by Eleven Labs. The producer is not affiliated with Anthropic or Eleven Labs. Feeding a language model detailed hardware measurements about its GPU code made the code slower than telling it nothing at all — and that counterintuitive result is the foundation for a system that wrote a kernel from scratch beating the human experts who hand-tuned the production version. The fix wasn't more data; it was a deterministic layer that pre-digests measurements into expert-style diagnoses. You'll learn why interpretation beats raw access, and exactly where the headline claims hold up and where they're thinner than they look. KEY TAKEAWAYS * Why raw hardware counters made the model slower (1.8x) than giving it no profiling data at all (3.3x) — and why that gap is the paper's most confident result * How KernelPro splits 'reading the profiler' from 'writing the code,' encoding 15 expert heuristics as deterministic tools that output diagnoses, not numbers * Why the SASS disassembly tool caught 37 kernels silently falling back to slow scalar code that no utilization metric could have detected * How the Monte Carlo Tree Search uses log-scaled rewards and a hard correctness wall to avoid being seduced by easy wins on garbage code * The production case study where a from-scratch kernel climbed from 14x slower to 1.23x faster than expert engineers over 18 iterations — and why the skeptic calls it an N-of-one result * Where the claims weaken: speedups measured against unoptimized PyTorch, unfair cross-system comparisons, and a 'headline' search-memory feature that didn't clear significance * 00:45 — How can information make you worse? The hosts establish the central paradox — raw profiler data underperforming silence — and why writing fast GPU code is the bottleneck under all of modern AI. * 01:56 — What actually makes a kernel fast? A primer on GPU kernels, the memory hierarchy, and why the expert's scarce skill is diagnostic reasoning, not reading numbers off a profiler. * 04:02 — The category error everyone was making Why jamming interpretation and creative code-writing into one step fails, and how KernelPro's 15 micro-profiling tools encode expert heuristics as trigger-analysis-prescription rules. * 07:56 — Checking the receipt against the kitchen How three profilers each see something the others can't, and why reading the literal compiled machine instructions caught 37 silent scalar fallbacks. * 10:35 — The search that refuses to quit How the tree search treats each node as a full compiled kernel, uses asymmetric branching, and log-scales rewards with a hard correctness wall to stay patient through repeated failure. * 14:46 — Does it actually hold up? The KernelBench results and ablation ladder, followed by the skeptic's caveats about PyTorch-eager baselines and unfair cross-system comparisons. * 17:26 — Beating the humans, once The production case study where KernelPro wrote a from-scratch CUDA kernel that edged past expert engineers — and a careful debate over what a single 1.23x result really proves. * 20:46 — Same speed, less power A preliminary energy-aware experiment cutting power by 12% with no speed cost, plus an honest accounting of which of the paper's own features underperformed. * 22:54 — Diagnose first, then prescribe The takeaway reframe — that raw data without interpretation misleads — and the open question of whether hand-coded heuristics are the future or a crutch. RECOMMENDED READING * KernelBench: Can LLMs Write Efficient GPU Kernels? [https://arxiv.org/abs/2502.10517] — The standard 250-task benchmark across three difficulty tiers that this episode's KernelPro system is evaluated on — including the PyTorch-eager baseline caveat the hosts flagged. * Mastering the Game of Go with Deep Neural Networks and Tree Search [https://doi.org/10.1038/nature16961] — The AlphaGo paper that popularized the Monte Carlo Tree Search algorithm KernelPro adapts — useful for understanding the explore-versus-exploit framing the hosts spent time on.

Kommentare

0

Sei die erste Person, die kommentiert

Melde dich jetzt an und werde Teil der AI Papers: A Deep Dive-Community!

Loslegen

2 Monate für 1 €

Dann 4,99 € / Monat · Jederzeit kündbar.

  • Podcasts nur bei Podimo
  • 20 Stunden Hörbücher / Monat
  • Alle kostenlosen Podcasts

Alle Folgen

174 Folgen

Episode How DeepSeek Made One User Faster Without Slowing Down the Crowd Cover

How DeepSeek Made One User Faster Without Slowing Down the Crowd

HOW DEEPSEEK MADE ONE USER FASTER WITHOUT SLOWING DOWN THE CROWD Source: DSpark: Confidence-Scheduled Speculative Decoding with [https://raw.githubusercontent.com/deepseek-ai/DeepSpec/main/DSpark_paper.pdf] Paper was published on 2026-06-27 This episode was AI-generated on June 27, 2026. The script was written by an AI language model and the host voices were synthesized by Eleven Labs. The producer is not affiliated with Anthropic or Eleven Labs. DeepSeek tore out the fast-text part of its flagship model two weeks into running it — and the replacement makes each user's words come back up to 85% faster while serving the same crowd on the same GPUs. The twist: their winning drafter is the 'dumber' one that guesses words blind, and the whole system works partly because a sloppy production shortcut accidentally made the math more correct. By the end you'll understand the two moves that break a trade-off everyone assumed was iron. KEY TAKEAWAYS * Why position-one accuracy carries enormous leverage in speculative decoding — and how a 'tall cliff' parallel drafter beats a flat-but-coherent autoregressive one * How DSpark's semi-autoregressive design keeps a deep parallel backbone but adds a tiny cheap correction head to stop the draft's tail from rotting * Why aggressive drafting blew up DeepSeek's last production system, and how making draft length a live, load-aware decision fixes the throughput-versus-latency trade * The causality trap in load-aware scheduling — and how using stale, two-step-old data accidentally restores the lossless guarantee instead of breaking it * The honest critique: the offline quality numbers and the production numbers never meet in one experiment, and the win is partly over a deliberately timid single-token baseline * Why the headline isn't one magic multiplier but a better Pareto frontier — more speed and more users on the same hardware * 01:30 — Why the slow part is the bottleneck Explains why one-token-at-a-time generation wastes a parallel GPU and turns a math monster into a typewriter. * 02:07 — The junior, the expert, and free speed Walks through speculative decoding and the rejection-sampling math that makes it exactly lossless. * 03:00 — Two camps, both half-right Lays out autoregressive versus parallel drafters and the 'of problem' multi-modal collision that wrecks parallel accuracy. * 04:45 — When the incoherent drafter won Introduces position-wise conditional acceptance and the cliff-versus-plateau chart that reveals first-token leverage. * 06:36 — A sliver of memory beats stacked depth Describes the semi-autoregressive Markov head, why it must stay strictly local, and the accepted-length gains it buys. * 10:07 — The second bottleneck that killed production Shifts to the verification term and why longer drafts steal batch capacity from other users under heavy load. * 11:51 — Express lanes that open with traffic Explains the load-aware scheduler, the confidence head, and the temperature-scaling fix for overconfident estimates. * 13:43 — How stale data fixed the cheating problem Shows how greedy admission collapses the combinatorial problem and how two-step-old estimates accidentally restore losslessness. * 16:46 — Does the whole machine actually hold up? Presents the production results, the disowned 661% number, and the Pareto frontier as the honest headline. * 19:17 — The catch the paper sometimes blurs Critiques the gap between offline and production numbers, the timid baseline, the heuristic scheduler, and the dropped RNN head — then names the durable ideas. RECOMMENDED READING * Fast Inference from Transformers via Speculative Decoding [https://arxiv.org/abs/2211.17192] — The original speculative-decoding paper and the rejection-sampling foundation DSpark builds on without modifying — essential for understanding the lossless guarantee the episode keeps returning to. * EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty [https://arxiv.org/abs/2401.15077] — The autoregressive drafter lineage (Eagle3) that DSpark benchmarks its accepted-length gains against, representing the 'coherent but sequential' camp the episode contrasts with parallel drafters. * Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads [https://arxiv.org/abs/2401.10774] — The canonical parallel multi-head drafter that exemplifies the 'fire out the whole block at once' camp whose multi-modal collision problem DSpark's semi-autoregressive head is designed to fix. * On Calibration of Modern Neural Networks [https://arxiv.org/abs/1706.04599] — Introduces temperature scaling, the exact single-dial calibration fix DSpark applies to its confidence head so the scheduler can trust survival-probability magnitudes, not just their ranking.

Gestern23 min
Episode Why Raw Profiler Data Made an AI Worse at Writing GPU Code Cover

Why Raw Profiler Data Made an AI Worse at Writing GPU Code

WHY RAW PROFILER DATA MADE AN AI WORSE AT WRITING GPU CODE Source: Optimizing CUDA like a Human: Micro-Profiling Tools as Expert Surrogates for LLM-Based GPU Kernel Optimization [https://arxiv.org/abs/2606.26453] Paper was published on June 24, 2026 This episode was AI-generated on June 26, 2026. The script was written by an AI language model and the host voices were synthesized by Eleven Labs. The producer is not affiliated with Anthropic or Eleven Labs. Feeding a language model detailed hardware measurements about its GPU code made the code slower than telling it nothing at all — and that counterintuitive result is the foundation for a system that wrote a kernel from scratch beating the human experts who hand-tuned the production version. The fix wasn't more data; it was a deterministic layer that pre-digests measurements into expert-style diagnoses. You'll learn why interpretation beats raw access, and exactly where the headline claims hold up and where they're thinner than they look. KEY TAKEAWAYS * Why raw hardware counters made the model slower (1.8x) than giving it no profiling data at all (3.3x) — and why that gap is the paper's most confident result * How KernelPro splits 'reading the profiler' from 'writing the code,' encoding 15 expert heuristics as deterministic tools that output diagnoses, not numbers * Why the SASS disassembly tool caught 37 kernels silently falling back to slow scalar code that no utilization metric could have detected * How the Monte Carlo Tree Search uses log-scaled rewards and a hard correctness wall to avoid being seduced by easy wins on garbage code * The production case study where a from-scratch kernel climbed from 14x slower to 1.23x faster than expert engineers over 18 iterations — and why the skeptic calls it an N-of-one result * Where the claims weaken: speedups measured against unoptimized PyTorch, unfair cross-system comparisons, and a 'headline' search-memory feature that didn't clear significance * 00:45 — How can information make you worse? The hosts establish the central paradox — raw profiler data underperforming silence — and why writing fast GPU code is the bottleneck under all of modern AI. * 01:56 — What actually makes a kernel fast? A primer on GPU kernels, the memory hierarchy, and why the expert's scarce skill is diagnostic reasoning, not reading numbers off a profiler. * 04:02 — The category error everyone was making Why jamming interpretation and creative code-writing into one step fails, and how KernelPro's 15 micro-profiling tools encode expert heuristics as trigger-analysis-prescription rules. * 07:56 — Checking the receipt against the kitchen How three profilers each see something the others can't, and why reading the literal compiled machine instructions caught 37 silent scalar fallbacks. * 10:35 — The search that refuses to quit How the tree search treats each node as a full compiled kernel, uses asymmetric branching, and log-scales rewards with a hard correctness wall to stay patient through repeated failure. * 14:46 — Does it actually hold up? The KernelBench results and ablation ladder, followed by the skeptic's caveats about PyTorch-eager baselines and unfair cross-system comparisons. * 17:26 — Beating the humans, once The production case study where KernelPro wrote a from-scratch CUDA kernel that edged past expert engineers — and a careful debate over what a single 1.23x result really proves. * 20:46 — Same speed, less power A preliminary energy-aware experiment cutting power by 12% with no speed cost, plus an honest accounting of which of the paper's own features underperformed. * 22:54 — Diagnose first, then prescribe The takeaway reframe — that raw data without interpretation misleads — and the open question of whether hand-coded heuristics are the future or a crutch. RECOMMENDED READING * KernelBench: Can LLMs Write Efficient GPU Kernels? [https://arxiv.org/abs/2502.10517] — The standard 250-task benchmark across three difficulty tiers that this episode's KernelPro system is evaluated on — including the PyTorch-eager baseline caveat the hosts flagged. * Mastering the Game of Go with Deep Neural Networks and Tree Search [https://doi.org/10.1038/nature16961] — The AlphaGo paper that popularized the Monte Carlo Tree Search algorithm KernelPro adapts — useful for understanding the explore-versus-exploit framing the hosts spent time on.

26. Juni 202625 min
Episode How an AI Reviewer Learned to Stop Going Easy on AI Writing Cover

How an AI Reviewer Learned to Stop Going Easy on AI Writing

HOW AN AI REVIEWER LEARNED TO STOP GOING EASY ON AI WRITING Source: The Red Queen Gödel Machine: Co-Evolving Agents and Their Evaluators [https://arxiv.org/abs/2606.26294] Paper was published on June 24, 2026 This episode was AI-generated on June 26, 2026. The script was written by an AI language model and the host voices were synthesized by Eleven Labs. The producer is not affiliated with Anthropic or Eleven Labs. An AI paper-reviewer was caught accepting machine-written papers nearly twice as often as human ones — and the researchers found a mechanical recipe to train that bias right out. The trick is letting the test itself evolve alongside the thing it grades, without the measurements turning to nonsense. It's a concrete proposal for how self-improving AI might escape the tiny island of coding and math where clean, fixed scoring exists. KEY TAKEAWAYS * Why recursive self-improvement only works where there's a cheap, trustworthy way to score output — and why a moving judge normally breaks that * The 'controlled utility evolution' trick: freeze the judge inside an epoch, swap only at boundaries against fixed real-world 'anchor' data * Why erasing old scores when a new judge takes over is the load-bearing step — without it, a stricter judge changes essentially nothing * How the system trained self-preference bias out of an AI reviewer by trapping it with the exact papers that fooled it earlier * The surprise that the proof grader's biggest gain came from getting less strict — learning calibration, not cruelty * Where the skeptic wins: the whole framework is only as good as its imperfect anchor, and the writing results were never checked by a human * 00:00 — The judge who changes nothing A gymnastics-judging analogy sets up the paper's central trick — a stricter standard only counts if you wipe the old scores. * 01:28 — The island self-improvement is stuck on Why systems that improve themselves only work where there's a clean, cheap, trustworthy way to score output. * 02:14 — Why a frozen judge fails you The breeding-program setup explains stationarity, the Red Queen idea, and the three ways a fixed test goes wrong. * 05:29 — Move the judge, break the stopwatch? How epochs, held-out anchors, and conservative scoring let the judge change without destroying the ability to measure progress. * 08:17 — Wipe the board, re-rank the winners Selective erasure is shown to be the entire mechanism — without deleting stale scores, a stricter judge reshuffles nothing. * 10:56 — Does any of it make code better? Co-evolving a code reviewer alongside a coder yields higher success and fewer tokens, with improvements that help both roles at once. * 12:51 — Catching the reviewer that gets fooled Self-preference bias is measured cold, then trained out with an adversarial trap built across an epoch boundary. * 15:55 — When the judge develops taste The evaluators evolve their own rubrics from a one-line prompt — and the grader's biggest gain came from getting less strict, not harsher. * 17:13 — Where the skeptic wins The honest limits: everything rides on imperfect anchors, the writing was never read by humans, the proof results are thin, and the long-run guarantees are absent. * 20:54 — Where the hard problem now lives The reframe to take away — the test is just another agent that can be improved or biased — and the open fork on whether to let evaluators move at all. RECOMMENDED READING * Gödel Agent: A Self-Referential Framework for Agents Recursively Self-Improvement [https://arxiv.org/abs/2410.04444] — The self-improving agent lineage this episode's Red Queen Gödel Machine extends, where an agent rewrites its own code to get better. * Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents [https://arxiv.org/abs/2505.22954] — The breeding-program-of-code framing the episode describes, where variants are scored, kept, and bred — the static-judge predecessor this paper reacts against. * LLM Evaluators Recognize and Favor Their Own Generations [https://arxiv.org/abs/2404.13076] — Documents the self-preference bias that is the episode's central villain — AI judges going easy on AI-written text. * Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena [https://arxiv.org/abs/2306.05685] — The foundational LLM-as-a-judge paper behind the evaluator agents the episode's framework co-evolves and the biases it tries to train out.

26. Juni 202623 min
Episode An AI Designed Its Own Psychology Studies, Then Confirmed What It Found Cover

An AI Designed Its Own Psychology Studies, Then Confirmed What It Found

AN AI DESIGNED ITS OWN PSYCHOLOGY STUDIES, THEN CONFIRMED WHAT IT FOUND Source: Closing the Loop to Discover Psychological Theories with an Automated Cognitive Scientist [https://arxiv.org/abs/2606.26448] Paper was published on June 24, 2026 This episode was AI-generated on June 26, 2026. The script was written by an AI language model and the host voices were synthesized by Eleven Labs. The producer is not affiliated with Anthropic or Eleven Labs. A system called AutoCog designed psychology experiments, paid 250 real people to take them, diagnosed why its own theories failed, and rediscovered one of the deepest principles in decision science — then locked in predictions and confirmed them. It's the first time an AI has closed the full scientific loop with no researcher in the chair. But the headline runs ahead of the evidence, and the honest version turns out to be more interesting than either the hype or the cynicism. KEY TAKEAWAYS * How AutoCog closes the full discovery loop — designing experiments, paying online participants, diagnosing failures, and revising theories — with no human in the chair * Why the system scores theories by whether they can generate human-like behavior rather than by fitting data, and why that guards against overfitting * How three classic decision rules — Take-the-Best, Tallying, and WADD — collapse into endpoints of a single tunable dial * The flagship 'discovery,' Diminishing Returns WADD, turns out to be a fresh instance of Kahneman and Tversky's prospect theory * Where the headline overreaches: a friendly domain, a search that stayed local, an unaudited gap between the verbal theory and its code, and one thin confirmation * Why the durable result may not be the finding itself, but the idea that theory-building can become an auditable, resumable trace instead of a private flash of insight * 00:04 — Can you automate the creative leap? Sets up the frontier question — whether the irreducibly human act of inventing a better theory can be handed to an AI. * 03:24 — Two blenders and three rival rules Grounds the task in multi-attribute decision-making and lays out the three classic strategies the AI works with. * 05:42 — Two lawyers, one self-correcting wheel Walks through the four-stage loop of advocate agents, a simulate-before-collect gate, and a neutral arbiter that rebuilds the loser. * 07:58 — Why it refuses to Photoshop the data Explains the generate-don't-fit scoring metric and the unification pressure that quietly forces parsimony. * 10:52 — Can it find an answer it was never given? The validation phase — recovering hidden strategies, even deliberately bizarre anti-theories, and reporting noise honestly instead of inventing structure. * 14:52 — When three theories become one knob The first live deployment on 250 real people, where the winning model unifies the three rivals as settings of a single dial. * 17:33 — The discovery it didn't go looking for One small change surfaces Diminishing Returns WADD — a concave curve that turns out to be prospect theory, confirmed by a preregistered study. * 22:19 — Where the headline runs out ahead The skeptic's case — a friendly domain, a local search, a known mechanism, and an unaudited verbal-to-code gap. * 26:46 — The creative leap, finally logged Why an auditable, resumable trace of the discovery process may matter more than the specific finding, and what comes next. RECOMMENDED READING * Centaur: a foundation model of human cognition [https://arxiv.org/abs/2410.20268] — The Helmholtz Munich line of work on behavioral foundation models that simulate human choices, the in-silico stand-in the episode flags as the conditional forward path for cheaper discovery loops.

26. Juni 202631 min
Episode One Crosscoder Feature Flips a Stalling Chatbot Into a Working Agent Cover

One Crosscoder Feature Flips a Stalling Chatbot Into a Working Agent

ONE CROSSCODER FEATURE FLIPS A STALLING CHATBOT INTO A WORKING AGENT Source: Localizing RL-Induced Tool Use to a Single Crosscoder Feature [https://arxiv.org/abs/2606.26474] Paper was published on June 25, 2026 This episode was AI-generated on June 26, 2026. The script was written by an AI language model and the host voices were synthesized by Eleven Labs. The producer is not affiliated with Anthropic or Eleven Labs. Reinforcement learning spent a whole training run teaching a model to use tools — and it turns out you can find that skill, grab one internal feature, and flip the behavior on at runtime with no retraining at all. But the same evidence that says the skill lives in one place also shows it quietly leaking into a model that was never trained for it. This episode unpacks what RL actually localizes, where it lives, and why you can concentrate a capability but never fully wall it off. KEY TAKEAWAYS * Why a single 'dedicated' crosscoder feature, steered at inference time with no weight changes, can recover most of an RL model's tool-calling accuracy * How just routing activations through the sparse dictionary and back raises tool correctness from 19% to ~50% — even though reconstruction quality barely predicts the gain * The 'capability spillover' result: a frozen base model, never trained for tools, picks up tool selection (0% to ~7%) just by passing through the shared crosscoder — but never reproduces the tool-call syntax * Why the exclusive feature shelf is a coffee filter, not a sealed sink — penalizing it degrades the RL model, proving the captured signal is load-bearing and leaky * The honest limits: the +65 number comes from one best-performing cell on 40 prompts with a wide confidence band, and the DFC's advantage is legibility, not better performance * Why the cleanest features are structural-template detectors — and why that may be exactly why a tool-calling skill concentrates into one dial when a messier capability might not * 00:00 — Where does an RL skill actually live? Sets up the puzzle: RL visibly installs tool use, but no one can point to where in the network that capability physically lives. * 02:34 — Reading the model's muddy scratchpad Explains superposition and sparse dictionaries — the tools that separate a model's blended internal state back into named features. * 04:26 — Bolting down the shelves: the DFC Introduces the crosscoder and the Dedicated Feature Crosscoder, which forces features into RL-exclusive, base-exclusive, and shared bins. * 07:13 — One master switch versus a fuse box Walks through the saturation curve where one DFC feature hits the accuracy ceiling while the plain crosscoder needs 33 features. * 09:29 — Feature 136 turns a hedger into an agent The before-and-after example where steering a single feature produces a clean, correct tool call — and reveals the top features are template detectors. * 11:03 — Why lossy reconstruction makes it better The surprising finding that just routing activations through the dictionary and back boosts tool correctness, validated across 48 crosscoder variants. * 13:09 — A frozen model catches the trick Capability spillover: the untrained base model inherits tool selection through the shared decoder, but never the exact tool-call syntax. * 15:10 — A coffee filter, not a sealed sink Penalizing the exclusive shelf degrades the RL model, showing the capability is entangled in shared geometry and can be concentrated but never fully isolated. * 18:22 — How soft is that headline number? The critique: the +65 estimate is a favorable draw on 40 prompts, the architecture comparison isn't significant, and 'capability' means propensity under one prompt. * 22:08 — When your interpretability tool leaks Why feature-level steering offers a gradient-free control handle for agents — but published diffing artifacts may themselves become a side channel that moves capability around. RECOMMENDED READING * Towards Monosemanticity: Decomposing Language Models With Dictionary Learning [https://transformer-circuits.pub/2023/monosemantic-features/index.html] — The Anthropic sparse-autoencoder work that grounds the episode's 'separate the mud back into named pigments' picture of superposition and single-meaning features. * Sparse Crosscoders for Cross-Layer Features and Model Diffing [https://transformer-circuits.pub/2024/crosscoders/index.html] — The original crosscoder writeup that introduced the shared-dictionary model-diffing approach the episode's Dedicated Feature Crosscoder extends. * Toy Models of Superposition [https://transformer-circuits.pub/2022/toy_model/index.html] — The foundational account of why a few-thousand-dimensional scratchpad packs far more concepts than dimensions — the entanglement the episode says makes perfect capability isolation impossible.

26. Juni 202625 min