EcoCompute Should-I-Quantize Estimator
Energy impact of LLM quantization, calibrated to measured GPU data. Every answer states its basis.
¿Debería usar esto?
Calidad y seguridad
Basado en el análisis automatizado de las definiciones de herramientas y el cumplimiento del protocolo.
Costo de contexto
Este es el número aproximado de tokens que se consumen cada vez que las herramientas del servidor se cargan en el contexto de un modelo. Los recuentos más altos reducen la atención disponible para otras tareas.
Instalar
Instalación con un clic
Agrega esto a tu archivo `claude_desktop_config.json`:
{
"mcpServers": {
"ecocompute-estimator": {
"url": "https://ecocompute-estimator.zhanghongping1982.workers.dev/mcp"
}
}
}Puntos de conexión remotos
https://ecocompute-estimator.zhanghongping1982.workers.dev/mcpstreamable-httpQué puede hacer
Inventario de herramientas
Herramientas (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.
Esquema de entrada
{
"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.
Esquema de entrada
{
"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.
Esquema de entrada
{
"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.
Esquema de entrada
{
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "model ('TinyLlama'), GPU ('4090'), architecture ('ampere') or size ('7')"
}
},
"required": [
"query"
]
}Comunidad
Evidencia