Six research topics that assume the worst case: one Frontenac node, CPU only, no GPU guaranteed, memory not guaranteed either. The memory constraint is treated as a first-class design input rather than a caveat — there is a full section on working out your real ceiling before choosing a topic. Every topic is grounded in a paper verified this session (real identifier, cross-checked title, no fabrication) and points at real, verified HuggingFace models or GitHub repos a team can clone today — not a training exercise, a reproduction-and-extension exercise.
Volume II's Tier 6 flagships (T6.6–T6.8) assume multi-GPU access on Frontenac. That is real, but it is not guaranteed for every team, every term. This track answers a different, harder-in-a-different-way question: what is genuinely publishable using one CPU-only node and open resources anyone can download for free?
The answer, grounded in five papers verified this session, is: quite a lot. CPU-only LLM inference, distillation, and retrieval-augmented generation are all active 2024–2026 research areas in their own right — not consolation prizes for teams without GPUs, but a real subfield with real venues (NeurIPS workshops, ACM ToIoT, HPCA) studying exactly this constraint.
Every resource cited below is free: open-weight models on HuggingFace, open-source code on GitHub, and — for topic T-CPU2 — hardware QHPC already owns (the Pi cluster). No topic in this track requires a purchase, a GPU allocation, or a cloud bill.
Each entry below states: (1) what real paper and resources it builds on, (2) whether one CPU-only node is actually sufficient, (3) a specific falsifiable question, (4) a method sketch, (5) a path to a finished paper, and — new in this revision — (6) what makes it look like a CUCAI or QMIND submission rather than a systems-lab report. That sixth item is not decoration; see below for why it earns its own section.
This section exists because a fair complaint was raised about the topics in this track and in Volume II: they read as HPC systems-measurement studies, and CUCAI/QMIND submissions do not typically look like that. That complaint deserved checking against real evidence rather than a guess, so the two organizations' own public materials were fetched directly.
| Source | What it actually showcases |
|---|---|
| cucai.ca (four streams: Applied AI, AI Ethics, AI Research, AI in Healthcare) | Three highlighted past projects: EEG — noisy EEG classification via an attention-based neural network; American Sign Language Recognition — CNN/LSTM comparison for ASL classification, deployed as an interactive GUI for education; RL2 — a reinforcement-learning agent that learns Rocket League maneuvers. |
| qmind.ca ("200+ lifetime AI papers & projects") | Four named projects: Virtual Assistant Attention Detection, Quantum Generative Adversarial Networks, Android Waste Classification, Predictive Diabetic Risk Modelling. |
Neither organization publishes a formal proceedings archive, so this is a small, homepage-curated sample — likely biased toward the most demo-friendly projects, not a full census of every accepted paper. Treated honestly, though, the pattern across all seven examples is unmistakable: apply a named ML technique (attention networks, CNN/LSTM, RL, GANs) to a named, recognizable task (EEG signals, sign language, a video game, waste photos, diabetes risk, virtual-assistant attention), build a working artifact, and report a metric — frequently with a live demo or GUI.
QHPC's Tier 4–6 and CPU-only-track topics are genuine, legitimate research — arguably more methodologically rigorous than a typical demo project, because they're built around a falsifiable measurement question with a stated refutation condition. But rigor and recognizability are different axes. A scheduler acquisition-cost study or a carbon-emissions measurement does not visually pattern-match to what CUCAI/QMIND judges are calibrated to reward, which is a trained model doing a recognizable task in front of them.
This is not a reason to abandon the systems-measurement framing — it is real research and belongs in the portfolio. It is a reason to make sure every topic also carries a demo-able, named-task deliverable wrapped around the measurement, so the paper reads as familiar-subject-plus-unusual-rigor rather than unfamiliar-genre.
The falsifiable-question discipline, the honest-baseline requirement, and the verified-citation corpus all stay exactly as rigorous as before. "CUCAI-shaped" is an additional presentation and framing layer on top of real methodology — never a replacement for it. A demo with no measurement behind it is exactly the kind of AI Slop this document set has spent two revisions trying to avoid in its own web pages; the goal here is both at once.
Each entry below states plainly: (1) what real paper and resources it builds on, (2) whether one CPU-only node is actually sufficient — checked, not assumed, (3) one specific, falsifiable research question with a working title, (4) a method sketch, and (5) a path to a finished paper, because the point of this track is not to start from zero.
"CPU-only RAG" is a subject area. "On one node with allocation M, what is the largest index that holds p95 latency under 200 ms at Recall@5 above 0.9?" is a research question. The difference is not pedantry — a subject area cannot be finished, cannot be falsified, and cannot be written up, which is why broadly-scoped student projects run out of term with nothing submittable.
Every topic below therefore carries a specific question block naming what is held fixed, what is varied, what is measured, the hypothesis, and — the part most often skipped — the result that would refute the hypothesis. If a team cannot state what would prove them wrong, they have a topic and not yet a project. The question is a starting point, not a constraint: teams should narrow it further as week-1 measurements come in, and say so in the paper.
The premise of this track is one node, CPU only, and memory not guaranteed. That third clause is the one teams underestimate. A CPU node will run any model in this track slowly but successfully; a node with insufficient RAM will not run it at all, and the failure arrives as an out-of-memory kill several minutes into a job rather than as a helpful error at startup.
Work out your memory ceiling in week 1, before choosing a topic. The arithmetic is simple and worth doing explicitly rather than trusting a rule of thumb.
Weight memory is parameter count × bytes per parameter. That is the floor, not the requirement:
| Precision | Bytes / param | 4B-param model | 8B-param model | Notes |
|---|---|---|---|---|
| FP32 | 4 | ~16 GB | ~32 GB | Rarely worth it on CPU; use only as an accuracy reference |
| FP16 / BF16 | 2 | ~8 GB | ~16 GB | CPU FP16 support is uneven; BF16 is better supported on recent server CPUs |
| INT8 | 1 | ~4 GB | ~8 GB | Usually near-lossless for these model sizes |
| INT4 (P6's target) | ~0.5 | ~2 GB | ~4 GB | Plus quantization metadata — scales and zero-points per group add real overhead |
Activations and KV cache. Attention key/value cache grows with sequence length and batch size and is entirely separate from weights. At long context this can exceed the weights themselves. Budget for it explicitly, and report the context length every measurement was taken at — a tokens-per-second number without a stated context length is not comparable to anything.
The loading transient. Naive loaders materialise a full-precision copy before quantizing, so peak RAM during load can be several times steady-state RAM. Memory-mapped formats such as GGUF largely avoid this, which is itself a measurable difference worth reporting in T-CPU1.
Everything else on a shared node. You do not get the node's nameplate memory. You get what the scheduler allocated you, which on a default submission may be a fraction of a gigabyte.
Every paper in this track's corpus reports throughput and accuracy. None of them reports the memory ceiling at which their approach stops being deployable. If your allocation is small, that is not a reason to pick a smaller topic — it is the axis on which your paper can say something the source papers do not. Report the largest model, context length, and index size that fit, and the exact point at which each failed.
The five topics are not interchangeable. Pick on three axes: how much memory you were actually granted, whether the team has run anything before, and whether QHPC's Pi cluster is available to you.
| Topic | Take it if | Do not take it if | Single go/no-go check |
|---|---|---|---|
| T-CPU1 | This is the team's first research project, or the first sprint of the year and you need a guaranteed result | You want a novel method — this is reproduction plus comparison by design | Does the Intel toolchain build on the node's compiler and CPU generation? |
| T-CPU2 | You can get physical access to the Pi cluster and a CPU node. This is the flagship. | The Pi cluster is committed elsewhere for the term — without both platforms the comparison collapses into a plain reproduction | Is the Pi cluster physically available and bootable this term? |
| T-CPU3 | The team can build a system, not just run one, and someone enjoys engineering over benchmarking | Nobody on the team has written a non-trivial program before | Does the embedding model load and embed a document within your memory allocation? |
| T-CPU4 | You have a comfortable memory allocation — this topic needs two model families resident, not one | Your allocation cannot hold the larger distilled model at INT4 plus its loading transient | Do the open weights download, and do the licence terms permit what you plan to publish? |
| T-CPU5 | The team wants a result that is directly useful to QHPC itself, and can bridge to Volume II's carbon work | Energy counters turn out to be unreadable on the node and no fallback is acceptable to you | Are the platform's energy counters readable from an unprivileged job? |
These topics compose. T-CPU1 produces the quantization pipeline that T-CPU4 consumes. T-CPU5 consumes T-CPU2's energy-measurement methodology and Volume II's carbon-intensity pipeline. A club running two sprints should take T-CPU1 then T-CPU4 (shared infrastructure, two papers) or T-CPU2 then T-CPU5 (shared instrumentation, two papers). Running T-CPU3 alongside either pair is fine — it shares nothing and therefore blocks nothing.
Efficient LLM Inference on CPUs (Shen et al., Intel, NeurIPS 2023 workshop) — verified matched/high. Proposes automatic INT4 weight-only quantization plus a hand-optimized CPU kernel runtime, validated on Llama2, Llama, and GPT-NeoX. Code is public: github.com/intel/intel-extension-for-transformers.
Added this revision — a third, stronger toolchain to include in the comparison: T-MAC (Wei et al., Microsoft, EuroSys 2025) — verified matched/high, DataCite record confirms the venue directly rather than a guessed one. T-MAC replaces dequantize-then-multiply with a lookup-table-based mixed-precision kernel, reporting up to 4× the throughput and 70% less energy than llama.cpp on low-bit models, with a stated 11 tokens/sec for BitNet-b1.58-3B on a Raspberry Pi 5 — a concrete, citable number this track's own Pi work (T-CPU2) can be measured against.
Yes — this is the entire point of the paper. It was written specifically to make LLM inference viable without a GPU. Any modern x86 Frontenac CPU node runs it.
Working title: “INT4 on a shared CPU node: Intel's LLM runtime against llama.cpp GGUF on identical hardware”
The question, in one sentence: For one open 3B-class instruct model at INT4, which of the two CPU quantization toolchains delivers higher decode throughput at equal output quality — and is the larger difference in kernel speed or in loading behaviour?
Held fixed: Model family and parameter count, prompt set, context length, allocated core count, node.
Varied: Toolchain (Intel extension versus llama.cpp GGUF), and quantization group size within each.
Measured: Prefill tokens/sec, decode tokens/sec, peak resident memory, model load time, accuracy on a fixed held-out set.
Hypothesis: The two toolchains land within roughly 20% of each other on decode throughput at matched quality, and the more consequential difference for a memory-constrained club is peak load memory rather than steady-state speed.
What would refute it: A decode-throughput gap larger than 2× at matched quality, or matched peak memory between the two loaders.
This is the easiest entry point in the track: a reproduction plus a head-to-head comparison, no novel method required. A clean 2,500–4,000 word write-up with a Frontenac-specific benchmark table is a strong CUCAI submission on its own, and a natural first project for a team member with no prior HPC background.
Named task: "how fast can this laptop-grade CPU answer questions" — not "quantization toolchain benchmarking."
Demo: a live side-by-side terminal — same prompt fired at both toolchains, tokens streaming out in real time next to each other, judges watch the race rather than read a table.
Headline metric: one number — "toolchain X answers Y% faster at identical output quality on the exact node QHPC's members use."
Sustainable LLM Inference for Edge AI (Husom et al., ACM Transactions on Internet of Things 2025) — verified matched/high. Benchmarks 28 quantized LLMs from the Ollama library on a Raspberry Pi 4 with 4GB RAM, measuring energy efficiency, latency, and accuracy across five standardized datasets (CommonsenseQA, BIG-Bench Hard, TruthfulQA, GSM8K, HumanEval) using hardware-based power measurement.
QHPC already owns a Pi cluster. This paper's exact experimental setup — Ollama, Raspberry Pi 4, hardware energy measurement — is nearly a direct match for hardware QHPC has right now. The reproduction cost is close to zero.
The genuine gap: Husom et al. tested only the Pi 4 in isolation. They never compare it against a "real" server-class CPU under the identical benchmark. Running their exact 28-model, five-dataset protocol on both the Pi cluster and a Frontenac CPU-only node produces a Pi-vs-server energy/accuracy/latency comparison that does not exist in the literature — and it directly answers the question every resource-constrained club actually has: is the Pi cluster or the shared cluster's CPU partition the better home for this kind of workload?
Added this revision — two more verified papers sharpen the metric and give a second reference point. Beyond Test-Time Compute Strategies (Wilhelm, Wittkopp & Kao, TU Berlin, EuroMLSys 2026) — verified matched/high — is the direct methodological argument for this topic's headline unit: it proposes energy-per-token as the metric that should sit alongside accuracy, exactly the axis this topic measures. And T-MAC's own reported number for a low-bit model on a Raspberry Pi 5 — 11 tokens/sec for BitNet-b1.58-3B (see T-CPU1) — gives a third data point beyond Husom et al.'s 28 Ollama models, from a different quantization family entirely.
Yes, and better than enough — you get two real platforms (Pi cluster node, Frontenac CPU node) for the comparison, which is what makes this a genuine extension rather than a straight reproduction.
Working title: “Pi or partition? Energy per generated token on a Raspberry Pi 4 against a shared server CPU node at matched accuracy”
The question, in one sentence: At what model size and quantization level does energy per generated token on a Pi 4 fall below that of one shared server CPU node, holding task accuracy equal?
Held fixed: Ollama version, the exact quantization artifacts, the five benchmark datasets, and the prompt set.
Varied: Platform (Pi 4 node versus server CPU node), model parameter count, quantization level.
Measured: Joules per generated token, tokens/sec, and per-dataset accuracy on each platform.
Hypothesis: The Pi wins on energy per token for the smallest models and loses as size grows, with a crossover somewhere in the 1–3B range — which is the number the paper exists to locate.
What would refute it: The server node winning on energy per token at every model size tested, i.e. no crossover exists within the range the Pi can run at all.
Different Ollama/model versions between platforms. Pin exact versions and quantization files; note them in the paper.
RAPL unavailable or restricted on the shared Frontenac node. Check /sys/class/powercap/intel-rapl access in week 1 — if unavailable, fall back to CPU-utilization-based estimation and say so explicitly, same discipline as the carbon-scheduling runbooks in Volume II.
Full 28-model reproduction is unrealistic for a club sprint. Scope down deliberately and say so — a defensible stratified sample beats an abandoned full reproduction.
The three-way comparison table (Pi vs. server CPU, across quantization levels and workload types) is the headline figure and is genuinely novel. Cite Husom et al. as the methodology source and frame this explicitly as "the comparison their paper's scope did not include." 4,000–6,000 words is a strong, self-contained CUCAI or QMIND submission.
Named task: "which machine should answer your question" — put the Pi cluster and a Frontenac node in front of the judges as two labeled boxes, not two rows in a spreadsheet.
Demo: ask both a live question, show the answer streaming from each with a running joules-per-token counter on screen — the same instinct as CUCAI's RL2 demo (watch it happen), applied to hardware instead of an agent.
Headline metric: the crossover model size itself, stated as a single sentence a non-specialist can repeat: "below N billion parameters, the Pi wins on energy per answer; above it, the server does."
RAGdb (Khalid, 2026) — verified matched/high. A monolithic RAG architecture consolidating multimodal ingestion, ONNX-based extraction, and hybrid vector retrieval into a single portable SQLite container, deliberately eliminating GPU inference at query time. Evaluated on an ordinary Intel i7 laptop: 100% Recall@1, 31.6× faster incremental ingestion, ~99.5% smaller disk footprint than a Docker-based RAG stack.
Paired with VectorLiteRAG (Kim & Mahajan, HPCA 2026) — verified matched/high — which quantifies precisely the cost this topic is testing: "CPU-only vector search incurs high latency on large, high-dimensional indices." That sentence is your baseline to beat or confirm.
Yes — this is RAGdb's entire design point. The reference hardware in the original paper (a consumer laptop) is less capable than any Frontenac node.
Working title: “How many documents fit? Recall and latency limits of single-file CPU-only RAG under a fixed memory allocation”
The question, in one sentence: On one CPU node with memory allocation M, what is the largest document index for which hybrid lexical-plus-dense retrieval holds 95th-percentile query latency under 200 ms at Recall@5 above 0.9?
Held fixed: Embedding model, scoring function and its weighting, query set, node and core count.
Varied: Index size in documents, and the memory allocation M itself.
Measured: p50 and p95 query latency, Recall@1 and Recall@5, index build time, peak resident memory.
Hypothesis: Latency stays close to flat while the working set fits in page cache and then knees sharply once it does not — meaning the binding constraint is the memory allocation, not the embedding model or the scoring function.
What would refute it: Latency growing smoothly and predictably with index size, with no knee attributable to the memory ceiling.
The scaling curve (recall and latency vs. index size, single CPU node) is the headline figure. Framing it against VectorLiteRAG's explicit claim about CPU-only latency gives the paper a real thesis to test rather than an open-ended benchmark. 3,500–5,500 words, strong CUCAI fit given how AI-audience-legible RAG is right now.
Named task: "ask your own documents a question, no cloud, no GPU" — a document-QA system, stated in exactly those consumer-facing terms.
Demo: load a real document set live (course notes, club meeting minutes), take a typed question from the audience, answer it on stage from a single laptop with no network connection.
Headline metric: the document-count ceiling itself — "N documents before answers slow down," a number anyone can picture regardless of RAG background.
Compact Language Models via Pruning and Knowledge Distillation (Muralidharan et al., NVIDIA, NeurIPS 2024) — verified matched/high, 172 citations. Prunes and distills the Nemotron-4 family (15B → 8B → 4B) using under 3% of original training data, requiring up to 40× fewer training tokens than training from scratch. Model weights are open on HuggingFace, verified real: nvidia/Minitron-4B-Base and nvidia/Minitron-8B-Base.
Added this revision — the distillation lineage, not just the newest entry in it. Minitron did not invent knowledge distillation; citing only P8 makes the related-work section look thinner than the field actually is. DistilBERT (Sanh et al., HuggingFace, NeurIPS 2019 workshop) — verified matched/high — established the now-standard trade-off point: 40% smaller, 97% of teacher performance, 60% faster. TinyBERT (Jiao et al., Huawei, EMNLP 2020 Findings) — verified matched/high — pushed further with two-stage transformer-specific distillation: 96.8% of teacher performance at 7.5× smaller and 9.4× faster. Citing both alongside Minitron shows the field's trajectory (encoder distillation in 2019–2020, decoder-LLM pruning-plus-distillation in 2024) rather than treating Minitron as the whole literature.
Yes, with a scope constraint: inference only, not training or distillation. You are not reproducing NVIDIA's distillation process — that used real GPU clusters and is out of reach. You are downloading their already-distilled open weights and benchmarking inference on CPU, which is a completely different and much cheaper task.
Working title: “Does the distillation advantage survive INT4 quantization? Minitron against same-size from-scratch models on CPU”
The question, in one sentence: P8 reports up to a 16% MMLU improvement for distilled models over training from scratch at equal parameter count; does that margin persist, shrink, or vanish after INT4 weight-only quantization for CPU inference?
Held fixed: Parameter-count band, quantization method and group size, evaluation harness and task set, node and core count.
Varied: Model provenance (distilled versus trained from scratch) and precision (a higher-precision reference versus INT4).
Measured: Accuracy delta between the two provenances at each precision, decode tokens/sec, peak resident memory.
Hypothesis: The distilled model's advantage shrinks under quantization, because a pruned-and-distilled network carries less redundancy to absorb quantization error than one trained from scratch at the same width.
What would refute it: The margin surviving unchanged or widening under INT4 — which would be the more interesting result and a stronger argument for distillation.
The original paper never combines distillation with CPU quantization — that combination, and whether the distillation advantage survives it, is your original contribution. 3,000–4,500 words. Pairs naturally with T-CPU1's quantization pipeline as a joint sprint for two teams sharing infrastructure.
Named task: "how much of a big model's knowledge survives shrinking it to fit on a CPU" — the compression-versus-capability trade-off, framed as a question anyone who has heard of ChatGPT can follow.
Demo: the teacher-scale reference model and the shrunk CPU model answer the same live audience question back to back — the gap (or its absence) is the show.
Headline metric: percentage of original capability retained at a stated size and speed, the same unit DistilBERT and TinyBERT made standard.
Combines this track's Husom et al. energy-measurement methodology (T-CPU2) with Volume II's carbon-aware scheduling work (T4.3, T6.8) — but scoped deliberately to CPU-only, single-node measurement using Intel RAPL rather than the GPU power telemetry T4.3 assumes.
Yes — this is precisely the point of the topic. RAPL (Running Average Power Limit) energy counters are built into essentially every modern Intel and AMD server CPU and need no external power meter, unlike GPU power measurement which typically needs nvidia-smi or an inline meter.
Working title: “What did a term actually cost? RAPL-measured energy and grid-weighted emissions for one club's CPU inference”
The question, in one sentence: Over one academic term, what are the measured joules and grams of CO₂e attributable to QHPC's own CPU inference workloads — and how much would shifting the non-interactive jobs to low-intensity hours have saved, holding every completion deadline fixed?
Held fixed: The real workload trace and each job's actual deadline; emissions accounting method and data source.
Varied: Scheduling policy only: as-run placement versus a retrospective carbon-aware placement over the same trace.
Measured: Per-job energy from processor energy counters, emissions using hourly regional carbon intensity, and deadline violations under the counterfactual policy.
Hypothesis: Achievable savings from time-shifting come in under 15%, because Ontario's grid is already low-carbon and comparatively flat across the day. That is a deflationary result, and it is worth publishing precisely because most carbon-aware scheduling work is evaluated on high-variance grids where the headline savings are much larger.
What would refute it: Savings above 15% under deadline-preserving placement — in which case the interesting question becomes which hours and which job classes produced them.
This is the topic that turns "we ran some models on CPU" into "here is what it costs the club and the planet, measured, not estimated." It is the natural capstone of this track precisely because it reuses infrastructure (T4.3's carbon pipeline) rather than building new — 4,000–6,000 words, strong for either CUCAI or an internal sustainability report to sponsors.
Named task: "the carbon receipt for a term of running our own tools" — a bill, not a benchmark.
Demo: a live dashboard replaying the term's real job trace against a carbon-intensity clock, showing the counterfactual carbon-aware schedule saving (or not saving) emissions in real time.
Headline metric: one number in one unit everyone understands — kilograms of CO₂e for the term, with the time-shifted counterfactual next to it.
P6 (Efficient LLM Inference on CPUs) establishes that INT4 weight-only quantization plus optimized kernels makes CPU LLM inference viable, and reports throughput on its target hardware. What its abstract claims is a runtime and a quantization flow — not a parallel-scaling characterisation. How inference throughput behaves as you vary allocated core count, thread affinity, and NUMA placement is left open.
That gap is precisely the shape of question this club is already equipped to answer. Volume I teaches strong and weak scaling, Amdahl's Law measured rather than recited, and the discipline of separating fixed cost from scaling cost. This topic points that existing machinery at a workload the CUCAI audience already cares about.
Every other topic in this track wants more memory. This one wants varying core counts and a fixed, small model. A team granted an awkward allocation — plenty of cores, little RAM — should take this one. It is also the only topic here whose method transfers directly to competition work, where per-core efficiency under a fixed node budget is the entire game.
Yes, and a single node is the correct scope: the object of study is intra-node parallelism. A second node would introduce network effects that are a different paper.
Working title: “Decode saturates first: core-count scaling of INT4 CPU inference and the allocation past which extra cores are wasted”
The question, in one sentence: At what allocated core count does decode throughput stop improving by more than 5% per doubling, how far does thread pinning move that point, and what does crossing a socket boundary cost?
Held fixed: Model, quantization level, context length, prompt set, node.
Varied: Allocated core count across the full grantable range; thread pinning on and off; single-socket versus spanning sockets.
Measured: Prefill and decode throughput separately, throughput per core, the serial fraction implied by fitting the measured speedup, and run-to-run spread.
Hypothesis: Decode saturates well before prefill does — plausibly by 8 to 16 cores — because decode is bandwidth-bound one token at a time, and pinning pushes the saturation point later at no cost.
What would refute it: Prefill and decode scaling alike, or pinning making no measurable difference — either would mean the memory system is not the limiter here.
| Quantity | Why it matters |
|---|---|
| Prefill tokens/sec vs. cores | The compute-bound half; should scale closest to ideal |
| Decode tokens/sec vs. cores | The memory-bound half; expected to saturate early, and where the interesting result lives |
| Throughput per core | Turns a rising curve into a falling one and makes the efficiency loss legible at a glance |
| Effect of pinning | Often a large and entirely free gain; almost never reported |
| Cross-socket penalty | The practical guidance a cluster operator would act on |
| Run-to-run spread | Shared nodes are noisy; three runs minimum, report median and spread |
Blending prefill and decode. The single most common error in CPU-inference benchmarking, and it destroys the result. Time them separately from the first measurement.
Letting the runtime pick thread counts. Most inference runtimes default to all visible cores regardless of what the scheduler granted, which means your two-core measurement may have silently used sixty-four. Set the thread count explicitly and verify it.
Varying context length across core counts. Longer prompts change the prefill/decode balance. Hold it fixed, and state it.
Contention from other jobs. On a shared node your neighbours affect memory bandwidth. Record when each run happened, and repeat the sweep on a different day to check the curve is stable.
The headline figure is throughput-per-core against core count, plotted separately for prefill and decode, with the pinned and unpinned variants overlaid. The thesis writes itself from the shape: quantized CPU inference does not scale uniformly, decode saturates first, and the practical consequence is that requesting more cores past a measurable point wastes an allocation other members could use. That last sentence is a genuine operational recommendation for a shared cluster, and it is the kind of finding that reviewers remember. 3,000–4,500 words.
Named task: "how many cores does your chatbot actually need" — reframe the scaling curve as a cost-of-ownership question, not a parallel-computing exercise.
Demo: a live slider or dashboard letting a judge pick a core count and watch the same model's response speed change in real time, saturating visibly on screen.
Headline metric: the single "past this many cores, you're wasting an allocation" number — the sentence a lab manager, not just a systems reviewer, would act on.
Every topic in this track already states its target word count and headline figure. The remaining steps are the same across all five:
Steps 2 and 4 above — building the related-work section from a verified corpus, and internal review — are covered in full in the Paper Kit, along with the statistics needed to report noisy CPU timings honestly and the procedure for confirming a citation is real rather than plausible.
All five topics are written to be legible to the same room the corpus-gap analysis identified: AI-focused reviewers who know LLMs and RAG, but who have not seen a CPU-only, single-node, RAPL-instrumented systems study before. That combination — familiar subject, unfamiliar rigor — is exactly what made T6.6–T6.8 strong CUCAI candidates, and it applies here too.
These are predictable. Each one has a cheap defence if it is anticipated during the experiment and an expensive one if it is discovered at review. Build the answer into the methodology section rather than saving it for a rebuttal.
| Objection | Why it is fair | The defence, executed during the work |
|---|---|---|
| "This is just a reproduction." | T-CPU1 and T-CPU4 are explicitly reproduction-plus-extension, and a reviewer who sees only the reproduction half will say so. | State the extension in the abstract's first two sentences, not the discussion. Name the specific condition the original paper did not test — different hardware, a combination it never evaluated, a scaling axis it never swept — and make that the title. |
| "One machine is not a result." | Single-node, single-platform measurement genuinely does limit generality, and pretending otherwise is worse than conceding it. | Report the hardware completely enough that someone else can reproduce it: CPU model, core count, memory allocation granted, thread settings, runtime and model versions pinned. A fully specified single platform is a legitimate data point; an under-specified one is not. |
| "Your baseline is weak." | The standard failure of student systems papers: an untuned comparison point makes any result look good. | Use the best available implementation as the baseline, tune it with the same effort you spent on your own configuration, and say how much effort that was. If you could not tune it, say that too and bound the claim accordingly. |
| "Accuracy was not checked." | Quantization trades accuracy for speed. A throughput number without an accuracy number is a measurement of nothing. | Every configuration reports both. If a quantization level degrades output quality past a usable point, that is a finding worth its own figure, not an inconvenience to omit. |
| "Noise is not addressed." | Shared clusters vary hour to hour, and reviewers of systems papers know it. | Three runs minimum, median and spread reported, timestamps logged, and one sweep repeated on a different day to demonstrate the curve is stable rather than a single afternoon's weather. |
Every paper in this track should contain one explicit sentence bounding its claim — what hardware, what memory allocation, what model sizes, what context lengths, and what was therefore not tested. Reviewers reward it and it costs one line. The papers in this track's own corpus that read most credibly are the ones that do exactly this, and the weakest submissions QHPC will produce are the ones that quietly generalise past their evidence.
Same discipline as Volume II's passport: every paper below returned matched / high confidence from Scholar Sidekick's verifyCitation, zero mismatches, zero fabrications. Every HuggingFace resource was independently confirmed to exist via the HuggingFace Hub search tool — not assumed from a paper's text.
| # | Paper | Identifier | Verdict | Used in |
|---|---|---|---|---|
| P6 | Efficient LLM Inference on CPUs | arXiv:2311.00502 | matched / high | T-CPU1, T-CPU4, T-CPU6 |
| P7 | Sustainable LLM Inference for Edge AI (28 models, Raspberry Pi 4) | arXiv:2504.03360 | matched / high | T-CPU2, T-CPU5 |
| P8 | Compact Language Models via Pruning and Knowledge Distillation (Minitron) | arXiv:2407.14679 | matched / high | T-CPU4 |
| P9 | RAGdb: Zero-Dependency Embeddable RAG on the Edge | arXiv:2602.22217 | matched / high | T-CPU3 |
| P10 | VectorLiteRAG: Latency-Aware Resource Partitioning for RAG | arXiv:2504.08930 | matched / high | T-CPU3 |
| P11 | T-MAC: CPU Renaissance via Table Lookup for Low-Bit LLM Deployment on Edge (Wei et al., Microsoft, EuroSys 2025) | arXiv:2407.00088 | matched / high | T-CPU1, T-CPU2 |
| P12 | Beyond Test-Time Compute Strategies: Advocating Energy-per-Token in LLM Inference (Wilhelm et al., TU Berlin, EuroMLSys 2026) | arXiv:2603.20224 | matched / high | T-CPU2, T-CPU5 |
| P13 | DistilBERT (Sanh et al., HuggingFace, NeurIPS 2019 workshop) | arXiv:1910.01108 | matched / high | T-CPU4 |
| P14 | TinyBERT (Jiao et al., Huawei, EMNLP 2020 Findings) | arXiv:1909.10351 | matched / high | T-CPU4 |
Four new papers (P11–P14) were located via Consensus and independently verified — title-against-resolved-record via Scholar Sidekick's verifyCitation, not just a resolving link — before being added anywhere in this document. Two candidates surfaced by the same search were rejected rather than cited, and that rejection is recorded here rather than silently dropped:
| Repo | Type | Verified stats | Used in |
|---|---|---|---|
| nvidia/Minitron-4B-Base | model | 2.7K downloads, 138 likes, license: other (check terms before redistribution) | T-CPU4 |
| nvidia/Minitron-8B-Base | model | 20.9K downloads, 71 likes | T-CPU4 |
| sentence-transformers/all-MiniLM-L6-v2 | model | 22.7M params, Apache-2.0, 3.4B downloads | T-CPU3 |
| bartowski/Llama-3.2-3B-Instruct-GGUF | model | 162.7K downloads, 229 likes, license: llama3.2 | T-CPU1 |
| intel/intel-extension-for-transformers | GitHub repo | Cited directly in P6's own abstract as the code release | T-CPU1 |
Extracted with pdftotext -layout against the actual PDF for all five papers, not an LLM's reading of raw PDF bytes. All five fetches of the raw binary independently confirmed the fabrication risk documented in Volume II: three of the five WebFetch summaries explicitly refused to invent quotes from unreadable binary stream data rather than guess, which is the correct behaviour — page numbers below come only from the deterministic text-layer extraction that followed.
"We support an automatic INT4 weight-only quantization flow and design a special LLM runtime with highly-optimized kernels to accelerate the LLM inference on CPUs...on popular LLMs including Llama2, Llama, GPT-NeoX...The code is publicly available at: https://github.com/intel/intel-extension-for-transformers." (Abstract)
"we conduct a comprehensive analysis of 28 quantized LLMs from the Ollama library...deployed on an edge device (Raspberry Pi 4 with 4GB RAM)...benchmarked on five standardized datasets (CommonsenseQA, BIG-Bench Hard, TruthfulQA, GSM8K, and HumanEval), and we employ a high-resolution, hardware-based energy measurement tool." (Abstract) — the extracted text runs exactly 30 pages, matching the paper's own stated length, a useful sanity check that the extraction is complete.
"we investigate if pruning an existing LLM and then re-training it with a fraction (<3%) of the original training data can be a suitable alternative to repeated, full retraining...Deriving 8B and 4B models from an already pretrained 15B model...requires up to 40x fewer training tokens per model...MINITRON models exhibit up to a 16% improvement [in MMLU]...We have open-sourced MINITRON model weights on Huggingface." (Abstract)
"We propose a deterministic Hybrid Scoring Function (HSF) that combines sublinear TF-IDF vectorization with exact substring boosting, eliminating the need for GPU inference at query time. Experimental evaluation on an Intel i7-1165G7 consumer laptop demonstrates that RAGdb achieves 100% Recall@1...and an ingestion efficiency gain of 31.6x...reduces disk footprint by approximately 99.5%." (Abstract) — extracted text is exactly 6 pages, matching the paper's own stated length.
"While CPU-only vector search incurs high latency on large, high-dimensional indices, co-locating the retriever and the LLM on the GPU leads to resource sharing that can create resource contention...VECTORLITERAG identifies an optimal index partitioning point across CPU and GPU that minimizes contention." (Abstract, IEEE HPCA 2026 camera-ready formatting)
Two independent confirmations that the extracted text is genuine and complete, not truncated or substituted: P7's extracted text breaks into exactly 30 pages, matching the "30 pages, 14 figures" the paper itself states in its arXiv metadata (captured during citation verification). P9's extracted text breaks into exactly 6 pages, matching its own "6 pages, 2 tables" metadata. Neither figure was targeted — both fell out naturally from counting real page-break characters in the pdftotext output.
Same convention as Volume II's passport — each claim in T-CPU1 through T-CPU4 that draws directly on P6–P10 has an HTML comment immediately following it, visible in page source:
<!--anchor:quote:<identifier>:<page/section>:"<exact quote>" — <verification note>-->
The requested ARS outline-with-evidence-map mode is a 13-agent pipeline built to produce a single new APA-style paper from scratch — not to annotate five existing topic write-ups with citations. What is delivered instead is the equivalent structure applied manually: for each topic, What this builds on functions as the literature-review section, Is one node enough as the feasibility check, Method as the outline body, and Path to a finished paper as the composition plan — each claim anchored to a real, page-verified quote rather than a generated citation. This is the same substitution made for Volume II's passport, for the same reason: the heavy pipeline is built for a different deliverable than the one actually needed here.
perseus-vault recall "QHPC verified literature corpus part 2 CPU-only"
Zero-GPU / Single-Node Track — 6 topics (T-CPU1–T-CPU6) spanning Tiers 1–4, plus a memory-ceiling section, a topic-selection guide, and 3 reference sections. Companion to Volume I (Tiers 1–3, GPU-optional) and Volume II (Tiers 4–6, GPU-flagship). All six topics assume one Frontenac CPU-only node as the ceiling, not the floor.
Compiled 2026-08-04. Each topic is falsifiable, mapped to verified literature, and scoped to CPU-only hardware available to QHPC (Frontenac CPU node, Raspberry Pi 4-class edge devices). Updated 2026-08-08: all four topics completed to phase1–7 pipeline depth. See
PROJECT_STATUS.mdand per-topictcpuN-phase7-final-manuscript.md(compiled PDF/DOCX). Measurement-dependent [MEASURED] slots remain open for T-CPU1/T-CPU2 pending hardware/cluster access.
Status (2026-08-08): registered report complete (tcpu1-phase7-*); measurement pending. Falsifiable question: Is toolchain X measurably faster (≥ threshold %) at identical output quality than toolchain Y for LLM inference on QHPC CPU hardware?
Status (2026-08-08): manuscript package complete + compiled (phase7-*); measurement pending (Pi 5 + INA219 edge leg; Frontenac blocked by gpu-rgrant partition rewrite). Falsifiable question: Does a Raspberry Pi 4-class edge device achieve lower energy-per-token than a Frontenac CPU node at some model-size/quantization operating point — i.e., does an energy-per-token crossover exist?
Status (2026-08-08): code + evaluation complete with real results (tcpu3-phase7-*); GPU-baseline comparison [MEASURED] pending cluster access. Falsifiable question: Can a CPU-only RAG pipeline (RAGdb-style, Khalid 2026) with sentence-transformers/all-MiniLM-L6-v2 (22.7M params, Apache-2.0) achieve retrieval quality within X% of GPU-hosted baselines on Frontenac?
Status (2026-08-08): simulator + full-factorial sweep + real results complete (tcpu4-phase7-*); hardware validation optional and pending. Falsifiable question: Does a green-aware scheduling policy (GAS-MARL / DRL-MOSHRS style) reduce energy-delay product vs. baseline policies on a simulated CPU-only cluster?
verified-bibliography-quality-matrix.mdhpc-reference-corpus.mdcpu-only-curriculum-publication-pathways.mdImported from qphc-cpu-four-topic-track.md (2026-08-08). T-CPU1 (toolchain), T-CPU2 (energy-per-token crossover), T-CPU3 (quantization), T-CPU4 (batched inference) with per-topic deliverables and pipeline status. Complements the Zero-GPU Track handbook above.