交互式模型适配查找器 — 选择硬件或模型,调整量化和上下文。
工作原理
该小部件使用以下方法估算内存需求:
MoE 模型(例如 Qwen3.8-2.4T-A95B 或 DeepSeek-V3)会将 所有 专家权重加载到内存中,因此总参数量决定了内存使用量——尽管每个令牌仅运行激活的子集。
尺寸计算公式
模型权重每个参数占用固定字节数,且该字节数完全取决于精度:
原始权重大小并非全貌。在适中的上下文长度下,KV 缓存、激活值和框架内存大约需要增加 20% 的开销(
×1.2)——更长的上下文会在此基础上进一步增加 KV 缓存。由此得出实际计算公式:
~Q4 (4-bit), including the ~1.2 overhead:
作为参考,更高精度会使相同模型的规模远超单张消费级显卡所能承载的范围。
70B 在 FP16 下约为 140 GB,而 120B 在 FP16 下约为 230 GB。
Hugging Face measured a similar pattern on a 15B+ model: about 29 GB at bf16, ~15 GB at 8-bit, and ~9.5 GB at 4-bit. See the Hugging Face guide to optimizing LLMs and the llama.cpp quantize README for the underlying numbers — GGUF Q4_K_M uses mixed precision that averages out to about 0.5–0.56 bytes per parameter.
这些公式估算的是权重大小。真正重要的数字是 Hugging Face 上列出的、针对您计划运行的确切量化版本的
GGUF 文件大小,再加上针对目标上下文长度的 KV 缓存。在确定硬件之前,请务必先检查这一点。GPU 显存概览
资料来源:NVIDIA GeForce RTX 50 系列、NVIDIA 专业 GPU、维基百科:GeForce RTX 40 系列、维基百科:GeForce RTX 30 系列、AMD Ryzen AI Max、Apple 技术规格。
专用 GDDR 内存(上述 NVIDIA 显卡)速度快且容量固定——后续无法增加更多。统一内存(Apple Silicon、Strix Halo)在 CPU 和 GPU 之间共享同一个内存池,因此容量可以大得多,但其带宽低于专用显卡。
各容量适配情况
下表估算了在~Q4 量化下,针对中等上下文长度的舒适程度。请将每个条目视为估算值——在做出决定之前,请结合实际 GGUF 文件大小加上 KV 缓存进行验证。
真实基准始终是您在 Hugging Face 上为所选量化版本查看的
GGUF 文件大小,加上您的上下文长度所需的 KV 缓存。
已选择模型?请连接它
在
https://api.tokios.com 处有一个经过身份验证的端点——无需入站端口,大约需要 5 分钟。为什么统一内存能加载大模型但运行速度较慢
加载模型仅需足够的内存容量来容纳权重。快速运行则需要足够的内存带宽来持续为计算单元供数,因为单流解码是内存带宽受限的——每个生成的令牌都必须从内存中读取模型权重(对于混合专家模型,则是读取激活的专家)。预填充(处理提示词)则是计算受限的,因此表现不同。 这就是两种内存类型权衡方式不同的原因:- 专用 GDDR(RTX 4090、5090 及类似产品):带宽高(大致为
1000–1800 GB/s),但容量由显卡固定。 - 统一内存(Apple Silicon、Strix Halo):容量大得多(最高可达
128 GB),但带宽较低(大致为256–546 GB/s)。
96 GB 统一内存机器可以加载一个在任何单张消费级 GPU 上都无法容纳的 120B 模型。它生成令牌的速度仍会慢于在自身 VRAM 内运行适配模型的专用 GPU,因为每个令牌可用来传输权重的带宽较少。
不要依赖其他配置发布的 tok/s 数值——硬件、驱动程序版本、量化、上下文长度和批处理大小都会影响结果。使用 llama-bench 测量您自己的部署,并在模型运行后,参阅 基准测试您的部署 以获取一种可重复比较部署的方法。
后续步骤
开始使用 Tokios
一旦模型适配您的硬件,Tokios 就会将其转化为一个稳定的 API 端点,您可以从任何位置调用。
为您的任务选择合适的模型
规模确定哪些模型能够适配。任务匹配度则决定首先加载哪个模型家族。