{"id":"e5bbe18f-e031-4e15-b8bc-339a0abb7817","arxiv_id":"2602.00343","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"A phase-aware carbon-accounting method for federated learning shows that client efficiency tiers and coordination idle time can inflate total CO2e by 8-22x, while GPU choice changes runtime more than energy.","lead":"This paper proposes a standard way to measure the carbon footprint of federated learning, using NVIDIA's NVFlare and the CodeCarbon tracker, and tests it on image classification and retinal segmentation. Slower, less efficient clients and coordination delays can increase total CO2e by up to roughly 22x under the same training protocol.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Central methodology relies on uncalibrated CodeCarbon process-level energy attribution per NVFlare client; with concurrent client processes this can be inaccurate, so empirical ratios and recommendations lack a verified measurement basis.","rationale":"The reader's CONDITIONAL verdict is appropriate. The central methodological claim—that the proposed pipeline provides a standardized and reproducible carbon accounting for FL—is plausible, especially given the open-source implementation and use of widely adopted tools. However, the empirical support depends crucially on CodeCarbon's process-level energy attribution, which the paper does not validate against any ground truth. This concern is load-bearing because all quantitative conclusions (the 8.34×/21.73× ratios, the 1.7× runtime gap, and per-site CO2e differences) are computed from those per-client energy estimates. A concrete calibration test would determine whether the methodology's numbers are trustworthy. The paper's omission of I_net and F_grid also undermines reproducibility, but that is secondary to the measurement-accuracy issue. The reader already identified this as the weakest assumption; our stress test agrees and makes the specific parallel-process/GPU-attribution risk explicit. The verdict remains CONDITIONAL: the method could be sound, but the authors must add calibration/uncertainty analysis and specify all model parameters before the empirical claims can be accepted. No basis is found to reject outright, because the methodological framework itself is not invalidated by the identified gaps.","tokens_in":7482,"tokens_out":6161,"duration_ms":75929,"concrete_test":"Run the smallest CIFAR-10 FL experiment (6 clients, high-efficiency baseline) on a single host with a calibrated wall-plug power meter and with CodeCarbon logging per client. Measure total host energy during the run and sum the per-client CodeCarbon estimates (plus server-side overhead). Repeat with clients executed sequentially and concurrently, matching the actual experimental setup. If the summed CodeCarbon estimate deviates from the power meter by more than 15%, or if the deviation changes between sequential and concurrent execution, the per-client attribution is unreliable and the empirical section requires recalibration or a different measurement strategy. Also report the exact I_net and F_grid values used so the comparison can be reproduced.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is that the NVFlare + CodeCarbon pipeline yields a standardized, reproducible carbon-accounting method. Its empirical validation rests on per-client energy values ('Client-side emissions tracking', §2.2) obtained with CodeCarbon's EmissionsTracker in tracking_mode='process', measure_power_secs=1. The text reports no calibration against physical power meters and no uncertainty analysis. This is not a minor detail: an NVFlare simulation with six clients typically launches separate processes on the same host, and CodeCarbon's process-mode GPU attribution apportions device power to a process using utilization or memory fractions. When multiple clients run concurrently and contend for the same GPU, attribution error can be large, and the sum of per-client estimates can diverge materially from the host's actual energy draw. All headline results—the 8.34×/21.73× CO2e ratios, the 1.7× H100/V100 gap, and the per-site/per-round reporting recommendation—are derived from these per-client energy numbers; if attribution is biased, those numbers do not support the methodological conclusions. In addition, the communication energy model (§2.4) leaves I_net and F_grid unspecified, so absolute totals are not reproducible. The weakest load-bearing assumption is therefore the unvalidated accuracy of CodeCarbon's per-process, per-client energy readings in a multi-client simulated FL setting.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a standardized carbon-accounting methodology for federated learning, integrating NVIDIA NVFlare with CodeCarbon process-level energy tracking to attribute CO2e to explicit phases (initialization, per-round training, idle/coordination, evaluation) and supplementing measured compute energy with an estimated communication-energy term. The authors report experiments on CIFAR-10 classification and retinal optic disk segmentation, including controlled client-efficiency tiers (high/medium/low) and an H100 versus V100 GPU comparison, and claim that their method supports reproducible green-FL evaluation. The main empirical findings are that medium- and low-efficiency tiers increase total CO2e by 8.34x and 21.73x relative to the high-efficiency baseline, and that H100/V100 runs show a ~1.7x runtime gap with non-uniform energy changes across sites.","tokens_in":7814,"tokens_out":4212,"duration_ms":50498,"significance":"If the method were soundly validated, it would provide a valuable measurement boundary and logging schema for the green-FL community, addressing a real need for comparable carbon accounting across FL studies. The paper also ships code and uses a configuration-driven workflow, which are strengths for reproducibility. However, the current manuscript does not substantiate the validation: the experimental sections are empty, and the measurement assumptions are not calibrated or uncertainty-quantified. The significance is therefore potential rather than established.","major_comments":[{"comment":"The core validation sections are missing from the submitted text. Headings '3.1 CIFAR-10 with Efficiency Testing', '3.2 Retinal Optic Disk Segmentation', '4 Discussion', and '5 Conclusion' appear with no body text. Tables 1–2 and Figures 2–5 are referenced but never described or interpreted. The central claim that the methodology is 'validated' on two workloads cannot be assessed. This is a load-bearing omission that must be repaired before any decision.","section":"§3.1–§3.2, §4, §5"},{"comment":"The entire empirical basis rests on CodeCarbon's process-level EmissionsTracker (tracking_mode='process', measure_power_secs=1) for per-client energy attribution. The manuscript reports no calibration against physical power meters, no repeated runs, and no uncertainty analysis. Since six clients run as separate processes on the same host, per-process GPU power attribution can be materially biased when processes contend for the same GPU. All headline CO2e ratios (8.34x, 21.73x) and the per-site comparisons derive from these per-client estimates; without a validation of the measurement, the empirical conclusions are unsupported.","section":"§2.2, 'Client-side emissions tracking'"},{"comment":"The communication emission model is specified as E_comm = 2 * D_GB * I_net and C_comm = E_comm * F_grid, but neither I_net (network energy intensity) nor F_grid (grid carbon factor) is given a numerical value or a source. Absolute emission totals are therefore not reproducible, undermining the paper's stated goal of a standardized, reproducible method. Additionally, the linear relationship between transmitted bytes and energy is an assumption with no cited basis or experimental justification.","section":"§2.4, Eq. (1)"},{"comment":"The efficiency-tier experiments are produced by 'injecting slowdowns' into the client training loop. The resulting ratios (8.34x and 21.73x) are arithmetic consequences of the chosen slowdown factors, not independent empirical discoveries about naturally occurring FL inefficiencies. This is acceptable as a demonstration of the measurement method, but the paper should explicitly frame it as such and report the actual slowdown-injection parameters. Without that, the claims risk being circular and are not reproducible.","section":"§2.5 and Table 1"},{"comment":"Site 1 reports identical energy (0.32 kWh) and identical CO2e (0.13 kg) for H100 and V100 runs, despite a 503-minute versus 290-minute runtime gap. This implies very different average power draws (≈38 W for V100 vs. ≈66 W for H100), which is surprising and may indicate a measurement artifact or a reporting error. The row undermines confidence in the H100/V100 comparison and needs a specific explanation or verification.","section":"Table 2, Site 1 row"}],"minor_comments":[{"comment":"The columns 'Mean energy (kWh/round)' and 'Mean CO2e (kg/round)' appear to be per-client-per-round averages, but this is not stated. The relationship between these values and 'Total CO2e' is not evident without assuming six clients and ten round. Clarify the aggregation.","section":"Table 1"},{"comment":"Several references have incorrect or inconsistent years (e.g., McMahan et al. is listed as 2023 despite the arXiv 1602.05629 reference; ACM copyright notice says 2018). Also, reference [15] and [20] appear to be the same work cited twice with different formatting. These need cleanup.","section":"References"},{"comment":"Figures 2–5 are referenced but not described in the text, and their captions are minimal. If the validation sections are restored, each figure needs an explicit discussion.","section":"Figures"},{"comment":"The measurement boundary is described as 'comparable across FL deployments,' but the list mixes measured and estimated components without a clear statement of which quantities enter the reported totals. A formula with explicit terms would help.","section":"§2.1"},{"comment":"The paper contains several typographical and formatting issues, including inconsistent use of 'CO2e' vs. 'CO 2e', a footnote number without a corresponding footnote, and a dangling URL in Figure 5's caption. These should be corrected.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The submitted text appears incomplete: the experimental sections are headings only, and the results tables and figures are left uninterpreted. This may be an artifact of the submission pipeline, but as received, the paper lacks any actual validation content. The measurement-calibration concern is also serious: CodeCarbon process-level tracking in a multi-client simulation is not a validated basis for the quantitative claims. I would not recommend rejection outright because the methodological framework is potentially useful and the missing material could be supplied, but the revision must include full experimental sections, explicit parameter values for I_net and F_grid, a calibration or sensitivity analysis, and a description of the slowdown injection."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper gives the FL community something it doesn't quite have: a concrete, arguably standardizable accounting schema for carbon emissions in NVFlare, with explicit phases (init, idle, per-round training, evaluation) and a communication-emissions estimate. That's a useful engineering contribution, and the authors are honest that prior frameworks like Flower-based FedSynthesis and Nebula/GreenDFL already measure emissions; their hook is integration with a production orchestrator and a clean per-site/per-round reporting boundary. The cuDNN initialization isolation is a sensible detail. The writing is straightforward, and the code is linked, which is real evidence of reproducibility.\n\nWhere the paper gets soft is the empirical layer. The most load-bearing assumption — that CodeCarbon's process-level tracker gives accurate per-client energy in a multi-client simulation running on the same host — is never validated against a power meter or an independent energy model. The stress-test note is right: when six client processes share a GPU, CodeCarbon's apportionment can be off by a lot, and all the headline ratios (8.34x, 21.73x, 1.7x) are built on those numbers. The paper doesn't report any error bars or repeated runs. This is not a minor omission; it's the difference between a demonstration and a calibrated measurement.\n\nAlso, the communication model is presented with an equation but no numeric values for I_net or F_grid, so the absolute totals are not reproducible. And the \"efficiency tier\" tests inject slowdowns without specifying how the slowdowns are applied, making the CIFAR-10 ratios a consequence of the injection rather than an independent finding. The paper should frame those results as a validation of the method's sensitivity, not as a discovery about FL.\n\nThe most glaring issue is the manuscript itself: sections 3.1, 3.2, 4, and 5 are empty headings. That makes it impossible to audit the results reported in the tables. Some of that may be an artifact of the submission format, but it means the paper as submitted is incomplete.\n\nThe H100/V100 table also has at least one oddity: site 1 shows identical energy and CO2e for both GPUs despite a 213-minute runtime difference. That needs explanation or correction.\n\nBottom line: the methodology is plausible and the proposal is worth engaging with, but the empirical backing needs real work: calibrate CodeCarbon, specify the network model parameters, detail the slowdown injections, and finish the missing sections. A serious referee could give constructive direction here, so I'd send it to review for a workshop-style venue or an e-Energy poster, not for publication in its current form. For my own reading list, it's a maybe — the standardization discussion is relevant, but the paper isn't there yet.","headline":"A practical NVFlare+CodeCarbon integration for standardized FL carbon accounting, but the empirical validation is under-specified and the measurement accuracy is uncalibrated.","tokens_in":8270,"tokens_out":3355,"would_cite":false,"duration_ms":39265,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Federated learning's carbon footprint can only be compared across studies if researchers adopt a standardized, phase-aware accounting method that includes both compute and communication emissions.","keywords":["green federated learning","carbon accounting","CodeCarbon","NVFlare","energy measurement","communication emissions","carbon intensity","reproducibility"],"falsifier":"Run the same CIFAR-10 FL experiment while logging each client's wall power with a calibrated meter; if CodeCarbon's process-level total energy differs systematically from the meter, or if the meter shows idle-phase energy the tracker misses, then the reported CO2e totals and the 8.34x/21.73x ratios will not survive.","tokens_in":7402,"feed_emoji":"🌱","tokens_out":4876,"duration_ms":51713,"temperature":0.7,"pith_summary":"This paper argues that federated learning's environmental cost cannot be meaningfully compared across studies until researchers agree on how to measure it. It offers a concrete protocol: attribute emissions to initialization, per-round training, evaluation, and idle/coordination phases at each client, and add an estimate for communication based on model-update size. Using this protocol on CIFAR-10, it finds that slower client hardware and coordination idle increase total CO2e by 8.34x and 21.73x over a high-efficiency baseline, costs that a fixed FL protocol hides. On retinal segmentation, swapping H100 for V100 GPUs changes runtime by roughly 1.7x but shifts energy and emissions unevenly across sites, arguing for per-site and per-round reporting. The paper's claim is that reproducible 'green' FL evaluation requires a standardized measurement boundary.","feed_headline":"Client slowdowns can multiply federated-learning emissions 21x","feed_subtitle":"Phase-aware accounting shows coordination idle and slow clients drive most of the carbon cost.","key_machinery":"The central mechanism is the phase-aware task boundary: CodeCarbon's EmissionsTracker with tracking_mode='process' and measure_power_secs=1, wrapped around explicit NVFlare client tasks (init, idle_time, round_k, evaluate), plus a communication-emissions estimator E_comm = 2 * D_GB * I_net, scaled by grid carbon intensity F_grid. This instrumentation converts an opaque FL run into a stream of per-round, per-site energy and CO2e numbers that can be aggregated and compared. The measurement boundary—including idle and one-time initialization—is what makes the accounting comparable across deployments.","core_discovery":"The discovery is that a standardized, phase-aware carbon accounting layer for federated learning is feasible and necessary. By wrapping each NVFlare client with CodeCarbon's process-level tracker and logging explicit tasks for initialization, idle time, per-round training, and evaluation, while additionally estimating communication emissions from transmitted update bytes, the authors obtain a comparable carbon footprint for FL workloads. Their measurements show that system-level inefficiency and coordination idle can dominate the carbon cost of an otherwise identical FL protocol, and that heterogeneous client hardware changes both runtime and the distribution of emissions across sites. The a","pith_inferences":["Left implicit in the paper is that the protocol can be extended to server-side aggregation and orchestration energy; the paper measures client-side and communication only, and adding server energy would likely raise the coordination share further.","The efficiency-tier ratios (8.34x, 21.73x) are tied to the specific injected slowdown schedules; a useful next test is to calibrate the protocol against physical power meters and to define a standard slowdown taxonomy so ratios transfer across studies.","The communication-emissions model uses a constant network energy intensity; plugging in time-varying or per-link intensity would let the same framework produce location- and time-aware footprints, which the paper identifies as a driver but does not implement.","Because the tracker's absolute values are estimates, the strongest use of this method is relative comparison across FL configurations rather than carbon certification; future work could add uncertainty bounds to each reported number."],"forward_implications":["Green-FL studies that report only compute energy will miss coordination idle and communication, which for slow clients can dominate the total.","A fixed FL protocol on less efficient client machines can produce more than 20 times the CO2e of the same protocol on efficient machines, so hardware tier must be reported as a covariate.","GPU-tier choices such as H100 vs V100 change both runtime and the spatial distribution of emissions across sites, so per-site and per-round reporting is necessary for fair comparisons.","A lightweight instrumentation layer around existing FL orchestration can yield standardized carbon numbers without requiring new hardware.","Because grid carbon intensity varies by location, the same energy use can correspond to very different CO2e; standardized reporting must include location or grid-intensity metadata."],"fun_headline_variants":["Standardized carbon accounting reveals 21x FL emission cost","Coordination idle can inflate federated-learning carbon 21x","Client inefficiency multiplies federated-learning CO2e 21x","Federated-learning carbon varies 21x with client slowdowns"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The entire empirical payload assumes CodeCarbon's process-level energy estimator faithfully captures each client's real CPU, GPU, and RAM draw without calibration against a physical meter.","fun_headline_variants_meta":{"raw":{"variants":["Standardized carbon accounting reveals 21x FL emission cost","Coordination idle can inflate federated-learning carbon 21x","Client inefficiency multiplies federated-learning CO2e 21x","Federated-learning carbon varies 21x with client slowdowns"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000899,"raw_usage":{"total_tokens":3721,"prompt_tokens":768,"completion_tokens":2953,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":512,"completion_tokens_details":{"reasoning_tokens":2879}},"tokens_in":512,"tokens_out":2953,"duration_ms":24747,"temperature":1.0,"reasoning_tokens":2879,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-03T06:04:16.790701+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same CIFAR-10 FL experiment while logging each client's wall power with a calibrated meter; if CodeCarbon's process-level total energy differs systematically from the meter, or if the meter shows idle-phase energy the tracker misses, then the reported CO2e totals and the 8.34x/21.73x ratios will not survive.","supporting_citations":[],"review_version":1}