我不断看到同样的本地LLM分量错误: “模型文件比我的GPU小,所以它应该适合。” 这只是第一次检查。
一个24GB GPU没有给您的模型一个干净的24GB内存预算.
显示堆栈,运行时间,临时缓冲,模型权重,和KV缓存都争夺同一个空间.
这是我在下载模型或租GPU之前使用的工作表。
1.
从重量底开始 最简单的重量估计是: 对于一个简单的4位估计:模型尺寸 重地 7B 3.3 GiB 13B 6.1 GiB 70B 32.6 GiB 这些是地板,不是承诺。
真正的量化文件也可以包含更精确地存储的尺度,元数据,和地层.
如果你知道确切的检查站大小,用这个来代替简单的每参数位数估计.
并且使用总参数 一个稀有的混合专家模型 除非你的运行时间 真正卸载不活跃的专家。
活性参数描述每个符号的计算.
它们并不自动描述必须储存的重量。
2.
将实际能力降低到可用的预算水平。
我通常从90%的可用VRAM开始用于规划: 准确的储备取决于OS,显示用法,驱动程序,运行时间,图捕捉,分配器行为等过程.
重要的部分是停止把盒子上的号码当作完全可用的.
3.
添加 KV 缓存 KV缓存是上下文长度和货币变得昂贵的地方.
一个有用的规划公式是: 两个存储键和值的系数.
取一个模型,其中: 32 层 8 KV 头每头128维 8,192 缓存符 1 并列序列 16-位 KV 值,它使用 2 字节 KV 缓存约为 1 GiB.
将上下文提升到32,768个符号,并成为了大约4个GiB.
保持上下文并运行四个并发的序列,它变成大约16个GiB.
这就是为什么一个模型可以在简短的本地聊天中工作,然后在服务器使用更大的上下文窗口或处理几个请求时失败.
组群关注在这里。
使用 KV 头数,而不是全部注意力头数 。
4.
增加运行时间头室我采用这一规划目标:在没有运行时间计量的情况下,20%的运行时间头室率是合理的初步估计。
尽快将其替换为测量数据。
以下是一个假设的32B模型的例子: 4位重地:大约14.9 GiB例 32K KV缓存:大约8个 GiB 小计:大约22.9个 GiB 拥有20%的头室: 大约27.5 GiB A 24 GB GPU, 拥有21.6 GiB可用预算 短约 5.9 GiB. 4位模型文件看起来足够小,但部署没有.
此示例中的架构值只是一个工作表.
在作出硬件决定前先读取实际的模型配置.
5.
不要假设多个GPU完美地添加了2个24GB卡,并不总是表现得像一个干净的48GB池.
特诺平行主义,管线平行主义,地层布置,复制缓冲,互通速度,运行时支持所有物质.
能力估计显示计划是否合理 它不能证明是暂时的或吞吐量。
我在调用本地模式可部署前使用的5个检查, 我写下: 精确的检查站大小或清晰的重量估计值 每个设备的可使用 VRAM KV缓存 准确的运行时间和 GPU 地形 如果其中任何一位失踪,我称答案为一楼,而不是部署计划。
尝试我把这些公式放入一个只浏览器的LLM GPU内存计算器的工作表.
它不会上传您输入的值 。
我最常使用的两个参考文献是"Hugging Face"模型内存估测指南和"变形金刚克V缓存指南".
你最惊讶的是什么样的 具体运行时间的内存成本: 上下文,货币,量化管理费,还是其他的?
披露:我用AI助手帮助编辑结构和措辞.
我对照上述公式核对了数字实例.