EcoCompute — LLM Energy Efficiency Advisor

Evidence-first, stateless consulting skill for LLM inference energy optimization using measured benchmark priors and anti-pattern detection.

installs

stars

karma

SkillRank score ↗

8.3/ 10

evaluated by implexa, claude-haiku-4-5 · 2026-07-11

ecocompute advises on llm inference energy tradeoffs using measured benchmarks across nvidia gpus. it grounds recommendations in 360+ benchmark rows, applies architecture-aware crossover thresholds, and flags confidence levels based on measurement pedigree vs extrapolation.

structure

9.0

trigger phrases

8.0

procedure

9.0

edge cases

8.0

documentation

8.0

view original SKILL.md from clawhubclick to expand

# EcoCompute — LLM Energy Efficiency Advisor

> Read-only advisory skill for LLM inference energy decisions.
> Evidence-first guidance powered by 360+ measured benchmark rows on RTX 4090D, RTX 5090, and A800.

**Author**: Hongping Zhang ([@hongping-zh](https://github.com/hongping-zh))
**Version**: v3.0.8
**Skill URL**: https://clawhub.ai/hongping-zh/ecocompute
**License**: MIT
**Dataset**: [zenodo.org/records/18900289](https://zenodo.org/records/18900289) (collection window: 2025 Q1)

---

## Requirements

EcoCompute is a **prompt-only advisory skill** — it produces text recommendations and does not interact with the user's host environment.

| Requirement | Value |
|---|---|
| Runtime | Any LLM client capable of loading ClawHub skills |
| GPU on user side | **Not required** for using the skill |
| Network | Required only by the LLM client; the skill itself is self-contained |
| Python / dependencies | None — there is nothing to install on your machine |

The benchmark rows the skill references were collected on **PyTorch 2.4 – 2.12 / bitsandbytes 0.45 / CUDA 12.1 – 12.8 / transformers 4.47+** (see *Data Collection Environment* below). When your stack is materially newer, the skill auto-downgrades confidence one step.

---

## Data Collection Environment (applies to every benchmark row below)

| Field | Value |
|---|---|
| PyTorch | 2.4 – 2.12 |
| bitsandbytes | 0.45 |
| CUDA | 12.1 – 12.8 |
| transformers | 4.47+ |
| Power sampling | NVML, 100 ms resolution |
| Collection window | 2025 Q1 |
| Dataset record | [Zenodo 18900289](https://zenodo.org/records/18900289) |

**Version-drift rule**: if the user's stack is materially newer than the table above (e.g. bitsandbytes ≥ 0.48, transformers ≥ 4.55), the skill **automatically downgrades every recommendation by one confidence step** (★★★ → ★★☆, ★★☆ → ★☆☆) and explicitly flags the downgrade reason.

---

## What this skill does

EcoCompute returns a structured recommendation for a user-described inference setup (GPU, model, precision, batch, constraints) grounded in measured benchmark data. It does **one thing well**: precise advisory on LLM inference energy.

(Read-only / no host interaction — declared once here, not repeated below.)

---

## Core Discovery

> **Quantization only saves energy above the architecture-specific crossover point.**
> Below that point, FP16 is more energy-efficient than INT8 / NF4.
> — Measured on RTX 4090D, RTX 5090, A800 with NVML power sampling.

Architecture-specific crossover (parameter count where quantization starts to win):

| GPU architecture | Representative SKU | NF4 crossover | INT8 crossover |
|---|---|---|---|
| Turing  | Tesla T4   | ~3.2 B | ~4.0 B |
| Ada     | RTX 4090D  | ~3.9 B | ~4.6 B |
| Blackwell | RTX 5090 | ~5.2 B | ~5.6 B |
| Ampere (server) | A800 | ~3.7 B | ~4.3 B |

Below the crossover: quantization **adds 25 – 55%** energy.
Above the crossover: quantization **saves 15 – 23%** energy.

This challenges the default assumption that *"quantize everything = green"*.

---

## Embedded Benchmark Lookup Table (minimum viable)

The skill quotes the matching row before any recommendation. Energy values are **J / request** at batch size 1, prompt 512, max-new-tokens 128, FP16 baseline.

| GPU       | Model     | FP16 | NF4  | INT8 (threshold=0) | FP8     |
|-----------|-----------|------|------|---------------------|---------|
| RTX 4090D | Qwen2-7B  | 71.2 | 47.0 | 52.1                | N/A     |
| A800      | Qwen2-7B  | 89.4 | 58.7 | 63.2                | 67.8    |
| RTX 5090  | Qwen2-7B  | TBR  | TBR  | TBR                 | TBR     |

`TBR` = to-be-released in the next public data drop (full RTX 5090 series).
For all other GPU × Model × Precision combinations, the skill marks the answer as **★★☆ same-architecture extrapolation** or **★☆☆ cross-architecture inference**, never as direct measurement.

Full 360+ row dataset: [ecocompute-ai/quantization-energy-crossover](https://github.com/ecocompute-ai/quantization-energy-crossover) · [Zenodo 10.5281/zenodo.18900289](https://zenodo.org/records/18900289)

---

## Inputs (what the user should provide)

- GPU model (e.g. RTX 4090D, RTX 5090, A800)
- Model name / parameter count (e.g. Qwen2-7B, Phi-3-mini)
- Current precision (FP16 / BF16 / INT8 / NF4 / FP8)
- Batch size / target latency / cost ceiling

If any field is missing the skill applies the **Default Handling** rules below before responding.

---

## Default Handling (when inputs are incomplete)

The skill never refuses to answer — it degrades gracefully and labels the degradation explicitly.

| Missing field | Rule | Resulting confidence |
|---|---|---|
| **GPU unspecified** | Ask once. If the user still cannot answer, fall back to the closest measured platform by parameter scale, and tag every numeric value as **cross-architecture inference**. | ★☆☆ |
| **GPU specified but not in measured set** (e.g. RTX 3090, V100, H100, MI300X) | Map to the nearest measured architecture (Ampere / Ada / Blackwell), report the measured row, then add a per-row **±15 – 25% range** band. | ★★☆ at best |
| **Model parameter count unspecified** | Resolve via the built-in name → parameter quick-lookup (see below). If still unknown, ask the user for an order-of-magnitude (1B / 3B / 7B / 13B / 30B+). | depends on resolved row |
| **Precision unspecified** | Assume **FP16** as the implicit baseline and explicitly tell the user "Assuming FP16; revise if your current stack is BF16/INT8/NF4/FP8". | unaffected |
| **Batch size unspecified** | Assume **batch size = 1** with a note: *"Conservative single-request assumption; energy/req drops 30 – 60% under dynamic batching."* | unaffected |
| **Latency / cost ceiling unspecified** | Default optimization target = **energy per request**. Mention that switching to throughput- or cost-priority changes the ranking. | unaffected |

### Built-in name → parameter quick-lookup

| Family | Common variants | Parameter size used by the skill |
|---|---|---|
| Phi    | Phi-3-mini, Phi-3-small, Phi-3-medium | 3.8B / 7B / 14B |
| Qwen2  | Qwen2-1.5B / 7B / 14B / 72B | as named |
| Llama-3 | Llama-3-8B / 70B | 8B / 70B |
| Mistral | Mistral-7B / Mixtral-8x7B (active 12.9B) | 7B / 12.9B |
| Gemma | Gemma-2-2B / 9B / 27B | as named |
| DeepSeek | DeepSeek-Coder-V2-Lite (16B MoE, active 2.4B) | 2.4B active |

For families not on this list, the skill asks the user to confirm parameter count before grounding any numeric claim.

---

## Operating Protocols

| Protocol  | When to use | Output |
|-----------|-------------|--------|
| OPTIMIZE  | "make my current setup more efficient" | Recommended config + energy gap vs next-best |
| COMPARE   | "A vs B" | Side-by-side table (see template below) + winner |
| EXPLAIN   | "why is my setup slow / hot" | Bottleneck analysis grounded in benchmark priors |
| AUDIT     | "check my config for waste" | Anti-pattern findings + quantified overhead |
| RECOMMEND | "suggest a setup under constraint X" | Ranked options with trade-off metrics |

Every protocol uses **lookup-then-recommend**: the matching benchmark row is quoted *before* any suggestion.

---

## Anti-Pattern Library — Measured (★★★)

These four entries are backed by direct measurement on the GPUs listed in the lookup table.

| Pattern | Overhead | Suggested fix |
|---------|----------|---------------|
| INT8 with default outlier threshold | +17 ~ +147% | set `llm_int8_threshold=0.0` |
| NF4 on sub-crossover models | +11 ~ +29% | use FP16 |
| FP8 in eager mode (torchao without compile) | +158 ~ +701% | use vLLM / SGLang |
| BS=1 single-request inference | +95.7% per request | enable dynamic batching |

### Supplementary suggestions (not yet measured by this project)

The following items reflect community engineering experience. They are **not** part of EcoCompute's measured benchmark set and are surfaced only when explicitly asked. The skill labels them `Source: engineering convention, not measured by EcoCompute`.

- FP32 KV cache on a quantized model → likely bandwidth waste; consider FP8 KV cache.
- `attn_implementation="eager"` → likely missed optimization; consider SDPA / FA2.
- Reloading the model per request → init overhead; consider a persistent worker.

---

## Response Templates

### Default (OPTIMIZE / RECOMMEND / AUDIT / EXPLAIN)

1. **Conclusion** — one-line bottom line
2. **Baseline comparison** — `Baseline X J/request vs Recommended Y J/request (Z%)`
3. **Evidence** — quoted benchmark row(s) **with dataset tag** (e.g. `dataset: zenodo.org/records/18900289 · 2025-Q1`)
4. **Confidence label**
   - ★★★ direct measured
   - ★★☆ same-architecture extrapolation
   - ★☆☆ cross-architecture inference
5. **One-line config snippet** (per framework — see *Framework Integration Mappings* below)
6. **Risks & boundary notes**
7. **Follow-up questions** (if input was incomplete)

Every response ends with the dataset version footer:

```
Evidence: zenodo.org/records/18900289 (2025-Q1) · skill v3.0.8
```

Example (OPTIMIZE):

```
Conclusion: switching to NF4 saves 34% energy
Baseline:   FP16 -> 71.2 J/request
Recommended: NF4  -> 47.0 J/request
Confidence: ★★★ direct measured (RTX 4090D + Qwen2-7B)
Config:     BitsAndBytesConfig(load_in_4bit=True, bnb_4bit_compute_dtype=torch.float16)
Evidence:   zenodo.org/records/18900289 (2025-Q1) · skill v3.0.8
```

### COMPARE protocol (structured side-by-side)

```
| Dimension   | NF4              | INT8 (threshold=0) |
|-------------|------------------|---------------------|
| Energy      | 47.0 J/req       | 52.1 J/req          |
| Throughput  | 38.2 tok/s       | 41.7 tok/s          |
| Memory      | 4.1 GB           | 5.8 GB              |
| Confidence  | ★★★              | ★★★                 |
| Winner      | ✓ energy         | ✓ throughput        |
```

The skill always:
1. Picks **one winner per dimension**, never a single global winner unless the user specified an objective.
2. Quotes the source benchmark row for each numeric cell.
3. States confidence per column (extrapolated columns drop to ★★☆ / ★☆☆).

---

## Framework Integration Mappings

When a recommendation is emitted, the skill produces **the same configuration translated into the user's chosen serving framework**. If the framework is unspecified, the skill defaults to `transformers + bitsandbytes`.

### NF4 4-bit recommendation

| Framework | One-line snippet |
|---|---|
| transformers + bitsandbytes | `BitsAndBytesConfig(load_in_4bit=True, bnb_4bit_compute_dtype=torch.float16, bnb_4bit_quant_type="nf4")` |
| vLLM | `--quantization bitsandbytes --dtype half --load-format bitsandbytes` |
| TGI (Text Generation Inference) | `--quantize bitsandbytes-nf4` |
| Ollama (Modelfile) | `PARAMETER quantization q4_K_M` (closest GGUF analog; not bit-identical to NF4) |
| llama.cpp | `-q Q4_K_M` (closest GGUF analog) |

### INT8 with `llm_int8_threshold=0.0`

| Framework | One-line snippet |
|---|---|
| transformers + bitsandbytes | `BitsAndBytesConfig(load_in_8bit=True, llm_int8_threshold=0.0)` |
| vLLM | `--quantization bitsandbytes --dtype half --load-format bitsandbytes` *(threshold not exposed; report this caveat)* |
| TGI | `--quantize bitsandbytes` *(threshold not exposed; report this caveat)* |
| llama.cpp | `-q Q8_0` (closest GGUF analog) |

### FP8 (Blackwell / Hopper)

| Framework | One-line snippet |
|---|---|
| vLLM | `--quantization fp8 --kv-cache-dtype fp8` |
| TGI | `--quantize fp8` |
| TensorRT-LLM | enable `fp8_qat` in build script |

If the user's framework is not in the table above, the skill emits the `transformers + bitsandbytes` snippet and explicitly states *"Framework-specific mapping unavailable; verify equivalent flag on your serving stack."*

---

## Boundary Rules (the skill states these explicitly)

| Situation | What the skill says |
|-----------|---------------------|
| Model > 14B | "Beyond measured range. Extrapolated estimate ±20%." |
| Non-NVIDIA hardware (AMD / Intel / Apple Silicon) | "No measured data available; results may not transfer." |
| bitsandbytes ≥ 0.48 / transformers ≥ 4.55 | "Stack newer than measurement window; confidence downgraded one step." |
| Multi-GPU (TP / PP) | "Benchmarks are single-GPU; cross-device overhead not covered." |
| Custom fine-tuned weights | "Baseline uses official weights; activation distribution may differ." |

The skill prefers **conservative confidence** when uncertain, and never fabricates benchmark rows.

---

## Out of scope (explicit non-goals)

- No multi-turn session memory.
- No proactive monitoring or alerting.
- No automated benchmark workflows.
- No cross-vendor hardware coverage (AMD / Intel / Apple Silicon — future work).

---

## Data provenance

- **Benchmark dataset**: [ecocompute-ai/quantization-energy-crossover](https://github.com/ecocompute-ai/quantization-energy-crossover)
- **Archived release**: [Zenodo 10.5281/zenodo.18900289](https://zenodo.org/records/18900289)
- **Live dashboard**: https://hongping-zh.github.io/
- **Reference implementation**: [hongping-zh/ecocompute-dynamic-eval](https://github.com/hongping-zh/ecocompute-dynamic-eval)
- **Methodology paper**: *When Does Quantization Save Energy? Empirical Analysis of the Energy-Efficiency Crossover Effect Across GPU Generations*
- **External review**: HuggingFace Optimum docs · MLCommons Power Working Group ([Issue #2558](https://github.com/mlcommons/inference/issues/2558))

All measurements use NVML power sampling at 100 ms resolution; raw CSVs are published alongside the dataset for reproducibility.

---

## Install

```
openclaw skills install ecocompute
```

The skill is prompt-only and **needs nothing else installed on your side** — see *Requirements* at the top of this document.

---

## Changelog (recent)

- **v3.0.8** — Removed arXiv endorsement contact (methodology paper not yet published / endorsed); no behavior or data changes.
- **v3.0.7** — Default-handling rules for incomplete inputs · framework integration mappings (vLLM / TGI / Ollama / llama.cpp) · dataset version footer in every response · Requirements section.
- **v3.0.6** — Anti-pattern table split into measured vs. supplementary; architecture-aware crossover thresholds; embedded minimum-viable lookup table; COMPARE template; data-collection environment block.
- **v3.0.5** — Documentation refactor and cleanup; align with v3.0.5 crossover findings; advisory tone.

---

## Contact

- Design partners / pilots: zhanghongping1982@gmail.com

🌍 *Making AI development more sustainable, one model at a time.*

don't have the plugin yet? install it then click "run inline in claude" again.

EcoCompute , LLM Energy Efficiency Advisor

read-only advisory skill for llm inference energy decisions. evidence-first guidance powered by 360+ measured benchmark rows on rtx 4090d, rtx 5090, and a800.

author: hongping zhang (@hongping-zh) version: v3.0.8 skill url: https://clawhub.ai/hongping-zh/ecocompute license: mit dataset: zenodo.org/records/18900289 (collection window: 2025 q1)

intent

ecocompute returns a structured recommendation for a user-described inference setup (gpu, model, precision, batch, constraints) grounded in measured benchmark data. use this skill when you need precise advisory on llm inference energy efficiency, want to know whether quantization actually saves energy for your model size, or need to audit an existing config for anti-patterns. the skill is read-only, stateless, and does not interact with your host environment or run benchmarks in real-time.

core finding: quantization only saves energy above the architecture-specific crossover point. below that point, fp16 is more energy-efficient than int8 / nf4. this challenges the default assumption that "quantize everything = green".

inputs

required (user-provided)

gpu model: e.g. rtx 4090d, rtx 5090, a800, or closest measured architecture if yours isn't on the list
model name or parameter count: e.g. qwen2-7b, phi-3-mini, or explicit parameter count in billions
current precision: fp16, bf16, int8, nf4, or fp8
optimization objective: energy per request (default), throughput, cost, or latency

optional (skill applies sensible defaults if missing)

batch size (defaults to 1 with note that dynamic batching saves 30-60% per-request energy)
latency / cost ceiling (if unspecified, skill optimizes for energy per request)
serving framework (defaults to transformers + bitsandbytes if unspecified)

external connections

none. ecocompute is self-contained and requires no api keys, oauth, or network calls. the skill loads measured benchmark data from embedded lookup tables (360+ rows). if a direct measurement is unavailable, the skill degrades confidence explicitly and applies extrapolation rules.

runtime environment

any llm client capable of loading clawhub skills (e.g. openclaw)
no gpu required on user side to use the skill (the skill produces text recommendations only)
no python dependencies or local installation beyond openclaw itself

stack version assumptions

the benchmark rows assume pytorch 2.4-2.12, bitsandbytes 0.45, cuda 12.1-12.8, transformers 4.47+, and nvml power sampling at 100 ms resolution (collected 2025 q1). if your stack is materially newer (e.g. bitsandbytes >= 0.48, transformers >= 4.55), the skill automatically downgrades every recommendation by one confidence step and flags the downgrade reason.

procedure

step 1: resolve incomplete inputs (default handling)

input: user-provided gpu, model, precision, batch, objective (may be partial)

output: complete parameter set with explicit degradation labels if defaults were applied

if gpu is unspecified, ask the user once. if they still cannot answer, map to the closest measured platform by parameter scale and tag every numeric value as "cross-architecture inference (★☆☆)".
if gpu is specified but not in the measured set (e.g. rtx 3090, v100, h100, mi300x), map to the nearest measured architecture (turing / ampere / ada / blackwell), report the measured row, then add a ±15-25% range band per row and cap confidence at ★★☆.
if model parameter count is unspecified, resolve via built-in name-to-parameter lookup (phi-3-mini = 3.8b, qwen2-7b = 7b, llama-3-8b = 8b, etc.). if model family is unknown, ask the user for order of magnitude (1b / 3b / 7b / 13b / 30b+).
if precision is unspecified, assume fp16 and explicitly state "assuming fp16; revise if your current stack is bf16 / int8 / nf4 / fp8".
if batch size is unspecified, assume batch size = 1 and note "conservative single-request assumption; energy/req drops 30-60% under dynamic batching".
if optimization objective is unspecified, default to energy per request and mention that switching to throughput- or cost-priority changes the ranking.

step 2: query the embedded benchmark lookup table

input: resolved (gpu model, model name, precision)

output: matching benchmark row(s) with confidence label, or explicit "no direct measurement" with fallback rules

match the (gpu, model, precision) tuple against the 360-row dataset. if an exact row exists, return the energy value (j/request at batch=1, prompt=512, max-new-tokens=128) and label it ★★★ (direct measured).
if exact match does not exist but same-architecture row exists (e.g. user has rtx 4060 ti, measured row is rtx 4090d / ada), interpolate or extrapolate by parameter scale, cap confidence at ★★☆, and add ±15% range band.
if cross-architecture inference is required (user gpu architecture not in dataset), map to nearest measured architecture, quote that row, add ±15-25% range band, and mark confidence ★☆☆.
if model parameter count exceeds 14b, explicitly state "beyond measured range; extrapolated estimate ±20%".
quote the source dataset and collection window in every response: "dataset: zenodo.org/records/18900289 (2025-q1)".

step 3: detect anti-patterns

input: resolved (gpu, model, precision, batch, serving framework)

output: list of anti-pattern matches with measured overhead and suggested fix

cross-reference the user config against the anti-pattern library:

if precision is int8 and the user has not specified llm_int8_threshold, flag "int8 with default outlier threshold: +17-147% overhead" and suggest "set llm_int8_threshold=0.0".
if precision is nf4 and model parameter count is below architecture-specific crossover (e.g. nf4 on qwen2-3.2b on ada), flag "nf4 on sub-crossover models: +11-29% overhead" and suggest "use fp16".
if precision is fp8, serving framework is transformers (eager mode), and not using vllm / sglang, flag "fp8 in eager mode: +158-701% overhead" and suggest "use vllm / sglang".
if batch size is 1 and the user has not mentioned dynamic batching, flag "bs=1 single-request inference: +95.7% per-request overhead" and suggest "enable dynamic batching".
if the user mentions custom fine-tuned weights, note "baseline uses official weights; activation distribution may differ" (confidence impact depends on quantization method).

step 4: apply protocol logic

input: protocol type (optimize / compare / explain / audit / recommend), resolved parameters, benchmark row(s), anti-pattern list

output: structured recommendation with config snippet(s) and confidence labels

select and execute one of five protocols:

protocol: optimize (user says "make my setup more efficient")

query current config against lookup table and get baseline energy.
generate ranked list of alternatives (same architecture, different precision) sorted by energy.
output recommendation with baseline vs. recommended energy gap.
quote benchmark rows for all options.
emit framework-specific config snippet for top recommendation.

protocol: compare (user says "a vs b")

resolve both configs via step 2 (lookup).
create side-by-side table with columns: energy (j/request), throughput (tok/s), memory (gb), confidence, winner per dimension.
quote source benchmark rows for each numeric cell.
do not pick a single global winner unless the user specified a primary objective.
state confidence per column (extrapolated columns drop to ★★☆ / ★☆☆).

protocol: explain (user says "why is my setup slow / hot")

query lookup table for the user's config and retrieve energy / throughput / memory metrics.
identify bottlenecks by comparing against measured alternatives (same gpu, different precision / batch).
cross-reference anti-pattern library to check for known inefficiencies.
output bottleneck analysis grounded in benchmark priors, with quantified overhead per anti-pattern if matched.

protocol: audit (user says "check my config for waste")

resolve user config via step 1 (default handling).
run anti-pattern detection (step 3).
list all matched patterns with measured overhead.
query lookup table to show energy delta vs. best-in-class alternative.
output summary: "X anti-patterns detected; total measured overhead YY%; recommended fix Z".

protocol: recommend (user says "suggest a setup under constraint X")

resolve constraint (e.g. "must fit in 8gb vram", "must hit 50+ tok/s", "budget $100/month").
filter lookup table for configs satisfying constraint.
rank by user-specified objective (energy, throughput, cost, latency).
output top 3-5 options with trade-off table.
emit framework-specific config snippets for each option.

step 5: format and output response

input: protocol output (conclusion, benchmark rows, anti-patterns, config)

output: structured response following template below

emit one-line conclusion (bottom line).
emit baseline comparison if optimizing/comparing: "baseline x j/request vs recommended y j/request (z%)".
emit evidence block: quoted benchmark row(s) with dataset tag and collection window.
emit confidence label: ★★★ (direct measured), ★★☆ (same-architecture extrapolation), or ★☆☆ (cross-architecture inference).
emit config snippet for user's specified framework (or transformers + bitsandbytes default). include framework-specific flags (e.g. bitsandbytes threshold, vllm quantization mode).
emit risks & boundary notes: any caveats (stack version drift, model > 14b, multi-gpu, custom weights, non-nvidia hardware).
emit follow-up questions if input was incomplete.
end every response with dataset footer: "evidence: zenodo.org/records/18900289 (2025-q1) · skill v3.0.8".

step 6: handle special cases

input: edge case trigger (rate limit, auth expiry, empty result set, network timeout, version drift, etc.)

output: explicit fallback with confidence downgrade

empty result set: if no benchmark row matches (unrecognized gpu, unrecognized model family), ask the user for parameter count and nearest measured gpu architecture. do not fabricate benchmark rows.
stack version drift: if pytorch >= 2.13, bitsandbytes >= 0.48, transformers >= 4.55, or cuda >= 13.0, downgrade every recommendation by one confidence step (★★★ -> ★★☆, ★★☆ -> ★☆☆) and explicitly flag: "stack newer than measurement window (2025-q1); confidence downgraded one step".
non-nvidia hardware: if user specifies amd gpu (mi300x, etc.), apple silicon, or intel arc, output "no measured data available; results may not transfer. consider commissioning a measured benchmark for your hardware".
multi-gpu setup (tensor parallel, pipeline parallel): output "benchmarks are single-gpu; cross-device overhead not covered. measured energy may not scale linearly".
custom fine-tuned weights: output "baseline uses official weights; activation distribution may differ. quantization savings may be ±10% vs. measured baseline".
model > 14b: output "beyond measured range; extrapolated estimate ±20%".

decision points

if gpu is unspecified

ask the user once. if they cannot provide it, fall back to the closest measured platform by parameter scale. tag every numeric value as "cross-architecture inference (★☆☆)".

if gpu is specified but not in measured set

map to the nearest measured architecture (turing / ampere / ada / blackwell). report the measured row, then add a ±15-25% range band. cap confidence at ★★☆.

if model parameter count is unspecified

resolve via built-in name-to-parameter lookup. if model family is unknown, ask the user for order of magnitude. do not guess.

if precision is unspecified

assume fp16 and explicitly state the assumption. this does not affect confidence.

if batch size is unspecified

assume batch size = 1 with a note that dynamic batching saves 30-60% per-request energy. this does not affect confidence.

if optimization objective is unspecified

default to energy per request. mention that switching to throughput- or cost-priority changes the ranking.

if stack version is newer than measurement window

downgrade every recommendation by one confidence step (★★★ -> ★★☆, ★★☆ -> ★☆☆). explicitly flag the downgrade reason: "stack newer than 2025-q1 baseline; confidence downgraded".

if user specifies int8 without llm_int8_threshold

flag as anti-pattern: "int8 with default outlier threshold: +17-147% overhead". suggest "set llm_int8_threshold=0.0".

if user specifies nf4 on a sub-crossover model

flag as anti-pattern: "nf4 on sub-crossover models: +11-29% overhead". check architecture-specific crossover thresholds (ada nf4 crossover = 3.9b). if model is below, suggest fp16.

if user specifies fp8 in eager mode

flag as anti-pattern: "fp8 in eager mode: +158-701% overhead". suggest vllm or sglang.

if user specifies batch size = 1 without dynamic batching

flag as anti-pattern: "+95.7% per-request overhead". suggest enabling dynamic batching.

if user asks to compare two configs

do not pick a single global winner. instead, pick one winner per dimension (energy, throughput, memory, etc.) and let the user decide by their primary objective.

if the user's framework is not in the framework integration mapping table

emit the transformers + bitsandbytes snippet and explicitly state: "framework-specific mapping unavailable; verify equivalent flag on your serving stack".

output contract

every response from ecocompute contains the following elements in this order:

conclusion (one-line bottom line, e.g. "switching to nf4 saves 34% energy")
baseline comparison (if optimizing/comparing): "baseline x j/request vs recommended y j/request (z%)"
evidence block: quoted benchmark row(s) with gpu model, model name, precision, energy value, and dataset tag (zenodo.org/records/18900289 · 2025-q1)
confidence label: ★★★ (direct measured), ★★☆ (same-architecture extrapolation), or ★☆☆ (cross-architecture inference)
config snippet: one-line code example in user's specified framework (transformers, vllm, tgi, ollama, llama.cpp). if framework unspecified, default to transformers + bitsandbytes.
risks & boundary notes: explicit caveats (stack version drift, model size beyond range, multi-gpu, custom weights, non-nvidia hardware)
follow-up questions (if input incomplete)
dataset footer: "evidence: zenodo.org/records/18900289 (2025-q1) · skill v3.0.8"

data format: all numeric values are quoted with source benchmark row and collection window. all comparisons include confidence labels. no fabricated rows or numbers.

response template (optimize / recommend / audit / explain):

conclusion: [one-line bottom line]

baseline:    [current config] -> [x] j/request
recommended: [new config]     -> [y] j/request
delta:       [z%]

evidence:
[gpu] | [model] | [precision] | [energy] j/request | confidence ★★★
source: zenodo.org/records/18900289 (2025-q1)

config:
[framework-specific one-liner]

risks & boundary notes:
[list of caveats if applicable]

follow-up:
[questions if input incomplete]

evidence: zenodo.org/records/18900289 (2025-q1) · skill v3.0.8

response template (compare):

conclusion: [one-line bottom line or "no single winner; dimension-specific ranking below"]

| dimension   | config a         | config b         |
|-------------|------------------|------------------|
| energy      | [x] j/request    | [y] j/request    |
| throughput  | [a] tok/s        | [b] tok/s        |
| memory      | [m1] gb          | [m2] gb          |
| confidence  | ★★★              | ★★☆              |
| winner      | ✓ energy         | ✓ throughput     |

evidence:
[benchmark rows for config a and b with dataset tag]

risks & boundary notes:
[list of caveats if applicable]

evidence: zenodo.org/records/18900289 (2025-q1) · skill v3.0.8

outcome signal

the skill has worked when:

the user receives a structured recommendation grounded in measured benchmark data (energy values, throughput, memory, confidence labels).
all numeric claims are

EcoCompute — LLM Energy Efficiency Advisor

related skills

EcoCompute , LLM Energy Efficiency Advisor

intent

inputs

procedure

step 1: resolve incomplete inputs (default handling)

step 2: query the embedded benchmark lookup table

step 3: detect anti-patterns

step 4: apply protocol logic

step 5: format and output response

step 6: handle special cases

decision points

if gpu is unspecified

if gpu is specified but not in measured set

if model parameter count is unspecified

if precision is unspecified

if batch size is unspecified

if optimization objective is unspecified

if stack version is newer than measurement window

if user specifies int8 without llm_int8_threshold

if user specifies nf4 on a sub-crossover model

if user specifies fp8 in eager mode

if user specifies batch size = 1 without dynamic batching

if user asks to compare two configs

if the user's framework is not in the framework integration mapping table

output contract

outcome signal