de en es ja ko ru zh

chimeraforge

Name: chimeraforge
Author: Sahil170595

by Sahil170595

Overview Schema Source Related Servers Discussions Admin

Python

Local

Chimeraforge

PyPI version Python License: MIT

一款本地优先、与模型无关的 LLM 部署规划器。 它把"用哪个模型、什么量化、哪块 GPU、什么后端——需要多少张、能不能装下、能否满足 SLO、要花多少钱"变成快速、诚实、可度量的答案，从你的 shell、你的 Python、或你的 AI 助手中直接获得。

uvx chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB"

信任原则

每个数字都标注为 measured、estimated 或 unknown，工具拒绝伪造它无法背书的数字。 VRAM 和 KV-cache 根据模型的真实架构计算（精确）。吞吐量在有数据时是实测查找，否则是明确的带宽上限估算——绝不冒充它本不是的数据。低于捆绑语料库的质量报告为 unknown，而不是编造的分数。0 结果的计划会指出拒绝所有候选者的具体门槛，而不是泛泛的"未找到"。无遥测、无回传，可离线运行。

给它一个模型——一个规模类别、一个 Hugging Face 仓库、一个 Ollama 标签，或针对未发布模型的手动覆盖参数——它会在（模型 x 量化 x 后端 x GPU 数量 x 张量/流水线并行）空间中，对照 VRAM、质量、延迟、成本、能耗和可选的安防门槛进行搜索，然后返回满足你 SLO 的最便宜配置。

一个工具，12 条命令： plan - suggest - measure - validate - catalog - safety - bench - eval - compare - refit - report - mcp。

经验语料库可追溯至技术报告 TR108-TR137（消费级 GPU 上约 204,000 条真实测量数据）。完整功能历史见 CHANGELOG。

Related MCP server: llm-cost

安装

无需安装即可试用：

uvx chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB"
pipx run chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB"

正式安装：

pip install chimeraforge            # planner + model resolution (HF/Ollama) + suggest/measure/safety/bench
pip install chimeraforge[bench]     # + GPU environment metadata for benchmarks (pynvml)
pip install chimeraforge[mcp]       # + MCP server so Claude/GPT/Cursor can call the planner
pip install chimeraforge[eval]      # + quality evaluation (BERTScore, ROUGE-L)
pip install chimeraforge[refit]     # + coefficient refitting (numpy, scipy)
pip install chimeraforge[all]       # everything

需要 Python 3.10+。核心安装涵盖规划器和面向网络的命令（httpx 是核心依赖）。plan / suggest / catalog 完全离线运行；bench / measure / safety 需要运行中的后端（Ollama、vLLM 或 TGI）。支持 Windows / macOS / Linux。

快速上手

# Plan a registry size class on your GPU
chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB" --request-rate 2.0

# Plan ANY model -- a Hugging Face repo or an Ollama tag
chimeraforge plan --model Qwen/Qwen2.5-7B-Instruct --hardware "RTX 4090 24GB"
chimeraforge plan --model ollama:qwen3:14b --ollama-url http://localhost:11434

# Split a model too big for one GPU across several (tensor parallelism)
chimeraforge plan --model meta-llama/Llama-3.3-70B-Instruct --hardware "H100 80GB" --tp 4

# Shrink the KV-cache, print the cost/latency/quality trade-off menu
chimeraforge plan --model-size 8b --hardware "RTX 4080 12GB" --kv-quant q8 --pareto

# Benchmark a live model and plan on the MEASURED numbers
chimeraforge plan --model qwen3:14b --measure

# Discover + rank what fits your GPU and budget
chimeraforge suggest --source ollama --hardware "RTX 4090 24GB" --budget 500

MCP 服务器——给 Claude / GPT / Cursor 同样的数字

GPU 容量规划恰恰是助手最容易出错的地方：训练截止时的硬件价格和规格，加上凭记忆做 KV-cache/批处理算术极易出错。chimeraforge mcp 运行一个 stdio MCP 服务器，让助手调用真实的规划器，基于实测数据而非猜测。

pip install "chimeraforge[mcp]"

Claude Code：

claude mcp add --transport stdio chimeraforge -- uvx --from "chimeraforge[mcp]" chimeraforge mcp

Claude Desktop / Cursor（添加到你的 MCP 配置文件中）：

{
  "mcpServers": {
    "chimeraforge": {
      "command": "uvx",
      "args": ["--from", "chimeraforge[mcp]", "chimeraforge", "mcp"]
    }
  }
}

--from "chimeraforge[mcp]" 拉入 MCP SDK；uvx 在自包含环境中运行服务器。如果你已经将 pip install "chimeraforge[mcp]" 安装到客户端启动的环境中，也可以改用 "command": "chimeraforge", "args": ["mcp"]。

暴露三个工具：chimeraforge_plan（完整门槛搜索）、chimeraforge_resolve_model（将模型 ID 落实到其真实参数/架构）和 chimeraforge_list_hardware。每个结果都带有与 CLI 相同的 measured / estimated / unknown 来源标注，工具描述会告诉模型优先使用这些数据而非自身知识。chimeraforge_plan 还返回一个 launch 字段——推荐配置的 serve 命令——这样助手就能回答"那怎么运行"而不必编造参数。

命令

`plan` —— 预测性容量规划器

chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB" --request-rate 2.0
chimeraforge plan --model Qwen/Qwen2.5-7B-Instruct --hardware "RTX 4090 24GB"   # any HF repo
chimeraforge plan --model ollama:qwen3:14b --ollama-url http://localhost:11434  # any Ollama tag
chimeraforge plan --model meta-llama/Llama-3.3-70B-Instruct --hardware "H100 80GB" --tp 4   # multi-GPU
chimeraforge plan --model-size 3b --kv-quant q4 --pareto                       # smaller KV cache, trade-off menu
chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB" --launch          # + the serve command to actually run it
chimeraforge plan --model-size 3b --workload agent --safety-target 0.85 --json

规划任何模型：注册表规模类别、HF 仓库（org/name）、Ollama 标签，或手动覆盖参数（--params-b/--n-layers/...）。
在（模型 x 量化 x 后端 x N 副本 x 批处理/GPU）空间中通过 5 道门槛流水线搜索：VRAM -> 质量 -> 安防（可选）-> 延迟 -> 预算。
建模真实服务物理：连续批处理（vLLM/TGI）、prefill/decode 分离（TTFT + TPOT）、KV-cache 约束的并发度，以及方差感知的排队（--workload）。
适配单 GPU 装不下的模型： --tensor-parallel/--tp {N|auto} 将权重 + KV 分片到 N 块 GPU 上（Megatron 风格，已建模通信开销）；--pipeline-parallel/--pp {N|auto} 改为将层拆分到 N 个阶段（在慢速互连上更便宜，需要批处理来填满流水线）。暂不可组合使用。
后端提供什么就服务什么： GGUF 量化在 Ollama 上提供；vLLM/TGI 获得 FP16 和 FP8（仅在具有 FP8 张量核心的 GPU 上——Ada/Hopper/Blackwell/CDNA3）。规划器不再在 vLLM 上以 llama.cpp 加速的价格建议 GGUF 检查点。
KV-cache 量化（--kv-quant {fp16,q8,q4}）缩小缓存并提高最大并发度——在长上下文下收益最大。
成本现实性（--duty-cycle、--gpu-price-multiplier）：头条的 $/1M-tok 价格假设的是满载集群。你还要为预留的余量和每个空闲小时付费，因此 8B 模型在 2 req/s 下的实际数字是满载时 $2.71/1M，30% 负载时 $9.04/1M，而容量满载时为 $0.92。Spot/预留定价是你的输入，不是捆绑的猜测。
自托管与 API 盈亏平衡（--compare-api）：将你的工作负载与托管 API 定价对比，报告自托管开始胜出的月度用量。价格是带每个提供商来源 URL 的日期快照，超过 90 天标记为过期——绝不冒充实时报价——前沿 API 被标注为不同质量层级，而非当作同级别对比。
前缀缓存（--prefix-cache-hit-rate）：聊天机器人和代理流量复用长系统提示词，因此大部分 prefill 已被缓存。在 4k 提示词和 90% 命中率下，8B 模型的 TTFT 从 166ms 降至 17ms。默认为 0 且从不推断，共享前缀节省的 KV 被刻意不扣除——KV 容量不足正是把"装得下"变成 OOM 的原因。
推理模型（--reasoning-tokens N）：隐藏的思考 token 由 GPU 解码并保存在 KV 中，即使调用方永远看不到它们。只计算可见输出会按推理比例低估 decode——在我们自己的检查中，1000 个隐藏 token 将 8B 计划的 p95 从 363ms 推高到 6128ms。默认为 0 且从不推断：该比例是你工作负载的属性，不是权重的属性。
注意力形态感知的 KV： MLA（DeepSeek-V2/V3）缓存压缩的潜在向量而非每头 K/V——将其按 GQA 计算会高估 DeepSeek-V3 的缓存 57 倍——滑动窗口模型在窗口之外停止增长缓存。层模式未声明的窗口不会被应用，因为 KV 容量不足正是把"装得下"变成 OOM 的原因。
混合专家（MoE）感知： VRAM 按总参数量计算（每个专家都驻留内存），而吞吐量和 TTFT 使用活跃参数量（一个 token 只读取它路由到的专家）。将 MoE 模型当作稠密模型会在 Mixtral-8x7B 上低估其吞吐量 3.6 倍，在 DeepSeek-V3 上约 18 倍。活跃数量从模型真实的专家几何结构推导，与已发布数据吻合。
能耗（--electricity-rate）：月度 kWh 成本、$/1M-tok (+energy) 和 tok/s-per-watt，与预算门槛并列报告（不并入其中）。
启动命令导出（--launch）：为胜出配置输出 vllm serve / ollama run / TGI docker run 命令，填入计划自身的上下文长度、TP/PP 度数、批大小和 KV dtype——这些正是容易手算出错的地方。它不会编造无法推导的内容：GGUF 量化级别变成一条注释，建议服务原生等效检查点，而不是虚构的 --quantization 参数。
每个预测都有来源标注（measured / estimated / unknown）；当无配置可行时解释被拒绝的约束门槛。
已在注册表数据上验证：VRAM R^2=0.968，吞吐量 R^2=0.859，质量 RMSE=0.062，延迟 MAPE=1.05%（比解析 M/D/1 好 20.4 倍，TR133）。无机器学习——经验查找表配合第一性原理插值（注册表外模型使用上限估算）。

`suggest` —— 发现并排序模型

chimeraforge suggest --source ollama --hardware "RTX 4090 24GB" --budget 500
chimeraforge suggest --source hf --hf-limit 8 --hardware "RTX 4080 12GB"
chimeraforge suggest --source catalog --hardware "RTX 4080 12GB"   # offline, after `catalog --build`

从运行中的 Ollama（/api/tags）、HF Hub（热门文本生成）和/或本地目录拉取候选；将每个解析为真实参数/架构，运行相同的门槛搜索，并显示每个模型的最佳配置。

`measure` —— 实时基准测试，基于真实数字规划

chimeraforge measure --model qwen3:14b --ollama-url http://localhost:11434
chimeraforge plan --model qwen3:14b --measure   # measure then plan in one step

对运行中的模型进行基准测试（真实 N=1 吞吐量、服务时间、并发扩展），并纳入本地语料库。plan / suggest 随后自动优先使用实测数字（来源标注翻转为 measured）。

`catalog` —— 本地模型目录

chimeraforge catalog --build         # resolve a curated seed (+ --with-ollama) and cache specs
chimeraforge catalog                 # list the cached catalog

持久化已解析的规格，使 suggest --source catalog 能完全离线地对已知良好的集合排序。

`safety` —— 实时拒答筛查

chimeraforge safety --model llama3.2-3b --prompts harmful.txt --quant Q4_K_M --safety-target 0.85

plan --safety-target 基于捆绑的 TR134/TR142 数据决策，而 safety 则测量：它对运行中的模型运行你的探针提示词，分类拒答（基于规则——TR134 正则基线），报告实测拒答率与捆绑门槛数据的对比（预期、漂移、RTSI 风险等级），低于 --safety-target 时以退出码 1 退出。提示词由你提供（--prompts，每行一个）——包内不附带攻击语料库；指向 HarmBench / AdvBench / 你自己的集合。需要运行中的 Ollama。

`bench` —— 实时推理基准测试

chimeraforge bench --model llama3.2-3b --runs 5
chimeraforge bench --model llama3.2-3b --all-quants --context 512,1024,2048,4096 --json
chimeraforge bench --model llama3.2-3b --backend vllm --base-url http://localhost:8000

三种工作负载配置（单请求 / 批处理 / 服务器-Poisson）；测量吞吐量、TTFT 和延迟的 p50/p90/p95/p99；基于 CV 的稳定性警告；JSON 输出。

`eval` —— 质量评估

chimeraforge eval --task general_knowledge --json
chimeraforge eval --predictions preds.txt --references refs.txt --model llama3.2-3b

指标：精确匹配、ROUGE-L（LCS 回退）、BERTScore、连贯性 -> 综合分（0.2*EM + 0.3*ROUGE + 0.3*BERT + 0.2*coherence）。质量等级来自 TR125；3 个内置任务（general_knowledge、summarization、code）。传入 --fp16-baseline 以分类下降等级。

`compare` —— 对比基准测试运行

chimeraforge compare --baseline run1.json --candidate run2.json,run3.json --json

按（模型、后端、量化、工作负载、上下文长度）匹配配置；计算吞吐量/TTFT/时长的差异，并给出总体改进/回退摘要。

`refit` —— 更新规划器系数

chimeraforge refit --bench-dir ./results/ --output fitted_models.json --validate

贝叶斯混合（按键置信度加权）、硬件偏移、幂律重拟合，以及一个 10 项验证套件来把关写入（--validate）。

`report` —— 生成报告

chimeraforge report --results-dir ./results/ --format markdown --output report.md

Markdown（GitHub 兼容）和自包含、XSS 安全的 HTML；统计分析（RMSE、MAE、MAPE、R^2），带每配置百分位表。

`mcp` —— 将规划器提供给 AI 助手

chimeraforge mcp

运行上述 stdio MCP 服务器。需要 pip install "chimeraforge[mcp]"。

建模了什么

维度	计算方式	来源
VRAM / KV-cache	基于真实模型架构做第一性原理推导；采用 KV-quant 以及感知 TP/PP 的 sharding	精确
最大并发数	每 GPU 上受 KV-cache 容量限制的序列数	精确
吞吐量（decode）	优先采用已测量的查表值，否则按带宽 roofline 估算；连续批处理曲线；TP 通信 / PP 气泡	实测 / 估算
TTFT（prefill）限制	计算受限，GPU FP16 TFLOPS × MFU	估算
质量	实测综合指标查表、同族先验估算，或未知	实测 / 估算 / 未知
成本	GPU $/hr × 集群规模（$/1M-tok 在副本数上不变）	精确
能源	TDP 驱动的月度电量（kWh）、$/1M-tok（含能源）、tok/s-per-watt	估算
安全性	TR134/TR142 拒绝率查表（opt-in 门控）	实测 / 未知

硬件： 22 款 GPU——消费级 Ada + Blackwell（RTX 40/50 系列）、数据中心级（A100 40/80GB、H100、H200、B200、L4、T4）以及 AMD MI300X——每款均含 VRAM、带宽、FP16 TFLOPS、TDP 和互联参数（NVLink/Infinity/PCIe）。

已知限制（如实说明）： 尚未对投机解码（speculative decoding）建模。前缀缓存只统计了 prefill 阶段节省的显存，并未统计 KV 缓存（刻意保持保守）。Reasoning token 已建模，但占比是由你用 --reasoning-tokens 传入的，绝不自动推断。对于 MoE，激活参数数 * 是*会建模的，但专家并行（expert parallelism）和路由非均衡未建模。vLLM/TGI 的量化支持 FP16 + FP8（AWQ/GPTQ 暂不支持）；FP8 质量按估算，而非实测。TP 与 PP 的吞吐量只是基于通信模型得出的估算，并非实测值，且不能合并到同一个 plan 中。排队容量是解析化（能感知方差），并不是离散事件模拟器。训练库主要在单台 RTX 4080 12GB 设备上适配；其他 GPU 会先从带宽/算力推算，直到你在自己的机器上 measure 得到测量结果。MCP 服务器仅支持 stdio 传输（Claude Code/Desktop、本地 Cursor），还没有 host 式的远程传输。

研究得到的结论

阶段 2（TR123-TR133，约 10.6 万次测量）沉淀为了一整套基于产物、可落到部署的框架——也就是规划器实际遵守的同一套规则：

决策	建议	依据
单 agent 后端	Ollama Q4_K_M	每美元吞吐最高；质量差距在 -4.1pp 以内（TR123-TR125）
多 agent 后端（N≥4）	vLLM FP16	在连续批处理下获得 2.25 倍优势（TR130-TR132）
编译策略	仅 prefill 阶段、Linux、Inductor+Triton	推理或解码阶段可提速 24-60%；decode 后端崩溃 100%（TR126）
量化方案	默认 Q4_K_M；质量敏感场景用 Q8_0；绝不使用 Q2_K	Q8 与 Q5 之间的合理平衡（TR125）
带长上下文预算	Ollama 在 12GB 上跑 >4K token 时建议使用	VRAM 溢出会造成 25–105 倍的性能悬崖（TR127）
容量规划	`chimeraforge plan`	已在 R²≥0.859 / M/D/1 队列模型上验证，优势 20 × TRP（TR133）
安全筛选	可选启用 `plan --safety-target`	按配置给出拒绝率 + RTSI 风险；拒绝那些会导致安全失效的配置（TR134/TR142）

核心发现（完整数据见各 TR）：Rust 在单 agent 上优于 Python（+15.2% 吞吐、-58% TTFT、-67% 内存——TR112）；双 Ollama 接近完美的多 agent（约 99%）并行度，而单实例仅 82.2%（TR110/TR112 113 及其后续）；vLLM 的连续批处理在 N=8 时带来 2.25 倍优势，强制短板在 GPU 内存带宽，而未非框架自身（TR130-TR132）。

完整 research 看这里： docs/archive/technical_reports.md 索引，全部 32 份报告；包含方法论与原始数据引用的完整归档位于 outputs/publish_ready/reports/。

数据是如何得出的

约 20.4 万次主测量来自 32 份技术报告（TR108-TR137，外加 TR142/TR146 安全数据来源），实验环境为 RTX 相关 Laptop（12 GB）。去重后：TR137/TR142 是已统计数据的整理结果，不再单独计数。
严谨性： 每次运行采用全新进程隔离（避免 warm-cache 干扰），强制冷启动，每个配置运行 3-5 次以达到统计显著性，并使用带完整溯源的结构化 JSON/CSV 日志。所有结论都可回溯原始数据重新复现。
项目背景： ChimeraForge 是父项目 Banterhearts 的 CLI 产物（约 133.7 万次主测量 + 裁判模型测量，跨 54 个 TR）；安全攻击池和相关服务栈研究位于相邻 repos 中。
549 个自动化测试（pytest tests/）覆盖 planner 模型、gate 搜索、resolver、发现、安全、 bench 后端以及 MCP 服务器——核心测试已与 GPU 解耦，无需真实后端也可运行。

复现任何数字：在 outputs/publish_ready/reports/ 中找到对应报告，按其中的引述定位数据目录，检查对应 CSV/JSON，再重新跑提供的脚本或 notebook。详见 docs/archive/methodology.md。

仓库结构

路径	内容
`src/chimeraforge/`	`chimeraforge` CLI + 容量规划器（即 pip 包）
`src/python/banterhearts/`	Python agent 基准测试、监控、profiling
`src/rust/`	Rust 单 agent 和 meltagent 实现（Tokio + 4 个替代运行时）
`outputs/publish/`	正式 TR 归档（TR108-TR137）+ 汇总—— 先看这里获取研究结论
`docs/`	指南、API 文档、TR 索引—— 先看这里获取 how-to
`experiments/`, `data/`, `benchmarks/`	复现脚手架、基线数据、原始 benchmark 产物

文档

docs/README.md —— 文档索引与导航
docs/quick_start.md —— 初次基准运行（Python + Rust）
docs/API.md —— 本包的 Python API 参考
docs/archive/technical_reports.md —— 全部 32 份技术报告索引
docs/archive/dual_ollama_setup.md —— 复现 multi-agent 结果所必需
**docs/archive/methodology.md / docs/archive/rust_vsPython.md —— 方法论与完整语言对比

贡献

欢迎贡献，见 CONTRIBUTING.md。适合的领域：新增 benchmark 配置、新的优化策略、更多模型/硬件、文档及数据分析工具。

许可证

MIT — 见 LICENSE。

致谢

本项目是 Banterhearts LLM 性能研究计划的一部分：阶段 1（TR108-TR122）建立了测量方法论和跨语言对比；阶段 2（TR123-TR133）产出了部署框架与容量规划器；阶段 3（TR134-TR137）量化了推理优化带来的安全成本——现在已作为 planner 中的 opt-in 安全门。

仓库： https://github.com/Sahil170595/Chimeraforge - PyPI： https://pypi.org/project/chimeraforge/ - 状态： Beta，积极开发中

Available Tools

5 tools

chimeraforge_compare_apiA

Compare self-hosting against the hosted APIs for a workload: sizes the cheapest feasible GPU fleet, prices the same traffic through each API model, and gives the monthly output-token volume where the two break even. Use for 'is it cheaper to self-host or use the API', 'when does a GPU pay for itself'. API prices come from a dated snapshot -- the result reports its age and flags it when stale; say so rather than quoting an old price as current.

ParametersJSON Schema

Name	Required	Default
`model`	No
`hardware`	Yes
`duty_cycle`	No
`model_size`	No	8b
`request_rate`	No
`allow_network`	No
`prompt_tokens`	No
`context_length`	No
`latency_slo_ms`	No
`quality_target`	No
`reasoning_tokens`	No
`avg_output_tokens`	No

TDQS

A4.2/5.0

Behavior5/5

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

With no annotations available, the description carries the full behavioral burden and does it well. It discloses that API prices come from a dated snapshot, that the result reports its age and flags staleness, and instructs the agent not to present old prices as current. This is a meaningful, non-obvious behavioral disclosure.

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

Conciseness5/5

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

Three sentences, each earning its place: the first explains what the tool computes, the second gives real user intents, and the third warns about stale pricing. The outcome is well structured and front-loaded.

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

Completeness3/5

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

The description is complete on purpose, behavior, and the staleness caveat, but it does not cover the 12-parameter input surface or any expected return format beyond the three high-level outputs. For a tool with no output schema and no annotations, that leaves a meaningful completeness gap.

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

Parameters2/5

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

Schema description coverage is 0% and there are 12 parameters, so the description needed to compensate. It only implies concepts like workload and traffic without explaining properties such as hardware, model, duty_cycle, latency_slo_ms, quality_target, or avg_output_tokens. An agent would struggle to set these correctly based solely on this description.

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 names a specific action (compare), a specific subject (self-hosting vs. hosted APIs), and the three concrete outputs: cheapest feasible GPU fleet sizing, price comparison for identical traffic, and break-even token volume. This clearly differentiates it from siblings like 'plan' and 'suggest'.

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 gives explicit, user-quoted use cases: 'is it cheaper to self-host or use the API' and 'when does a GPU pay for itself'. It does not explicitly name alternatives or say when to use a sibling tool instead, so it stops slightly short of a 5.

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

chimeraforge_list_hardwareA

List known GPUs with VRAM/bandwidth/TDP/interconnect.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It does not disclose any behavioral traits such as output format, size limits, or whether it reflects real-time data. The simple listing implies read-only behavior but this is not explicitly stated.

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

Conciseness5/5

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

The description is a single, focused sentence that directly states the core action and output characteristics. There is no wasted text, and it is immediately understandable.

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?

For a simple, parameterless listing tool with no output schema, the description is adequately complete. It identifies the resource (GPUs) and the key attributes (VRAM/bandwidth/TDP/interconnect). However, it could marginally benefit from a note on data recency or ordering, but this is not critical given the tool's simplicity.

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

Parameters4/5

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

The tool has zero parameters, so the baseline score is 4. The description correctly implies no input is needed. Since there are no parameters, no additional semantic information is required.

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's function: 'List known GPUs' with specific attributes (VRAM/bandwidth/TDP/interconnect). This is a specific verb+resource and clearly distinguishes from siblings like chimeraforge_plan and chimeraforge_resolve_model.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions. The description is purely functional with no usage direction.

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

chimeraforge_planA

Recommend the best (model x quantization x backend x GPU-count) deployment for a workload, or report why nothing fits. Returns candidates with per-number provenance (measured/extrapolated/estimated/unknown). Use for: 'what GPU do I need for ', 'will fit on ', 'how many GPUs for N req/s', 'what will it cost'. Set platform (linux/windows/wsl2/macos) to the deployment OS: engines are offered only where their own docs say they run.

ParametersJSON Schema

Name	Required	Default
`mode`	No	online
`cloud`	No
`model`	No
`hardware`	Yes
`kv_quant`	No	fp16
`platform`	No
`workload`	No	steady
`lora_rank`	No
`duty_cycle`	No
`model_size`	No	3b
`grid_region`	No
`lora_target`	No	qv
`tpot_slo_ms`	No
`ttft_slo_ms`	No
`quality_from`	No
`request_rate`	No
`think_time_s`	No
`allow_network`	No
`allow_offload`	No
`gpu_overrides`	No
`lora_adapters`	No
`prompt_tokens`	No
`safety_target`	No
`session_turns`	No
`context_length`	No
`latency_slo_ms`	No
`quality_target`	No
`model_revisions`	No
`tensor_parallel`	No
`budget_usd_month`	No
`reasoning_tokens`	No
`avg_output_tokens`	No
`pipeline_parallel`	No
`use_contributions`	No
`host_bandwidth_gbps`	No
`gpu_price_multiplier`	No
`prefix_cache_hit_rate`	No
`max_num_batched_tokens`	No
`unified_memory_fraction`	No
`carbon_intensity_g_per_kwh`	No

TDQS

A3.5/5.0

Behavior4/5

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

With no annotations, the description carries the full burden, and it does disclose two genuine behavioral traits: results come back labeled with per-number provenance (measured/extrapolated/estimated/unknown), which tells the agent how much to trust each figure, and engine availability is gated by the platform's own documentation. It stops short of stating the obvious-but-unconfirmed fact that this is a pure analysis call with no side effects, and says nothing about cost, latency, or what happens when nothing fits beyond a short reason.

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

Conciseness4/5

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

Three tight sentences with the core capability front-loaded, followed by return-shape and use-case routing, then a parameter caveat. No filler or repetition. The platform sentence is somewhat tacked on at the end and could be grouped with the framing, but nothing is wasteful.

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

Completeness2/5

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

For a 40-parameter tool with no annotations and no output schema, the description should be doing far more work than it is. It usefully characterizes the return value via provenance labels even without an output schema, but it leaves the semantics of nearly every input undocumented, gives no prerequisite or scoping guidance, and never states the invocation cost of such a large search space.

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

Parameters2/5

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

There are 40 parameters at 0% schema description coverage, and the description only gives meaning to one of them (platform). High-impact inputs such as gpu_overrides, allow_offload, use_contributions, quality_target, gpu_price_multiplier, prefix_cache_hit_rate, duty_cycle, safety_target, and the parallel/SLO knobs are left completely opaque, so an agent has little basis for filling them meaningfully rather than relying on defaults.

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

Purpose4/5

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

The first sentence names a specific verb (recommend) and a well-defined resource (model x quantization x backend x GPU-count deployment), and even states the failure mode ('or report why nothing fits') plus the return shape (candidates with provenance). It is very clear what the tool does, but it never names or contrasts with the ambiguous sibling chimeraforge_suggest, leaving the agent to infer the boundary from context alone.

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 'Use for:' list gives four concrete query shapes ('what GPU do I need for <model>', 'will <model> fit on <gpu>', 'how many GPUs for N req/s', 'what will it cost'), which is strong intent-routing guidance. It also gives an actionable platform rule (set platform to the deployment OS; engines are offered only where their docs say they run). What is missing is any explicit when-not-to-use or named alternative, so the agent must guess whether a 'what GPU do I need' question belongs here or in chimeraforge_suggest.

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

chimeraforge_resolve_modelB

Resolve a model id to real params/architecture (grounds hallucinated specs).

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes
`hf_revision`	No
`allow_network`	No

TDQS

B3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It hints that results are grounded/real rather than generated, but omits critical behavior: that allow_network defaults to true (this call may hit the network), how hf_revision affects resolution, what happens on failure, and whether results are cached.

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

Conciseness4/5

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

A single front-loaded sentence with no filler; the core action and purpose come first. The parenthetical is slightly jargon-y but earns its place by conveying the anti-hallucination intent.

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

Completeness3/5

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

With no annotations and no output schema, the description should explain more about the return shape ('params/architecture' is only a gesture) and the network/revision behavior of the tool. Adequate as a minimum but leaves meaningful gaps for a 3-param resolution tool.

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

Parameters2/5

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

Schema description coverage is 0% across 3 parameters, so the description must compensate. It only loosely implies what 'model' means (a model id) and says nothing about hf_revision or allow_network, leaving two of three parameters undocumented in both schema and description.

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

Purpose4/5

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

Specific verb+resource: 'Resolve a model id to real params/architecture' clearly states the transformation performed. The parenthetical '(grounds hallucinated specs)' reinforces intent. It is distinguishable from siblings like list_hardware or compare_api, though it never names them.

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

Usage Guidelines3/5

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

The parenthetical implies the use case (verify model specs rather than trust hallucinated ones), which is a soft usage signal. However, it gives no when-not guidance, no prerequisites, and never points to an alternative among the siblings.

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

chimeraforge_suggestA

Rank the models that actually fit and hit the SLO on a given GPU -- the inverse of planning. Use for 'what can I run on a 4090', 'best model for 12GB'. Sources: catalog (offline curated set), ollama (locally installed), hf (top Hub repos).

ParametersJSON Schema

Name	Required	Default
`limit`	No
`source`	No	catalog
`hardware`	Yes
`hf_limit`	No
`ollama_url`	No
`request_rate`	No
`context_length`	No
`latency_slo_ms`	No
`quality_target`	No
`budget_usd_month`	No
`avg_output_tokens`	No

TDQS

A3.8/5.0

Behavior3/5

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

No annotations exist, so the description carries the behavioral disclosure burden. It communicates core behavior: ranking models against a fit/SLO objective and drawing from three sources: catalog, ollama, and hf. However, it does not disclose external interactions (e.g., reaching out to Ollama or Hugging Face), side effects, failure modes, or whether the operation is read-only.

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

Conciseness5/5

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

Two sentences carry the core behavior, user-facing examples, and source list without redundancy. The most important action is front-loaded: 'Rank the models...' instead of burying the intent in filler.

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

Completeness3/5

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

The description covers core purpose and high-level sources, which is enough to make a reasonable first call with the one required parameter. However, with 11 parameters, no output schema, no annotation safety clues, and 0% parameter documentation coverage, the description omits too much detail to fully steer an agent through meaningful variations of source, SLO, latency, and quality trade-offs.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, but it only adds meaning to the source concept ('catalog', 'ollama', 'hf') and general context around SLO. The other 10 parameters, including latency_slo_ms, request_rate, quality_target, hf_limit, and budget_usd_month, are left to the agent to infer from their names and defaults, which is risky for a tool with this much configuration surface.

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 uses a specific verb and object: 'Rank the models that actually fit and hit the SLO on a given GPU.' It clearly identifies itself as the inverse of planning, which separates it from its most likely sibling confusion. The example use cases ('what can I run on a 4090', 'best model for 12GB') make the intent immediately understandable.

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 provides concrete usage framing with quoted examples and explicitly contrasts it with planning. It would be stronger if it also stated when not to use it or pointed to the sibling tools, but the 'inverse of planning' hint gives the agent enough context to route appropriately.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesv0.65.0Oct 18, 2026

Changedchimeraforge_plan1 field changed

addedInput schema / properties / model_revisions

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Model Revisions"
+}

Changedchimeraforge_resolve_model1 field changed

addedInput schema / properties / hf_revision

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Hf Revision"
+}

1 tool updatev0.50.0Oct 4, 2026

Changedchimeraforge_plan4 fields changed

addedInput schema / properties / cloud

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Cloud"
+}

addedInput schema / properties / session_turns

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Session Turns"
+}

addedInput schema / properties / think_time_s

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Think Time S"
+}

addedInput schema / properties / use_contributions

Added value: +{
+  "default": false,
+  "title": "Use Contributions",
+  "type": "boolean"
+}

1 tool updatev0.46.0Oct 1, 2026

Changedchimeraforge_plan6 fields changed

addedInput schema / properties / carbon_intensity_g_per_kwh

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Carbon Intensity G Per Kwh"
+}

addedInput schema / properties / grid_region

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Grid Region"
+}

addedInput schema / properties / latency_slo_ms / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / latency_slo_ms / default
```
Previous value: -5000New value: +null
```
removedInput schema / properties / latency_slo_ms / type
```
Removed value: -"number"
```

addedInput schema / properties / mode

Added value: +{
+  "default": "online",
+  "title": "Mode",
+  "type": "string"
+}

1 tool updatev0.43.0Sep 26, 2026

Changedchimeraforge_plan2 fields changed

addedInput schema / properties / platform

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Platform"
+}

addedInput schema / properties / unified_memory_fraction

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Unified Memory Fraction"
+}

1 tool updatev0.34.0Sep 19, 2026

Changedchimeraforge_plan3 fields changed

addedInput schema / properties / gpu_overrides

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Gpu Overrides"
+}

addedInput schema / properties / max_num_batched_tokens

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Max Num Batched Tokens"
+}

addedInput schema / properties / quality_from

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Quality From"
+}

3 tool updatesv0.30.0Aug 22, 2026

Addedchimeraforge_compare_api

Changedchimeraforge_plan10 fields changed

addedInput schema / properties / allow_offload

Added value: +{
+  "default": false,
+  "title": "Allow Offload",
+  "type": "boolean"
+}

addedInput schema / properties / gpu_price_multiplier

Added value: +{
+  "default": 1,
+  "title": "Gpu Price Multiplier",
+  "type": "number"
+}

addedInput schema / properties / host_bandwidth_gbps

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Host Bandwidth Gbps"
+}

addedInput schema / properties / lora_adapters

Added value: +{
+  "default": 0,
+  "title": "Lora Adapters",
+  "type": "integer"
+}

addedInput schema / properties / lora_rank

Added value: +{
+  "default": 16,
+  "title": "Lora Rank",
+  "type": "integer"
+}

addedInput schema / properties / lora_target

Added value: +{
+  "default": "qv",
+  "title": "Lora Target",
+  "type": "string"
+}

addedInput schema / properties / safety_target

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Safety Target"
+}

addedInput schema / properties / tpot_slo_ms

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Tpot Slo Ms"
+}

addedInput schema / properties / ttft_slo_ms

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Ttft Slo Ms"
+}

addedInput schema / properties / workload

Added value: +{
+  "default": "steady",
+  "title": "Workload",
+  "type": "string"
+}

Addedchimeraforge_suggest

3 tool updatesAug 22, 2026
- First observedchimeraforge_list_hardware
- First observedchimeraforge_plan
- First observedchimeraforge_resolve_model

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.7/5.0

Scored 2026-10-18 01:05 across 5 tools

Disambiguation5/5

Each tool targets a distinct task: model metadata lookup (resolve_model), GPU metadata lookup (list_hardware), forward planning (plan), API-vs-self-host cost analysis (compare_api), and inverse ranking (suggest). The only potential overlap is plan vs suggest, but the description explicitly frames suggest as 'the inverse of planning,' resolving ambiguity.

Naming Consistency4/5

All names share the consistent chimeraforge_ prefix and mostly use a verb_noun pattern (resolve_model, list_hardware, compare_api). Two entries are bare verbs (plan, suggest), a minor deviation that stays readable and predictable.

Tool Count5/5

Five tools is well-scoped for a GPU/model deployment advisor: model resolution, hardware lookup, forward planning, cost comparison, and inverse suggestion each cover a distinct need. No tool feels redundant or missing at the structural level.

Completeness4/5

The surface covers the core advisory lifecycle: resolving models, listing hardware, planning deployments, comparing self-host vs API cost, and reverse-fitting models to GPUs. Minor gaps exist (e.g., no general catalog browsing or pricing-refresh beyond the dated snapshot noted in compare_api), but agents can work around them.

Maintenance

ActivityActive

ResponsivenessSlow

Resources

Need Help?

Related Servers

Related MCP Connectors

tokcalc MCP Server
io.github.stevecrates489-commits
LLM serving capacity planner: VRAM, KV cache, GPU topology, latency, and cost.
AI & Machine Learning Developer Tools
11
StudioTV LLM VRAM Calculator
com.studiotvai
Does an LLM fit on your GPU? VRAM, KV cache and GPU count for any Hugging Face model.
AI & Machine Learning Developer Tools
1
Nodegrove VRAM: can I run it?A
io.nodegrove
Can this LLM run on my GPU? VRAM, speed ceiling and what fits instead, for any model and GPU.
AI & Machine Learning Developer Tools
61
FitLLM A
run.fitllm
Will this LLM fit on your GPU, multi-GPU rig or Mac? Exact VRAM & KV-cache math. Read-only.
AI & Machine Learning Developer Tools
328

Related MCP Servers

infra-advisor-mcp
Cloud Platforms AI & Machine Learning
yangsong7
A
license
A
quality
D
maintenance
Estimates GPU requirements, training/inference costs, and cloud-vs-on-prem TCO for AI workloads using deterministic calculators.
Updated 13 days ago (2026-10-05 18:02 UTC)
12
1
MIT
llm-cost
AI & Machine Learning Developer Tools
comparedge
A
license
Not graded
quality
C
maintenance
Token cost math for LLM API calls: current per-million-token rates for 69 models across 17 providers, with local arithmetic for estimates, comparisons and monthly budgets. Rates are verified and date-stamped.
Updated 3 months ago (2026-07-10 23:44 UTC)
44 npm
2
MIT
ComputeSage server
Agent Orchestration AI & Machine Learning Developer Tools
magnetism87
A
license
A
quality
A
maintenance
Evidence-backed private AI deployment intelligence for GPU and LLM inference. Search benchmark evidence, check deployment fit, predict performance, get hardware recommendations, and generate launch configurations.
Updated 2 months ago (2026-09-02 01:57 UTC)
5
GPL 3.0
DIO Predictive Inference
Agent Orchestration AI & Machine Learning Monitoring
nisaral
A
license
A
quality
A
maintenance
Real-time cluster health monitoring, pre-request NLMS latency prediction, and intelligent prompt routing across multi-instance LLM backends (vLLM, Ollama, SGLang, TGI).
Updated a month ago (2026-09-21 00:36 UTC)
4
3
Apache 2.0

Chimeraforge

信任原则

安装

快速上手

MCP 服务器——给 Claude / GPT / Cursor 同样的数字

命令

plan —— 预测性容量规划器

suggest —— 发现并排序模型

measure —— 实时基准测试，基于真实数字规划

catalog —— 本地模型目录

safety —— 实时拒答筛查

bench —— 实时推理基准测试

eval —— 质量评估

compare —— 对比基准测试运行

refit —— 更新规划器系数

report —— 生成报告

mcp —— 将规划器提供给 AI 助手

建模了什么

研究得到的结论

数据是如何得出的

仓库结构

文档

贡献

许可证

致谢

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`plan` —— 预测性容量规划器

`suggest` —— 发现并排序模型

`measure` —— 实时基准测试，基于真实数字规划

`catalog` —— 本地模型目录

`safety` —— 实时拒答筛查

`bench` —— 实时推理基准测试

`eval` —— 质量评估

`compare` —— 对比基准测试运行

`refit` —— 更新规划器系数

`report` —— 生成报告

`mcp` —— 将规划器提供给 AI 助手