Pith. sign in

REVIEW 4 major objections 3 minor 16 cited by

KernelEvolve claims an agentic kernel-coding framework—tree search plus a persistent knowledge base and retrieval-augmented prompting—can autonomously generate correct, optimized kernels across three hardware platforms, with 100% correctnes

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-03 13:41 UTC pith:J6RLRBL6

load-bearing objection Credible industrial report on an agentic kernel-coding system, but the headline production speedups are measured on synthetic data matched only by mean/std, so the quantitative claims should be read as synthetic-benchmark results until validated. the 4 major comments →

arxiv 2512.23236 v4 pith:J6RLRBL6 submitted 2025-12-29 cs.LG cs.AIcs.ARcs.MAcs.PF

KernelEvolve: Scaling Agentic Kernel Coding for Heterogeneous AI Accelerators at Meta

Gang Liao , Hongsen Qin , Ying Wang , Alicia Golden , Michael Kuchnik , Yavuz Yetim , Jia Jiunn Ang , Chunli Fu
show 31 more authors
Yihan He Samuel Hsia Zewei Jiang Dianshi Li Uladzimir Pashkevich Varna Puvvada Feng Shi Matt Steiner Ruichao Xiao Liyuan Li Nathan Yan Xiayu Yu Zhou Fang Roman Levenstein Kunming Ho Haishan Zhu Alec Hammond Richard Li Ajit Mathews Kaustubh Gondkar Abdul Zainul-Abedin Ketan Singh Hongtao Yu Wenyuan Chi Barney Huang Sean Zhang Noah Weller Zach Marine Wyatt Cook Carole-Jean Wu Gaoxiang Liu
This is my paper
classification cs.LG cs.AIcs.ARcs.MAcs.PF
keywords agentic kernel codingheterogeneous AI acceleratorstree searchretrieval-augmented promptingDLRM inferenceTritonkernel generationMTIA
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper sets out to prove that the curse of heterogeneity in AI infrastructure—combinatorial diversity of operators, model architectures, and hardware generations—can be tamed by an autonomous software agent rather than by manual kernel engineering. It presents KernelEvolve, a system that takes a kernel specification and searches over candidate implementations, guided by execution feedback, profiling data, and a persistent knowledge base of hardware-specific constraints. The authors report that KernelEvolve generates numerically correct kernels for all 480 operator–platform configurations tested, achieves a 100% pass rate on all 250 KernelBench problems across three difficulty levels, and delivers 1.25–17× speedups on production recommendation workloads while cutting development time from weeks to hours. If true, this means emerging accelerators—including proprietary ones with scarce public documentation—can reach production-ready kernel coverage without waiting for vendor libraries or manual porting.

Core claim

On its own terms, the paper's central discovery is that kernel optimization can be fully automated as a graph-based search over kernel artifacts. KernelEvolve starts from a kernel specification, repeatedly generates candidate Triton kernels with an LLM, evaluates each on target hardware for numerical correctness and speed, and feeds profiling insights back into the next generation. Three elements carry the argument: a single 'universal operator' whose prompt adapts to runtime context; a persistent knowledge base encoding hardware-specific constraints, including the undocumented details of a proprietary accelerator; and a tree-search strategy (greedy, MCTS, or evolutionary) with checkpointing

What carries the argument

The load-bearing mechanism is the 'universal operator'—a single transformation function that, given a kernel artifact and runtime context (profiling results, error messages, hardware constraints), generates the next kernel candidate. It is driven by retrieval-augmented prompt synthesis: a context-memory sub-agent analyzes execution artifacts to diagnose bottlenecks, and a deep-search sub-agent fetches relevant documents from a hierarchical knowledge base that encodes hardware-specific knowledge, including MTIA-specific Triton extensions, dual-core synchronization, and inter-PE communication primitives. The system frames the whole loop as a search tree with a fitness function (speedup over a

Load-bearing premise

The production speedup numbers rest on the unverified claim that synthetic data matching only Min, Max, Mean, and STD of real production tensors yields the same kernel performance as the production data itself.

What would settle it

Rerun the production benchmark kernels on the actual production tensors (or on distributions that match higher-order statistics of the real data, such as skew or access-pattern locality) and compare measured speedups with the reported 1.25–17× range; if the range does not reproduce, the synthetic-data equivalence claim collapses.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • If the reported correctness and speedup numbers hold, automated kernel generation becomes a practical path for deploying models on new accelerators: a missing kernel changes from a deployment blocker to an automated enablement step.
  • Shape-specific specialization means production kernels can be tuned to the exact tensor shapes and distributions they serve, with runtime dispatch falling back to vendor libraries when the generated kernel underperforms, so regressions are avoided in production.
  • By automating data-preprocessing kernels, the system can remove the binary constraint that forces disaggregated serving architectures, eliminating the 10–20 ms network overhead the paper attributes to missing native implementations.
  • Cutting development from weeks to hours lowers the cost of keeping pace with 12–18 month hardware generation cycles and makes heterogeneous fleets economically viable.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If a proprietary accelerator can be handled purely through knowledge-base injection, then the real barrier to kernel generation on new hardware is documentation, not model exposure; this suggests any vendor could onboard the same agent without retraining the underlying LLM—a testable claim by running the system on another custom accelerator.
  • The paper implies kernel quality should improve with search compute, but it does not report a fitness-versus-steps curve; a natural extension is to measure how speedup grows with the number of tree expansions across operator families, which would test the inference-time-scaling hypothesis directly.
  • The reported equivalence between synthetic and production data rests on four summary statistics; a stress test that varies access patterns, skew, or tensor shapes beyond Min/Max/Mean/STD would either confirm the equivalence or reveal where it breaks, directly bounding the production speedup claims.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

4 major / 3 minor

Summary. KernelEvolve is an agentic kernel-generation system for DLRM training/inference across NVIDIA, AMD, and Meta's MTIA accelerators. The paper formalizes kernel optimization as graph-based tree search with a universal operator, retrieval-augmented prompt synthesis, a persistent knowledge base, and multi-level evaluation/profiling tooling. The headline claims are 100% correctness across 480 operator-platform configurations and 100% pass rate on KernelBench, 1.25-17× speedups on production workloads, development-time reduction from weeks to hours, and first at-scale deployment for business-critical recommendation inference. The empirical support includes KernelBench results, ATen operator coverage, detailed case studies (conv1d, Optimized FM, PFFN, MapId, MBDT, Batch Event Truncate), and an appendix with generated kernel source.

Significance. If the empirical claims hold, this is a significant industrial systems contribution: it would demonstrate that an agentic LLM framework can produce production-grade kernels for both commodity and proprietary accelerators, with correctness validation and performance competitive with or better than compiler baselines on domain-specific operators. The paper is honest in several places: Table 3 reports out-of-distribution regressions, Table 7 reports a 0.80× regression at the largest MTIA v3 batch size, Appendix A discloses synthetic data and an internal Triton fork, and the fitness function F(v)=t_pytorch/t_triton is a standard objective-based evaluation rather than a circular derivation. These disclosures strengthen the credibility of the system's architecture. However, the load-bearing production-performance claim currently rests on an unvalidated synthetic-data equivalence assertion, and the 100% correctness claims rest on unspecified numerical tolerances. Both need to be made explicit and reproducible before the headline conclusions can be accepted.

major comments (4)
  1. [Appendix A; §5.1; §8] The production-speedup headline (1.25-17×, Fig. 4 and §8) depends on the Appendix A assertion that 'synthetic data that preserves the statistical properties (Min, Max, Mean, and STD) of the original production dataset ... has been validated to yield equivalent speedup characteristics.' No validation protocol, comparison table, or error bounds are shown. Kernel performance is sensitive to distribution shape, sparsity, access patterns, and tensor shapes, none of which are determined by four summary statistics. Please provide a head-to-head validation on real production data for at least one representative workload per case study, or clearly scope the claims to 'synthetic production-like data.' Without this, the reported numbers cannot be interpreted as production speedups.
  2. [§3.4.1; §4; §5.1] The 100% correctness claims over 480 operator-platform configurations and 100% KernelBench pass rate are not reproducible as stated. §3.4.1 says outputs are compared 'via torch.allclose() with precision-dependent tolerances,' but no tolerances are specified for §4; §5.1 reports atol=1e-4, rtol=5e-4 for conv1d only. Please list the exact tolerance settings, the number of seeds/input distributions, and the pass/fail criterion used for each operator and for KernelBench. Also clarify whether '100% pass rate' includes all three KernelBench difficulty levels with the original KernelBench harness and open-source Triton, since Appendix A states an internal Triton trunk was used.
  3. [Appendix A; §3.4; §5] The evaluation environment is partially proprietary: the paper uses Meta's internal Triton trunk (Appendix A), internal interpreters, FaaS infrastructure, and MTIA-specific compilers. The generated Triton source in Appendix A also uses torch.compile(..., mode='max-autotune-no-cudagraphs') for the PyTorch baseline, while the text describes 'PyTorch baselines' without this detail. Please specify exact software versions/commits (PyTorch, Triton, ROCm/CUDA, MTIA toolchain) for each platform and state the baseline configuration consistently. This is needed to assess whether the speedups are due to KernelEvolve's generated kernels or to a particular compiler configuration.
  4. [§5.4.1; Table 7] Table 7 shows a 0.80× regression for MapId on MTIA v3 at batch size 50000, which the text acknowledges. The text then claims 'runtime dispatch based on input dimensions ensures fallback to PyTorch, preventing performance degradation,' but no evidence of this dispatch mechanism is provided, and it is unclear whether batch 50000 is outside the production shape distribution. Since this is the largest batch evaluated and could be representative of batched inference, please clarify whether the fallback is actually deployed, and state the production shape distribution for MapId.
minor comments (3)
  1. [Figure 3; Table 7; §5.4] There are several typos and inconsistencies: Figure 3's legend shows 'Tritor' and duplicate labels; Table 7's text in §5.4.1 says 'on v1' where the table refers to MTIA v2i; §5.4.2 says 'v2i has higher native operator coverage (Table 5)' although Table 5 shows v2i has more missing ATen operators than v3.
  2. [Figure 4; §5.5] Figure 4 lists '2D Jagged Split' while the corresponding case study in §5.5 is 'Batch Event Truncate'. Please align the labels.
  3. [§2.1; References] There are formatting issues: 'Luo et al. (2025))' has an extra parenthesis, and the reference list contains minor typos (e.g., 'Attention is all you need' style capitalization inconsistencies).

Circularity Check

0 steps flagged

No significant circularity: the reported speedups are the system's own optimization objective evaluated against PyTorch baselines, correctness is checked against external references and the public KernelBench suite, and self-citations appear only as related work or infrastructure, not as load-bearing justification.

full rationale

KernelEvolve's central derivation is a search-based kernel optimizer whose fitness function is explicitly F(v) = t_pytorch / t_triton (§3.1). Reporting speedups over the same PyTorch baseline is standard objective-based evaluation, not a circular prediction: the paper does not claim to predict an independent quantity from fitted parameters. Correctness claims are anchored by comparisons to PyTorch reference implementations and by the public KernelBench suite (§4), providing independent grounding. The main weaknesses are not circular. Appendix A states that synthetic data 'preserves the statistical properties (Min, Max, Mean, and STD)' and 'has been validated to yield equivalent speedup characteristics,' but no validation protocol is shown; this is an unsupported empirical assumption about transfer, not a reduction of the reported speedup to its own input. Similarly, the 'precision-dependent tolerances' for torch.allclose (§3.4.1, §4) are unspecified, but nothing in the paper defines the claimed 100% correctness in terms of those tolerances by construction. Self-citations exist — Meta's prior MTIA papers, KernelLLM, CWM, TritonBench, and TLX — but they are used as related work, hardware documentation, or infrastructure components, not as a uniqueness theorem forbidding alternatives or as the sole support for the core claim. No ansatz is smuggled in via citation, no known result is renamed as a new contribution, and no equation reduces to another by definition. The production-speedup and 100%-correctness claims carry correctness risk due to the unvalidated synthetic-data equivalence and the internal Triton trunk noted in Appendix A, but those are evidentiary concerns, not circularity. I therefore find no significant circularity and assign score 0.

Axiom & Free-Parameter Ledger

3 free parameters · 4 axioms · 0 invented entities

KernelEvolve is a systems paper, so the ledger records assumptions behind the empirical claims rather than derivation axioms. The dependence on external LLM backends is a black-box capability assumption. The design hypothesis that one context-adaptive operator beats fixed multi-operator pipelines is inherited from cited literature rather than measured here. The Appendix A synthetic-data claim is the most consequential assumption; the unspecified allclose tolerances are free parameters in the correctness definition; the autotune configs and MTIA flags are fitted per shape by design (disclosed as such). No invented entities: the knowledge base, universal operator, and sub-agents are software components without independent falsifiable handles.

free parameters (3)
  • torch.allclose tolerance settings = unspecified ('precision-dependent')
    The '100% correctness' claims over 480 operator-platform configs and 250 KernelBench problems are pass/fail results; the numerical thresholds are never stated (§4, §3.4.1).
  • Triton autotune configuration sets (BLOCK_M/BLOCK_N/BLOCK_K, num_warps, num_stages) = searched per shape; 20+ configs for conv1d in Appendix A
    Configs are tuned by the search to production shapes, and the reported speedups are measured on those shapes (§5.1, §5.3).
  • MTIA compilation flags (cb_multiplier, use_dual_core) = explored via @triton.autotune over ranges (BLOCK_SIZE in {32,1024}, cb_multiplier in {1,8}); final values not reported
    These flags materially affect the MTIA v3 performance numbers (§3.2.3, §5.4).
axioms (4)
  • domain assumption Synthetic data matching min/max/mean/std of production tensors produces speedup characteristics equivalent to the real production data.
    Appendix A: 'This synthetic dataset has been validated to yield equivalent speedup characteristics...' — asserted without protocol; underpins all §5 production speedups.
  • domain assumption A single universal operator with retrieval-augmented dynamic prompting outperforms fixed multi-operator (Draft/Debug/Improve) frameworks.
    §3.1 argues this from cited operator-bottleneck research (Toledo et al. 2025); no ablation in this paper isolates the universal operator's contribution.
  • domain assumption External LLM backends (Claude 4.5, GPT-5, Llama, CWM) supply base coding ability adequate for Triton synthesis.
    §3 uses these backends as the synthesis engine; the system's performance ceiling depends on untrained model capabilities.
  • domain assumption The Meta-internal Triton trunk produces kernels representative of what the method would achieve on open-source Triton.
    Appendix A notes the internal trunk 'differs slightly from the open-source release'; the reported correctness/speedup numbers were generated with it.

pith-pipeline@v1.3.0-alltime-deepseek · 49840 in / 20956 out tokens · 179966 ms · 2026-08-03T13:41:52.384004+00:00 · methodology

0 comments
read the original abstract

Making deep learning recommendation model (DLRM) training and inference fast and efficient is important. However, this presents three key system challenges - model architecture diversity, kernel primitive diversity, and hardware generation and architecture heterogeneity. This paper presents KernelEvolve-an agentic kernel coding framework-to tackle heterogeneity at-scale for DLRM. KernelEvolve is designed to take kernel specifications as input and automate the process of kernel generation and optimization for recommendation model across heterogeneous hardware architectures. KernelEvolve does so by operating at multiple programming abstractions, from Triton and CuTe DSL to low-level hardware agnostic languages, spanning the full hardware-software optimization stack. The kernel optimization process is described as graph-based search with selection policy, universal operator, fitness function, and termination rule, dynamically adapts to runtime execution context through retrieval-augmented prompt synthesis. We designed, implemented, and deployed KernelEvolve to optimize a wide variety of production recommendation models across generations of NVIDIA and AMD GPUs, as well as Meta's AI accelerators. We validate KernelEvolve on the publicly-available KernelBench suite, achieving 100% pass rate on all 250 problems across three difficulty levels, and 160 PyTorch ATen operators across three heterogeneous hardware platforms, demonstrating 100% correctness. KernelEvolve reduces development time from weeks to hours and achieves substantial performance improvements over PyTorch baselines across diverse production use cases and for heterogeneous AI systems at-scale. Beyond performance efficiency improvements, KernelEvolve significantly mitigates the programmability barrier for new AI hardware by enabling automated kernel generation for in-house developed AI hardware.

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 16 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. FastKernels: Benchmarking GPU Kernel Generation in Production

    cs.LG 2026-05 conditional novelty 8.0

    FastKernels is a production-aligned benchmark covering 96.2% of HuggingFace Transformers that reveals state-of-the-art kernel agents deliver at most 0.94x aggregate speedup.

  2. Optimizing CUDA like a Human: Micro-Profiling Tools as Expert Surrogates for LLM-Based GPU Kernel Optimization

    cs.LG 2026-06 conditional novelty 7.0

    KernelPro combines LLM code generation, roofline-guided tool orchestration, and domain-adapted MCTS to produce GPU kernels that outperform prior automated and some hand-tuned baselines on KernelBench and VeOmni workloads.

  3. PassNet: Scaling Large Language Models for Graph Compiler Pass Generation

    cs.AI 2026-05 unverdicted novelty 7.0

    PassNet provides a dataset of 18K graphs and PassBench for LLM-generated compiler passes, with fine-tuned models achieving 2.67x gains on long-tail tasks where TorchInductor underperforms.

  4. From Human Guidance to Autonomy: Agent Skill System for End-to-End LLM Deployment on Spatial NPUs

    cs.LG 2026-05 conditional novelty 7.0

    A two-stage agent skill system enables autonomous end-to-end deployment of eight decoder-only LLMs on AMD XDNA 2 NPU with numerical correctness in 0.5-4 hours each, generalizing from a human-guided Llama-3.2-1B reference.

  5. Autopoiesis: A Self-Evolving System Paradigm for LLM Serving Under Runtime Dynamics

    cs.DC 2026-04 unverdicted novelty 7.0

    Autopoiesis uses LLM-driven program synthesis to evolve serving policies online during deployment, delivering up to 53% and average 34% gains over prior LLM serving systems under runtime dynamics.

  6. AtumAI: A Principled Framework for Agentic Generation of Datacenter Control-Plane Policies

    cs.AI 2026-08 conditional novelty 6.0

    AtumAI compiles plain-language goals into a formal search problem and uses an LLM-plus-evolution loop to generate datacenter control-plane policies that beat hand-tuned baselines in simulation.

  7. Experience Graphs: The Data Foundation for Self-Improving Agents

    cs.DB 2026-06 unverdicted novelty 6.0

    Trellis treats agent experience graphs as first-class database state so that search patterns become queries, enabling crash recovery, scaling, and closed-loop training as architectural byproducts.

  8. Evolution Fine-Tuning: Learning to Discover Across 371 Optimization Tasks

    cs.CL 2026-06 unverdicted novelty 6.0

    Evolution Fine-Tuning trains LLMs on 156K trajectories spanning 371 tasks to achieve 10.22% average improvement on 22 held-out optimization tasks and match SOTA on select circle-packing problems when combined with tes...

  9. MKEvolve: A Modular Multi-Agent Framework for Kernel Code Generation

    cs.AI 2026-06 conditional novelty 6.0

    MKEvolve iteratively co-evolves a modular decomposition of PyTorch modules and per-subkernel Triton implementations, improving KernelBench L2/L3 correctness and speedup while cutting LLM tokens by up to 35%.

  10. SpecGen: Accelerating Agentic Kernel Optimization with Speculative Generation

    cs.DC 2026-06 unverdicted novelty 6.0

    SpecGen introduces speculative generation to fork non-reasoning kernel candidates during LLM reasoning traces, enabling early termination and parallel profiling to reduce end-to-end optimization time on H200 GPUs.

  11. JAXBench: Benchmarking Autonomous TPU Kernel Optimization

    cs.AI 2026-05 conditional novelty 6.0

    On a new 50-workload TPU benchmark (JAXBench), documentation-conditioned LLM agents reach 37.3% per-sample correctness and 1.28-1.36x geomean speedups over XLA, with curated context beating model scale.

  12. Agentic Discovery of Neural Architectures: AIRA-Compose and AIRA-Design

    cs.AI 2026-05 unverdicted novelty 6.0

    Multi-agent LLM systems discover new Transformer and hybrid architectures that outperform Llama 3.2 at 1B scale and approach human SOTA on long-range benchmarks.

  13. DITRON: Distributed Multi-level Tiling Compiler for Parallel Tensor Programs

    cs.PL 2026-05 unverdicted novelty 6.0

    DITRON introduces a hierarchical multi-level tiling compiler for distributed tensor programs that matches or exceeds expert CUDA libraries with 6-30% speedups and has been deployed to improve training MFU by over 10% ...

  14. Compiler-Grounded Hierarchical Diagnosis for LLM-Based Triton Kernel Optimization

    cs.AI 2026-07 conditional novelty 5.0

    A hierarchical, compiler-grounded LLM optimization loop reports 4.35x geometric-mean Triton kernel speedups on 37 Ascend NPU benchmark kernels, but with no causal ablation yet.

  15. Harness Engineering for LLM-Driven GPU Kernel Generation

    cs.LG 2026-07 conditional novelty 5.0

    A human-designed evaluation harness with a profile-backed controller lets LLM coding agents produce GPU kernels that beat FlashInfer baselines by up to 29.7x in a contest setting.

  16. AscendOptimizer: Episodic Agent for Ascend NPU Operator Optimization

    cs.LG 2026-03 unverdicted novelty 5.0

    AscendOptimizer combines kernel rewinding for reusable experience with evolutionary search on hardware feedback to optimize Ascend NPU operators, delivering 1.21x geometric-mean speedup and faster performance on 53.47...

Reference graph

Works this paper leans on

31 extracted references · 15 linked inside Pith · cited by 16 Pith papers

  1. [1]

    "" Generate test inputs for the conv1d benchmark. Returns: List of input tuples for benchmarking

    // BN return(gm, groups, gn) # Launch kernel conv1d_gemm_kernel[grid]( input_tensor, 59 weight_packed, bias_tensor, output, batch_size, in_channels, out_channels, input_length, output_length, groups, M, N, K, in_channels_per_group,# Cin_g as constexpr kernel_sz, stride, padding, dilation, has_bias, ) returnoutput classTritonModel(nn.Module): def__init__(s...

    2048

  2. [4]

    Evaluating large language models trained on code.arXiv preprint arXiv:2107.03374,

    Mark Chen. Evaluating large language models trained on code.arXiv preprint arXiv:2107.03374,

    Pith/arXiv arXiv

  3. [6]

    Corresponding authors: Aram Markosyan, Mark Saroufim

    https://huggingface.co/facebook/KernelLLM. Corresponding authors: Aram Markosyan, Mark Saroufim. Jonas Gehring, Kunhao Zheng, Jade Copet, Vegard Mella, Quentin Carbonneaux, Taco Cohen, and Gabriel Synnaeve. Rlef: Grounding code llms in execution feedback with reinforcement learning.arXiv preprint arXiv:2410.02089,

    Pith/arXiv arXiv

  4. [7]

    ISBN 978-1-939133-47-2

    USENIX Association. ISBN 978-1-939133-47-2. Anmol Gulati, James Qin, Chung-Cheng Chiu, Niki Parmar, Yu Zhang, Jiahui Yu, Wei Han, Shibo Wang, Zhengdong Zhang, Yonghui Wu, et al. Conformer: Convolution-augmented transformer for speech recognition.arXiv preprint arXiv:2005.08100,

    Pith/arXiv arXiv 2005

  5. [8]

    Alec M. Hammond, Aram Markosyan, Aman Dontula, Simon Mahns, Zacharias Fisches, Dmitrii Pedchenko, Keyur Muzumdar, Natacha Supper, Mark Saroufim, Joe Isaacson, Laura Wang, Warren Hunt, Kaustubh Gondkar, Roman Levenstein, Gabriel Synnaeve, Richard Li, Jacob Kahn, and Ajit Mathews. Agentic operator generation for ml asics, 2025.https://arxiv.org/abs/2512.109...

    arXiv 2025

  6. [11]

    Filescale: Fast and elastic metadata management for distributed file systems

    Gang Liao and Daniel J Abadi. Filescale: Fast and elastic metadata management for distributed file systems. In Proceedings of the 2023 ACM Symposium on Cloud Computing, pages 459–474,

    2023

  7. [12]

    Flock: A low-cost streaming query engine on faas platforms.arXiv preprint arXiv:2312.16735,

    Gang Liao, Amol Deshpande, and Daniel J Abadi. Flock: A low-cost streaming query engine on faas platforms.arXiv preprint arXiv:2312.16735,

    Pith/arXiv arXiv

  8. [14]

    Indexing code at scale with glean.Engineering at Meta, 2024.https://engineering

    Simon Marlow and Pepe Iborra. Indexing code at scale with glean.Engineering at Meta, 2024.https://engineering. fb.com/2024/12/19/developer-tools/glean-open-source-code-indexing/. 44 Meta. Pytorch profiler.Pytorch at Meta,

    2024

  9. [16]

    doi: 10.14778/3476311.3476374

    ISSN 2150-8097. doi: 10.14778/3476311.3476374. https: //doi.org/10.14778/3476311.3476374. Deepak Nathani, Lovish Madaan, Nicholas Roberts, Nikolay Bashlykov, Ajay Menon, Vincent Moens, Amar Budhiraja, Despoina Magka, Vladislav Vorotilov, Gaurav Chaurasia, et al. Mlgym: A new framework and benchmark for advancing ai research agents.arXiv preprint arXiv:2502.14499,

    arXiv

  10. [17]

    Deep learning recommendation model for personalization and recommendation systems.arXiv preprint arXiv:1906.00091,

    Maxim Naumov, Dheevatsa Mudigere, Hao-Jun Michael Shi, Jianyu Huang, Narayanan Sundaraman, Jongsoo Park, Xiaodong Wang, Udit Gupta, Carole-Jean Wu, Alisson G Azzolini, et al. Deep learning recommendation model for personalization and recommendation systems.arXiv preprint arXiv:1906.00091,

    Pith/arXiv arXiv 1906

  11. [18]

    Alexander Novikov, Ngân V˜ u, Marvin Eisenberger, Emilien Dupont, Po-Sen Huang, Adam Zsolt Wagner, Sergey Shirobokov, Borislav Kozlovskii, Francisco J. R. Ruiz, Abbas Mehrabian, M. Pawan Kumar, Abigail See, Swarat Chaudhuri, George Holland, Alex Davies, Sebastian Nowozin, Pushmeet Kohli, and Matej Balog. Alphaevolve: A coding agent for scientific and algo...

    Pith/arXiv arXiv 2025

  12. [19]

    https://docs.nvidia.com/nsight-compute/ NsightComputeCli/index.html. NVIDIA. Introduction to cute dsl. 2025.https://docs.nvidia.com/cutlass/latest/media/docs/pythonDSL/cute_ dsl_general/dsl_introduction.html. OpenAI. Introduction to gluon

    2025

  13. [20]

    Anne Ouyang, Simon Guo, Simran Arora, Alex L Zhang, William Hu, Christopher Ré, and Azalia Mirhoseini

    https://github.com/triton-lang/triton/blob/main/python/tutorials/ gluon/01-intro.py. Anne Ouyang, Simon Guo, Simran Arora, Alex L Zhang, William Hu, Christopher Ré, and Azalia Mirhoseini. Kernelbench: Can llms write efficient gpu kernels?arXiv preprint arXiv:2502.10517,

    Pith/arXiv arXiv

  14. [21]

    Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Romain Sauvestre, Tal Remez, et al

    https://engineering.fb.com/2024/11/19/data-infrastructure/ sequence-learning-personalized-ads-recommendations/. Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Romain Sauvestre, Tal Remez, et al. Code llama: Open foundation models for code.arXiv preprint arXiv:2308.12950,

    Pith/arXiv arXiv 2024

  15. [22]

    Scaling llm test-time compute optimally can be more effective than scaling model parameters.arXiv preprint arXiv:2408.03314,

    Charlie Snell, Jaehoon Lee, Kelvin Xu, and Aviral Kumar. Scaling llm test-time compute optimally can be more effective than scaling model parameters.arXiv preprint arXiv:2408.03314,

    Pith/arXiv arXiv

  16. [23]

    https://storage.googleapis.com/deepmind-media/ AlphaCode2/AlphaCode2_Tech_Report.pdf. FAIR CodeGen team, Jade Copet, Quentin Carbonneaux, Gal Cohen, Jonas Gehring, Jacob Kahn, Jannik Kossen, Felix Kreuk, Emily McMilin, Michel Meyer, Yuxiang Wei, David Zhang, Kunhao Zheng, Jordi Armengol-Estapé, Pedram Bashiri, Maximilian Beck, Pierre Chambon, Abhishek Cha...

    arXiv 2025

  17. [24]

    Miller, Abhishek Charnalia, Derek Dunfield, Carole-Jean Wu, Pontus Stenetorp, Nicola Cancedda, Jakob Nicolaus Foerster, and Yoram Bachrach

    Edan Toledo, Karen Hambardzumyan, Martin Josifoski, Rishi Hazra, Nicolas Baldwin, Alexis Audran-Reiss, Michael Kuchnik, Despoina Magka, Minqi Jiang, Alisia Maria Lupidi, Andrei Lupu, Roberta Raileanu, Kelvin Niu, Tatiana Shavrina, Jean-Christophe Gagnon-Audet, Michael Shvartsman, Shagun Sodhani, Alexander H. Miller, Abhishek Charnalia, Derek Dunfield, Car...

    arXiv

  18. [25]

    Catransformers: Carbon aware transformers through joint model-hardware optimization, 2025a.https://arxiv.org/abs/2505.01386

    Irene Wang, Newsha Ardalani, Mostafa Elhoushi, Daniel Jiang, Samuel Hsia, Ekin Sumbul, Divya Mahajan, Carole-Jean Wu, and Bilge Acun. Catransformers: Carbon aware transformers through joint model-hardware optimization, 2025a.https://arxiv.org/abs/2505.01386. Jianghui Wang, Vinay Joshi, Saptarshi Majumder, Xu Chao, Bin Ding, Ziqiong Liu, Pratik Prabhanjan ...

    arXiv 2025

  19. [26]

    Tritonrl: Training llms to think and code triton without cheating.arXiv preprint arXiv:2510.17891,

    Jiin Woo, Shaowei Zhu, Allen Nie, Zhen Jia, Yida Wang, and Youngsuk Park. Tritonrl: Training llms to think and code triton without cheating.arXiv preprint arXiv:2510.17891,

    arXiv

  20. [27]

    Lee, Bugra Akyildiz, Maximilian Balandat, Joe Spisak, Ravi Jain, Mike Rabbat, and Kim Hazelwood

    Carole-Jean Wu, Ramya Raghavendra, Udit Gupta, Bilge Acun, Newsha Ardalani, Kiwan Maeng, Gloria Chang, Fiona Aga Behram, James Huang, Charles Bai, Michael Gschwind, Anurag Gupta, Myle Ott, Anastasia Melnikov, Salvatore Candido, David Brooks, Geeta Chauhan, Benjamin Lee, Hsien-Hsin S. Lee, Bugra Akyildiz, Maximilian Balandat, Joe Spisak, Ravi Jain, Mike Ra...

    Pith/arXiv arXiv 2022

  21. [28]

    Dhen: A deep and hierarchical ensemble network for large-scale click-through rate prediction

    Buyun Zhang, Liang Luo, Xi Liu, Jay Li, Zeliang Chen, Weilin Zhang, Xiaohan Wei, Yuchen Hao, Michael Tsang, Wenjun Wang, et al. Dhen: A deep and hierarchical ensemble network for large-scale click-through rate prediction. arXiv preprint arXiv:2203.11014,

    Pith/arXiv arXiv

  22. [29]

    Wukong: Towards a scaling law for large-scale recommendation.arXiv preprint arXiv:2403.02545,

    Buyun Zhang, Liang Luo, Yuxin Chen, Jade Nie, Xi Liu, Daifeng Guo, Yanli Zhao, Shen Li, Yuchen Hao, Yantao Yao, et al. Wukong: Towards a scaling law for large-scale recommendation.arXiv preprint arXiv:2403.02545,

    Pith/arXiv arXiv

  23. [30]

    cuda"):

    Guorui Zhou, Jiaxin Deng, Jinghao Zhang, Kuo Cai, Lejian Ren, Qiang Luo, Qianqian Wang, Qigen Hu, Rui Huang, Shiyao Wang, et al. Onerec technical report.arXiv preprint arXiv:2506.13695, 2025a. Guorui Zhou, Hengrui Hu, Hongtao Cheng, Huanjie Wang, Jiaxin Deng, Jinghao Zhang, Kuo Cai, Lejian Ren, Lu Ren, Liao Yu, et al. Onerec-v2 technical report.arXiv prep...

    arXiv 2025

  24. [200]

    cuda" ) print(

    # Use torch.float32 to match production data dtype input_full, weight_tensor, bias_tensor = generate_synthetic_production_data( dtype=torch.float32, device="cuda" ) print("Generated synthetic production data:") print(f" Input shape: {input_full.shape}, dtype: {input_full.dtype}") print(f" Weight shape: {weight_tensor.shape}, dtype: {weight_tensor.dtype}")...

    2048

  25. [2006]

    Mlir: A compiler infrastructure for the end of moore’s law

    Chris Lattner, Mehdi Amini, Uday Bondhugula, Albert Cohen, Andy Davis, Jacques Pienaar, River Riddle, Tatiana Shpeisman, Nicolas Vasilache, and Oleksandr Zinenko. Mlir: A compiler infrastructure for the end of moore’s law. arXiv preprint arXiv:2002.11054,

    Pith/arXiv arXiv 2002

  26. [2017]

    Deepgemm.github, 2025.https://github.com/deepseek-ai/DeepGEMM

    DeepSeek. Deepgemm.github, 2025.https://github.com/deepseek-ai/DeepGEMM. Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schelten, Amy Yang, Angela Fan, et al. The llama 3 herd of models.arXiv e-prints, pages arXiv–2407,

    2025

  27. [2019]

    Gevo-ml: a proposal for optimizing ml code with evolutionary computation

    Jhe-Yu Liou, Xiaodong Wang, Stephanie Forrest, and Carole-Jean Wu. Gevo-ml: a proposal for optimizing ml code with evolutionary computation. InProceedings of the 2020 Genetic and Evolutionary Computation Conference Companion, GECCO ’20, page 1849–1856, 2020a. Jhe-Yu Liou, Xiaodong Wang, Stephanie Forrest, and Carole-Jean Wu. Gevo: Gpu code optimization us...

    2020

  28. [2021]

    https://docs.pytorch.org/tutorials/recipes/recipes/profiler_ recipe.html. Meta. Our next-generation meta training and inference accelerator.Meta AI blog, 2024.https://ai.meta.com/blog/ next-generation-meta-training-inference-accelerator-AI-MTIA/. Meta. Tritonbench.Pytorch at Meta, 2025a.https://github.com/meta-pytorch/tritonbench. Meta. Tlx - triton low-l...

    2024

  29. [2022]

    Autotriton: Automatic triton programming with reinforcement learning in llms.arXiv preprint arXiv:2507.05687,

    Shangzhan Li, Zefan Wang, Ye He, Yuxuan Li, Qi Shi, Jianling Li, Yonggang Hu, Wanxiang Che, Xu Han, Zhiyuan Liu, et al. Autotriton: Automatic triton programming with reinforcement learning in llms.arXiv preprint arXiv:2507.05687,

    Pith/arXiv arXiv

  30. [2023]

    Kevin: Multi-turn rl for generating cuda kernels.arXiv preprint arXiv:2507.11948,

    Carlo Baronio, Pietro Marsella, Ben Pan, Simon Guo, and Silas Alberti. Kevin: Multi-turn rl for generating cuda kernels.arXiv preprint arXiv:2507.11948,

    Pith/arXiv arXiv

  31. [2024]

    Anthropic

    https://www.anthropic.com/ news/model-context-protocol. Anthropic. Effective context engineering for ai agents.Engineering at Anthropic, 2025.https://www.anthropic.com/ engineering/effective-context-engineering-for-ai-agents. Andrew Audibert, Yang Chen, Dan Graur, Ana Klimovic, Jiří Šimša, and Chandramohan A Thekkath. tf. data service: A case for disaggre...

    2025