Profiling and optimization of multi-card GPU machine learning jobs

Krzesimir Samborski; Kyrylo Khloponin; {\L}ukasz Szustak; Marcin Lawenda

REVIEW 3 major objections 5 minor 37 references

Profiling and optimization of multi-card GPU machine learning jobs

T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

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

Pith's one-line read On a four-GPU H100 node, image-recognition speedups come from FP16 precision, pinned memory, and NHWC tensor layout, while LLM fine-tuning gains little from memory-transfer tweaks.

desk verdict A useful engineering benchmark of ML optimizations on 4xH100 nodes, but the headline NUMA/DALI conclusion rests on an explicitly untested hypothesis and single-run timings. read the letter →

arxiv 2505.22905 v1 pith:4JQAMRSW submitted 2025-05-28 cs.DC cs.PF

Marcin Lawenda , Kyrylo Khloponin , Krzesimir Samborski , {L}ukasz Szustak This is my paper

classification cs.DCcs.PF

keywords multi-GPUmachinelearningNVIDIAH100distributeddataparallelismNUMAmemoryarchitecturePyTorchLoaderDALIFP16mixedprecisionLLMfine-tuningoptimization

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

This paper tries to establish which optimization techniques actually pay off for machine learning jobs on a multi-card GPU node, and under what conditions. Using a node with four NVIDIA H100 GPUs and a two-socket NUMA CPU, the authors profile image recognition (MobileNet v2) and large-language-model fine-tuning (Llama3-8B) with Nsight Systems. They find that for image recognition, lowering precision to FP16 speeds up execution by roughly 2.1 to 2.5 times relative to FP64, enabling pinned memory cuts time by 16-30%, and switching the tensor layout from NCHW to NHWC brings PyTorch DataLoader close to NVIDIA DALI on 1-2 GPUs. They further claim DALI is resilient to NUMA effects while PyTorch DataLoader degrades on 3-4 GPUs due to suspected cross-socket memory traffic. For LLM tuning, they find memory-transfer optimizations such as pin_memory have negligible effect; the tuning method (LoRA, DPO, QLoRA, QAT) dominates runtime and memory behavior.

What carries the argument

The analysis is carried by four interacting mechanisms: Nsight Systems profiling metrics (CUDA memcpy Host-to-Device, cudaLaunchKernel, cudaStreamSynchronize, and ncclDevKernel_AllGather) that expose where execution time goes; distributed data parallelism with a distributed sampler (DDP-DS), which partitions data so each GPU receives a distinct subset; the data-pipeline comparison between PyTorch DataLoader and NVIDIA DALI, where the tensor layout NCHW versus NHWC changes memory-access coalescing and cache locality; and the node topology itself, with two CPU sockets linked by UPI and two H100 GPUs attached to each socket, which creates the cross-socket memory path invoked to explain DataLoader stalls. Precision and pin_memory act through the profiled memory-transfer path, while NHWC and NUMA effects act through cache behavior and memory placement.

What would settle it

Run the 4-GPU DataLoader scenario while forcing memory allocation local to each socket (for example, with numactl --membind set per worker) and check whether the pre-epoch pauses disappear and scaling recovers; if the pauses persist, the UPI-transfer explanation is false.

Watch

Extended reading notes

Core claim

The central discovery is a set of measured relationships between optimization choices and execution time on a modern multi-GPU architecture. Reducing computation precision from FP64 to FP32 gives 54-68% speedups in the image-recognition tests, and FP16 gives 110-152% speedups, with no loss against the 98-99% test-accuracy target; the authors summarize the FP16 result as up to a 210% efficiency gain relative to FP64. Enabling pin_memory reduces time by 16-30%, with the benefit shrinking as GPU count grows because faster host-to-device transfers are partly offset by increased NCCL AllGather time. Comparing data pipelines, NVIDIA DALI sustains uniform GPU utilization across 1-4 GPUs, while PyTorch DataLoader shows pauses before training epochs at 3-4 GPUs; switching DataLoader to the NHWC tensor format makes it nearly match DALI at 1-2 GPUs but does not remove the 3-4 GPU degradation, which the authors attribute to memory placement on the NUMA architecture rather than to tensor layout. In the LLM part, per-iteration time rises slightly as GPUs are added, pin_memory changes little, LoRA is 30-40% faster than DPO, QLoRA trades speed for lower VRAM, and QAT only finished tuning in their configuration with 4 GPUs.

Load-bearing premise

The explanation for PyTorch DataLoader's slowdown on 3-4 GPUs rests on an unverified assumption: that worker processes on the second CPU socket are being served memory from the first socket, forcing cross-socket UPI traffic, and this is inferred from pauses in profiling timelines rather than measured memory placement.

Editorial extensions

If this is right

Image-recognition workloads on similar multi-GPU nodes should combine FP16 training, pin_memory, and an NHWC-based pipeline; the paper's numbers imply roughly a doubling from precision and an additional 16-30% from pinning.
On NUMA nodes with four GPUs, DALI is the safer data-loading choice, because PyTorch DataLoader carries a scaling penalty at 3-4 GPUs that tensor-layout changes do not remove.
For LLM fine-tuning, pin_memory and host-to-device transfer tuning are low-value; effort is better spent on reducing kernel-launch and synchronization overhead or on choosing LoRA over DPO.
LoRA is consistently 30-40% faster than DPO on the same templates and uses less VRAM, while QLoRA is the memory-saving option at the cost of time, and QAT should be scheduled only when enough GPUs are available to fit its memory footprint.
Adding GPUs to LLM tuning does not reduce per-iteration time beyond two GPUs because communication and synchronization costs grow, although total wall-clock time still decreases because fewer iterations are needed.

Reading between the lines

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

Implicit in the NUMA hypothesis is a concrete fix the paper does not test: binding DataLoader worker processes to their local socket's memory, or using an interleaved memory policy, should remove the pre-epoch pauses at 3-4 GPUs if the hypothesis is correct.
If the NHWC effect generalizes beyond MobileNet v2, the 1-2 GPU gap between PyTorch DataLoader and DALI may be mostly a tensor-layout artifact; this could be checked by benchmarking other CNN architectures with matched layouts.
The paper's LLM finding that memory transfers are negligible for one-epoch LoRA tuning may not extend to multi-epoch training or much larger datasets, where data reuse and transfer volume grow substantially.
The observed rise in NCCL AllGather time when pin_memory is enabled suggests an untested tuning lever: overlapping collective communication with computation, or changing the collective algorithm, could recover the pin_memory benefit at four GPUs.

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.

Desk Editor's Note

read the letter

Two things to know. First, this is an engineering benchmark on a 4xH100 NUMA node, not a methods paper. It measures MobileNetV2/MNIST training under FP64/FP32/FP16, pin_memory, NCHW vs NHWC, and PyTorch DataLoader vs DALI, plus Llama-3-8B tuning with LoRA/DPO/QLoRA/QAT. The genuinely new content is the specific hardware measurements and the observation that DataLoader throughput collapses at 3–4 GPUs while DALI scales. Second, the NUMA explanation for that collapse is a hypothesis the authors themselves label as such, and it is not tested.

What the paper does well: the measurements are direct and the internal profiler story is coherent. FP16 cuts HtoD copy time roughly in line with data size, pin_memory reduces transfer time, and NHWC brings DataLoader close to DALI on 1–2 GPUs. The LLM section is a modest but honest datapoint that pin_memory matters little when host-device transfers are tiny and that GEC templates run fastest. The citation pattern is normal; no self-citation loops.

The soft spots are real but not fatal to the practical takeaway. The main one is causal overreach in Section 6. The claim that DALI is preferred for enhanced compatibility with NUMA architectures rests on the Section 4.3.1 hypothesis, with no numa_maps, numastat, or numactl data, no repeated runs, and no released artifacts. Since DALI does preprocessing on GPU while DataLoader normalizes on CPU, CPU-side preprocessing or worker synchronization is a plausible alternative explanation for the 3–4 GPU slowdown. The 500x500 observation that DataLoader cannot run with 2 GPUs but DALI can is suggestive of a memory allocation problem, but it is not proof of cross-socket UPI transfers. Separately, the tables report one timing per configuration, so the 16–30% pin_memory and 210% FP16 figures are point estimates without uncertainty. Table 2 also shows 97.94% accuracy for 2-GPU FP16 while the text says quality does not deteriorate; that contradiction should be fixed.

None of this sinks the engineering recommendation to use FP16/FP32, pin_memory, and NHWC; those effects are consistent with known behavior and with the profiler metrics. But the DALI-NUMA recommendation should be softened until the mechanism is actually tested.

This paper is for HPC/ML engineers choosing data pipelines and precision on H100 nodes. It deserves a serious referee, not a desk reject. It needs revision: repeated runs or error bars, a NUMA-memory check or a reframed claim, an artifact release, and cleanup of the accuracy inconsistency. I would not cite it in my own work until those are in place.

Referee Report

3 major / 5 minor

Summary. The paper profiles two machine-learning workloads on a four-GPU H100 node: image recognition training with MobileNetV2 under PyTorch DDP, and LLM fine-tuning of Llama3-8B with LoRA/QLoRA/DPO/QAT under TorchTune. Using NVIDIA Nsight Systems, the authors compare precision levels (FP64/FP32/FP16), the pin_memory flag, tensor layouts (NCHW vs NHWC), and the PyTorch DataLoader against NVIDIA DALI. The main claims are that FP16 and FP32 yield substantial speedups (up to roughly 2.1x relative to FP64 in their efficiency metric), that pin_memory gives 16-30% improvement for image recognition, that switching DataLoader to NHWC closes the gap with DALI on 1-2 GPUs, and that DataLoader degrades on 3-4 GPUs because of hypothesized NUMA/UPI memory-placement problems while DALI does not. The LLM experiments show that pin_memory has negligible effect, that iteration time grows slightly with GPU count, and that LoRA is faster and less memory-hungry than the other tuning methods.

Significance. If the results withstand scrutiny, the paper offers useful practical guidance for operators of multi-GPU H100 systems, especially the comparison of DALI and DataLoader and the measured effect of NHWC. The paper's strengths are that it uses direct profiling on a current H100 platform, compares several optimization levers in a controlled environment, and does not introduce fitted parameters or circular derivations. However, the quantitative claims rest on single runs without uncertainty estimates, and the central causal explanation for DataLoader's scaling degradation is explicitly presented as an unverified hypothesis. These issues make the contribution conditional rather than immediately transferable. With additional experimental support and softened causal language, the paper would be a reasonable empirical case study for a systems/performance venue.

major comments (3)

[Section 4.3.1 and Section 6] The recommendation that DALI is preferable for NUMA compatibility is load-bearing for the conclusions, but it rests on an explicitly labeled hypothesis. The text states: "The hypothesis is that these pauses are caused by memory for processes on the second socket being allocated to the first socket, forcing frequent data transfers between sockets via UPI." No direct memory-placement evidence (e.g., numa_maps, numastat, or numactl experiments) is provided, and no repeated runs establish that the observed NSYS pauses are reproducible. Moreover, DALI and DataLoader differ in an obvious architectural way: DALI moves preprocessing to the GPU while DataLoader normalizes on the CPU (Scenario B, Section 4.3.1). The pauses could therefore be caused by CPU-side preprocessing, HDD I/O (the text says the dataset is stored on HDD), or worker-process synchronization rather than cross-socket UPI traffic. Please either test the NUMA attribution directly with memory-placement measurements and controlled repetitions, or remove the NUMA-based recommendation from the conclusions.
[Tables 2, 3, 5 and Figures 6, 10, 13, 14] All reported execution times and speedups appear to come from a single run per configuration, with no error bars, confidence intervals, or statistical analysis. The claims of 16-30% benefit from pin_memory and up to 210% speedup from FP16 therefore have no assessed uncertainty. This is particularly problematic in Table 5, where the reported differences are 0.04%, 1.57%, -0.03%, and 3.50%; these values are plausibly within run-to-run noise, yet they are interpreted as showing that pin_memory has negligible or small effect. The DALI-versus-DataLoader comparison in Figure 6, which drives the NUMA conclusion, is likewise based on single timings. The authors should report means and variances over at least several repetitions, and should indicate whether the 3-4 GPU pauses are consistently observed across runs.
[Section 4.2.1 and Table 2] The claim that "the quality of results does not deteriorate when transitioning from double to float or half precision" is contradicted by the reported 2-GPU FP16 test accuracy of 97.94%, compared with 99.20% for FP64, which is also below the 98-99% accuracy target stated in Section 4.1. This discrepancy should be addressed either by showing that the 97.94% value is an outlier across repeated runs, or by qualifying the accuracy claim with a tolerance margin. As written, the paper internally asserts both that accuracy does not deteriorate and that one configuration falls outside the stated target range.

minor comments (5)

[References] Reference [20] cites Simonyan and Zisserman's VGG paper, but the text uses it for MobileNet v2; the correct reference is Sandler et al., "MobileNetV2: Inverted Residuals and Linear Bottlenecks" (CVPR 2018).
[Section 4.2.1 and Section 6] The phrase "reducing execution time by ... up to 210%" is semantically incorrect: a percentage reduction cannot exceed 100%. The table reports efficiency relative to FP64, so the correct statement is a speedup of up to approximately 2.1x, or a 52% reduction in execution time in the best case.
[Figures 6, 7, 8 and 9] The NSYS report figures are presented as screenshots with visual annotations rather than quantitative summaries; extracting the pause durations and per-phase timings into a table would make the claims easier to verify and would strengthen the comparison between DataLoader and DALI.
[Section 4.1] The image-recognition experiments use upsampled grayscale MNIST images as a stand-in for realistic RGB workloads; the paper should state this limitation more prominently, since the representativeness of a synthetic proxy is not established.
[Section 3.1 and Section 4.3.1] The hardware description does not mention the storage type, but Section 4.3.1 says the dataset is stored on HDD; specifying the filesystem and disk characteristics would help readers judge the I/O-related explanations for DataLoader behavior.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: all central claims are direct measurements against standard baselines, with no fitted parameters, definitions, or self-citation chains acting as load-bearing inputs.

full rationale

The paper is an empirical profiling and optimization study. Its central claims about FP16 speedups, pin_memory gains, and NHWC tensor structure effects are presented as direct comparisons of measured execution times from Tables 2, 3, and Figure 9, with no fitted parameters, no derived equations, and no quantity that is defined in terms of the result it is said to predict. The DALI-versus-DataLoader recommendation in Section 6 is supported by NSYS traces and timing comparisons in Section 4.3.1, and the paper explicitly labels the NUMA memory-placement mechanism as a hypothesis (“The hypothesis is that these pauses are caused by memory for processes on the second socket being allocated to the first socket”), which may be unverified or uncertain but is not circular. No step reduces to its own input by construction, and no load-bearing argument depends on a self-citation. The absence of repeated runs and the untested NUMA explanation are correctness/evidence concerns, not circularity. Accordingly, the circularity score is 0.

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

No free parameters are fitted; the paper is purely empirical. The key unstated premises are that single runs are representative, the upsampled MNIST proxy is meaningful, and profiler-summarized metrics reveal the true causes of observed slowdowns.

assumptions (3)

domain assumption Single-run profiler measurements are representative of steady-state performance.
All tables and figures report one measurement per configuration, with no standard deviation or repetitions; the paper treats these as stable values.
ad hoc to paper Upsampled MNIST images (up to 500x500) are a valid proxy for image-recognition workloads despite being synthetic.
Section 4.1 acknowledges that 28x28 MNIST was insufficient to load the GPU and resizes images to create load, which is an artificial workload choice.
domain assumption Nsight Systems profiling overhead is negligible and the selected metrics capture the main causes of slowdown.
The paper relies on NSYS metric timings to attribute performance changes to memory transfers, kernel launches, and synchronization without calibrating the profiler overhead.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Profiling and optimization of multi-card GPU machine learning jobs." pith.science (2026). https://pith.science/paper/4JQAMRSW

@misc{pith2026250522905,
  author       = {Pith},
  title        = {Pith review of: Profiling and optimization of multi-card GPU machine learning jobs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4JQAMRSW}},
  note         = {Machine review of arXiv:2505.22905}
}

read the original abstract

The effectiveness and efficiency of machine learning methodologies are crucial, especially with respect to the quality of results and computational cost. This paper discusses different model optimization techniques, providing a comprehensive analysis of key performance indicators. Several parallelization strategies for image recognition, adapted to different hardware and software configurations, including distributed data parallelism and distributed hardware processing, are analyzed. Selected optimization strategies are studied in detail, highlighting the related challenges and advantages of their implementation. Furthermore, the impact of different performance improvement techniques (DPO, LoRA, QLoRA, and QAT) on the tuning process of large language models is investigated. Experimental results illustrate how the nature of the task affects the iteration time in a multiprocessor environment, VRAM utilization, and overall memory transfers. Test scenarios are evaluated on the modern NVIDIA H100 GPU architecture.

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

37 extracted references · 25 canonical work pages

[1]

https://mitsloan.mit.edu/ideas- made-to-matter/ai-has-high-data-center-energy-costs-there-are-solutions

MIT Sloan - AI has high data center energy costs — but there are solutions; 2025. https://mitsloan.mit.edu/ideas- made-to-matter/ai-has-high-data-center-energy-costs-there-are-solutions

work page 2025
[2]

Beyond T raditional Learning: The LLM Revolution in BPM Education at Univer- sity

Grzesiak M, Kluza K, Potoczek NR, Szała L. Beyond T raditional Learning: The LLM Revolution in BPM Education at Univer- sity. In: Di Ciccio C, Fdhila W, Agostinelli S, Amyot D, Leopold H, Krčál M, et al., editors. Business Process Management: Blockchain, Robotic Process Automation, Central and Eastern European, Educators and Industry Forum Cham: Springer ...

work page 2024
[3]

The Language Model Revolution: LLM and SLM Analysis

Örpek Z, T ural B, Destan Z. The Language Model Revolution: LLM and SLM Analysis. In: 2024 8th International Artiﬁcial Intelligence and Data Processing Symposium (IDAP); 2024. p. 1–4

work page 2024
[4]

A New Golden Age in Computer Architecture: Empowering the Machine-Learning Revo- lution

Dean J, Patterson D, Y oung C. A New Golden Age in Computer Architecture: Empowering the Machine-Learning Revo- lution. IEEE Micro 2018;38(2):21–29

work page 2018
[5]

https://arxiv.org/abs/2404.12674

Lin Z, Sun N, Bhattacharya P , Feng X, Feng L, Owens JD, T owards Universal Performance Modeling for Machine Learning T raining on Multi-GPU Platforms; 2024. https://arxiv.org/abs/2404.12674. 26 Lawenda et al

arXiv 2024
[6]

TwinPilots: A New Computing Paradigm for GPU-CPU Parallel LLM Inference

Yu C, Wang T, Shao Z, Zhu L, Zhou X, Jiang S. TwinPilots: A New Computing Paradigm for GPU-CPU Parallel LLM Inference. In: Proceedings of the 17th ACM International Systems and Storage Conference SYSTOR ’24, New Y ork, NY, USA: Association for Computing Machinery; 2024. p. 91–103. https://doi.org/10.1145/3688351.3689164

arXiv 2024
[7]

Understanding the eﬃciency of GPU algorithms for matrix-matrix multiplication

Fatahalian K, Sugerman J, Hanrahan P . Understanding the eﬃciency of GPU algorithms for matrix-matrix multiplication. In: Proceedings of the ACM SIGGRAPH/EUROGRAPHICS Conference on Graphics Hardware HWWS ’04, New Y ork, NY, USA: Association for Computing Machinery; 2004. p. 133–137. https://doi.org/10.1145/1058129.1058148

work page arXiv 2004
[8]

Optimization and architecture eﬀects on GPU computing workload performance

Stratton JA, Anssari N, Rodrigues C, Sung IJ, Obeid N, Chang L, et al. Optimization and architecture eﬀects on GPU computing workload performance. In: 2012 Innovative Parallel Computing (InPar); 2012. p. 1–10

work page 2012

Show all 37 references

[9]

Coordinating the use of GPU and CPU for im- proving performance of compute intensive applications

T eodoro G, Sachetto R, Sertel O, Gurcan MN, Meira W, Catalyurek U, et al. Coordinating the use of GPU and CPU for im- proving performance of compute intensive applications. In: 2009 IEEE International Conference on Cluster Computing and Workshops; 2009. p. 1–10

2009
[10]

Comparing Energy Eﬃciency of CPU, GPU and FPGA Im- plementations for Vision Kernels

Qasaimeh M, Denolf K, Lo J, Vissers K, Zambreno J, Jones PH. Comparing Energy Eﬃciency of CPU, GPU and FPGA Im- plementations for Vision Kernels. In: 2019 IEEE International Conference on Embedded Software and Systems (ICESS)

2019
[11]

A comparative study of GPU programming models and architectures using neural networks

Pallipuram VK, Bhuiyan M, Smith MC. A comparative study of GPU programming models and architectures using neural networks. The Journal of Supercomputing 2012 Sep;61(3):673–718. https://doi.org/10.1007/s11227-011-0631-3

2012 doi
[12]

https: //arxiv.org/abs/1604.01946

Appleyard J, Kocisky T, Blunsom P , Optimizing Performance of Recurrent Neural Networks on GPUs; 2016. https: //arxiv.org/abs/1604.01946

2016 arXiv
[13]

PyT orch distributed: experiences on accelerating data parallel training

Li S, Zhao Y, Varma R, Salpekar O, Noordhuis P , Li T, et al. PyT orch distributed: experiences on accelerating data parallel training. Proc VLDB Endow 2020 Aug;13(12):3005–3018. https://doi.org/10.14778/3415478.3415530

2020
[14]

https://top500.org/system/180290/

T op500 - Poznan Supercomputing and Networking Center - Proxima; 2025. https://top500.org/system/180290/

2025
[15]

https://docs.nvidia.com/datacenter/nvtags/1.1/nvtags- user-guide/index.html

NVIDIA T opology-Aware GPU Selection User Guide; 2025. https://docs.nvidia.com/datacenter/nvtags/1.1/nvtags- user-guide/index.html

2025
[16]

https://pytorch.org/tutorials/intermediate/ddp_tutorial

Getting Started with Distributed Data Parallel; 2025. https://pytorch.org/tutorials/intermediate/ddp_tutorial. html

2025
[17]

https://pytorch.org/torchtune/stable/deep_dives/configs

Foundation TL, T orchtune conﬁg documentation; 2024. https://pytorch.org/torchtune/stable/deep_dives/configs. html

2024
[18]

https://developer.nvidia.com/nsight-systems

NVIDIA Nsight Systems; 2025. https://developer.nvidia.com/nsight-systems

2025
[19]

High-Performance Data Loader for Large-Scale Data Processing

Martinez-Noriega EJ, Peng C, Y okota R. High-Performance Data Loader for Large-Scale Data Processing. Electronic Imaging 2024;36(12):196–1–196–1. https://library.imaging.org/ei/articles/36/12/HPCI-196

2024
[20]

Very Deep Convolutional Networks for Large-Scale Image Recognition

Simonyan K, Zisserman A. Very Deep Convolutional Networks for Large-Scale Image Recognition. CoRR 2014;abs/1409.1556. https://api.semanticscholar.org/CorpusID:14124313

2014 arXiv
[21]

https://www.kaggle.com/datasets/hojjatk/mnist-dataset

MNIST Dataset; 2025. https://www.kaggle.com/datasets/hojjatk/mnist-dataset

2025
[22]

https://keras.io/api/applications/mobilenet/

MobileNet parameters; 2025. https://keras.io/api/applications/mobilenet/

2025
[23]

https: //arxiv.org/abs/1505.04597

Ronneberger O, Fischer P , Brox T, U-Net: Convolutional Networks for Biomedical Image Segmentation; 2015. https: //arxiv.org/abs/1505.04597

2015 arXiv
[24]

https://arxiv.org/abs/ 2012.09904

Kundu S, Mostafa H, Sridhar SN, Sundaresan S, Attention-based Image Upsampling; 2020. https://arxiv.org/abs/ 2012.09904. Lawenda et al. 27

2020 arXiv
[25]

Vasconcelos C, Oztireli C, Matthews M, Hashemi M, Swersky K, T agliasacchi A, CUF: Continuous Upsampling Filters
[26]

An Emotion T ext Classiﬁcation Model Based on Llama3-8b Using Lora T echnique

Shui H, Zhu Y, Zhuo F, Sun Y, Li D. An Emotion T ext Classiﬁcation Model Based on Llama3-8b Using Lora T echnique. In: 2024 7th International Conference on Computer Information Science and Application T echnology (CISAT); 2024. p. 380–383

2024
[27]

https://arxiv.org/abs/2402.06196

Minaee S, Mikolov T, Nikzad N, Chenaghlu M, Socher R, Amatriain X, et al., Large Language Models: A Survey; 2024. https://arxiv.org/abs/2402.06196

2024 arXiv
[28]

https://arxiv.org/abs/2305.13245

Ainslie J, Lee-Thorp J, de Jong M, Zemlyanskiy Y, Lebrón F, Sanghai S, GQA: T raining Generalized Multi-Query T rans- former Models from Multi-Head Checkpoints; 2023. https://arxiv.org/abs/2305.13245

2023 arXiv
[29]

https://arxiv.org/abs/2407.21783

AI @ Meta LT, The Llama 3 Herd of Models; 2024. https://arxiv.org/abs/2407.21783

2024 arXiv
[30]

https://arxiv.org/abs/2106.09685

Hu EJ, Shen Y, Wallis P , Allen-Zhu Z, Li Y, Wang S, et al., LoRA: Low-Rank Adaptation of Large Language Models; 2021. https://arxiv.org/abs/2106.09685

2021 arXiv
[31]

Direct Preference Optimization: Y our Language Model is Secretly a Reward Model

Rafailov R, Sharma A, Mitchell E, Manning CD, Ermon S, Finn C. Direct Preference Optimization: Y our Language Model is Secretly a Reward Model. In: Thirty-seventh Conference on Neural Information Processing Systems; 2023. https: //arxiv.org/abs/2305.18290

2023 arXiv
[32]

https: //arxiv.org/abs/2305.14314

Dettmers T, Pagnoni A, Holtzman A, Zettlemoyer L, QLoRA: Eﬃcient Finetuning of Quantized LLMs; 2023. https: //arxiv.org/abs/2305.14314

2023 arXiv
[33]

Hasan J, Optimizing Large Language Models through Quantization: A Comparative Analysis of PTQ and QAT T echniques
[34]

Synthetic Data Generation for Grammatical Error Correction with T agged Corruption Models

Stahlberg F, Kumar S. Synthetic Data Generation for Grammatical Error Correction with T agged Corruption Models. In: Burstein J, Horbach A, Kochmar E, Laarmann-Quante R, Leacock C, Madnani N, et al., editors. Proceedings of the 16th Workshop on Innovative Use of NLP for Buildi...

2021
[35]

SAMSum Corpus: A Human-annotated Dialogue Dataset for Abstractive Sum- marization

Gliwa B, Mochol I, Biesek M, Wawer A. SAMSum Corpus: A Human-annotated Dialogue Dataset for Abstractive Sum- marization. In: Proceedings of the 2nd Workshop on New Frontiers in Summarization Hong Kong, China: Association for Computational Linguistics; 2019. p. 70–79. https://w...

2019
[2022]

https://arxiv.org/abs/2210.06965

arXiv
[2024]

https://arxiv.org/abs/2411.06084

arXiv

Pith tools

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

[1] [1]

https://mitsloan.mit.edu/ideas- made-to-matter/ai-has-high-data-center-energy-costs-there-are-solutions

MIT Sloan - AI has high data center energy costs — but there are solutions; 2025. https://mitsloan.mit.edu/ideas- made-to-matter/ai-has-high-data-center-energy-costs-there-are-solutions

work page 2025

[2] [2]

Beyond T raditional Learning: The LLM Revolution in BPM Education at Univer- sity

Grzesiak M, Kluza K, Potoczek NR, Szała L. Beyond T raditional Learning: The LLM Revolution in BPM Education at Univer- sity. In: Di Ciccio C, Fdhila W, Agostinelli S, Amyot D, Leopold H, Krčál M, et al., editors. Business Process Management: Blockchain, Robotic Process Automation, Central and Eastern European, Educators and Industry Forum Cham: Springer ...

work page 2024

[3] [3]

The Language Model Revolution: LLM and SLM Analysis

Örpek Z, T ural B, Destan Z. The Language Model Revolution: LLM and SLM Analysis. In: 2024 8th International Artiﬁcial Intelligence and Data Processing Symposium (IDAP); 2024. p. 1–4

work page 2024

[4] [4]

A New Golden Age in Computer Architecture: Empowering the Machine-Learning Revo- lution

Dean J, Patterson D, Y oung C. A New Golden Age in Computer Architecture: Empowering the Machine-Learning Revo- lution. IEEE Micro 2018;38(2):21–29

work page 2018

[5] [5]

https://arxiv.org/abs/2404.12674

Lin Z, Sun N, Bhattacharya P , Feng X, Feng L, Owens JD, T owards Universal Performance Modeling for Machine Learning T raining on Multi-GPU Platforms; 2024. https://arxiv.org/abs/2404.12674. 26 Lawenda et al

arXiv 2024

[6] [6]

TwinPilots: A New Computing Paradigm for GPU-CPU Parallel LLM Inference

Yu C, Wang T, Shao Z, Zhu L, Zhou X, Jiang S. TwinPilots: A New Computing Paradigm for GPU-CPU Parallel LLM Inference. In: Proceedings of the 17th ACM International Systems and Storage Conference SYSTOR ’24, New Y ork, NY, USA: Association for Computing Machinery; 2024. p. 91–103. https://doi.org/10.1145/3688351.3689164

arXiv 2024

[7] [7]

Understanding the eﬃciency of GPU algorithms for matrix-matrix multiplication

Fatahalian K, Sugerman J, Hanrahan P . Understanding the eﬃciency of GPU algorithms for matrix-matrix multiplication. In: Proceedings of the ACM SIGGRAPH/EUROGRAPHICS Conference on Graphics Hardware HWWS ’04, New Y ork, NY, USA: Association for Computing Machinery; 2004. p. 133–137. https://doi.org/10.1145/1058129.1058148

work page arXiv 2004

[8] [8]

Optimization and architecture eﬀects on GPU computing workload performance

Stratton JA, Anssari N, Rodrigues C, Sung IJ, Obeid N, Chang L, et al. Optimization and architecture eﬀects on GPU computing workload performance. In: 2012 Innovative Parallel Computing (InPar); 2012. p. 1–10

work page 2012