Skip to main content
Glama
c3-yang-song

infra-advisor-mcp

by c3-yang-song

estimate_training_cost

Estimate GPU-hours, wall-clock time, cost, and sharding strategy for training runs. Supports pretraining, fine-tuning, LoRA, and RL with automatic parallelism recommendations.

Instructions

Estimate GPU-hours, wall-clock time, cost, and sharding strategy for a training run.

Covers pre-training, continual pre-training, full SFT, parameter-efficient fine-tuning (LoRA / QLoRA), and RL. Uses Chinchilla scaling laws for pre-training compute estimates. LoRA/QLoRA train only small adapters, so they need far less VRAM and fewer GPUs than full fine-tuning (QLoRA quantizes the base to 4-bit). Also returns a recommended parallelism strategy (DDP / FSDP-ZeRO-3 / tensor+pipeline parallel) based on model footprint, GPU VRAM, and interconnect.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_params_bYesModel size in billions of parameters (e.g. 7 for 7B).
training_typeNoOne of pretrain, continual_pretrain, sft, lora, qlora, rl.sft
dataset_tokensNoNumber of training tokens. Uses sensible defaults if omitted.
gpu_keyNoGPU type key (h100_sxm, a100_80gb_sxm, h200_sxm, rtx_4090, l40s).h100_sxm
num_gpusNoOverride GPU count. Auto-calculated from VRAM if omitted.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
training_typeYes
model_params_bYes
dataset_tokensYes
gpu_typeYes
gpu_countYes
mfuYes
total_flops_exaflopsYes
effective_gpu_hoursYes
wall_clock_daysYes
vram_required_gbYes
cloud_costsYes
onprem_cost_usdYes
onprem_capex_usdYes
chinchilla_optimal_tokensYes
parallelism_strategyYes
parallelism_degreesYes
parallelism_frameworkYes
notesYes
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description bears full burden. It mentions using Chinchilla scaling laws and explains LoRA/QLoRA behavior. But it omits limitations, assumptions, or accuracy notes, leaving gaps in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a dense paragraph covering many points. It is front-loaded with the core purpose but could be more structured (e.g., bullet points) for better readability. Some sentences could be merged.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (not shown but known from context), the description does not need to detail return values. It covers training types, algorithm, and parallelism recommendation. Missing explicit prerequisites or context requirements, but overall sufficient for an estimation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and describes all parameters well. The description adds minor value (e.g., 'sensible defaults' for dataset_tokens, enumeration of GPU types) but doesn't significantly extend beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool estimates GPU-hours, wall-clock time, cost, and sharding strategy for training runs, with specific verb 'estimate' and resource 'training cost'. It lists covered training types and distinguishes from sibling tools like estimate_inference_cost and estimate_maintenance_cost.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (for various training runs) and differentiates between training types (e.g., LoRA/QLoRA vs full fine-tuning). However, it does not explicitly state when not to use it or direct to alternatives, though sibling tools provide implicit differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/c3-yang-song/LLM-Infra-Advisor-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server