交互式模型适配查找器 — 选择硬件或模型，调整量化和上下文。
工作原理
该组件使用以下方式估算内存需求：
MoE 模型（如 Qwen3.8-2.4T-A95B 或 DeepSeek-V3）需要将所有专家权重加载到内存中，因此总参数量决定内存占用——即使每个 token 只运行活跃的子集。
大小计算公式
模型权重每个参数占用固定的字节数，而字节数完全取决于精度：
原始权重大小并非全部。你还需要为 KV 缓存、激活值和框架开销预留内存。上方的组件添加了一个适度的 KV 缓存估算（基于所选上下文长度），再加上权重与 KV 缓存合计的 5% 开销系数：
×1.2 乘数作为快速心算的简便方法——它在一步中包含了一个粗略的 KV 缓存估算和开销，也是下方示例所采用的方式。
计算示例，基于 ~Q4（4-bit），包含 ~1.2 开销：
作为参考，更高精度会将相同模型的大小远远超出单张消费级显卡的容量：
70B FP16 约为 140 GB，120B FP16 约为 230 GB。
Hugging Face 记录了跨模型大小的类似规律：例如，大型模型约 29 GB（bf16），~15 GB（8-bit），~9.5 GB（4-bit）。底层数据请参阅 Hugging Face 的 LLM 优化指南和 llama.cpp 量化 README——GGUF Q4_K_M 使用混合精度，平均约 0.5–0.56 字节每参数。
三元权重压缩比任何标准量化走得更远。Bonsai 2 27B 将每个权重存储为 -1、0 或 +1——每权重约 1.58 bit——将 Qwen3.8-27B 从 54 GB 缩小到 5.9 GB。这可以在消费级 GPU 上低于 6 GB 的 VRAM 中运行。上方的计算器不直接建模三元格式，因为它是一种训练时技术，而非可以应用于任何模型的训练后量化。
这些公式估算的是权重大小。真正重要的实际数字是 Hugging Face 上针对你计划运行的确切量化列出的
GGUF 文件大小，加上你目标上下文长度所需的 KV 缓存。在确定硬件之前务必先核实这些数值。GPU VRAM 速查
来源：NVIDIA GeForce RTX 50 系列、NVIDIA 专业 GPU、Wikipedia：GeForce RTX 40 系列、Wikipedia：GeForce RTX 30 系列、AMD Ryzen AI Max、Apple 技术规格。
独立 GDDR 内存（上述 NVIDIA 显卡）速度快且容量固定——之后无法增加。统一内存（Apple Silicon、Strix Halo）在 CPU 和 GPU 之间共享一个内存池，因此容量可以大得多，但带宽低于独立显卡。
各 VRAM 等级的适配情况
下表估算了在~Q4 量化和适度上下文长度下的适配程度。将每个条目视为估算值——在确定之前，请对照实际 GGUF 文件大小加 KV 缓存进行核实。
可靠依据始终是 Hugging Face 上你所选量化对应的
GGUF 文件大小，加上你的上下文长度所需的 KV 缓存。
选好了模型？连接它
一个认证端点
https://api.tokios.com——无需入站端口，约 5 分钟完成。为什么统一内存能加载大模型但运行更慢
加载模型只需要足够的内存容量来存放权重。快速运行则需要足够的内存带宽来持续供给计算单元，因为单流解码是内存带宽受限的——每生成一个 token 都需要从内存中读取模型权重（对于混合专家模型，则是活跃专家）。预填充（处理提示词）则是计算受限的，表现不同。 这就是两种内存类型的权衡差异：- 独立 GDDR（RTX 4090、5090 等）：高带宽（约
1000–1800 GB/s），但容量由显卡固定。 - 统一内存（Apple Silicon、Strix Halo）：容量大得多（最高
128 GB），但带宽较低（约256–546 GB/s）。
96 GB 统一内存的机器可以加载一个在任何单张消费级 GPU 上都放不下的 120B 模型。但它的 token 生成速度仍然慢于在自身 VRAM 内容纳模型的独立 GPU，因为每 token 移动权重的带宽更少。
不要依赖其他环境发布的 tok/s 数据——硬件、驱动版本、量化、上下文长度和 batch size 都会影响结果。使用 llama-bench 测量你自己的部署，并参阅测试你的部署了解模型运行后对比部署的可复现方法。
后续步骤
开始使用 Tokios
模型适配你的硬件后，Tokios 将其转变为可从任何位置调用的稳定 API 端点。
为你的任务选择合适的模型
大小计算缩小适配范围。任务适配则进一步缩小首先应加载的模型系列。