Pith. sign in

REVIEW 5 major objections 6 minor 23 references

This paper argues that LLM latency on edge devices can be predicted accurately enough for model screening by fusing static descriptors with runtime telemetry and calibrating on a handful of target-device runs.

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-02 14:18 UTC pith:3GN3WDA6

load-bearing objection The screening claim is undercut by test-run telemetry leakage in the evaluation protocol, but the engineering is honest and the profiling data has real value; deserves serious review. the 5 major comments →

arxiv 2607.21602 v1 pith:3GN3WDA6 submitted 2026-05-11 cs.AI

Transferable Latency Prediction for Fast LLM Screening on Heterogeneous Edge Devices

Xiaolong Tu , Vinod K. Mishra , Venkat R. Dasari , Anu G. Bourgeois , Haoxin Wang This is my paper
classification cs.AI
keywords latency predictionon-device LLMedge deploymentruntime telemetryphase-aware modelingmodel screeningcross-device transfercalibration
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.

Latency-aware deployment of LLMs on edge devices is currently expensive because every candidate model must be benchmarked on every target device. This paper argues instead that latency can be predicted from a hardware-runtime-model-prompt configuration, and that a predictor combining static descriptors with runtime telemetry—separated into prefill and decode—can transfer across devices once anchored by a small calibration set. The experiments show calibration converting cross-device decode R² from -1.085 to 0.927 and total R² from -0.974 to 0.940 on mobile phones, and within-device prefill R² from -1.383 to 0.966. If correct, the result turns exhaustive profiling into a short calibration step, making model screening practical for growing model zoos.

Core claim

The paper's central claim is that runtime-aware prediction with lightweight calibration can replace exhaustive profiling for LLM screening on heterogeneous edge devices. It represents each inference request as a configuration of device, model, runtime, and prompt; models prefill and decode separately; and fuses static and dynamic embeddings through a gated mechanism. The load-bearing evidence is that within-device prediction is strong (decode R² 0.973 on Pixel 8, prefill R² 0.966 on Pixel 8 Pro) and that calibration pulls cross-device transfer from strongly negative to usable R² (0.927 decode, 0.940 total for Pixel 8 Pro → Pixel 8). The paper also documents that latency is highly device- and

What carries the argument

The central mechanism is a two-branch predictor with gated fusion. The static branch encodes known-before-run descriptors—device, model, runtime backend, prompt length, max generation length—into a static embedding. The dynamic branch segments the runtime trace into prefill and decode regions, aligns repeated prefill runs to normalized phase time to reconstruct sparse bursty states, and passes the sequence through a temporal encoder to produce a dynamic embedding. A gating network computes softmax weights over the two embeddings, and a multi-output regression head jointly predicts prefill, decode, and total latency. A small target-device calibration set then adjusts the predictor's scale, wh

Load-bearing premise

The predictor's dynamic path uses live hardware telemetry from the execution being predicted, and the paper does not state whether test records' traces come from the test run itself; if they do, the within-device gains do not transfer to the advertised pre-execution screening use case.

What would settle it

Run a controlled screening experiment where a candidate model and prompt that never appeared in training or calibration is predicted on a fresh target device, using only static descriptors plus a calibration set collected from unrelated requests. Compare predicted versus measured total and decode latency; if R² falls to the negative zero-shot values reported before calibration, the screening benefit is not realized. Also report bootstrap confidence intervals for R², since the headline values rest on 11–41 test samples.

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

If this is right

  • A deployer can rank candidate LLMs on an unprofiled device using a handful of calibration runs instead of exhaustive benchmarking, cutting profiling cost.
  • Because prefill and decode are predicted separately, screening can enforce phase-specific budgets such as first-token latency and steady-state tokens per second.
  • The calibration loop is cumulative: each profiled candidate adds traces that refine future predictions on the same device.
  • Combining predicted latency with quality scores in a Pareto step can remove dominated candidates before full target-device execution while preserving the best feasible model.
  • The profiling schema extends across mobile, embedded GPU, single-board, and desktop GPU classes, so source-device data from one class can seed prediction for another.

Where Pith is reading between the lines

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

  • Beyond the paper: the reported transfer experiments use only 6 calibration samples (Pixel 8 Pro → Pixel 8), so the practical recipe implied here is that a device owner can anchor an entire model zoo with a handful of representative runs; this is worth testing at zoo scale, since the screening evaluation itself only covers 2–3 candidates.
  • Beyond the paper: the finding that smaller models are slower than larger ones on the GPU-class platform suggests parameter count is a weak screening signal; a deployer should treat runtime and kernel effects as first-order, which strengthens the case for learned prediction over rule-of-thumb cost models.
  • Beyond the paper: since the dynamic traces already include power-related signals, the same architecture could be repurposed to predict energy or memory alongside latency; the paper lists this as future work.
  • Beyond the paper: a stricter split that isolates calibration traces from test traces would resolve whether the calibration gains are due to genuine domain alignment or to partial leakage of the target run's own telemetry.

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

5 major / 6 minor

Summary. The paper proposes a runtime-aware latency prediction framework for screening candidate LLMs on heterogeneous edge devices. A deployment is represented as a hardware-runtime-model-prompt configuration, with a static branch for pre-execution descriptors and a dynamic branch consuming runtime telemetry; the two are combined through gated fusion, and a small target-device calibration set is used to adapt the predictor. The evaluation reports within-device and cross-device R² and MAE results on Pixel 8/Pixel 8 Pro, heterogeneous profiling on Jetson Nano, Orange Pi 5 Pro, and an RTX 3090-class GPU, plus a small deployment-screening study. The central claim is that runtime-aware prediction with lightweight calibration reduces profiling cost and supports latency-aware LLM deployment before full target-device execution.

Significance. If the claimed results held under a protocol that matches the screening use case, the framework would be practically valuable: it would let a deployer rank or filter candidate LLMs for an unprofiled device using only a few calibration runs, avoiding exhaustive benchmarking. The paper has notable strengths: a clean configuration formulation, explicit prefill/decode phase modeling, a multi-platform profiling pipeline, and a well-motivated calibration loop. It also makes concrete falsifiable predictions (Tables 5–6) and documents its own limitations in §5.7. However, the advertised pre-execution screening scenario is not currently validated because the evaluation protocol appears to feed test-run telemetry and realized token counts into the predictor; moreover, the reported R² values rest on very small test sets and the profiling-cost reduction is never measured. With a corrected protocol and uncertainty quantification, the approach could be a solid contribution; in its present form, the evidence does not support the abstract's headline claims.

major comments (5)
  1. [§4.3, Eq. (3), Tables 5–6] The evaluation protocol randomly partitions complete request records into training and test sets (§4.3). The dynamic path (Eq. 3) consumes runtime telemetry from an execution, so under this protocol each test record's dynamic input is that test run's own telemetry. At screening time, however, the candidate model has not been executed and no such trace exists; §3.8 explicitly profiles selected candidates only after selection. The paper never states that test traces are restricted to calibration traces. Consequently, the full-model R² improvements (e.g., Pixel 8 Pro prefill R² −1.383→0.966) may be partially self-predictive and do not demonstrate the advertised 'fast LLM screening before full target-device execution.' Please re-evaluate with dynamic features derived only from calibration runs, or explicitly justify why the current protocol matches the deployment scenario.
  2. [§4.1, §3.4.1] The prompt-side descriptors recorded for each request include 'generated token count' (§4.1). If this realized output length is used as an input feature in the static path (Eq. 2 / §3.4.1), then the predictor is given the answer to part of what it must estimate for decode and total latency. §3.4.1 lists input length and maximum generation length but does not list generated token count; §4.1 does record it. Please clarify whether generated token count is a feature or only a target/statistic. If it is a feature, the within-device results (Table 5) and transfer results (Table 6) are optimistic relative to the pre-execution screening scenario.
  3. [Tables 5–6, §4.3] The headline metrics are computed on 11–41 test samples within devices, with only 6 or 20 calibration samples in transfer. No confidence intervals, repeated random splits, or significance tests are reported. For example, Pixel 8 total R² improves from 0.953 to 0.960 with 11 test samples, which is well within sampling noise, while Pixel 8 Pro total R² actually degrades from 0.978 to 0.967 but is presented as supporting the full model. The central cross-device claims (e.g., Pixel 8 Pro→Pixel 8 decode R² −1.085→0.927) are therefore not yet statistically supported. Please add uncertainty quantification or repeated splits and interpret differences accordingly.
  4. [Abstract, §5.6, Table 9] The abstract and §1 claim the framework can 'reduce profiling cost' and 'screen candidate models before full target-device execution,' but the screening experiment in §5.6/Table 9 only reports filtering ratios on 2–3 candidate models and never measures profiling cost, wall-clock time, or savings relative to exhaustive benchmarking. The cost-reduction claim is asserted rather than measured. A simple accounting experiment—number of runs avoided, profiling time saved, or cost versus exhaustive search—would make the claim operational.
  5. [§5.1, §5.4] The paper twice states that 'Qwen-family models' are excluded from the reported model pool (§5.1, §5.4), but Qwen models do not appear in Table 2 or Table 4 and no justification for the exclusion is given. If the exclusion is due to data quality or compatibility, say so explicitly; otherwise the reported model pool is a selected subset and its representativeness should be discussed.
minor comments (6)
  1. [§5.2, Table 5] Please state whether the static-only baseline includes the generated-token count. This affects the interpretation of the ablation and the within-device comparisons.
  2. [Eqs. (7)–(9), §3.4.3] The hyperparameters α, λ_pre, λ_dec, and the architecture of the gating network g(·) are not specified, and no sensitivity analysis is reported.
  3. [§6.3] The sentence 'For LLM inference, latency is shaped not only by static model and hardware properties, but also by execution structure and runtime state' appears twice in the same subsection; remove the duplicate.
  4. [Table 6] The calibration counts are very small (6 or 20 samples). Please describe exactly how the calibration set is constructed (number of runs, prompts, models) and how the split is performed.
  5. [Figure 2] The normalized phase time τ is defined, but the 'state' axis, alignment procedure, and state-space smoothing method are not specified. Please clarify the reconstruction algorithm and its parameters.
  6. [References] Some references (e.g., [3], [4]) lack full venue or publication details; please format consistently.

Circularity Check

2 steps flagged

Evaluation feeds test-run telemetry and realized token counts into the predictor, so Tables 5–6 do not validate pre-execution screening.

specific steps
  1. fitted input called prediction [§4.3 Evaluation Protocol; §3.4.2 Eq. (3); §3.6]
    ""the within-domain setting randomly partitions requests from the same device-runtime-model-prompt distribution into training and testing sets" (§4.3); "The dynamic path models execution-dependent behavior using runtime traces collected during profiling. ... D = f_d(x_d)" (§3.4.2); "the full model with calibration uses the complete feature set together with a small calibration set from the target device before final testing" (§4.2)."

    The advertised workflow is screening candidates before target-device execution, but the dynamic branch cannot produce D without a runtime trace of the request whose latency is being predicted. A random partition of complete request records places each test sample's own telemetry into x_d, so the model predicts a run's latency partly from that run's own hardware counters. The paper never restricts test traces to calibration-set traces, and the reported R² gains (e.g., prefill −1.383→0.966) therefore reflect trace-conditioned fitting rather than the claimed pre-execution screening capability.

  2. fitted input called prediction [§4.1 Experimental Setup; §4.2 Baselines]
    ""For each request, we record prompt-side descriptors, including prompt identifier, task category when available, input token count, generated token count, maximum generation length, and runtime configuration." (§4.1); the static-only baseline uses "prompt-level descriptors" and "generation configuration" (§4.2)."

    Generated token count is realized only after autoregressive generation and is unknown at screening time. Decode and total latency are approximately (generated tokens) × (per-token time), so a predictor given the realized token count can fit the target almost directly. Because this value is recorded among the descriptors available to the static branch and no exclusion is stated, the high decode/total R² values (0.957–0.985) partly measure an output-derived input rather than a pre-execution prediction.

full rationale

The central results are not self-contained evidence for the paper's strongest claim. The within-device and calibrated-transfer evaluations appear to consume each test request's own runtime trace to form the dynamic embedding D=f_d(x_d), and the static descriptors include the realized generated-token count. Both are unavailable when screening an unprofiled candidate before full execution, so Tables 5–6 inflate the reported R² relative to the deployment scenario in §3.6–§3.8. The calibration sets are separate from test sets, so the calibration mechanism itself is not circular; the problem is that the test-time dynamic features are self-predictive. There is no load-bearing self-citation chain or imported uniqueness theorem; the circularity is in the evaluation construction, not the citations. Score 6 reflects partial circularity: the reported predictive gains reduce in part to inputs from the same run that produced the latency target, though the framework still contains independent static modeling and calibration components.

Axiom & Free-Parameter Ledger

4 free parameters · 5 axioms · 0 invented entities

The framework's central claim depends on unreported hyperparameters (α, λ_pre, λ_dec, network sizes), on the availability of runtime telemetry before a candidate model is run, on the accuracy of phase segmentation, and on treating realized generated-token count as a pre-execution static feature. No invented entities are introduced; the calibration correction is the de facto free parameter that carries the cross-device results.

free parameters (4)
  • α (MAE/MSE loss balance)
    Eq. 7, L = α·MAE + (1−α)·MSE; value never reported, but it weights every reported result.
  • λ_pre, λ_dec (phase-loss weights)
    Eq. 8 phase-level supervision weights; never specified.
  • calibration correction model parameters = fitted on 6 or 20 target-device samples (Table 6)
    This free correction, not the learned representation, is what turns zero-shot R² from −33 to +0.44 in transfer experiments.
  • temporal encoder / gating network hyperparameters
    Network sizes, feature encodings, training epochs, seeds — all unspecified, so effectively free.
axioms (5)
  • domain assumption Runtime telemetry from heterogeneous devices can be mapped into one unified representation that preserves latency-relevant signal.
    §4.1 maps differing hardware counters into a 'unified runtime-aware representation' without validating cross-device comparability.
  • domain assumption Dynamic telemetry for a target candidate is available at screening time (via calibration runs) without running the candidate itself.
    §3.6: screening relies on a small calibration set to 'estimate dynamic behavior'; no experiment covers prediction for a candidate whose trace was never observed on the target device.
  • domain assumption Realized generated-token count is usable as a pre-execution static feature.
    §4.1 lists generated token count among prompt-side descriptors; it is unknown before execution, so its use inflates within-device R² for the screening use case.
  • standard math Softmax gating (Eq. 4) and Pareto dominance (Eqs. 11–13) behave as standard machinery.
    No novel mathematical content; standard definitions used without proof.
  • domain assumption The runtime's phase segmentation into prefill and decode is accurate across backends.
    §4.1: latency targets depend on the backend's phase timing; segmentation accuracy is unvalidated across MLC-LLM and PyTorch backends.

pith-pipeline@v1.3.0-alltime-deepseek · 15247 in / 21509 out tokens · 218090 ms · 2026-08-02T14:18:33.701612+00:00 · methodology

0 comments
read the original abstract

Accurate latency prediction is critical for deploying large language models (LLMs) on heterogeneous edge devices, where inference latency is affected by model architecture, prompt behavior, runtime backend, hardware utilization, dynamic voltage and frequency scaling (DVFS), and thermal variation. This paper presents a runtime-aware latency prediction framework for deployment-oriented LLM selection. The framework represents each inference request as a hardware-runtime-model-prompt configuration, separates inference into prefill and decode phases, and adaptively fuses static descriptors with dynamic hardware telemetry through a gated prediction model. We evaluate the framework using Pixel mobile devices and validate the profiling pipeline on Jetson Nano, Orange Pi 5 Pro, and an RTX 3090-class GPU platform. On Pixel 8, the full predictor improves total-latency R-squared from 0.953 to 0.960 and decode-latency R-squared from 0.957 to 0.973 over a static-only baseline. On Pixel 8 Pro, it improves prefill-latency R-squared from -1.383 to 0.966. For cross-device transfer, calibration improves Pixel 8 Pro to Pixel 8 total-latency R-squared from -0.974 to 0.940 and decode-latency R-squared from -1.085 to 0.927. Heterogeneous profiling further shows that latency is highly device- and runtime-dependent: the same SmolLM2 model family reaches 8.42 tokens/s on Orange Pi 5 Pro but 64.38 tokens/s on an RTX 3090-class GPU. These results demonstrate that runtime-aware prediction with lightweight calibration can reduce profiling cost and support latency-aware LLM deployment across heterogeneous edge platforms.

Figures

Figures reproduced from arXiv: 2607.21602 by Anu G. Bourgeois, Haoxin Wang, Venkat R. Dasari, Vinod K. Mishra, Xiaolong Tu.

Figure 1
Figure 1. Figure 1: Overall system framework. The system begins with a model space and deployment configuration that includes [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Phase-aware modeling of runtime traces. The raw runtime trace is reorganized into phase-structured representations [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗

discussion (0)

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

Reference graph

Works this paper leans on

23 extracted references · 2 linked inside Pith

  1. [1]

    Large language models on mobile devices: Measurements, analysis, and insights

    Xiang Li, Zhenyan Lu, Dongqi Cai, Xiao Ma, and Mengwei Xu. Large language models on mobile devices: Measurements, analysis, and insights. InProceedings of the Workshop on Edge and Mobile Foundation Models, 2024

    2024

  2. [2]

    On-device language models: A comprehensive review.arXiv preprint arXiv:2409.00088, 2024

    Junxiong Xu et al. On-device language models: A comprehensive review.arXiv preprint arXiv:2409.00088, 2024

    Pith/arXiv arXiv 2024

  3. [3]

    MLC-LLM: Universal llm deployment engine with machine learning compilation

    MLC AI. MLC-LLM: Universal llm deployment engine with machine learning compilation. GitHub repository, 2024. Tu et al

    2024

  4. [4]

    lm-meter: Unveiling runtime inference latency for on-device language models

    Haoxin Wang, Xiaolong Tu, Hongyu Ke, Huirong Chai, Dawei Chen, and Kyung- tae Han. lm-meter: Unveiling runtime inference latency for on-device language models. InProceedings of the Tenth ACM/IEEE Symposium on Edge Computing, pages 1–17, 2025

    2025

  5. [5]

    Understanding large language models in your pockets: Performance study on cots mobile devices.arXiv preprint arXiv:2410.03613, 2024

    Jie Xiao, Qianyi Huang, Xu Chen, and Chen Tian. Understanding large language models in your pockets: Performance study on cots mobile devices.arXiv preprint arXiv:2410.03613, 2024

    arXiv 2024

  6. [6]

    nn-meter: Towards accurate latency prediction of deep- learning model inference on diverse edge devices

    Qiang Zhang et al. nn-meter: Towards accurate latency prediction of deep- learning model inference on diverse edge devices. InMobiSys, 2021

    2021

  7. [7]

    Unveiling energy efficiency in deep learning: Measurement, prediction, and scoring across edge devices

    Xiaolong Tu, Anik Mallik, Dawei Chen, Kyungtae Han, Onur Altintas, Haoxin Wang, and Jiang Xie. Unveiling energy efficiency in deep learning: Measurement, prediction, and scoring across edge devices. InProceedings of the Eighth ACM/IEEE Symposium on Edge Computing, pages 1–14, 2023

    2023

  8. [8]

    Aienergy: An energy benchmark for ai-empowered mobile and iot devices.ITU Journal on Future and Evolving Technologies, 6(2):183–197, 2025

    Xiaolong Tu, Anik Mallik, Haoxin Wang, and Jiang Xie. Aienergy: An energy benchmark for ai-empowered mobile and iot devices.ITU Journal on Future and Evolving Technologies, 6(2):183–197, 2025

    2025

  9. [9]

    On latency predictors for neural architecture search

    Yash Akhauri, Mohamed Abdelfattah, David Singh, et al. On latency predictors for neural architecture search. InProceedings of Machine Learning and Systems, 2024

    2024

  10. [10]

    Efficient memory management for large language model serving with pagedattention

    Woosuk Kwon, Eric Yin, et al. Efficient memory management for large language model serving with pagedattention. InProceedings of the ACM SIGOPS 29th Symposium on Operating Systems Principles, 2023

    2023

  11. [11]

    ztt: Learning-based dvfs with zero thermal throttling for mobile devices

    Seyeon Kim, Kyungmin Bin, Sangtae Ha, Kyunghan Lee, and Song Chong. ztt: Learning-based dvfs with zero thermal throttling for mobile devices. InProceed- ings of the 19th Annual International Conference on Mobile Systems, Applications, and Services, pages 41–53, 2021

    2021

  12. [12]

    A workload-aware dvfs robust to concurrent tasks for mobile devices

    Chengdong Lin, Kun Wang, Zhenjiang Li, and Yu Pu. A workload-aware dvfs robust to concurrent tasks for mobile devices. InProceedings of the 29th Annual International Conference on Mobile Computing and Networking, 2023

    2023

  13. [13]

    Impact of thermal throttling on long-term visual inference in a cpu-based edge device

    Théo Benoit-Cattin, Delia Velasco-Montero, and Jorge Fernández-Berni. Impact of thermal throttling on long-term visual inference in a cpu-based edge device. Electronics, 9(12):2106, 2020

    2020

  14. [14]

    Orca: A distributed serving system for transformer-based generative mod- els

    Gyeong-In Yu, Joo Seong Jeong, Geon-Woo Kim, Soojeong Kim, and Byung-Gon Chun. Orca: A distributed serving system for transformer-based generative mod- els. In16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 22), pages 521–538. USENIX Association, 2022

    2022

  15. [15]

    Distserve: Disaggregating prefill and decoding for goodput-optimized large language model serving

    Yinmin Zhong, Sheng Shen, et al. Distserve: Disaggregating prefill and decoding for goodput-optimized large language model serving. In18th USENIX Symposium on Operating Systems Design and Implementation (OSDI 24). USENIX Association, 2024

    2024

  16. [16]

    An analysis of power consumption in a smartphone

    Aaron Carroll and Gernot Heiser. An analysis of power consumption in a smartphone. In2010 USENIX Annual Technical Conference (USENIX ATC 10). USENIX Association, 2010

    2010

  17. [17]

    Onur Sahin and Ayse K. Coskun. On the impacts of greedy thermal management in mobile devices.IEEE Embedded Systems Letters, 7(2):55–58, 2015

    2015

  18. [18]

    Deepen2023: Energy datasets for edge artificial intelligence.arXiv preprint arXiv:2312.00103, 2023

    Xiaolong Tu, Anik Mallik, Haoxin Wang, and Jiang Xie. Deepen2023: Energy datasets for edge artificial intelligence.arXiv preprint arXiv:2312.00103, 2023

    Pith/arXiv arXiv 2023

  19. [19]

    Help: Hardware-adaptive efficient latency prediction for nas via meta-learning

    Hayeon Lee, Sewoong Lee, and Song Chong. Help: Hardware-adaptive efficient latency prediction for nas via meta-learning. InAdvances in Neural Information Processing Systems, volume 34, pages 27023–27036, 2021

    2021

  20. [20]

    Hw-nas-bench: Hardware-aware neural architecture search benchmark

    Chunyu Li, Liangzhen Lai, Hanrui Wang, Yiran Chen, et al. Hw-nas-bench: Hardware-aware neural architecture search benchmark. InInternational Confer- ence on Learning Representations (ICLR), 2021

    2021

  21. [21]

    Litepred: Transferable and scalable latency prediction for hardware-aware neural architecture search

    Chengquan Feng, Li Lyna Zhang, Yuanchi Liu, Jiahang Xu, Chengruidong Zhang, Zhiyuan Wang, Ting Cao, Mao Yang, and Haisheng Tan. Litepred: Transferable and scalable latency prediction for hardware-aware neural architecture search. In21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24), pages 1463–1479, 2024

    2024

  22. [22]

    Platformx: An end-to-end transferable platform for energy-efficient neural ar- chitecture search

    Xiaolong Tu, Dawei Chen, Kyungtae Han, Onur Altintas, and Haoxin Wang. Platformx: An end-to-end transferable platform for energy-efficient neural ar- chitecture search. InProceedings of the Tenth ACM/IEEE Symposium on Edge Computing, pages 1–16, 2025

    2025

  23. [23]

    Greenauto: An automated platform for sustainable ai model design on edge devices

    Xiaolong Tu, Dawei Chen, Kyungtae Han, Onur Altintas, and Haoxin Wang. Greenauto: An automated platform for sustainable ai model design on edge devices. InProceedings of the 26th International Workshop on Mobile Computing Systems and Applications, pages 7–12, 2025

    2025