Will a QLoRA fine-tune of gemma-3-4b-it fit your GPU? Verdicts from measured AMD and NVIDIA probes.
Scored across 3 tools
Each tool answers a distinct question: vram_fit evaluates a given config for a verdict, vram_max_rank searches for the largest fitting rank, and vram_probes returns raw measured data. The differing return shapes (verdict/margin vs. max rank vs. probe rows) make misselection unlikely.
All three tools share a consistent 'vram_' prefix, which makes the set recognizable. The suffixes mix verb-like (fit) and noun-like (probes, max_rank) forms, a minor deviation from a strict pattern.
Three tools is thin but well-matched to the narrow purpose of VRAM-fit estimation for LoRA training. Each tool earns its place with a distinct role.
The surface covers the core workflow: check a config, derive a max rank, and inspect raw probe data. A gap remains around discovering which GPUs/cards are available and other config axes, but agents can largely work around it.
Will this LoRA config train on a card with vram_gb GB? Returns verdict fits / tight / does_not_fit, the predicted peak in MB, the margin, how each part was derived, and any measured probe with the same settings.
| Name | Required | Description | Default |
|---|---|---|---|
| os | No | windows or linux; Windows spills instead of OOM | linux |
| dora | No | ||
| rank | Yes | ||
| model | No | unsloth/gemma-3-4b-it | |
| quant | No | Base weights: bitsandbytes nf4 or bf16 | 4bit |
| seq_len | No | Longest training example, in tokens | |
| vram_gb | Yes | Card memory as sold, in GB (8, 12, 16, 24...) | |
| lora_dropout | No | ||
| response_len | No | Tokens the loss covers (the response span) | |
| other_processes_mb | No | VRAM already held by other programs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing that the peak is a prediction with a margin and a derivation breakdown, and that it cross-references a measured probe when one exists with matching settings — telling the agent the estimate's provenance and reliability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the question comes first, then the return contract. No filler, and the most decision-relevant information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters and no output schema, the description does the important work of enumerating the return shape (verdict values, peak MB, margin, derivation, probe). What remains thin is parameter-level meaning for the LoRA config fields, but the core call semantics are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%, so roughly half the parameters (rank, model, dora, lora_dropout, other_processes_mb) carry no descriptive text anywhere. The description only echoes vram_gb, which the schema already documents. It adds almost no parameter meaning beyond the structured fields, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description frames a concrete feasibility question ('Will this LoRA config train on a card with vram_gb GB?') and enumerates the outputs (verdict, peak MB, margin, derivation, probe). This makes the tool's role as a yes/no VRAM estimator unambiguous. It does not explicitly differentiate itself from vram_max_rank or vram_probes, though the mention of 'any measured probe with the same settings' hints at the relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the yes/no question framing — an agent can infer it is for checking a specific config against a specific card. There is no explicit when-to-use guidance, no statement of when to prefer vram_max_rank or vram_probes instead, and no prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Largest LoRA rank (multiple of 8) that fits with margin on a card with vram_gb GB, and the largest that is tight (a real run may fit, the one-step probe would not).
| Name | Required | Description | Default |
|---|---|---|---|
| dora | No | ||
| model | No | unsloth/gemma-3-4b-it | |
| quant | No | Base weights: bitsandbytes nf4 or bf16 | 4bit |
| seq_len | No | Longest training example, in tokens | |
| vram_gb | Yes | Card memory as sold, in GB (8, 12, 16, 24...) | |
| lora_dropout | No | ||
| response_len | No | Tokens the loss covers (the response span) | |
| other_processes_mb | No | VRAM already held by other programs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so a pure local computation is understood. The description usefully explains the two-tier semantics (fits-with-margin vs tight), which is real added context, but it does not disclose the output shape or the cost/assumptions of the probe-estimate it describes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence with the operative concept (largest rank) front-loaded and the two-tier clarification immediately after. No filler, though the nested parentheticals make it slower to parse than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 8 parameters, the description should at least characterize the return value's structure (two ranks? a dict? units?). It conveys the concept fully but leaves the response shape and the dependence on model/quant/seq_len unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 63%; vram_gb's meaning is already in the schema, and the description adds only the 'GB as sold' framing. The other seven parameters (model, quant, seq_len, dora, dropout, response_len, other_processes_mb) that materially change the answer are never referenced in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific derived quantity (largest LoRA rank, multiple of 8) as a function of vram_gb, and even returns two tiers of answer rather than one. It does not name or contrast with the siblings vram_fit or vram_probes, so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Use is implied (planning a LoRA config for a given card size), and the parenthetical about 'a real run may fit, the one-step probe would not' hints at the relationship to vram_probes, but it never says when to call this instead of vram_fit or vram_probes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The raw measured probe rows (RX 7900 XTX and RTX 3060 Ti), filtered by any of the given settings. gpu matches part of the card name, e.g. '7900' or '3060'.
| Name | Required | Description | Default |
|---|---|---|---|
| gpu | No | ||
| dora | No | ||
| rank | No | ||
| quant | No | ||
| seq_len | No | ||
| lora_dropout | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value by disclosing the dataset scope (only RX 7900 XTX and RTX 3060 Ti measurements exist), which bounds what can be returned, but it omits row ordering, result limits, and what happens with non-matching filters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler, with the core identity of the data front-loaded followed by the one parameter clarification that matters most. Slightly vague phrasing ('any of the given settings') costs it a point but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter, zero-required, read-only filter tool with no output schema, the description should say what a probe row contains and how filters combine. It establishes provenance and the gpu matching rule but leaves the returned shape and filter interaction to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across six parameters, so the description must compensate and it only partially does: it explains that gpu is a substring match with examples. dora, rank, quant, seq_len, and lora_dropout are left completely undefined beyond their bare names, and combination semantics (AND vs OR) are unstated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource precisely: raw measured probe rows as opposed to computed/estimated output, which implicitly separates it from siblings like vram_fit and vram_max_rank. It does not explicitly name those siblings, so the differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says results can be filtered by 'any of the given settings', but gives no guidance on when to choose this tool over vram_fit or vram_max_rank, nor any prerequisites or exclusion conditions. The agent must guess that this is the raw-data fallback rather than a computed answer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
vram_fitvram_max_rankvram_probesWill a local LLM run on your hardware? GGUF quant, buy-vs-rent-vs-API cost, used-GPU prices.
Can this LLM run on my GPU? VRAM, speed ceiling and what fits instead, for any model and GPU.
Does an LLM fit on your GPU? VRAM, KV cache and GPU count for any Hugging Face model.
Will this LLM fit on your GPU, multi-GPU rig or Mac? Exact VRAM & KV-cache math. Read-only.
Add one secure layer between your agents and this server.
