把一台DGX Spark抱回家后我第一件事就是往上面部署Hermes系列的开源私有大模型。原因很简单数据不出门、离线能跑、不用按token计费听起来像是一劳永逸。可真的折腾下来才意识到本地部署并没有把“token成本”消灭只是把计费式的额度换成了物理式的额度——你不再被账单提醒但上下文窗口、KV Cache、内存带宽这些看不见的“额度”依然会把你卡得明明白白。这篇文章就以“在DGX Spark上折腾Hermes”这条主线先拆解这台小机器的硬件底牌再把token的物理账本算清楚最后给出完整的部署配置和排障实录。对正在玩本地大模型或者准备入手高内存开发机但还没算清账的朋友应该能省下不少试错时间。1. 装之前先搞清楚DGX Spark到底强在哪1.1 128GB统一内存才是本地LLM的命根子很多朋友一看到“本地跑大模型”第一反应是看算力比如每秒多少万亿次浮点运算。说实话对于大模型推理尤其是单机单用户场景算力反而没那么容易成为瓶颈。DGX Spark真正值钱的地方是128GB统一内存。这意味着CPU和GPU共享同一块内存池模型权重、KV Cache、中间计算结果都能在一个池子里统一调配省掉了传统显卡那种“显存不够就死给你看”的分裂感。当然我得把话说清楚统一内存只是让物理资源可以互通不代表没有上限。128GB会被三方面抢走模型权重、KV Cache每个token的注意力键值缓存、以及运行时杂项。如果开足上下文、跑大批次照样能让你看到OOMOut Of Memory内存耗尽报错。还有一个经常被忽略的点DGX Spark的功耗和体积决定了它适合放在办公桌上常开。云服务器按小时计费让人不敢随便挂机本地设备则完全由自己掌控训练好一个私有助手后可以7×24小时待命。这个“随时可调、不用排队”的体验本质上也是本地部署的价值之一。1.2 为什么挑Hermes而不是别的开源模型选Hermes系列做部署对象有两个原因。第一它对指令跟随和工具调用的优化在开源模型里属于第一梯队日常当私助手的体验比较接近商业API。第二它的参数规模跨度完整小到8B大到70B甚至更大的版本都有特别适合用来做“同一台机器上跑不同尺寸模型”的对照测试。我这次主要以Hermes 3的8B版和70B版为样本一方面看小模型能不能被喂满长上下文另一方面看大模型在量化之后到底能不能在128GB里舒舒服服地住下来。这里先补一个常识给刚入门的朋友Hermes 3并不是从零训练的原生模型它是基于Llama 3.1系列底座做的继续训练和对话优化。所以它的最大上下文长度、注意力头数量这些底层的“生理结构”继承自底座模型。你看模型卡时会发现它标着128K上下文但标称值能不能兑现到了本地还得先过内存这关。1.3 部署工具怎么选从Ollama到llama.cpp同一台机器上跑同样的模型不同工具给出的体验差很多。我三种都试过结论如下Ollama适合新手和快速试验一条命令就能拉起服务上下文长度、量化等级都能在Modelfile里配置。缺点是封装层级高KV Cache实际占了多大空间、带宽跑到多少你看不太清楚排查问题全靠猜。llama.cpp本项目最终主用的方案。它把模型编译成GGUF量化格式结构简单参数暴露充分--ctx-size、--mlock、--flash-attn这些开关都明明白白。对想弄清楚“token为什么会用完”的人来说这是最好的教学刀具。vLLM更擅长高并发、大批次的在线推理场景在服务器集群上是首选。但在DGX Spark这种“自己一个人用”的桌面环境下它牺牲的显存开销和配置复杂度不值得。所以下面的实操会以llama.cpp为主线Ollama只给一套最简配置作对照。2. Token为什么会在本地“用完”2.1 先分清两种“Token用完”聊这个话题前得先把概念拆开。云端API语境下Token用完通常指钱包不够了是计费模式。本地部署语境下Token用完指的是物理模式上下文窗口占用满了新内容塞不进去KV Cache把内存吃光进程崩溃或拒绝服务单次生成的最大Token数配小了回答开到一半就停模型底层的最大上下文长度到了比如标称128K你再往模型里输入140K的文本它要么截断要么报错。一句话总结本地部署只是把Token额度从“账单”换成了“内存和算力”额度一直存在只是计价单位变了。这也是很多人“以为本地部署无限使用”实测之后却感到困惑的原因。2.2 KV Cache吃掉内存的隐形大户要解释本地上下文长度的天花板必须先说KV Cache。Transformer模型在生成第N个token时会对前N-1个token的Key和Value做缓存下次继续生成时不用重新计算。K和V每份都要在内存里留一份拷贝而且长度随上下文线性增长。给你看具体计算式KV Cache大小 2 × 层数 × KV头数 × 头维度 × 字节数 × 上下文长度以Hermes 3 8B为例基础配置是32层、8个KV头、每个头的维度是128如果使用FP16每个数2字节那么每个token需要2 × 32 × 8 × 128 × 2 131072 字节也就是128KB看起来单token不多但上下文一拉长就相当可观。32K上下文大约需要4GB128K上下文大约需要16GB。这个数字在128GB的DGX Spark上看上去还过得去但请注意这只是FP16未量化KV Cache而且8B已经是小模型了。再看70B版本80层、8个KV头、头维度128FP16下每个token是2 × 80 × 8 × 128 × 2 327680 字节即320KB/token128K上下文的话KV Cache就要约40GB。加上70B模型即使量化到Int4也要35GB左右的权重没怎么使劲128GB统一内存就去掉了75GB再算上运行时开销和系统占用已经很紧张了。所以“标称几K上下文”和“实际能开几K”是两码事。2.3 算一算128GB统一内存真正能撑多大实际操作上我会先给系统和其他进程留15GB余量再把模型权重、KV Cache、推理缓冲区这三项往剩下的预算里塞。按这个规则看Hermes 3 8B量化版约5GB权重如果KV Cache保持FP16不量化上下文可以开到64K甚至128K内存都还有剩。小模型在DGX Spark上是相当滋润的。Hermes 3 70B量化版Int4约35GB如果KV Cache不量化128K上下文需要约40GB总占用约75GB能跑但再叠加多并发或长系统提示词就可能碰壁。如果KV Cache量化到8bit40GB减半成20GB预算立刻宽松很多。这个计算过程说明一个反直觉的结论决定你到底能开多大上下文的往往不是模型参数规模而是你的KV Cache开销策略。模型再大权重是一次性驻留内存的KV Cache却会随着对话轮次和文档长度不断膨胀就像会议室的座位来一个人占一个座。2.4 生成速度你以为算得快其实卡在带宽再补一个容易误判的指标。DGX Spark标称AI算力非常强听起来很恐怖但生成token的时候每个新token都需要把模型权重“过一遍”。在这个环节内存带宽才是真正的天花板。生成速度上限可以用一个很粗的公式估算生成速度tokens/s≈ 内存带宽 ÷ 每次生成需要读取的权重字节数300GB/s级别的内存带宽跑一个Int4量化后约5GB的8B模型理论极限在50token/s上下实测友好对话场景在40~50token/s之间浮动的概率很大跑35GB的70B Int4模型理论极限就掉到8~9token/s实际体验普遍在5~8token/s。这是本地跑大模型最真实的体感瓶颈不是算力不够是每次解码都得从内存里把模型“翻一遍”。上下文变长还会雪上加霜因为注意力计算和KV Cache的读取量也同步增加。你会发现同一个模型短对话流畅得像本地应用长文档问答时回答明显变钝。这种“速度手感骤变”也是token物理上限的另一种表现。3. 实操在DGX Spark上把Hermes真正跑起来3.1 准备环境和模型文件部署前先把系统状态检查一遍。我习惯先确认磁盘余量、内存占用和swap配置。70B的Int4量化GGUF文件大约40GB8B量化文件约5GB下载前至少要留出两倍磁盘空间因为解压或拷贝过程会临时占用额外空间。系统服务尽量精简能关的监控类服务关掉。这个建议在128GB统一内存的机器上听起来多余但大上下文推理时系统很容易因为后台程序占用一点点内存而触发OOM谁踩谁知道。模型文件我选的是Hermes 3对应底座版本的量化GGUF。选量化等级时Q4_K_M性价比最高质量接近半精度且体积可控想要更高精度的对话体验可以用Q5_K_M或Q6_K但DGX Spark的统一内存优势并不是无限容量如果还要同时开长上下文建议就停在Q4_K_M。3.2 llama.cpp部署命令与参数详解以下是我实际跑通的一组配置以Hermes 3 8B的GGUF为例./llama-server -m ./models/Hermes-3-Llama-3.1-8B.Q4_K_M.gguf \ --ctx-size 32768 \ --flash-attn \ --mlock \ --no-mmap \ --host 127.0.0.1 \ --port 8080逐个参数说一下我的选择和理由--ctx-size 32768把上下文窗口开成32K。为什么不直接开128K因为8B虽然内存上扛得住但开128K后KV Cache会占掉相当大的内存空间且长上下文的attention计算时间会明显拉高首token延迟。从产品体验讲32K已经能覆盖绝大多数私助手的对话和文档分析需求。--flash-attn启用Flash Attention优化减少显存占用并加速注意力计算。这个开关别省。--mlock把模型权重锁定在物理内存里避免被换出到swap否则长对话时你可能会经历突然的卡顿。--no-mmap让内存占用更直观。加上它会让加载更慢、占内存更明显但对排查“token用完”这类问题非常有帮助。想调整生成上限时通过请求参数控制。比如调用OpenAI兼容接口时设置max_tokens2048就能限制单次回答最多生成2048个token如果你不设服务会一直生成到停止条件或默认上限长文本场景可能产生你意料之外的token开销。对于想省事的朋友Ollama方案也不复杂Modelfile里写FROM Hermes-3-Llama-3.1-8B.Q4_K_M.gguf PARAMETER num_ctx 32768 PARAMETER temperature 0.7然后直接运行起来。注意Ollama的num_ctx默认往往只有2048很多人说“模型没记忆”或“回答突然掉线”八成是这个值没调。3.3 实测不同模型尺寸下的Token真实上限这次实测我主要记录了资源占用和速度配置权重KV Cache策略上下文长度峰值内存实测生成速度Hermes 3 8B Q4约5GBFP1632K约22GB40~50 token/sHermes 3 8B Q4约5GBFP16128K约54GB20~30 token/sHermes 3 70B Q4约35GB8bit量化32K约55GB5~7 token/sHermes 3 70B Q4约35GB8bit量化128K约75GB4~5 token/s数值为本人实测和估算受宿主系统后台影响会有浮动几个值得注意的现场观察第一8B在128K长上下文的生成速度大幅下滑这说明即便内存装得下带宽和注意力计算也开始成为新的瓶颈第二70B在32K和128K之间的速度差距反而没那么剧烈因为权重读取占了大头KV Cache增加的读取量相对不显著。所以不同模型尺寸下“token用完”的体感完全不同小模型是被速度拖累大模型是被内存吃紧吓到。3.4 把Token额度放大实测有效的四招如果测试之后觉得内存余量不够或者长文本场景多可以按顺序试几个方案对KV Cache做量化。这是性价比最高的一步8bit KV Cache能把缓存开销减半质量损失在多数任务上几乎不可感知4bit方案更激进但有些任务会有明显掉质量建议按需开启。开启Flash Attention等内存优化能降低一部分attention中间变量开销给上下文窗口腾地方。别让单次请求的无限制生成吃掉过多token。在接入业务或自动化脚本时总是给max_tokens设置合理上限避免模型在长文场景里“写到停不下来”。多轮对话使用摘要压缩。聊到一定轮数就调用一次模型把历史总结成摘要再塞回上下文。这是把128K当“无限量”用最容易翻车的地方很多人聊到一半发现模型开始重复或失忆就是因为上下文窗口被旧历史塞满了。及时裁剪和压缩保住你真正需要的上下文空间。4. 折腾这几天踩过的坑和排查实录4.1 启动就崩内存看起来够为什么还是OOM第一次跑70B Int4模型时128GB机器直接OOM。排查下来发现两个原因一是操作系统和桌面环境已经在吃内存后台还需要保留足够的free空间二是我开了过高的上下文窗口但没开KV Cache量化导致上下文KV开销直接爆掉。修正方法把上下文降到32K开启KV Cache 8bit量化并保持mlock锁页问题当场解决。4.2 回答总是“顶到天花板”式地戛然而止有次让8B模型写长报告写到一千多字突然就停了看起来像是生成完毕。排查后发现是请求里的max_tokens默认值给小了。很多人以为是模型能力问题其实是生成长度上限在作怪。建议在UI或代码里显式设置生成上限而不是用默认值。4.3 越聊越慢直到卡顿长对话变成龟速是一个很有迷惑性的过程。一开始速度正常聊了半小时后回答变慢甚至卡住。原因是多轮对话的历史token在不断膨胀KV Cache越来越大注意力和Cache读取都在变重。不要和上下文窗口硬扛这正好是前面说的裁剪和摘要压缩该上场的时机。4.4 长文档问答别把全文硬塞给模型很多朋友遇到长文档第一反应是把文档整个丢进上下文。在DGX Spark这种大内存机器上它能塞但你会看到速度急剧下降如果模型是70B还可能直接把内存吃穿。正确做法是做RAG先把文档切块、向量化检索出和最相关问题最相关的几段再交给模型这样既省token又能跑得更快。下面把这些典型问题整理成一张速查表现象可能原因排查/解决模型启动时立即退出内存不足或模型文件损坏检查剩余内存、重新下载模型文件、先降低ctx-size回答中途无故停止max_tokens设置过小在请求中显式增大max_tokens上下文改大后速度骤降KV Cache和注意力开销暴涨开KV Cache量化、Flash Attention、降低没用的历史长度多轮对话后模型“失忆”旧token把上下文窗口塞满新的历史被截断压缩摘要、滑动窗口裁剪旧历史长文档问答卡到没法用直接把全文塞进上下文改用RAG切块检索后再问答用Ollama时模型“没记忆”num_ctx默认只有2048在Modelfile里显式调大num_ctx4.5 一个额外的经验先跑小模型再上大模型如果是第一次在DGX Spark这类设备上玩本地部署强烈建议从8B模型开始跑通全流程再用同样流程去上70B。原因不复杂8B加载快、素材小、出现问题时日志里一眼能看出是内存问题、配置问题还是模型文件问题直接在70B上排查排错一次加载几十GB光试错时间就够你喝一壶。我在实际测试中还发现一个小习惯很管用监控内存时不要只看“已用内存”要看KV Cache具体吃了多少。llama.cpp的日志会定期打印context、kv cache usage、sampling等统计行。盯着这些数字跑一次长上下文对话你对什么样的任务会吃掉多少token心里就有谱了。说到底本地部署私有大模型并没有消灭token问题它只是把token从一个账单数字变成一个物理资源数字。DGX Spark能把70B量化模型和几十K上下文同时握在手里已经比传统显卡方案宽裕太多但正如上面算的账你要是不管上下文窗口、不量化KV Cache、不给生成长度设上限它一样能在几分钟内让你看到“资源用完”的窘境。我自己的体会是管理好token才是本地大模型的正确打开方式而DGX Spark Hermes只是给了你一个足够大的沙箱怎么在这个沙箱里精打细算才是真正值得折腾的部分。
把一台DGX Spark抱回家后我第一件事就是往上面部署Hermes系列的开源私有大模型。原因很简单数据不出门、离线能跑、不用按token计费听起来像是一劳永逸。可真的折腾下来才意识到本地部署并没有把“token成本”消灭只是把计费式的额度换成了物理式的额度——你不再被账单提醒但上下文窗口、KV Cache、内存带宽这些看不见的“额度”依然会把你卡得明明白白。这篇文章就以“在DGX Spark上折腾Hermes”这条主线先拆解这台小机器的硬件底牌再把token的物理账本算清楚最后给出完整的部署配置和排障实录。对正在玩本地大模型或者准备入手高内存开发机但还没算清账的朋友应该能省下不少试错时间。1. 装之前先搞清楚DGX Spark到底强在哪1.1 128GB统一内存才是本地LLM的命根子很多朋友一看到“本地跑大模型”第一反应是看算力比如每秒多少万亿次浮点运算。说实话对于大模型推理尤其是单机单用户场景算力反而没那么容易成为瓶颈。DGX Spark真正值钱的地方是128GB统一内存。这意味着CPU和GPU共享同一块内存池模型权重、KV Cache、中间计算结果都能在一个池子里统一调配省掉了传统显卡那种“显存不够就死给你看”的分裂感。当然我得把话说清楚统一内存只是让物理资源可以互通不代表没有上限。128GB会被三方面抢走模型权重、KV Cache每个token的注意力键值缓存、以及运行时杂项。如果开足上下文、跑大批次照样能让你看到OOMOut Of Memory内存耗尽报错。还有一个经常被忽略的点DGX Spark的功耗和体积决定了它适合放在办公桌上常开。云服务器按小时计费让人不敢随便挂机本地设备则完全由自己掌控训练好一个私有助手后可以7×24小时待命。这个“随时可调、不用排队”的体验本质上也是本地部署的价值之一。1.2 为什么挑Hermes而不是别的开源模型选Hermes系列做部署对象有两个原因。第一它对指令跟随和工具调用的优化在开源模型里属于第一梯队日常当私助手的体验比较接近商业API。第二它的参数规模跨度完整小到8B大到70B甚至更大的版本都有特别适合用来做“同一台机器上跑不同尺寸模型”的对照测试。我这次主要以Hermes 3的8B版和70B版为样本一方面看小模型能不能被喂满长上下文另一方面看大模型在量化之后到底能不能在128GB里舒舒服服地住下来。这里先补一个常识给刚入门的朋友Hermes 3并不是从零训练的原生模型它是基于Llama 3.1系列底座做的继续训练和对话优化。所以它的最大上下文长度、注意力头数量这些底层的“生理结构”继承自底座模型。你看模型卡时会发现它标着128K上下文但标称值能不能兑现到了本地还得先过内存这关。1.3 部署工具怎么选从Ollama到llama.cpp同一台机器上跑同样的模型不同工具给出的体验差很多。我三种都试过结论如下Ollama适合新手和快速试验一条命令就能拉起服务上下文长度、量化等级都能在Modelfile里配置。缺点是封装层级高KV Cache实际占了多大空间、带宽跑到多少你看不太清楚排查问题全靠猜。llama.cpp本项目最终主用的方案。它把模型编译成GGUF量化格式结构简单参数暴露充分--ctx-size、--mlock、--flash-attn这些开关都明明白白。对想弄清楚“token为什么会用完”的人来说这是最好的教学刀具。vLLM更擅长高并发、大批次的在线推理场景在服务器集群上是首选。但在DGX Spark这种“自己一个人用”的桌面环境下它牺牲的显存开销和配置复杂度不值得。所以下面的实操会以llama.cpp为主线Ollama只给一套最简配置作对照。2. Token为什么会在本地“用完”2.1 先分清两种“Token用完”聊这个话题前得先把概念拆开。云端API语境下Token用完通常指钱包不够了是计费模式。本地部署语境下Token用完指的是物理模式上下文窗口占用满了新内容塞不进去KV Cache把内存吃光进程崩溃或拒绝服务单次生成的最大Token数配小了回答开到一半就停模型底层的最大上下文长度到了比如标称128K你再往模型里输入140K的文本它要么截断要么报错。一句话总结本地部署只是把Token额度从“账单”换成了“内存和算力”额度一直存在只是计价单位变了。这也是很多人“以为本地部署无限使用”实测之后却感到困惑的原因。2.2 KV Cache吃掉内存的隐形大户要解释本地上下文长度的天花板必须先说KV Cache。Transformer模型在生成第N个token时会对前N-1个token的Key和Value做缓存下次继续生成时不用重新计算。K和V每份都要在内存里留一份拷贝而且长度随上下文线性增长。给你看具体计算式KV Cache大小 2 × 层数 × KV头数 × 头维度 × 字节数 × 上下文长度以Hermes 3 8B为例基础配置是32层、8个KV头、每个头的维度是128如果使用FP16每个数2字节那么每个token需要2 × 32 × 8 × 128 × 2 131072 字节也就是128KB看起来单token不多但上下文一拉长就相当可观。32K上下文大约需要4GB128K上下文大约需要16GB。这个数字在128GB的DGX Spark上看上去还过得去但请注意这只是FP16未量化KV Cache而且8B已经是小模型了。再看70B版本80层、8个KV头、头维度128FP16下每个token是2 × 80 × 8 × 128 × 2 327680 字节即320KB/token128K上下文的话KV Cache就要约40GB。加上70B模型即使量化到Int4也要35GB左右的权重没怎么使劲128GB统一内存就去掉了75GB再算上运行时开销和系统占用已经很紧张了。所以“标称几K上下文”和“实际能开几K”是两码事。2.3 算一算128GB统一内存真正能撑多大实际操作上我会先给系统和其他进程留15GB余量再把模型权重、KV Cache、推理缓冲区这三项往剩下的预算里塞。按这个规则看Hermes 3 8B量化版约5GB权重如果KV Cache保持FP16不量化上下文可以开到64K甚至128K内存都还有剩。小模型在DGX Spark上是相当滋润的。Hermes 3 70B量化版Int4约35GB如果KV Cache不量化128K上下文需要约40GB总占用约75GB能跑但再叠加多并发或长系统提示词就可能碰壁。如果KV Cache量化到8bit40GB减半成20GB预算立刻宽松很多。这个计算过程说明一个反直觉的结论决定你到底能开多大上下文的往往不是模型参数规模而是你的KV Cache开销策略。模型再大权重是一次性驻留内存的KV Cache却会随着对话轮次和文档长度不断膨胀就像会议室的座位来一个人占一个座。2.4 生成速度你以为算得快其实卡在带宽再补一个容易误判的指标。DGX Spark标称AI算力非常强听起来很恐怖但生成token的时候每个新token都需要把模型权重“过一遍”。在这个环节内存带宽才是真正的天花板。生成速度上限可以用一个很粗的公式估算生成速度tokens/s≈ 内存带宽 ÷ 每次生成需要读取的权重字节数300GB/s级别的内存带宽跑一个Int4量化后约5GB的8B模型理论极限在50token/s上下实测友好对话场景在40~50token/s之间浮动的概率很大跑35GB的70B Int4模型理论极限就掉到8~9token/s实际体验普遍在5~8token/s。这是本地跑大模型最真实的体感瓶颈不是算力不够是每次解码都得从内存里把模型“翻一遍”。上下文变长还会雪上加霜因为注意力计算和KV Cache的读取量也同步增加。你会发现同一个模型短对话流畅得像本地应用长文档问答时回答明显变钝。这种“速度手感骤变”也是token物理上限的另一种表现。3. 实操在DGX Spark上把Hermes真正跑起来3.1 准备环境和模型文件部署前先把系统状态检查一遍。我习惯先确认磁盘余量、内存占用和swap配置。70B的Int4量化GGUF文件大约40GB8B量化文件约5GB下载前至少要留出两倍磁盘空间因为解压或拷贝过程会临时占用额外空间。系统服务尽量精简能关的监控类服务关掉。这个建议在128GB统一内存的机器上听起来多余但大上下文推理时系统很容易因为后台程序占用一点点内存而触发OOM谁踩谁知道。模型文件我选的是Hermes 3对应底座版本的量化GGUF。选量化等级时Q4_K_M性价比最高质量接近半精度且体积可控想要更高精度的对话体验可以用Q5_K_M或Q6_K但DGX Spark的统一内存优势并不是无限容量如果还要同时开长上下文建议就停在Q4_K_M。3.2 llama.cpp部署命令与参数详解以下是我实际跑通的一组配置以Hermes 3 8B的GGUF为例./llama-server -m ./models/Hermes-3-Llama-3.1-8B.Q4_K_M.gguf \ --ctx-size 32768 \ --flash-attn \ --mlock \ --no-mmap \ --host 127.0.0.1 \ --port 8080逐个参数说一下我的选择和理由--ctx-size 32768把上下文窗口开成32K。为什么不直接开128K因为8B虽然内存上扛得住但开128K后KV Cache会占掉相当大的内存空间且长上下文的attention计算时间会明显拉高首token延迟。从产品体验讲32K已经能覆盖绝大多数私助手的对话和文档分析需求。--flash-attn启用Flash Attention优化减少显存占用并加速注意力计算。这个开关别省。--mlock把模型权重锁定在物理内存里避免被换出到swap否则长对话时你可能会经历突然的卡顿。--no-mmap让内存占用更直观。加上它会让加载更慢、占内存更明显但对排查“token用完”这类问题非常有帮助。想调整生成上限时通过请求参数控制。比如调用OpenAI兼容接口时设置max_tokens2048就能限制单次回答最多生成2048个token如果你不设服务会一直生成到停止条件或默认上限长文本场景可能产生你意料之外的token开销。对于想省事的朋友Ollama方案也不复杂Modelfile里写FROM Hermes-3-Llama-3.1-8B.Q4_K_M.gguf PARAMETER num_ctx 32768 PARAMETER temperature 0.7然后直接运行起来。注意Ollama的num_ctx默认往往只有2048很多人说“模型没记忆”或“回答突然掉线”八成是这个值没调。3.3 实测不同模型尺寸下的Token真实上限这次实测我主要记录了资源占用和速度配置权重KV Cache策略上下文长度峰值内存实测生成速度Hermes 3 8B Q4约5GBFP1632K约22GB40~50 token/sHermes 3 8B Q4约5GBFP16128K约54GB20~30 token/sHermes 3 70B Q4约35GB8bit量化32K约55GB5~7 token/sHermes 3 70B Q4约35GB8bit量化128K约75GB4~5 token/s数值为本人实测和估算受宿主系统后台影响会有浮动几个值得注意的现场观察第一8B在128K长上下文的生成速度大幅下滑这说明即便内存装得下带宽和注意力计算也开始成为新的瓶颈第二70B在32K和128K之间的速度差距反而没那么剧烈因为权重读取占了大头KV Cache增加的读取量相对不显著。所以不同模型尺寸下“token用完”的体感完全不同小模型是被速度拖累大模型是被内存吃紧吓到。3.4 把Token额度放大实测有效的四招如果测试之后觉得内存余量不够或者长文本场景多可以按顺序试几个方案对KV Cache做量化。这是性价比最高的一步8bit KV Cache能把缓存开销减半质量损失在多数任务上几乎不可感知4bit方案更激进但有些任务会有明显掉质量建议按需开启。开启Flash Attention等内存优化能降低一部分attention中间变量开销给上下文窗口腾地方。别让单次请求的无限制生成吃掉过多token。在接入业务或自动化脚本时总是给max_tokens设置合理上限避免模型在长文场景里“写到停不下来”。多轮对话使用摘要压缩。聊到一定轮数就调用一次模型把历史总结成摘要再塞回上下文。这是把128K当“无限量”用最容易翻车的地方很多人聊到一半发现模型开始重复或失忆就是因为上下文窗口被旧历史塞满了。及时裁剪和压缩保住你真正需要的上下文空间。4. 折腾这几天踩过的坑和排查实录4.1 启动就崩内存看起来够为什么还是OOM第一次跑70B Int4模型时128GB机器直接OOM。排查下来发现两个原因一是操作系统和桌面环境已经在吃内存后台还需要保留足够的free空间二是我开了过高的上下文窗口但没开KV Cache量化导致上下文KV开销直接爆掉。修正方法把上下文降到32K开启KV Cache 8bit量化并保持mlock锁页问题当场解决。4.2 回答总是“顶到天花板”式地戛然而止有次让8B模型写长报告写到一千多字突然就停了看起来像是生成完毕。排查后发现是请求里的max_tokens默认值给小了。很多人以为是模型能力问题其实是生成长度上限在作怪。建议在UI或代码里显式设置生成上限而不是用默认值。4.3 越聊越慢直到卡顿长对话变成龟速是一个很有迷惑性的过程。一开始速度正常聊了半小时后回答变慢甚至卡住。原因是多轮对话的历史token在不断膨胀KV Cache越来越大注意力和Cache读取都在变重。不要和上下文窗口硬扛这正好是前面说的裁剪和摘要压缩该上场的时机。4.4 长文档问答别把全文硬塞给模型很多朋友遇到长文档第一反应是把文档整个丢进上下文。在DGX Spark这种大内存机器上它能塞但你会看到速度急剧下降如果模型是70B还可能直接把内存吃穿。正确做法是做RAG先把文档切块、向量化检索出和最相关问题最相关的几段再交给模型这样既省token又能跑得更快。下面把这些典型问题整理成一张速查表现象可能原因排查/解决模型启动时立即退出内存不足或模型文件损坏检查剩余内存、重新下载模型文件、先降低ctx-size回答中途无故停止max_tokens设置过小在请求中显式增大max_tokens上下文改大后速度骤降KV Cache和注意力开销暴涨开KV Cache量化、Flash Attention、降低没用的历史长度多轮对话后模型“失忆”旧token把上下文窗口塞满新的历史被截断压缩摘要、滑动窗口裁剪旧历史长文档问答卡到没法用直接把全文塞进上下文改用RAG切块检索后再问答用Ollama时模型“没记忆”num_ctx默认只有2048在Modelfile里显式调大num_ctx4.5 一个额外的经验先跑小模型再上大模型如果是第一次在DGX Spark这类设备上玩本地部署强烈建议从8B模型开始跑通全流程再用同样流程去上70B。原因不复杂8B加载快、素材小、出现问题时日志里一眼能看出是内存问题、配置问题还是模型文件问题直接在70B上排查排错一次加载几十GB光试错时间就够你喝一壶。我在实际测试中还发现一个小习惯很管用监控内存时不要只看“已用内存”要看KV Cache具体吃了多少。llama.cpp的日志会定期打印context、kv cache usage、sampling等统计行。盯着这些数字跑一次长上下文对话你对什么样的任务会吃掉多少token心里就有谱了。说到底本地部署私有大模型并没有消灭token问题它只是把token从一个账单数字变成一个物理资源数字。DGX Spark能把70B量化模型和几十K上下文同时握在手里已经比传统显卡方案宽裕太多但正如上面算的账你要是不管上下文窗口、不量化KV Cache、不给生成长度设上限它一样能在几分钟内让你看到“资源用完”的窘境。我自己的体会是管理好token才是本地大模型的正确打开方式而DGX Spark Hermes只是给了你一个足够大的沙箱怎么在这个沙箱里精打细算才是真正值得折腾的部分。
![从机械臂视觉分拣工作站到毕业论文：我会这样搭一套 AI 辅助写作流水线 [特殊字符]](http://pic.xiahunao.cn/yaotu/从机械臂视觉分拣工作站到毕业论文：我会这样搭一套 AI 辅助写作流水线 [特殊字符])
