nodegrove VRAM: can I run it?
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| can_i_runA | Can this GPU run this open-weight LLM? Returns fits, tight or no, the memory split (weights, KV cache, overhead), a decode-speed ceiling, the longest context that fits and, on a no, every change that would make it fit: quantisation, KV cache, context, another card or a smaller model. Model: a name or id from list_models, any Hugging Face repo id, or its architecture. GPU: a name or id from list_gpus, or vram_gb for any other card. |
| what_fitsA | Which open-weight LLMs fit this GPU: every model in list_models checked at one quantisation and context, with a recommended everyday model (the biggest class that fits with room for context at conversational speed), the largest that fits, the best at Q8 and the first out of reach. GPU: a name or id from list_gpus, or vram_gb for any other card. |
| estimate_vramA | How much memory an LLM needs: weights + KV cache + overhead at each quantisation (or one), at a given context, and the smallest common card class that holds each. Model: a name or id from list_models, any Hugging Face repo id, or its architecture (params_b, layers, kv_heads, head_dim). |
| estimate_from_hf_repoA | Reads any Hugging Face model repo's config.json and parameter count and estimates its memory: the attention layout found (standard, sliding-window, hybrid or latent), how much each 1,000 tokens of context costs, and weights + KV cache + overhead at every quantisation. For models nodegrove.io has not reviewed; anything the reader cannot model is listed in warnings. |
| list_modelsA | The open-weight LLMs nodegrove.io has verified against their config.json (data version 2026-10-16): id, size, attention design, native context, licence, memory at Q4 with 8k context and each model's page. |
| list_gpusB | The GPUs and machines nodegrove.io covers: memory, the memory a runtime can use and bandwidth, from the makers' specs, with each one's page. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Tools are separated along reasonable axes (model+GPU pair, model-only, GPU-only, arbitrary HF repo), but can_i_run, estimate_vram, estimate_from_hf_repo, and what_fits all return overlapping memory-fit information, so an agent must read descriptions carefully to pick the right entry point.
Names use consistent snake_case, but conventions are mixed: list_* and estimate_* follow a verb_noun pattern while can_i_run and what_fits are question phrases. Still readable but not a single predictable scheme.
Six tools is well-scoped for a VRAM-estimation server, with each tool covering a distinct query direction (catalog, forward estimate, reverse fit).
The surface covers model and GPU catalogs, both fit directions, and memory estimation for known and unknown models, forming a near-complete lifecycle. Minor gaps exist around exploring quantisation/context spaces without committing to a model, but most workflows are supported.