{"id":"4ababc15-65b6-413c-b677-645a361e4c68","arxiv_id":"2603.22774","paper_version":2,"verdict":"UNVERDICTED","confidence":"LOW","novelty_score":4.5,"correctness_risk":"high","formal_verification":"none","parameter_count":0,"one_line_summary":"CPU under-provisioning, not GPU saturation, is a primary bottleneck in multi-GPU LLM inference; more CPU cores cut TTFT 1.47–5.15× at low marginal cost.","lead":"Multi-GPU LLM servers often run slowly because the CPU cannot keep the GPUs busy, not because the GPUs are saturated. Adding relatively cheap CPU cores can cut time-to-first-token by about 1.5–5× and stop timeouts without buying more GPUs.","discovery_kind":"extension","skeptic_critique":{"model":"grok-4.5","headline":"Body is unrelated number-theory paper; systems claims on CPU-induced LLM slowdowns cannot be checked.","rationale":"The reader already identified the title/abstract vs. body mismatch and correctly applied abstract-only rules, producing UNVERDICTED with low confidence. No technical soft spot inside an unseen argument can be diagnosed; the load-bearing obstacle is simply the missing manuscript. Supplying the correct full text is the only action that would allow a soundness or novelty re-evaluation. Verdict therefore remains unchanged.","tokens_in":9010,"tokens_out":401,"duration_ms":13102,"concrete_test":"Retrieve the genuine full PDF/source of arXiv:2603.22774 and re-run the review; if it contains ablations that fix GPU count, model, interconnect and memory bandwidth while varying only CPU cores (and still recover the reported TTFT factors under moderate load), the claim can be re-scored; otherwise retain abstract-only UNVERDICTED status.","verdict_should_be":"UNVERDICTED","load_bearing_attack":"The strongest claim (limited CPU cores cause delayed launches, stalled comms, tokenization latency and GPU underutilization in multi-GPU LLM serving; extra cores restore responsiveness and cut TTFT 1.47–5.15×) rests on methods, ablations and measurements that are absent. The supplied full text is Kawalec’s k-free Dirichlet series manuscript (arXiv 2603.22775), not 2603.22774. Consequently the reader’s weakest assumption—that the slowdowns are primarily CPU-core-count effects rather than memory bandwidth, NUMA, PCIe/NVLink topology or stack configuration—cannot be examined at all. No figures, hardware tables, serving-stack details or controlled experiments exist in the provided body, so the claim is unverifiable rather than internally inconsistent.","agreement_with_reader":"agree"},"referee_report":{"model":"grok-4.5","summary":"The submission is titled and abstracted as an empirical systems paper (cs.AR) claiming that multi-GPU LLM inference is often limited by insufficient CPU resources rather than GPU saturation, with symptoms including delayed kernel launch, stalled communication, and elevated tokenization latency, and that increasing CPU cores restores responsiveness and reduces TTFT by 1.47–5.15× under moderate load without extra GPUs. The provided full manuscript body, however, is an unrelated number-theory article on the Laurent expansion and analytic continuation of the k-free Dirichlet series ζ(s)/ζ(ks), Stieltjes-type formulas for coefficients γ_{M,k}^n, and limit formulas for ζ(1/k). No systems methods, hardware, serving stacks, workloads, or measurements appear in the body.","tokens_in":9187,"tokens_out":878,"duration_ms":12467,"significance":"If the abstract’s systems claims were supported by a matching manuscript with controlled multi-GPU experiments, ablations isolating CPU core count from NUMA/PCIe/memory effects, and reproducible serving configurations, the work could be practically useful for cost-aware LLM serving. As submitted, the body does not advance those claims at all; the mathematical content on k-free series is a separate contribution that is not what the title, abstract, or category advertise. There is therefore no verifiable systems significance in this package.","major_comments":[{"comment":"Title/abstract vs. full text: the abstract and paper_id claim a multi-GPU LLM inference systems study with TTFT gains of 1.47–5.15× under CPU reallocation, but the entire body (Introduction through §4, Tables 1–5, Figures 1–4, and references) is Kawalec’s manuscript on k-free Dirichlet series (Laurent expansion (4), Theorem 1 / Eq. (5), analytic continuation (49), and ζ(1/k) formulas (55)–(60)). No experimental section, hardware table, serving stack, load generator, or latency measurement exists. The central systems claim is therefore unsupported by the manuscript as provided.","section":null},{"comment":"Absence of any evaluation of the load-bearing claim: the abstract’s causal story (limited CPU cores → delayed kernel launch / stalled communication / tokenization latency → GPU underutilization; extra cores restore TTFT) cannot be assessed. There are no controlled CPU-allocation sweeps, no isolation from confounds (memory bandwidth, NUMA, PCIe/NVLink topology, scheduler noise, process-level separation, CUDA Graphs), and no error bars or timeout methodology. Without that evidence the 1.47–5.15× TTFT range and timeout-recovery claim are unverifiable.","section":null},{"comment":"Category and contribution mismatch: primary_cat is cs.AR and the abstract targets multi-GPU LLM serving, yet the body is pure analytic number theory (Möbius k-free indicator, Stieltjes integration of Q_k(x), RH-conditional bounds). A journal in computer architecture cannot evaluate or accept this package as a systems paper; the mathematical content would need to be submitted under the correct title, abstract, and venue.","section":null}],"minor_comments":[{"comment":"Even as a standalone number-theory note, the body has presentation issues (e.g., inconsistent notation γ_{M,k} vs. γ_{M,k}^n / γ_M^{n,k}, typographical glitches such as “xX” in sums, and figures described but not quantitatively summarized beyond oscillation about known ζ(1/k) values). These are secondary to the identity mismatch.","section":null}],"recommendation":"reject","confidential_remarks":"The supplied full text is clearly arXiv:2603.22775 (Kawalec, k-free Dirichlet series), not a systems manuscript matching 2603.22774. This looks like a packaging/cache error or wrong PDF attachment rather than a borderline systems paper. Recommend desk-reject or return to authors for the correct manuscript; do not send the number-theory body to architecture reviewers as if it were the LLM-serving study."},"author_rebuttal":null,"desk_editor":{"model":"grok-4.5","letter":"The one thing you need to know: the cacheable full text is not this paper. Title and abstract are Chung et al. on CPU-induced slowdowns in multi-GPU LLM inference (2603.22774). The body is Kawalec’s k-free Dirichlet series note (2603.22775). So this is effectively abstract-only for the systems work.\n\nFrom the abstract alone, the claim is operationally useful if true. Multi-GPU LLM serving often leaves GPUs idle because the host cannot keep up—delayed launches, stalled collectives, tokenization latency—even with process separation and CUDA Graphs. Extra CPU cores are cheap relative to GPUs and, under moderate load, are said to stop timeouts and cut TTFT by roughly 1.5–5× without buying more GPUs. That is the kind of cost/reliability guidance fleet operators actually want. Framing known host-side bottlenecks specifically for modern LLM serving stacks is a reasonable incremental contribution; it is not a new algorithm or hardware primitive.\n\nWhat we cannot do is verify any of it. No hardware table, models, serving stack versions, load generator, CPU/GPU allocation matrix, NUMA/PCIe notes, ablations, or error bars appear in the provided body. The weakest assumption—that core count is the primary cause rather than memory bandwidth, topology, scheduler noise, or stack config—is exactly what the missing methods would have to pin down. The numeric range 1.47–5.15× is therefore uncheckable marketing until the right PDF shows up.\n\nWho this is for: systems people running multi-GPU inference who care about $/token and tail latency. A serious referee should see the real manuscript if it matches the abstract; the topic is important enough for review time. With the wrong body in hand, I would not bring it to reading group, would not cite it, and would not treat the numbers as established. Get the correct full text and re-read; until then the paper is a claim, not a result.","headline":"We only have the abstract for the multi-GPU CPU paper; the supplied full text is an unrelated number-theory manuscript, so the systems claims cannot be checked.","tokens_in":9786,"tokens_out":509,"would_cite":false,"duration_ms":12194,"reading_group":"no","serious_thinker":"unclear","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"grok-4.5","headline":"Multi-GPU LLM inference often slows because CPUs cannot keep the GPUs busy, not because the GPUs are saturated.","keywords":["multi-GPU","LLM inference","CPU bottleneck","time-to-first-token","CUDA Graphs","GPU underutilization","serving systems","kernel launch"],"falsifier":"Hold CPU core count fixed and vary only memory bandwidth, NUMA binding, or PCIe/NVLink topology on the same serving stack and load; if the same timeouts and TTFT gaps still appear or vanish independently of core count, the core-count claim fails. Alternatively, reproduce the reported 1.47–5.15× TTFT gains solely by adding cores under otherwise identical hardware and software.","tokens_in":9901,"feed_emoji":"🖥️","tokens_out":834,"duration_ms":24242,"temperature":0.7,"pith_summary":"Large language model inference on multi-GPU machines is frequently limited by the CPU rather than the GPUs. When too few CPU cores are allocated, kernel launches are delayed, communication stalls, and tokenization slows, so GPUs sit idle even though GPU capacity remains. These effects appear even in serving stacks that isolate processes and use CUDA Graphs. Because extra CPU cores cost little compared with GPU instances, simply giving the system more cores restores responsiveness under moderate load, eliminates many timeouts, and reduces time-to-first-token latency by 1.47 to 5.15 times without adding any GPUs.","feed_headline":"Extra CPU cores cut LLM first-token latency up to 5x","feed_subtitle":"Multi-GPU serving often leaves GPUs idle when CPUs are too few; more cores fix it cheaply","key_machinery":"A detailed empirical characterization of modern multi-GPU LLM inference and serving stacks under constrained CPU core counts, measuring the resulting launch, communication, and tokenization stalls and the TTFT and timeout improvements obtained by increasing cores.","core_discovery":"Under limited CPU allocations, multi-GPU LLM inference and serving degrade through delayed kernel launch, stalled communication, and increased tokenization latency, producing severe GPU underutilization even when GPU resources are ample; supplying adequate CPU cores restores stability and cuts time-to-first-token latency by 1.47–5.15× at minimal extra cost.","pith_inferences":["Similar CPU-side starvation is likely in multi-GPU training or other tightly synchronized GPU workloads once kernels become short or communication-heavy.","Hardware and cloud instance design may need to rebalance CPU–GPU ratios or accelerate the CPU–GPU control path for LLM serving.","Tokenization and request preprocessing may need further offload or hardware acceleration when CPU cores remain scarce.","NUMA and interconnect topology effects could interact with the reported core-count sensitivity and warrant separate measurement."],"forward_implications":["Operators can improve multi-GPU LLM serving latency and reliability by provisioning more CPU cores per GPU instead of more GPUs.","Serving frameworks should treat CPU-side launch latency, tokenization, and communication scheduling as first-class monitored bottlenecks.","Cost models for multi-GPU inference must treat CPU core count as a first-order design variable, not a free secondary resource.","Process-level isolation and CUDA Graphs alone do not remove the need for sufficient CPU capacity.","Under moderate load, CPU-starved configurations can time out while GPU-rich but CPU-poor setups remain unresponsive."],"fun_headline_variants":["CPU starvation idles multi-GPU LLMs despite free accelerators","Extra CPU cores restore LLM TTFT and cut latency 1.5-5x","Limited CPUs stall kernels and tokenization in multi-GPU serving","More cores end GPU underuse in multi-GPU LLM inference cheaply","CPU bottlenecks delay launches and raise TTFT in multi-GPU stacks"],"cache_read_input_tokens":128,"weakest_assumption_plain":"The observed slowdowns and speedups are caused mainly by the number of CPU cores rather than by memory bandwidth, NUMA placement, interconnect topology, scheduler noise, or serving-stack configuration, and the tested loads represent real multi-GPU serving.","fun_headline_variants_meta":{"raw":{"variants":["CPU starvation idles multi-GPU LLMs despite free accelerators","Extra CPU cores restore LLM TTFT and cut latency 1.5-5x","Limited CPUs stall kernels and tokenization in multi-GPU serving","More cores end GPU underuse in multi-GPU LLM inference cheaply","CPU bottlenecks delay launches and raise TTFT in multi-GPU stacks"]},"model":"grok-4.5","effort":"low","cost_usd":0.003578,"raw_usage":{"total_tokens":1161,"prompt_tokens":751,"num_sources_used":0,"completion_tokens":98,"cost_in_usd_ticks":35780000,"prompt_tokens_details":{"text_tokens":751,"audio_tokens":0,"image_tokens":0,"cached_tokens":256},"completion_tokens_details":{"audio_tokens":0,"reasoning_tokens":312,"accepted_prediction_tokens":0,"rejected_prediction_tokens":0}},"tokens_in":751,"tokens_out":98,"duration_ms":4214,"temperature":1.0,"reasoning_tokens":312,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-13T20:05:17.684960+00:00","model_set":{"reader":"grok-4.5"},"falsifier":"Hold CPU core count fixed and vary only memory bandwidth, NUMA binding, or PCIe/NVLink topology on the same serving stack and load; if the same timeouts and TTFT gaps still appear or vanish independently of core count, the core-count claim fails. Alternatively, reproduce the reported 1.47–5.15× TTFT gains solely by adding cores under otherwise identical hardware and software.","supporting_citations":[],"review_version":1}