EcoCompute Should-I-Quantize Estimator
Energy impact of LLM quantization, calibrated to measured GPU data. Every answer states its basis.
Sollte ich dies verwenden
Qualität und Sicherheit
Basierend auf einer automatisierten Analyse der Tool-Definitionen und der Einhaltung des Protokolls.
Kontextkosten
Dies ist die ungefähre Anzahl der Tokens, die jedes Mal verbraucht werden, wenn die Tools des Servers in den Kontext eines Modells geladen werden. Höhere Werte verringern die Aufmerksamkeit, die für andere Aufgaben verfügbar ist.
Installieren
Installation mit einem Klick
Fügen Sie dies Ihrer Datei `claude_desktop_config.json` hinzu:
{
"mcpServers": {
"ecocompute-estimator": {
"url": "https://ecocompute-estimator.zhanghongping1982.workers.dev/mcp"
}
}
}Remote-Endpunkte
https://ecocompute-estimator.zhanghongping1982.workers.dev/mcpstreamable-httpWas es kann
Tool-Inventar
Tools (4)
🟡estimate_quantization_energy(params_b, arch, precision, batch, ctx, ...)
Estimate the task-level energy change (ΔE% vs FP16) of weight-only quantization (NF4 or INT8) for a model of a given size on a GPU architecture class, from measured-anchored curves. The answer carries basis (measured/interpolated/estimated), confidence and evidence boundaries.
Eingabe-Schema
{
"type": "object",
"properties": {
"params_b": {
"type": "number",
"description": "model size in billions of parameters, e.g. 7"
},
"arch": {
"type": "string",
"enum": [
"turing",
"ada",
"blackwell",
"ampere",
"hopper"
],
"description": "GPU architecture class"
},
"precision": {
"type": "string",
"enum": [
"NF4",
"INT8"
],
"description": "quantization format (default NF4)"
},
"batch": {
"type": "integer",
"description": "batch size (default 1; >1 shrinks savings — modelled, not measured)"
},
"ctx": {
"type": "integer",
"description": "context length (default 2048)"
},
"q": {
"type": "string",
"description": "alternative: plain-English query, e.g. '13B on A100 int8 batch 32'"
}
}
}🟢get_quantization_crossover(arch)
Get the model-size crossover for NF4/INT8 per architecture: below it quantization costs energy, above it saves. Crossovers belong to a card + software stack, not an architecture — the answer says so.
Eingabe-Schema
{
"type": "object",
"properties": {
"arch": {
"type": "string",
"enum": [
"turing",
"ada",
"blackwell",
"ampere",
"hopper"
],
"description": "optional: limit to one architecture"
}
}
}🟢list_data_coverage
List what is actually measured (GPU architecture × precision × size range, NVML direct), what is borrowed/estimated, and where the gaps are. Use this before trusting an estimate at the edges of coverage, and to answer 'is there data for my GPU?' honestly.
Eingabe-Schema
{
"type": "object",
"properties": {}
}🟢search_measurements(query)
Search the measured anchors by model name, GPU name, architecture or size. Returns ΔE% vs FP16 per anchor with run counts — the raw evidence behind the curves.
Eingabe-Schema
{
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "model ('TinyLlama'), GPU ('4090'), architecture ('ampere') or size ('7')"
}
},
"required": [
"query"
]
}Community
Nachweis