Pith. sign in

REVIEW 3 major objections 4 minor 1 cited by

NPUEval: Optimizing NPU Kernels with LLMs and Open Source Compilers

T0 review · 3 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read NPUEval is a benchmark that measures LLM-generated NPU kernels on real hardware and reports only about 10% average vectorization for frontier models.

desk verdict Useful first benchmark for NPU kernel generation, but the headline vectorization claim needs per-kernel reference ceilings before it shows LLMs are bad at vectorization. read the letter →

arxiv 2507.14403 v1 pith:5K24PZ4N submitted 2025-07-18 cs.PL

Sarunas Kalade , Graham Schelle This is my paper
classification cs.PL
keywords NPUkernelgenerationLLMcodebenchmarkvectorizationscoreAIEnginecompilerfeedbackretrieval-augmentedcorrectnessevaluationAMD
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

NPUEval is a benchmark of 102 common machine-learning operators written as AMD AI Engine kernel prompts, evaluated on real NPU hardware through an open-source compiler stack. The paper's central claim is that frontier LLMs, even when given compiler error feedback and retrieved vectorized examples, average only about 10% on its vectorization score, making NPU kernel optimization a hard and meaningful open problem. A few kernels do reach above 50% vectorization with out-of-the-box reasoning models, showing partial latent knowledge of NPU programming. If the benchmark is right, it gives the field a reproducible target and exposes a clear gap between functionally correct code generation and hardware-efficient code generation.

What carries the argument

The load-bearing object is the vectorization score, defined as the fraction of total NPU cycles spent executing vector instructions on the AIE vector processing unit, measured cycle-accurately on real hardware; kernels that fail functional tests count as zero. The supporting machinery is the evaluation harness built from NumPy behavioral models, including ml_dtypes for bfloat16, the LLVM-AIE compiler with up to ten feedback-retry iterations, MLIR-AIE for graph and data-movement configuration, and a retrieval-augmented generation pipeline that supplies open-source vectorized kernel examples.

What would settle it

Re-run the 102 kernel prompts with tightened correctness tolerances (for example 1e-3) and compare vectorization scores against measured wall-clock throughput; if many previously passing kernels fail under stricter tolerances, or if high vectorization scores do not track faster execution, the reported LLM capability numbers would be misleading.

Watch

Extended reading notes

Core claim

The paper introduces NPUEval as, to its knowledge, the first benchmark for evaluating LLMs on vectorized NPU kernel generation, and reports that state-of-the-art LLMs achieve only roughly 10% average vectorization across all 102 kernels, with any kernel that fails functional correctness scored as zero. Functional pass rates improve substantially with recompilation, reaching 60-70% for several models after five attempts, while vectorization stays low overall. The strongest out-of-the-box result comes from the DeepSeek R1 reasoning model, which exceeds 50% vectorization on selected kernels without retrieved examples; adding retriever-augmented examples improved most models but hurt R1 because the retrieved kernels used compiler-specific pragmas that LLVM-AIE ignores. The paper presents this gap as evidence that LLM-assisted NPU kernel optimization is still in its early stages.

Load-bearing premise

The benchmark's conclusions rest on the assumption that the vectorization score, the fraction of cycles spent on vector instructions, is a good proxy for kernel efficiency, and that correctness tolerances of 1e-2 to 3e-2 are strict enough to validate outputs.

Editorial extensions

If this is right

  • If the vectorization score is accepted as a proxy for kernel efficiency, frontier LLM output is far from production-ready for NPUs: the reported average is roughly 10%.
  • Compiler feedback materially improves functional pass rates for several models, so iterative recompilation should be a standard component in accelerator code benchmarks.
  • Smaller models more often write scalar code and pass functional tests, while stronger models attempt vectorization and hallucinate APIs; NPUEval can distinguish these failure modes.
  • Retrieval-augmented generation with vectorized examples raises average VPU utilization for most models, but can be counterproductive when retrieved examples use incompatible compiler pragmas.
  • The fully open-source stack runs on commodity laptops, so the benchmark can be reproduced and extended to other accelerator families.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The same prompt-and-behavioral-model methodology could be extended to other NPU or accelerator ISAs, with compiler-backend-specific retrieval as a first testable improvement.
  • The 10% average partly reflects a zero-score policy for any functionally failing kernel; pass@k or partial-credit scoring might produce different model rankings.
  • A direct wall-clock speedup study on end-to-end workloads would test whether the vectorization score truly predicts real efficiency rather than merely measuring VPU activity.
  • NPUEval could serve as a fine-tuning dataset for making LLMs fluent in NPU-specific APIs, not just as an evaluation set.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 4 minor

Summary. NPUEval introduces a benchmark for evaluating LLM-generated kernel code for AMD NPUs (AIE tiles), consisting of 102 common ML operators. The evaluation harness compiles generated C++ kernels with LLVM-AIE/MLIR-AIE, runs them on actual NPU hardware, checks functional correctness against NumPy behavioral models, and computes a vectorization score defined as the fraction of cycles spent on the VPU. The paper evaluates a range of proprietary and open-weight LLMs under zero-shot, compiler-feedback, and RAG conditions, reporting that average vectorization scores remain around 10% even with feedback and vectorized examples, while select kernels reach 50%+ scores. The authors position NPUEval as the first benchmark for LLM-based NPU kernel generation and plan to release the dataset and code.

Significance. If the empirical claims are robust, NPUEval fills a real gap: existing code-generation benchmarks emphasize functional correctness and GPU kernels, while NPU programming is fragmented and underrepresented in LLM training data. The paper's strengths include evaluation on real hardware with an open-source compiler stack, a relatively large operator set (102 kernels), and a detailed failure analysis with concrete examples. The result that frontier LLMs achieve only modest vectorization on specialized NPU kernels is a useful data point for the community. However, the central quantitative claim is currently weakened by an uncalibrated performance metric, potential confounds between correctness and vectorization scoring, and the absence of public code/data. The paper would be much stronger with per-kernel reference ceilings, a normalized or conditional metric, and a released artifact.

major comments (3)
  1. [Section 6.3, Appendix A, Section 7] The vectorization score (VPU cycles / total cycles) is not calibrated against per-kernel reference implementations. The paper's own reference vectorized kernels achieve only 13% (eltwise_add_bf16_vector, Listing 1) and 30% (conv2dk1_i8_vector, Listing 2), and Section 7 states that state-of-the-art open-source kernels 'typically see a vectorization factor of 10-30%'. An LLM average of roughly 10% therefore sits near the bottom of the reference range rather than clearly below it. Without per-kernel reference vectorization scores for all 102 operators, the headline claim that current LLMs 'struggle' at NPU vectorization is not quantitatively established. Please report reference scalar and vectorized scores per kernel, or normalize the metric by the observed reference ceiling, and discuss the distribution of attainable scores.
  2. [Section 6.3] Scoring kernels that fail functional tests as 0% conflates correctness failure with vectorization performance. Because functional pass rates in Table 1 are well below 100% for most models (e.g., 20-70% even after recompilation), the average vectorization scores in Figure 5 are depressed by correctness failures rather than reflecting the VPU utilization of the generated code. Please report vectorization scores separately for functionally passing kernels, or present correctness and vectorization as two independent axes, to avoid attributing a correctness failure to a vectorization failure.
  3. [Section 3.2.2] The correctness tolerances of 1e-2 to 3e-2 absolute error are quite loose, and the paper does not justify these thresholds per operator or provide a sensitivity analysis. Since functional correctness is one of the two primary benchmark axes and failing kernels are assigned a 0% vectorization score, the interaction between loose tolerances and the reported scores should be quantified. Please show how many kernels pass or fail when the tolerance is tightened (e.g., 1e-3), or provide per-operator reasoning for the chosen thresholds.
minor comments (4)
  1. [Figure 6 caption] The caption lists the examples in an order that does not match the figure. Figure 6a is GPT-4o (scalar loop), 6b is Llama-3.1-70b (hallucinated API), and 6c is Claude 3.7 Sonnet (scalar loop with conditional), but the caption states 'scalar loop with conditional (claude-3-7-sonnet), incomplete vectorization (gpt-4o), and hallucinated API usage (llama-3.1-70b)', which is inconsistent.
  2. [Appendix B] The word 'grevious' should be 'grievous' in the sentence discussing the effect of omitting dataflow information.
  3. [Abstract / Section 7] The paper states that the dataset and evaluation code 'will be released', but no link or public artifact is provided. For a benchmark paper, an anonymous or persistent repository link would substantially aid reproducibility and community adoption.
  4. [Section 6] All performance results appear to be based on single hardware runs with greedy decoding. The paper notes this in Section 7, but adding variance information (e.g., repeated runs or pass@k for at least a subset of models) would strengthen the quantitative claims.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: NPUEval is an empirical benchmark whose headline results are measured against external behavioral models and on-hardware cycle counts, not derived from its own assumptions.

full rationale

NPUEval is an empirical benchmark, not a derivation. The headline quantities (functional pass rates and vectorization scores) are obtained by compiling LLM-generated kernels with the LLVM-AIE compiler, running them on AMD NPU hardware, and comparing outputs to NumPy/ ml_dtypes behavioral models plus hardware cycle counts. Nothing in the paper fits a parameter to the benchmark's own conclusions. The behavioral models are defined from the kernel specifications before evaluation, and the vectorization score is measured as VPU cycles over total cycles (Section 6.3), an observed ratio rather than a constructed equivalence. The RAG database and compiler are AMD-authored open-source tools, but this is a tooling choice: LLM outputs are still checked against external ground truth, so no result reduces to a self-citation. The most serious concern, flagged by the reviewer and visible in the paper itself, is metric calibration: Appendix A reports reference vectorized kernels scoring only 13% (eltwise_add_bf16_vector) and 30% (conv2dk1_i8_vector), and Section 7 concedes that current SoTA is 'not higher than 30%, though this will be highly kernel dependent,' so the ~10% LLM average sits near the reference floor rather than clearly below it. This is a validity/interpretability weakness, not circularity: the score is still measured, not defined into the conclusion. Similarly, the loose tolerances in Section 3.2.2 could overstate correctness, but the tolerance choice is an evaluation parameter, not a quantity that makes the result equivalent to the input. The 'first benchmark' claim is hedged with 'to our knowledge' and does not invoke a uniqueness theorem. No load-bearing step in the paper's argument reduces to its own inputs by definition or by fitted-input renaming, so the appropriate finding is no circularity.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

The benchmark's claims rest on the choice of evaluation metrics, tolerances, and dataset composition. These are all stated explicitly, but none are independently validated against external standards. The paper does not introduce new theoretical entities.

free parameters (2)
  • Correctness error tolerances = 1e-2, 2e-2, 3e-2
    Chosen by the authors to give LLMs leeway in floating point comparisons; these thresholds directly affect functional pass rates and are not derived from any external standard.
  • Maximum recompilation attempts = 10 (results reported up to 5)
    Protocol choice that affects the reported pass rates; the paper notes diminishing returns after ten attempts.
assumptions (4)
  • domain assumption Vectorization score (fraction of cycles on the VPU) is a good proxy for kernel efficiency.
    Section 6.3 states 'While not perfect, this is a good proxy for how well the kernel is utilizing the VPU.' The entire performance analysis relies on this metric.
  • domain assumption Functional correctness against NumPy behavioral models with specified error tolerances is a valid measure of kernel correctness.
    Section 3.2.2 and Section 4 define correctness in this way, acknowledging that floating point implementations may differ.
  • domain assumption The 102 operators in the dataset are representative of common ML workloads on NPUs.
    Section 3 states the dataset consists of '102 common operators for machine learning workloads' without a formal sampling or validation procedure.
  • domain assumption The open source LLVM-AIE compiler and MLIR-AIE toolchain produce results representative of production NPU programming.
    Section 4.1 uses these tools for evaluation, and Section 7 acknowledges that results are specific to one compiler backend.

how reviews work

0 comments
Cite this review

Pith. "Pith review of NPUEval: Optimizing NPU Kernels with LLMs and Open Source Compilers." pith.science (2026). https://pith.science/paper/5K24PZ4N

@misc{pith2026250714403,
  author       = {Pith},
  title        = {Pith review of: NPUEval: Optimizing NPU Kernels with LLMs and Open Source Compilers},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/5K24PZ4N}},
  note         = {Machine review of arXiv:2507.14403}
}
read the original abstract

Neural processing units (NPUs) are gaining prominence in power-sensitive devices like client devices, with AI PCs being defined by their inclusion of these specialized processors. Running AI workloads efficiently on these devices requires libraries of optimized kernels. Creating efficient kernels demands expertise in domain-specific C++ with vector intrinsics and in-depth knowledge of the target architecture. Unlike GPU programming, which has had years to mature, NPU programming is new, with smaller and more fragmented developer communities across hardware platforms. This fragmentation poses a challenge when utilizing LLMs to assist in writing NPU kernels, as domain-specific optimized code examples are underrepresented in LLM pre-training data. In this paper we introduce NPUEval -- a benchmark for writing and evaluating NPU kernels, consisting of 102 common operators for machine learning workloads. We evaluate LLM generated code on actual hardware based on both functional correctness and vectorization efficiency using open source compiler tools targeting the AMD NPU. We evaluate a range of state-of-the-art LLMs with a mix of proprietary and open-weight models. Latest reasoning models like DeepSeek R1, show promising results achieving out-of-the-box 50%+ vectorization on select kernels. However, the average score across the entire dataset remains roughly 10% even with compiler feedback and vectorized kernel examples -- showing that this is a challenging dataset even for frontier models. The dataset and evaluation code will be released with a permissive open source license, providing an essential benchmark for advancing research in code generation and NPU kernel optimization.

Figures

Figures reproduced from arXiv: 2507.14403 by the authors.

Figure 1
Figure 1. Simple example of vectorizing a passthrough kernel [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Sample prompt from the NPUEval dataset. 3.1 Structure Each kernel in the dataset will have the following components: • Prompt - HumanEval inspired prompts containing a basic explanation of what the kernel does and function signature. • Data movement information - specifying the data sizes coming in and out of the tile. • Behavioral model - NumPy-based Python implementation of the target kernel. • (Optional) Canonica… view at source ↗
Figure 3
Figure 3. Overview of NPUEval evaluation pipeline. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Zero shot results (ranked from top to bottom) [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: While the scores seem very low it should be noted that SoTA open source kernels[ [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 5
Figure 5. Figure 5: Vectorization results To guide model responses towards vectorized code we introduced vectorized kernel RAG into the code generation pipeline. Introducing RAG composed of openly available AIE kernels into the prompts improved VPU utilization across the board, with GPT-4…
Figure 6
Figure 6. Figure 6: Examples of LLM errors in vectorized kernel generation: scalar loop with conditional [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: Simple example of vectorizing a passthrough kernel. [PITH_FULL_IMAGE:figures/full_fig_p017_7.png]
Figure 8
Figure 8. Figure 8: Number of compiler iterations vs pass rate. [PITH_FULL_IMAGE:figures/full_fig_p018_8.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

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

  1. Towards Automated Kernel Generation in the Era of LLMs

    cs.LG 2026-01 conditional novelty 4.0 of 10

    A structured survey of LLM-based and agentic approaches for GPU kernel generation, plus a catalog of datasets and benchmarks for the field.

Reference graph

Works this paper leans on

28 extracted references · 21 canonical work pages · cited by 1 Pith paper

  1. [1]

    Evaluating large language models trained on code

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

    arXiv 2021

  2. [2]

    Program synthesis with large language models

    Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le, et al. Program synthesis with large language models. arXiv preprint arXiv:2108.07732, 2021

    arXiv 2021

  3. [3]

    Is your code generated by chatgpt really correct? rigorous evaluation of large language models for code generation, 2023

    Jiawei Liu, Chunqiu Steven Xia, Yuyao Wang, and Lingming Zhang. Is your code generated by chatgpt really correct? rigorous evaluation of large language models for code generation, 2023

    2023

  4. [4]

    Multipl- e: a scalable and polyglot approach to benchmarking neural code generation

    Federico Cassano, John Gouwar, Daniel Nguyen, Sydney Nguyen, Luna Phipps-Costin, Donald Pinckney, Ming-Ho Yee, Yangtian Zi, Carolyn Jane Anderson, Molly Q Feldman, et al. Multipl- e: a scalable and polyglot approach to benchmarking neural code generation. IEEE Transactions on Software Engineering, 49(7):3675–3691, 2023

    work page 2023

  5. [5]

    Mceval: Massively multilingual code evaluation, 2024

    Linzheng Chai, Shukai Liu, Jian Yang, Yuwei Yin, Ke Jin, Jiaheng Liu, Tao Sun, Ge Zhang, Changyu Ren, Hongcheng Guo, Zekun Wang, Boyang Wang, Xianjie Wu, Bing Wang, Tongliang Li, Liqun Yang, Sufeng Duan, and Zhoujun Li. Mceval: Massively multilingual code evaluation, 2024

    work page 2024

  6. [6]

    Evaluation of llms on syntax-aware code fill-in-the-middle tasks

    Linyuan Gong, Sida Wang, Mostafa Elhoushi, and Alvin Cheung. Evaluation of llms on syntax-aware code fill-in-the-middle tasks. arXiv preprint arXiv:2403.04814, 2024

    arXiv 2024

  7. [7]

    Evocodebench: An evolving code generation benchmark aligned with real-world code repositories, 2024

    Jia Li, Ge Li, Xuanming Zhang, Yihong Dong, and Zhi Jin. Evocodebench: An evolving code generation benchmark aligned with real-world code repositories, 2024

    work page 2024

  8. [8]

    Bigcodebench: Bench- marking code generation with diverse function calls and complex instructions

    Terry Yue Zhuo, Minh Chien Vu, Jenny Chim, Han Hu, Wenhao Yu, Ratnadira Widyasari, Imam Nur Bani Yusuf, Haolan Zhan, Junda He, Indraneil Paul, et al. Bigcodebench: Bench- marking code generation with diverse function calls and complex instructions. arXiv preprint arXiv:2406.15877, 2024

    arXiv 2024

Show all 28 references
  1. [9]

    Swe-bench: Can language models resolve real-world github issues? arXiv preprint arXiv:2310.06770, 2023

    Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. Swe-bench: Can language models resolve real-world github issues? arXiv preprint arXiv:2310.06770, 2023

    2023 arXiv

  2. [10]

    Claude 3.7 sonnet and claude code, https://www.anthropic.com/news/claude-3- 7-sonnet

    Anthropic PBC. Claude 3.7 sonnet and claude code, https://www.anthropic.com/news/claude-3- 7-sonnet

  3. [11]

    AMD XDNA

    Advanced Micro Devices (AMD). AMD XDNA. https://www.amd.com/en/ technologies/xdna.html

  4. [12]

    Apple Neural Engine

    Apple Inc. Apple Neural Engine. https://en.wikipedia.org/wiki/Apple_Neural_ Engine

  5. [13]

    Huawei Technologies Co

    Ltd. Huawei Technologies Co. Ascend ai processor, https://e.huawei.com/en/products/computing/ascend

  6. [14]

    Intel neural processor, https://intel.github.io/intel-npu-acceleration- library/npu.html

    Intel Corporation. Intel neural processor, https://intel.github.io/intel-npu-acceleration- library/npu.html

  7. [15]

    Samsung neural processing unit, https://semiconductor.samsung.com/support/tools-resources/dictionary/the-neural-processing- unit-npu-a-brainy-next-generation-semiconductor/

    Samsung Electronics. Samsung neural processing unit, https://semiconductor.samsung.com/support/tools-resources/dictionary/the-neural-processing- unit-npu-a-brainy-next-generation-semiconductor/. 10

  8. [16]

    Qualcomm Technologies

    Inc. Qualcomm Technologies. Hexagon processor, https://en.wikipedia.org/wiki/qualcomm_hexagon

  9. [17]

    Zhang, William Hu, Christopher Ré, and Azalia Mirhoseini

    Anne Ouyang, Simon Guo, Simran Arora, Alex L. Zhang, William Hu, Christopher Ré, and Azalia Mirhoseini. Kernelbench: Can llms write efficient gpu kernels?, 2025

    2025

  10. [18]

    The ai cuda engineer: Agentic cuda kernel discovery, optimization and composition

    Robert Tjarko Lange, Aaditya Prasad, Qi Sun, Maxence Faldor, Yujin Tang, and David Ha. The ai cuda engineer: Agentic cuda kernel discovery, optimization and composition. 2025

    2025

  11. [19]

    Tritonbench: Benchmarking large language model capabilities for generating triton operators, 2025

    Jianling Li, Shangzhan Li, Zhenye Gao, Qi Shi, Yuxuan Li, Zefan Wang, Jiacheng Huang, Haojie Wang, Jianrong Wang, Xu Han, Zhiyuan Liu, and Maosong Sun. Tritonbench: Benchmarking large language model capabilities for generating triton operators, 2025

    2025

  12. [20]

    Efficiency, expressivity, and extensibility in a close-to-metal npu programming interface, 2025

    Erika Hunhoff, Joseph Melber, Kristof Denolf, Andra Bisca, Samuel Bayliss, Stephen Neuen- dorffer, Jeff Fifield, Jack Lo, Pranathi Vasireddy, Phil James-Roxby, and Eric Keller. Efficiency, expressivity, and extensibility in a close-to-metal npu programming interface, 2025

    2025

  13. [21]

    A stand-alone implementation of several NumPy dtype extensions used in machine learning, https://github.com/jax-ml/ml_dtypes, 2025

    Google. A stand-alone implementation of several NumPy dtype extensions used in machine learning, https://github.com/jax-ml/ml_dtypes, 2025

    2025

  14. [22]

    Fork of LLVM to support AMD AIEngine processors, https://github.com/Xilinx/mlir-aie, 2024

    AMD. Fork of LLVM to support AMD AIEngine processors, https://github.com/Xilinx/mlir-aie, 2024

    2024

  15. [23]

    Developing a blas library for the amd ai engine, 2024

    Tristan Laan and Tiziano De Matteis. Developing a blas library for the amd ai engine, 2024

    2024

  16. [24]

    Versal VCK190 Evaluation Board, 2025

    AMD. Versal VCK190 Evaluation Board, 2025. Accessed: 2025-03-13

    2025

  17. [25]

    An MLIR-based toolchain for AMD AI engine-enabled devices, https://github.com/Xilinx/llvm-aie, 2024

    AMD. An MLIR-based toolchain for AMD AI engine-enabled devices, https://github.com/Xilinx/llvm-aie, 2024

    2024

  18. [26]

    An open-source exploration framework for first time users of the AMD Ryzen AI Neural Processing Unit, https://riallto.ai/, 2024

    AMD. An open-source exploration framework for first time users of the AMD Ryzen AI Neural Processing Unit, https://riallto.ai/, 2024

    2024

  19. [27]

    LlamaIndex, https://github.com/jerryjliu/llama_index, 2022

    Jerry Liu. LlamaIndex, https://github.com/jerryjliu/llama_index, 2022

    2022

  20. [28]

    Retrieval-augmented generation for large language models: A survey, 2024

    Yunfan Gao, Yun Xiong, Xinyu Gao, Kangxiang Jia, Jinliu Pan, Yuxi Bi, Yi Dai, Jiawei Sun, Meng Wang, and Haofen Wang. Retrieval-augmented generation for large language models: A survey, 2024. 11 A Examples of vectorized kernels Here we provide example vectorized kernels availa...

    2024

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.