Pith. sign in

REVIEW 5 major objections 8 minor 1 cited by

Omniwise: Predicting GPU Kernels Performance with LLMs

T0 review · 5 major / 8 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 Omniwise fine-tunes a 3B-parameter LLM to predict GPU kernel performance counters directly from HIP source text, architecture, and compiler flags, reporting over 90% of predictions within 10% relative error.

desk verdict Promising LLM-for-GPU-kernels idea with a load-bearing evaluation flaw: the 90% accuracy claim is not established because the test set is drawn from the same generative pool as training, with no baselines or external validation. read the letter →

arxiv 2506.20886 v1 pith:2AYCI2GK submitted 2025-06-25 cs.LG cs.AI

Zixian Wang , Cole Ramos , Muhammad A. Awad , Keith Lowery This is my paper
classification cs.LGcs.AI
keywords GPUkernelLLMperformancepredictioncountersfine-tuningHIProoflineROCm
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

Omniwise aims to make GPU kernel profiling as fast as an editor keystroke by predicting hardware performance counters from source code alone, without running or instrumenting the kernel. The authors fine-tune a 3B-parameter open LLM (LLaMA 3.2 3B Instruct) on roughly 955,000 self-contained HIP kernels labeled with ROCm Compute Profiler counters measured on AMD MI250 and MI300X across different compiler flags. On a held-out test set of about 4,000 kernels, they report that over 90% of predicted counters fall within 10% relative error of ground truth, with arithmetic intensity the strongest at more than 99.8% within 2% error. The pipeline matters because traditional profiling can require replaying an application about 14 times to collect all counters, while a fine-tuned 3B model can be served on a laptop for real-time feedback.

What carries the argument

The central object is the training sample: a HIP kernel's source text plus a system prompt naming the architecture (gfx90a or MI300X) and compiler flags, paired with a JSON dictionary of normalized ROCm counters. Three mechanisms carry the argument: a three-source data generator (a synthetic kernel generator that creates data-dependency chains, GPT-4o prompted to produce kernels at different optimization levels, and hand-written kernels covering per-thread, tiled, and persistent programming patterns), a normalization scheme that divides each counter by its hardware ceiling so all labels live in a stable 0-1 scale, and LoRA fine-tuning of LLaMA 3.2 3B Instruct with a strict JSON output format to stabilize decoding. The effect is to convert performance profiling, normally a measurement task requiring execution and hardware expertise, into a text-to-JSON generation task that a small LLM can answer in a single forward pass.

What would settle it

Take a set of HIP kernels that were not produced by the paper's synthetic generator, GPT-4o prompts, or hand-written examples—for instance, production kernels from an unrelated codebase with varied problem sizes, data types, and external library calls—profile them with ROCm Compute Profiler, and compare with Omniwise's predictions; if far fewer than 90% of counters land within 10% relative error, the claimed accuracy does not extend beyond the paper's data distribution.

Watch

Extended reading notes

Core claim

The central claim is that a general-purpose LLM, adapted with a parameter-efficient fine-tuning method, can map a HIP kernel's source text, target architecture, and compiler flags to a vector of normalized performance counters well enough to substitute for hardware profiling in practical workflows. Concretely, the paper's fine-tuned LLaMA 3.2 3B model produces over 90% of its counter predictions within 10% relative error on the test set, and it is most accurate on arithmetic intensity (more than 99.8% within 2% error) and cache hit rates (over 94% within 10% error). Predictions are emitted as strict JSON objects covering cache hit rates, cache and HBM bandwidths, arithmetic intensity, and GFLOP/s at L1, L2, and HBM levels, normalized against hardware ceilings to keep values in a stable 0-1 range. This establishes a new application of LLMs: static, execution-free estimation of fine-grained GPU performance counters.

Load-bearing premise

The load-bearing assumption is that the roughly 4,000 test kernels, drawn from the same generated-and-curated pool as the training set, are representative of the GPU kernels developers will actually query; if real-world code differs in structure, problem size, data types, or library use, the 90% figure may not transfer.

Editorial extensions

If this is right

  • Developers get instant, per-kernel predictions of bandwidth, cache hit rate, arithmetic intensity, and GFLOP/s from an IDE extension, without compiling or launching the kernel first.
  • The repeated-execution cost of profiling disappears: the paper notes that collecting all counters in ROCm Compute Profiler can require replaying an application roughly 14 times.
  • Because the fine-tuned model has only 3B parameters and a 128K-token context window, it can run on a laptop, making this style of static performance feedback portable.
  • The pipeline is model-agnostic and language-agnostic in design, so the same recipe should transfer to other open LLMs and, the authors argue, to other programming languages and intermediate representations beyond HIP.
  • Predicted counters are reported for large problem sizes; the paper states that for other problem sizes users must reason about which counters are invariant.

Reading between the lines

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

  • An implication the paper leaves implicit is that the test set shares the same generation pipeline as training, so the 90% figure is evidence of learning those code styles more than of generalization to arbitrary production kernels; a stronger test would exclude entire generation sources or kernel families during training.
  • A practical consequence worth flagging: normalized metrics with ground truth near zero make relative error unstable, so on sparse counters users should expect occasional large relative errors even when absolute deviations are small.
  • A testable extension of the same machinery is to predict other hardware-derived labels such as register pressure, occupancy, or energy per instruction, and to use the compiler-flag conditioning to sweep flag combinations and pick the fastest variant without executing code.
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

5 major / 8 minor

Summary. The paper presents Omniwise, an end-to-end pipeline that fine-tunes a LLaMA 3.2 3B Instruct model to predict GPU performance counters (cache hit rates, bandwidths, arithmetic intensity, GFLOP/s) directly from HIP kernel source code, compiler flags, and target architecture, without execution or profiling. The model is trained on a dataset of approximately 955,000 kernels assembled from a synthetic generator, GPT-4o-generated code, and hand-written examples, then augmented by variable renaming, multiple compiler flags, and two GPU architectures (MI250, MI300X). The authors report that over 90% of predictions fall within 10% relative error on a test set of about 4,000 kernels, and they present a VS Code extension for serving the model.

Significance. If the claimed accuracy held on a representative sample of real-world GPU kernels, Omniwise would be a valuable tool for developers, providing near-real-time performance feedback without profiling overhead. The paper's strengths include a clear problem formulation, a reproducible fine-tuning recipe, and a practical serving infrastructure. However, the current evaluation does not establish the central claim because the test set is drawn from the same generation/augmentation pool as the training set, and no baselines are provided. The significance of the contribution therefore hinges on whether the evaluation can be strengthened.

major comments (5)
  1. [Section 4.1] Section 4.1 states that the test set of ~4,000 kernels was 'sampled from the entire pool of data described in Section 3.1, and no overlapping with the training set.' Because the pool is generated from a small number of sources (the synthetic generator in Listing 1, GPT-4o prompts from Listing 2, and hand-written kernels from Listing 3) and then augmented by random variable renaming, multiple compiler flags, and two architectures, 'no overlapping' is at best a string-level guarantee. A test kernel can be a renamed or flag-varied instance of a training kernel, and the 90% figure could reflect template memorization rather than learning to predict from code semantics. The authors need to quantify the number of distinct kernel templates, perform template-level deduplication, or evaluate on kernels drawn from a different distribution (e.g., real-world kernels) to support the generalization claim.
  2. [Section 4.1, Table 4] The evaluation reports only the fine-tuned model's accuracy with no comparison to baselines. Given the heavily skewed target distributions shown in Figures 4-8 (e.g., L1 hit rate concentrated near 0.55, bandwidths mostly near zero), a trivial predictor such as the training-set median or mean per metric may already achieve a substantial fraction of predictions within 10% relative error for low-variance metrics. Without at least a constant predictor, a roofline-based heuristic, and a simple linear model on hand-crafted features, the reported percentages are uninterpretable as evidence of learned prediction. Adding these baselines is necessary to justify the central claim.
  3. [Section 4.1] The relative error definition in Section 4.1 is undefined when the ground truth is zero, and the paper notes that low-range metrics produce 'unusually high relative error.' However, the authors do not state how zero or near-zero ground-truth values are handled in the reported percentages—whether they are excluded, clipped, or counted as infinite. This choice can materially change the aggregates in Table 4. The authors should specify the exact rule and report the fraction of affected samples for each metric.
  4. [Section 3.1/4] The paper does not report the proportion of synthetic, AI-generated, and hand-written kernels in the dataset, nor the distribution of kernel types or problem sizes. If the pool is dominated by simple elementwise kernels (as in Listing 1), the model's high accuracy may not transfer to the complex kernels that the introduction motivates. The authors should provide a breakdown of the dataset and validate on kernels outside the generation distribution, even if only a small manually inspected set, to support the claim of practical generality.
  5. [Section 4.2] The abstract and Section 1 claim that 'over 90% of predicted counters fall within 10% of relative error,' but Table 4 reports per-metric percentages and no pooled proportion is given. To verify the headline number, the authors should compute the proportion of all predicted values across all metrics and test samples that satisfy the threshold, or define the statistic precisely. As written, the claim is not directly supported by the table.
minor comments (8)
  1. [Abstract/Introduction] The term 'self-supervised fine-tuning' is inaccurate; the model is trained with ground-truth profiler labels, which is supervised learning. Please rephrase.
  2. [Section 2.2.1] The citation for ChatGPT appears as [21] (Gemini); it should be [1] (GPT-4 Technical Report).
  3. [Figures 4-8] The y-axis is labeled 'Frequency (%)' but appears to use a logarithmic scale; please indicate this in the caption or axis label.
  4. [Table 2] The normalization ceilings are not derived from the hardware peaks or the profiler documentation. Please justify the ranges (e.g., why 16384 GB/s for bandwidth) or cite the source.
  5. [Section 4.2] For arithmetic intensity metrics, the reported accuracy (99.8% within 2%) is remarkably high. The authors should discuss why this metric is easy to predict (e.g., it is nearly deterministic from the code's operation and memory-access counts) and how that affects the overall claim of learning non-trivial relationships.
  6. [Section 3.1] The description of the synthetic kernel generator is brief; Listing 1 shows only a simple elementwise example. Please clarify the space of kernels the generator can produce and its parameter distribution.
  7. [Section 5] The limitation of fixed large problem size is acknowledged, but this condition is central to the approach; the abstract and introduction should more prominently state this scope so readers are not misled.
  8. [References] Reference [14] is a blog announcement; consider citing the LLaMA 3.2 model card or a more formal reference.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: Omniwise is an empirical supervised-learning study whose accuracy claims are measured on a held-out test set, not derived from its own inputs.

full rationale

The paper makes no first-principles derivation. Its central claim, 'Omniwise is able to achieve 90% of predicted counters falling within 10% of relative error compared to the ground-truth in our test set' (Section 1), is a measured evaluation against ROCm profiler ground truth after fine-tuning LLaMA 3.2 3B on a separate training split. The normalization in Table 2 and the relative-error formula in Section 4.1 are standard preprocessing and evaluation steps that do not encode the predicted outputs. No parameter is fitted to a subset and then reported as a prediction of that same subset; the test set is explicitly disjoint from the training set. The self-citations that appear (ROCm Compute Profiler [13], GPU hash tables [4], and the MLPerf BERT study [22]) are contextual or tooling references rather than load-bearing premises, and no uniqueness theorem or ansatz is imported from the authors' prior work to force the model choice. The only material caveat is external validity: the test set is sampled from the same generative pool (synthetic, GPT-4o, and hand-written kernels) as the training set, so the reported 90% within-10% figure may not transfer to out-of-distribution real-world kernels. That is a data-distribution and generalization limitation, not circularity, because the claim as stated is explicitly about 'our test set' and is an empirical measurement rather than a derivation.

Assumptions & free parameters 3 free parameters · 5 assumptions · 0 invented entities

The central claim depends on the quality and representativeness of the generated dataset, the accuracy of the profiler labels, and the validity of the evaluation protocol. The model itself is a fitted artifact, and the normalization choices affect the reported error. No new physical or mathematical entities are introduced.

free parameters (3)
  • LLM fine-tuned weights (LLaMA 3.2 3B Instruct + LoRA rank 24) = Trained for up to 50,000 steps, 1 epoch, on ~860k of ~955k kernels
    The accuracy numbers are properties of this specific fitted model. No external validation is provided, so the reported accuracies are contingent on this fit.
  • Per-metric normalization maxima (Table 2) = Bandwidth 16,384 GB/s; L1/L2 AI 2,048 and 5,120; GFLOP/s 12,288; hit rate 100%
    All counters are normalized to [0, '0.xxx'] by dividing by these ceilings, and relative errors are computed on normalized values. These hand-chosen maxima directly affect the reported error percentages.
  • Large fixed problem size = e.g., N = 1<<24 in Listing 2
    The pipeline fixes large problem sizes; Section 5 states predictions apply only to this regime. This choice bounds the claim and is an input assumption.
assumptions (5)
  • domain assumption ROCm Compute Profiler provides accurate ground-truth performance counters.
    All labels come from rocprofiler-compute; any profiler error or variance propagates to training and evaluation.
  • domain assumption Generated kernels are representative of real-world GPU kernels.
    The test set is sampled from the same generation pool as training; generalization to other code styles, libraries, or problem sizes is assumed but not demonstrated.
  • domain assumption Relative error is a valid accuracy metric for the reported normalized counters despite near-zero ground-truth values.
    Section 4.1 notes instability near zero, but the paper still reports high accuracy on low-range metrics, implying these cases do not dominate or that predictions are closely correct.
  • domain assumption The input representation (source code + architecture + compiler flags) contains sufficient information to determine the measured counters.
    The model is trained to map this input to counters; the high accuracy shows learnability, not that the mapping is complete or causal (e.g., runtime scheduling effects are ignored).
  • domain assumption No significant overlap or memorization between training and test kernels.
    The paper states no overlap (Section 4.1) but does not describe deduplication or similarity checks; synthetic kernels generated with random seeds could yield near-duplicates across the split.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Omniwise: Predicting GPU Kernels Performance with LLMs." pith.science (2026). https://pith.science/paper/2AYCI2GK

@misc{pith2026250620886,
  author       = {Pith},
  title        = {Pith review of: Omniwise: Predicting GPU Kernels Performance with LLMs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2AYCI2GK}},
  note         = {Machine review of arXiv:2506.20886}
}
read the original abstract

In recent years, the rapid advancement of deep neural networks (DNNs) has revolutionized artificial intelligence, enabling models with unprecedented capabilities in understanding, generating, and processing complex data. These powerful architectures have transformed a wide range of downstream applications, tackling tasks beyond human reach. In this paper, we introduce Omniwise, the first end-to-end, self-supervised fine-tuning pipeline that applies large language models (LLMs) to GPU kernel performance prediction--a novel use case in performance profiling. Omniwise is model-agnostic and lightweight, achieving strong results even with a small 3B-parameter model. It can predict key performance metrics, including memory bandwidth, cache hit rates, GFLOPs, and arithmetic intensity, directly from kernel code without the need for code execution or profiling tools. Our approach achieves over 90% of predictions within 10% relative error on GPU kernels executed on AMD MI250 and MI300X architectures. In addition to the pipeline, we develop an online inference server and a Visual Studio Code plugin that seamlessly integrate LLM-based performance prediction into developers' workflows.

Figures

Figures reproduced from arXiv: 2506.20886 by the authors.

Figure 1
Figure 1. Omniwise end-to-end workflow. # include < cstdint > 1 # include < iostream > 2 3 # include < hip / hip_runtime .h > 4 # include < hip / hip_runtime_api .h > 5 # include < thrust / device_vector .h > 6 7 __global__ void generated_kernel ( double * 8 input_0 , double * output_0 ) { auto thread_id = threadIdx . x + 9 blockIdx . x * blockDim . 10 x ; auto var_0 = input_0 [ thread_id ]; 11 auto var_1 = var_0 * var_0 + va… view at source ↗
Figure 2
Figure 2. Omniwise dataset examples [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Omniwise training sample. inference request includes the source code and extension user￾controlled variables such as compiler flags and architecture. Upon receiving an inference request, the inference server simply performs a forward pass, extracts the JSON-formatted performance counters, denormalizes the counters and finally returns the predictions to the extension. The extension provides the interactive prediction… view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Distributions and relative errors for L1 and L2 Cache Hit Rates. [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: Distributions and relative errors for L1 and L2 Cache Bandwidth. [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: Distributions and relative errors for HBM Read and Write Bandwidth. [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: Distributions and relative errors for L1 and L2 Arithmetic Intensity. [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 8
Figure 8. Figure 8: Distributions and relative errors for HBM Arithmetic Intensity and GFLOP/s. [PITH_FULL_IMAGE:figures/full_fig_p011_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. TileSight: A First-Principles Tile-Centric Analytical GPU Performance Model from Cores to Clusters

    cs.DC 2026-07 conditional novelty 7.0 of 10

    A tile-centric analytical model predicts GPU kernel latency and cache behavior purely from microbenchmark-calibrated hardware rates, reaching about 12% GEMM error and 13% end-to-end LLM serving error across five GPU lines.

Reference graph

Works this paper leans on

26 extracted references · 13 canonical work pages · cited by 1 Pith paper

  1. [1]

    Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Floren- cia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. 2023. GPT-4 Technical Report. arXiv preprint arXiv:2303.08774 (2023). doi:10.48550/arXiv.2303.08774

    arXiv doi:10.48550/arxiv.2303.08774 2023

  2. [2]

    Meta AI. 2025. LLaMA 3.2-3B Instruct. https://huggingface.co/meta-llama/Llama- 3.2-3B-Instruct. [Online; accessed 17-January-2025]

    work page 2025

  3. [3]

    AMD. 2025. HPC Training Examples. https://github.com/amd/ HPCTrainingExamples. [Online; accessed 17-January-2025]

    work page 2025

  4. [4]

    Awad, Saman Ashkiani, Serban D

    Muhammad A. Awad, Saman Ashkiani, Serban D. Porumbescu, Martín Farach- Colton, and John D. Owens. 2023. Analyzing and Implementing GPU Hash Tables. In SIAM Symposium on Algorithmic Principles of Computer Systems (APOCS23) . 33–50. doi:10.1137/1.9781611977578.ch3

    work page doi:10.1137/1.9781611977578.ch3 2023

  5. [5]

    NVIDIA Corporation. 2024. NVIDIA Nsight Compute. Accessed: 2024-11-05

    work page 2024

  6. [6]

    Chris Cummins, Volker Seeker, Dejan Grubisic, Baptiste Roziere, Jonas Gehring, Gabriel Synnaeve, and Hugh Leather. 2024. Meta Large Language Model Com- piler: Foundation Models of Compiler Optimization. arXiv:2407.02524 [cs.PL] doi:10.48550/arXiv.2407.02524

    arXiv doi:10.48550/arxiv.2407.02524 2024

  7. [7]

    Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schelten, Amy Yang, Angela Fan, et al. 2024. The LLaMA 3 Herd of Models. arXiv preprint arXiv:2407.21783 (2024). doi:10.48550/arXiv.2407.21783

    arXiv doi:10.48550/arxiv.2407.21783 2024

  8. [8]

    Zhangyin Feng, Daya Guo, Duyu Tang, Nan Duan, Xiaocheng Feng, Ming Gong, Linjun Shou, Bing Qin, Ting Liu, Daxin Jiang, et al . 2020. CodeBERT: A Pre-Trained Model for Programming and Natural Languages. arXiv preprint arXiv:2002.08155 (2020). doi:10.48550/arXiv.2002.08155

    arXiv doi:10.48550/arxiv.2002.08155 2020

Show all 26 references
  1. [9]

    Kshitij Gupta, Jeff Stuart, and John D. Owens. 2012. A Study of Persistent Threads Style GPU Programming for GPGPU Workloads. In Proceedings of Innovative Parallel Computing (InPar ’12) . doi:10.1109/InPar.2012.6339596

    2012

  2. [10]

    Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Lu Wang, and Weizhu Chen

    Edward J. Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Lu Wang, and Weizhu Chen. 2021. LoRA: Low-Rank Adaptation of Large Language Models. arXiv preprint arXiv:2106.09685 (2021). doi:10.48550/arXiv. 2106.09685

    2021 doi arXiv

  3. [11]

    Diederik P Kingma, J Adam Ba, and J Adam. 2020. A method for stochastic optimization. arXiv 2014. arXiv preprint arXiv:1412.6980 106 (2020), 6

    2020 arXiv

  4. [12]

    Anton Lozhkov, Raymond Li, Loubna Ben Allal, Federico Cassano, Joel Lamy- Poirier, Nouamane Tazi, Ao Tang, Dmytro Pykhtar, Jiawei Liu, Yuxiang Wei, et al. 2024. StarCoder 2 and The Stack v2: The Next Generation. arXiv preprint arXiv:2402.19173 (2024). doi:10.48550/arXiv.2402.19173

    2024 doi arXiv

  5. [13]

    Schulz, Jose Santos, Keith Lowery, Nicholas Curtis, and Cristian Di Pietrantonio

    Xiaomin Lu, Cole Ramos, Fei Zheng, Karl W. Schulz, Jose Santos, Keith Lowery, Nicholas Curtis, and Cristian Di Pietrantonio. 2024. ROCm/rocprofiler-compute: v3.0.0 (01 November 2024) . doi:10.5281/zenodo.7314631

    2024 doi

  6. [14]

    Meta AI. 2025. LLaMA 3: 2024 Vision for Edge and Mobile Devices. https://ai. meta.com/blog/llama-3-2-connect-2024-vision-edge-mobile-devices/. [Online; accessed 17-January-2025]

    2025

  7. [15]

    OpenAI. 2025. Hello GPT-4o. https://openai.com/index/hello-gpt-4o/. [Online; accessed 17-January-2025]

    2025

  8. [16]

    Samyam Rajbhandari, Jeff Rasley, Olatunji Ruwase, and Yuxiong He. 2020. ZeRO: Memory Optimizations Toward Training Trillion Parameter Models. In SC20: International Conference for High Performance Computing, Networking, Storage and Analysis. 1–16. doi:10.1109/SC41405.2020.00024

    2020 arXiv

  9. [17]

    Jeff Rasley, Samyam Rajbhandari, Olatunji Ruwase, and Yuxiong He. 2020. Deep- speed: System optimizations enable training deep learning models with over 100 billion parameters. In Proceedings of the 26th ACM SIGKDD international conference on knowledge discovery & data mining ...

    2020

  10. [18]

    Vijay Janapa Reddi, Christine Cheng, David Kanter, Peter Mattson, Guenther Schmuelling, Carole-Jean Wu, Brian Anderson, Maximilien Breughe, Mark Charlebois, William Chou, et al . 2020. Mlperf inference benchmark. In 2020 ACM/IEEE 47th Annual International Symposium on Computer...

    2020

  11. [19]

    ROCm. 2025. HIP: Heterogeneous Interface for Portability. https://github.com/ ROCm/HIP. [Online; accessed 17-January-2025]

    2025

  12. [20]

    ROCm Documentation Team. 2025. Performance Model. https://rocm.docs. amd.com/projects/rocprofiler-compute/en/latest/conceptual/performance- model.html. [Online; accessed 17-January-2025]

    2025

  13. [21]

    Gemini Team, Petko Georgiev, Ving Ian Lei, Ryan Burnell, Libin Bai, Anmol Gulati, Garrett Tanzer, Damien Vincent, Zhufeng Pan, Shibo Wang, et al. 2024. Gemini 1.5: Unlocking Multimodal Understanding Across Millions of Tokens of Context. arXiv preprint arXiv:2403.05530 (2024). ...

    2024 doi arXiv

  14. [22]

    Zixian Wang, Khai Vu, Miro Hodak, Aarush Mehrotra, Francisco Gutierrez, Kyle Smith, Gloria Seo, Austin Garcia, Bryan Chin, Marty Kandes, and Mary P Thomas

  15. [23]

    An Yang, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chengyuan Li, Dayiheng Liu, Fei Huang, Haoran Wei, et al . 2024. Qwen2.5 Technical Report. arXiv preprint arXiv:2412.15115 (2024). doi:10.48550/arXiv. 2412.15115

    2024 doi arXiv

  16. [24]

    Charlene Yang, Rahulkumar Gayatri, Thorsten Kurth, Protonu Basu, Zahra Ronaghi, Adedoyin Adetokunbo, Brian Friesen, Brandon Cook, Douglas Do- erfler, Leonid Oliker, Jack Deslippe, and Samuel Williams. 2018. An Empirical Roofline Methodology for Quantitatively Assessing Perform...

    2018

  17. [25]

    Wu, Yukun Li, Huazuo Gao, Shirong Ma, et al

    Qihao Zhu, Daya Guo, Zhihong Shao, Dejian Yang, Peiyi Wang, Runxin Xu, Y. Wu, Yukun Li, Huazuo Gao, Shirong Ma, et al . 2024. DeepSeek-Coder-V2: Breaking the Barrier of Closed-Source Models in Code Intelligence.arXiv preprint arXiv:2406.11931 (2024). doi:10.48550/arXiv.2406.11...

    2024 doi arXiv

  18. [2024]

    In Practice and Experience in Advanced Research Computing 2024: Human Powered Computing

    Preliminary Results of the MLPerf BERT Inference Benchmark on AMD Instinct GPUs. In Practice and Experience in Advanced Research Computing 2024: Human Powered Computing. Association for Computing Machinery

    2024

Pith tools

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