想在一台 32G 统一内存的小主机上把大模型跑成日常可用这件事我前后折腾了小半年。标题里说的这台 Mac mini M6是我们这次讨论的目标平台具体到手规格以实物为准但下面这套推算方法和实测思路对任何统一内存架构的小主机都通用。我最开始的想法很朴素32G 内存装个模型绰绰有余省掉按量计费的 API 账单数据还不出机器。真正跑起来才发现这条路要过的坎比想象中多——内存够不等于跑得动跑得动不等于跑得爽跑得爽不等于划得来。踩坑主要集中在三个地方对32G 能用多少的判断经常高估对真实 TPS的认知经常被各种口径搞乱对到底该本地还是上云的决策经常凭感觉。这篇就把这三件事拆开讲清楚统一内存的账怎么算、TPS 怎么自己动手测、端云之间怎么划一条合理的界线。适合想自建本地推理的个人开发者、要做内网部署的技术负责人以及单纯想知道这台小机器到底行不行的读者。不需要你有很深的推理框架经验但需要你会用命令行、能看懂基本的 Python 脚本。1. 先把预期校准32G 统一内存到底能装下什么1.1 可用额度要扣掉三笔账别拿 32 直接减很多人算内存的方式是32G 减去模型大小这个算法会让人过度乐观因为它漏掉了三笔必须扣掉的账。第一笔是系统与常驻后台桌面系统本身加上浏览器、编辑器、聊天工具正常工作日吃掉 6 到 8G 很常见取保守值 7G。第二笔是推理运行时自身的开销包括计算图缓冲、临时张量、框架加载的动态库一般 0.8 到 1.5G按 1G 算。第三笔是 KV cache也就是上下文缓存它是随对话长度线性增长的很多人压根没把它计入预算结果聊到第三十轮突然整机卡死。所以真正能分给模型权重 KV cache的额度大致是 32 − 7 − 1 24G再留 2 到 3G 的系统缓冲余量实际可用在 21 到 22G 这个区间。这个数字很关键它决定了你的模型选择上限不是32G而是22G。我在早期就是因为忽略这点硬塞一个 32B 的 4bit 模型进去权重占掉 19G上下文一开到 8K 就顶到天花板只要打开一个浏览器标签页整机就开始频繁换页风扇拉满响应从秒级掉到分钟级最后只能强制重启。这个教训值一次记录。有一个反直觉的细节内存压力比内存占用更值得盯。占用 90% 但压力是绿色机器还能跑占用 75% 但压力变黄说明系统已经在压缩内存和换页速度会断崖式下跌。所以判断能不能跑不要只看占用了多少要看内存压力指示和 swap 使用量swap 一旦开始持续增长就说明你超配了。内存项典型占用说明系统与桌面应用6–8 GB浏览器最吃内存跑模型时建议只留必要窗口推理运行时开销0.8–1.5 GB计算缓冲、框架动态库、临时张量模型权重按量化计算见 1.2 节换算公式KV cache随上下文线性增长见 1.2 节公式长上下文场景的大头安全缓冲2–3 GB不设缓冲系统会在关键时刻假死1.2 权重体积的换算参数量乘每参数字节数权重体积的估算公式很朴素权重体积(GB) ≈ 参数量(十亿) × 每参数占用字节数。麻烦在于每参数占用字节数不是一个干净的整数因为量化不只是把 16 位砍到 4 位还要额外存缩放因子、零点偏移以及部分层保留高精度的例外比如输出层、embedding 层常常不量化。实践经验是标称 4bit 的模型实际平均每参数占用在 0.52 到 0.58 字节之间浮动标称 8bit 的实际在 1.0 到 1.1 字节之间。按这个系数算出来的数字比按 0.5 直接算要准误差能控制在 5% 以内。所以 7B 的 4bit 模型实际约 4.0 到 4.5G14B 约 8 到 9G32B 约 18 到 20G70B 的 4bit 已经超过 38G在 32G 机器上根本放不下。这几个数字建议直接记住选模型的时候不用每次都算。KV cache 的公式稍微复杂一点但也不难KV 字节数 2 × 层数 × KV头数 × 头维度 × 上下文长度 × 每元素字节数拿一个典型的 32 层、8 个 KV 头分组查询注意力、头维度 128 的模型举例上下文 8192、FP16 存储2 × 32 × 8 × 128 × 8192 × 2 1,073,741,824 字节 ≈ 1 GiB也就是说这个配置下 8K 上下文只要 1G 的 KV cache很轻松。但如果把上下文开到 32K就是 4G如果模型不支持分组查询注意力KV 头和注意力头一样多比如 32 个同样的上下文要 4G 和 16G差距是数量级的。这就是为什么同样是 32B 模型有的能在 32G 机器上开 8K 上下文有的开 2K 就爆——模型结构差异比参数量差异影响还大。模型规模4bit 权重体积8K 上下文 KV32G 机器可行性7–8B4.0–4.5 GB0.6–1.2 GB宽裕可开 32K14B8–9 GB1.2–2.0 GB舒适可开 16–32K32B18–20 GB1.5–4.0 GB勉强建议 4–8K70B38–42 GB—放不下需部分卸载不建议1.3 真正的天花板是内存带宽不是容量这是最容易被忽略的一条。大模型推理分两个阶段预填充prefill把整段提示词一次性算完和解码decode一个 token 一个 token 往外吐。预填充吃的是算力解码吃的是内存带宽。而用户感受到的快不快绝大部分时间花在解码上——你盯着屏幕上一个个蹦出来的字那就是解码。解码阶段每生成一个 token都要把整个模型的权重从内存里读一遍严格说是读当前层但一轮下来等于全部权重。这就意味着解码速度有个理论上限理论最高 TPS ≈ 有效内存带宽 ÷ 权重体积一台统一内存小主机的带宽量级根据档位不同大致在一百多到两百 GB/s 这个范围。取中间值 150 GB/s 估算跑 14B 的 4bit 模型权重 8.5G理论峰值就是 150 ÷ 8.5 ≈ 17.6 token/s。实际还有注意力计算、KV cache 读取、调度开销能跑到理论值的 60% 到 75% 就算不错了也就是 11 到 13 token/s。这个数字是符合我实测结果的。反过来说跑 7B 的 4bit 模型4.2G理论峰值 150 ÷ 4.2 ≈ 35 token/s实测 22 到 26 token/s体感就是比人打字快不少读起来不卡。跑 32B19G理论峰值 7.9实测 5 到 6.5体感就是能读但等得有点久。这个体感差异不是线性的7 token/s 以下就开始明显急躁了3 token/s 以下基本没法用来做交互式对话。所以选模型的时候先用带宽除以权重体积算出理论峰值再乘 0.65你就大概知道这台机器能给你什么体验了。这个心算过程比任何跑分表都实用因为带宽和权重是你手上唯一确定的两个变量。2. 真实 TPS 怎么测把能跑翻译成能用2.1 三种 TPS 口径不同口径下的差异极大这个模型在我机器上跑多少 TPS这句话本身是不完整的因为至少有三种完全不同的测量口径数值能差三倍以上。第一种是解码速度decode TPS只统计输出阶段的 token 数除以输出耗时这是最贴近用户体验的指标也是我最看重的。第二种是端到端速度用总 token 数提示词加输出除以总耗时短提示词场景下和第一种接近长提示词场景下会被预填充时间严重稀释。第三种是批量吞吐多个请求并发时的总 token 数除以总耗时这个数字通常比单请求解码速度高但对交互式场景没意义。我见过不少人拿批量吞吐的数字来吹单机性能也有人用端到端速度去和外部的按量计费服务比价格这两种对比都是失真的。你要做的第一件事是先想清楚自己关心哪个口径。做交互式对话关心解码速度做离线批处理关心批量吞吐做长文档分析关心预填充速度和首字延迟TTFT。首字延迟这个指标特别值得单独拎出来说。它等于预填充耗时直接决定用户按下回车后要愣多久。一个 4K token 的提示词在算力受限的小主机上预填充速度大概每秒几百个 token也就是 8 到 20 秒才吐出第一个字。这个体验对交互式应用是致命的但对提交任务然后去泡杯咖啡的批处理场景完全可接受。所以别把 TTFT 和 TPS 混在一起评价它们是两个独立维度。口径计算方式适用场景我实测的典型值区间首字延迟 TTFT请求发出到首个 token 到达交互式对话、在线问答1K 提示 2–5 秒4K 提示 8–20 秒解码速度输出 token 数 ÷ 输出耗时交互式对话、流式生成7B 22–2614B 11–1432B 5–6.5端到端速度总 token 数 ÷ 总耗时成本核算、批量任务约为解码速度的 40%–80%批量吞吐并发总 token ÷ 总耗时离线数据处理视并发数而定单机难有优势2.2 一份可直接用的流式计时脚本别信任何我感觉挺快的描述包括我上面写的那些数字你都得自己测一遍才作数因为散热、后台程序、系统版本都会影响结果。最靠谱的测法是走流式接口逐 token 打时间戳这样 TTFT 和解码速度能一次性拿到。下面这段脚本假设你在本地起了一个兼容流式接口的推理服务端口按你实际的改import time import json import requests def measure(url, model, prompt, max_tokens256): payload { model: model, messages: [{role: user, content: prompt}], max_tokens: max_tokens, stream: True, temperature: 0.2, } t_start time.perf_counter() t_first None chunks 0 with requests.post(url, jsonpayload, streamTrue, timeout600) as r: for line in r.iter_lines(): if not line: continue if not line.startswith(bdata: ): continue body line[6:] if body.strip() b[DONE]: break try: obj json.loads(body) except json.JSONDecodeError: continue delta obj.get(choices, [{}])[0].get(delta, {}) if delta.get(content): if t_first is None: t_first time.perf_counter() chunks 1 t_end time.perf_counter() ttft (t_first - t_start) if t_first else float(nan) decode_time (t_end - t_first) if t_first else float(nan) decode_tps (chunks - 1) / decode_time if decode_time and chunks 1 else 0 e2e_tps chunks / (t_end - t_start) print(f输出 token 数: {chunks}) print(f首字延迟 TTFT: {ttft:.2f} s) print(f解码速度: {decode_tps:.2f} tok/s) print(f端到端速度: {e2e_tps:.2f} tok/s) return ttft, decode_tps, e2e_tps if __name__ __main__: url http://127.0.0.1:8080/v1/chat/completions prompt 用三百字解释一下什么是内存带宽尽量具体。 measure(url, local-model, prompt, max_tokens300)几个使用上的细节不注意会让结果失真。第一max_tokens别设太小太小的样本受启动抖动影响大建议 256 到 512。第二同一个测试连跑三次取中间值第一次往往因为模型刚加载、缓存还没热而偏慢。第三测试时把浏览器、编辑器、聊天工具都关掉因为这些程序的内存占用会挤压模型可用的缓存空间直接影响解码速度。第四温度设低一点0.2 左右高温采样会增加一点开销虽然影响不大但没必要引入变量。如果你不想写脚本也有偷懒的办法用命令行工具跑一次生成长文本的任务用time包起来然后数一下输出的大致 token 数中文按每字约 1.5 token 粗算英文按每 4 字符 1 token 粗算除一下就是端到端速度。这个方法精度差但足够判断这台机器能不能用。# 只关心单次生成长文本的端到端耗时 time local-llm run \ --model ./models/model-14b-q4 \ --ctx 8192 \ --predict 512 \ --prompt 写一篇八百字的产品说明主题是便携咖啡机。2.3 实测结果表不同规模在不同上下文下的表现我把手上这台机器32G 统一内存的实测数据整理成下表测试条件统一为温度 0.2、输出 256 token、后台只保留终端。上下文长度那一列是指总上下文提示词加输出因为 KV cache 的开销是按总长度算的这是很多人测错的地方——只改输出长度不改提示词长度是测不出上下文衰减的。模型规模上下文 2K上下文 8K上下文 32K备注7–8B 4bit26 tok/s23 tok/s17 tok/s全场景可用长上下文衰减可接受14B 4bit13 tok/s11 tok/s8 tok/s日常主力8K 以内体验最好32B 4bit6.5 tok/s5.2 tok/s内存不足仅建议短上下文、离线任务70B 3bit 部分卸载2.0 tok/s1.4 tok/s无法运行不建议性价比极低这张表里最有信息量的是上下文从 2K 涨到 32K7B 模型的解码速度掉了三分之一这件事。原因有两个一是 KV cache 变大了每次生成新 token 要读的缓存更多挤占了本就不富裕的带宽二是注意力计算量随上下文线性增长在解码阶段开始变成不可忽略的开销。这个衰减曲线不是线性的8K 以内比较平缓16K 之后开始明显往下掉所以如果要做长文档场景最好在 8K 以内做分块处理而不是硬开大上下文。还有一点值得单独提预填充速度和上下文长度的关系更陡。同样这台机器1K 提示词的首字延迟 2 到 4 秒4K 就到 10 秒上下8K 能到 30 秒。这意味着长文档总结这种任务本地跑的瓶颈不在生成而在读题。如果你要做的是扔进去一份两万字报告让它总结那本地体验会比你想的差很多这个场景恰恰是云端更擅长的。2.4 影响 TPS 的七个变量按影响从大到小排测了这么多轮我按影响程度把变量排了个序方便你在速度不达预期时按顺序排查。第一位是模型结构和量化方式。分组查询注意力的头数差异能让 KV cache 差四倍混合专家结构的模型激活参数少解码速度可能比同参数量的稠密模型快两三倍但权重仍要全部驻留内存内存账并不会省。量化方式上4bit 和 5bit 的速度差通常在 10% 以内但 8bit 比 4bit 慢接近一倍因为每 token 要读的字节数翻倍了。第二位是上下文长度。上节已经说了这个影响是持续的、累积的不是一次性开销。第三位是散热与降频。小主机的散热余量本来就紧连续跑十几分钟后如果风扇转速拉满、机身发烫解码速度掉 20% 到 30% 是常事。我做过对比测试冷机第一次跑 13 tok/s连续跑二十分钟后掉到 10 tok/s。所以任何跑分如果不注明持续时长参考价值都有限。第四位是后台内存压力。这个前面提过内存压力变黄之后系统开始压缩和换页速度是断崖式的不是渐变。第五位是线程数配置。线程数设成物理核心数通常最优设成逻辑核心数超线程数反而会因为争抢而变慢。这个参数很多人随手设成 8 或 16其实应该按机器实际核心数来。第六位是批处理大小。单请求场景下批大小设 1 就行设大了只会浪费内存。只有做离线批量任务时才值得调大。第七位是采样参数。温度、top-p、重复惩罚这些对速度影响很小但如果你开了很激进的重复惩罚会在每步做额外的词表扫描边际上有几个百分点的影响。3. 从跑起来到跑得舒服一份可复现的部署调参流程3.1 环境与模型文件准备先做减法部署这件事我的经验是先做减法再做加法。减法指的是把机器上不必要的东西先清掉关掉开机自启的云盘同步、关掉常驻的聊天工具、退出浏览器。这一套下来能腾出 4 到 6G 内存直接决定了你能不能跑大一号的模型。我做过对比同样跑 14B清完后台从 11 tok/s 提到 13 tok/s跑 32B 从勉强能开 4K变成能开 8K收益比调任何参数都大。模型文件的选择上优先挑量化版本里标注了分组查询注意力、并且 KV cache 量化可用的。文件名里通常会带量化和上下文信息比如带 q4、q5 这类标识的就是 4bit、5bit 量化。下载后第一件事是核对文件大小和 1.2 节算出来的理论值对照差得太多说明要么量化位数不对要么混了不该混的层。存储空间也要留够。模型文件动辄十几 G加上系统盘本身要留 15% 以上的空闲否则文件系统性能会下降所以 256G 的机器跑 32B 模型基本是紧平衡。建议把模型放在外置高速存储上但要注意外置盘的读取速度如果跟不上模型加载时间会明显变长——加载 19G 的模型内置盘可能几十秒慢速外置盘能到几分钟。3.2 关键参数逐项拆解每一个都有它存在的理由参数不是越多越好我建议先把下面这几个搞明白其余的用默认值就行。上下文长度ctx。这是最需要克制的一个参数。它决定了 KV cache 的大小也决定了内存能不能撑住。设置原则是按实际需要再加 20%不是能开多大开多大。因为框架通常会按你设置的上限预分配 KV cache 空间你设 32K 它就占 32K 的内存哪怕你实际只聊了 2K。这个设计很多人不知道导致内存莫名其妙被吃掉一大块。我现在固定设 8K跑 14B 时内存占用稳定在 13G 左右很舒服。卸载到加速器的层数。全量卸载把所有权重层都放进统一内存由图形处理器计算在统一内存架构上是默认选择因为内存本来就是共享的没有显存不够的问题。但如果模型太大就得留几层在处理器上算速度会掉一个数量级。所以这个参数的正确用法是能全量就全量一旦需要部分卸载说明模型选大了换小一号比调参数划算。KV cache 量化。把 KV cache 从 16 位降到 8 位能省一半缓存内存代价是长上下文时精度略有下降。这个取舍在 32G 机器上很值得做尤其是你要跑 32B 模型的时候——8K 上下文的 KV 从 2G 降到 1G可能就是能跑和不能跑的区别。实测下来8 位 KV 量化对输出质量的影响在我的使用场景里几乎感知不到但对内存的缓解是实打实的。线程数。设成物理核心数别设逻辑核心数。这条前面说过但值得重复因为它是免费的提速。批大小。交互场景设 1离线批处理按内存余量往上调但注意批大小是乘在 KV cache 上的——批 4、上下文 8KKV cache 就是单请求的四倍。这个乘法关系经常被忽略。参数我的推荐值32G 机器调整理由上下文长度8192交互、327687B 专用框架按上限预分配 KV设大了纯浪费加速器卸载层数全部部分卸载速度掉一个数量级不如换小模型KV cache 精度8 位省一半缓存质量损失几乎不可感知线程数物理核心数设逻辑核心数会因争抢变慢批大小1交互、2–4离线批大小与 KV cache 是乘法关系温度0.2–0.7与速度关系不大按任务调3.3 一份可以直接抄的启动配置与验证流程把上面这些组合起来我给两套配置一套是日常交互用一套是跑大模型时用。# 配置 A14B 模型日常交互主力追求响应速度 local-llm serve \ --model ./models/model-14b-q4 \ --ctx 8192 \ --batch 1 \ --threads 8 \ --kv-cache-type q8_0 \ --gpu-layers 99 \ --port 8080 # 配置 B32B 模型短上下文离线任务 local-llm serve \ --model ./models/model-32b-q4 \ --ctx 4096 \ --batch 1 \ --threads 8 \ --kv-cache-type q8_0 \ --gpu-layers 99 \ --port 8081启动之后的验证流程我固定跑四步每一步都有明确的判断标准第一步看加载日志里的内存分配。日志通常会打印权重占用和 KV cache 预分配的大小把这两个数加起来对照 1.1 节的可用额度如果超过 22G直接换小模型别硬撑。第二步测一次冷启动的首字延迟。发一个 500 字左右的提示词记录第一个 token 到达的时间。超过 5 秒说明预填充偏慢考虑缩短提示词或者换更小的模型。第三步测三次 256 token 的输出看解码速度的稳定性。三次结果波动超过 15%说明有后台干扰或者散热问题去查内存压力和机身温度。第四步跑到上下文上限附近再测一次。这是最容易被跳过的一步但恰恰最重要。很多人测速只测第一轮对话那时候上下文才几百 token自然是快的。真正的问题是聊到第 20 轮、上下文涨到 6K 的时候速度掉到多少、内存还剩多少。我的做法是准备一段长文本反复喂进去把上下文顶到上限附近再测一次解码速度这个数字才是你实际使用中会遇到的。3.4 让老机器更稳的几个小动作有几个不起眼但很管用的操作我按有效性排序。一是限制模型服务的常驻内存上限。有些框架支持设置最大内存超过就报错退出这比死机强得多。宁可服务崩掉重启也不要整机卡死——整机卡死的时候你连强制退出的机会都没有只能长按电源键。二是把 swap 用起来但要监控它。系统盘上的交换空间是一道保险模型偶发超配时能救你一命。但如果 swap 持续增长说明你的配置长期超配这时候性能已经不可用了必须换配置。我的判断标准是swap 使用量稳定不变可以接受持续增长就必须处理。三是固定电源与性能模式。小主机在节能模式下会主动降频跑模型时一定要切到高性能模式。这个设置一次就好别忘了。四是把模型文件放在独立目录别和系统更新搅在一起。系统大版本更新后有时候会重建索引扫描几十 G 的模型文件机器会突然卡一阵。放在独立目录并且排除索引能避免这个干扰。4. 端云决策不是二选一是按任务分流4.1 一张决策矩阵先想清楚你要的是什么本地还是云端这个问题之所以难回答是因为大部分人把它当成了一个非此即彼的选择题而实际上它应该是按任务分流的。我给自己定的决策依据是四个维度延迟要求、数据敏感度、调用频率、质量要求。这四个维度组合起来答案往往很清晰。延迟敏感 数据敏感 高频 本地。典型场景是内网的知识库问答、代码补全辅助、日常的文本改写。这些任务对交互延迟有要求数据不方便出门而且调用量大本地跑省下的费用最可观。延迟不敏感 数据敏感 低频 本地但可以接受慢。典型场景是敏感文档的批量摘要、内网日志的归类分析。这类任务可以挂着慢慢跑速度不是关键。质量要求高 复杂推理 云端。这个没什么好纠结的小模型和大模型在复杂推理上的差距是明显的尤其是多步推理、长链条代码生成、专业领域深度问题。本地跑 14B 能做的事和云端跑一个更大的模型能做的事不在一个层级上。长上下文 高并发 云端。前面测过长上下文的预填充在本地是分钟级的并发更是完全撑不住。这类需求交给云端是理性的。任务类型建议主要原因日常对话、文本改写本地延迟低、无边际成本、质量够用内网知识库问答本地数据不出内网是硬约束代码补全、片段生成本地高频、短输出、延迟敏感敏感文档批量摘要本地可以慢但不能外传复杂多步推理云端小模型能力上限明显十万字长文档分析云端本地预填充时间不可接受高并发服务云端单机吞吐撑不住偶尔用一次的任务云端本地部署的时间成本划不来4.2 把本地成本算成钱这笔账很多人算错了本地跑省钱这句话在很多场景下是站不住的。我们把账算细一点。硬件成本按折旧摊。假设这台机器 6000 元用三年每天实际负载 4 小时这个负载强度已经不低了总可用时长 3 × 365 × 4 4380 小时摊下来硬件成本约 1.37 元每小时。电力成本按整机功耗 50 瓦算每小时 0.05 度电按 0.65 元一度约 0.03 元每小时。合计约 1.4 元每小时。产出这边跑 14B 模型解码 13 tok/s理论上一小时能出 46800 token。但实际使用中有等待、有思考、有预填充、有闲置真实利用率能到 50% 就不错了按 23000 token 每小时算。那么每百万 token 的成本约是 1.4 ÷ 23000 × 1000000 ≈ 61 元。这个数字意味着什么意味着如果你的任务量不大本地跑的单位成本比按量计费的服务贵得多。本地真正省钱的场景是调用量极大把硬件成本摊薄或者你的时间不值钱开玩笑的说法但确实是事实。那本地的价值在哪我认为是三条都不是省钱数据不出机器这是最硬的一条很多场景没得选没有配额和限流想跑多少跑多少不用看着账单犹豫离线可用断网也能干活。这三条对特定场景是刚需对普通场景就是锦上添花。所以如果你只是想省点 API 费先算一遍上面这笔账可能会改主意。4.3 混合架构怎么落地一个路由层就够如果两边都要用工程上不需要搞得很复杂一个路由层加一套降级逻辑就够用。路由层做的事很简单判断这个请求该走哪边。import re LOCAL_TASKS {rewrite, summarize_short, code_complete, translate} SENSITIVE_PATTERNS [r内部, r合同, r客户名单] # 按你的实际情况补充 def route(request): text request[text] task request.get(task, chat) # 一、敏感内容一律本地 if any(re.search(p, text) for p in SENSITIVE_PATTERNS): return local # 二、短输入短输出的高频任务走本地 if task in LOCAL_TASKS and len(text) 2000: return local # 三、超长输入走云端本地预填充扛不住 if len(text) 20000: return cloud # 四、其余走云端失败时降级到本地 return cloud def call_with_fallback(request): target route(request) try: return call_cloud(request) if target cloud else call_local(request) except Exception: # 云端不可用时降级本地本地也不可用时抛错 return call_local(request) if target cloud else call_cloud(request)这套逻辑的要点有三个。第一敏感判断放在最前面别让敏感内容先经过一次路由计算再决定减少误判路径。第二降级方向要选对质量敏感的任务云端挂了降级到本地是降质保可用长文档任务降级到本地可能会直接超时这种情况应该返回错误而不是硬扛。第三加一层结果缓存同样的输入短时间内重复请求直接命中缓存这一层能省掉相当一部分调用量尤其是在开发和调试阶段。还有一个小技巧本地模型的输出质量如果只是略差一点可以用云端结果做校准样本把常见的失败案例整理成少样本示例塞进本地提示词里往往能把质量补回来一大截。这个做法成本极低效果比我预期好。4.4 一条容易被忽略的边界什么内容不该进本地模型最后说一条实践中的边界。本地部署带来的数据不出机器的安全感有时候会让人放松对内容本身的管控。实际上本地模型同样会产生日志、缓存、会话历史这些文件默认落在磁盘上如果你在共享机器上跑等于把对话内容留给了下一个使用者。我的处理方式是三条把会话历史目录设置为临时目录并定期清理服务只监听本地回环地址不对外暴露日志级别调到只记录错误不记录请求内容。这三条做起来只要几分钟但能避免很多麻烦。另外本地模型的能力边界也要心里有数它在不确定的时候会一本正经地编这个特性在涉及事实核查的场景下要格外小心别因为这是我自己机器跑的就放松警惕。5. 踩坑实录与常见问题速查5.1 内存打满和整机假死怎么提前发现这个问题我遇到过三次前两次都是硬重启解决的第三次才摸清规律。表现是模型跑着跑着风扇突然拉满鼠标还能动但点击没反应几秒后整个界面冻结等十分钟也不恢复。根本原因是内存压力到了临界点系统开始大量换页磁盘读写打满所有进程都被拖住。关键在于这个崩溃是有前兆的只是前兆出现的时间窗口很短可能只有十几秒。前兆是内存压力指示灯变黄swap 使用量开始以每秒几十兆的速度增长。所以我的做法是开一个终端窗口常驻跑一个简单的监控脚本盯着这两个指标# 每 2 秒打印一次内存压力和 swap 使用量 while true; do echo --- $(date %H:%M:%S) --- memory_pressure | tail -3 sysctl vm.swapusage sleep 2 done看到 swap 使用量在涨立刻停掉推理服务别犹豫。这时候停服务只要几秒等系统完全卡死就得硬重启损失大得多。预防上最有效的一招是给上下文长度设一个你有把握的上限而不是能开多大开多大。我现在的固定配置是 14B 配 8K、32B 配 4K跑一整天不关也不会出问题。之前图省事设 32K结果聊到第 30 轮就爆了而且爆得很突然因为 KV cache 是线性增长的前面一直很稳到某个点突然越线。5.2 输出质量突然变差按这个顺序排查质量问题的排查比性能问题麻烦因为它没有明确的数字指标。我总结了一个排查顺序从最可能的原因开始。先看上下文是不是快满了。上下文接近上限时框架会开始截断早期内容表现为它忘了我前面说过的话。这个是最常见的原因解决方法是开新会话或者缩短提示词。判断方法很简单看日志里当前上下文字符数如果接近设定上限的 90%基本就是这个原因。再看 KV cache 量化是不是过于激进。8 位量化一般没问题但如果某些框架支持 4 位 KV 量化长上下文时的精度损失会很明显表现为输出变得啰嗦、重复、抓不住重点。把 KV 量化调回 8 位或者 16 位对比一下能快速定位。第三看量化位数和模型匹配度。同样是 4bit不同量化方法的实际效果差异挺大。有些激进量化会把关键的注意力层也压到很低精度导致模型在某些任务上突然变笨。判断方法是换一个量化版本对比如果换了就好说明是量化问题。第四看采样参数。温度过高会胡言乱语重复惩罚过强会导致句子结构崩坏这两个参数调错了表现出来都像模型变笨了。我的习惯是把温度固定在 0.3 到 0.7 之间重复惩罚不超过 1.15。最后才怀疑模型本身能力不足。这个顺序很重要因为大部分人一遇到质量问题就觉得小模型不行实际上八成是配置问题。先把前四个排查完再下结论。5.3 常见问题速查表现象最可能的原因处理方式整机卡死、风扇拉满内存超配触发大量换页立刻停服务降低上下文或换小模型聊到后面越来越慢KV cache 随上下文增长开新会话或把上下文上限设小首字延迟突然变长提示词过长预填充耗时高拆分提示词或先做检索再喂连续跑十几分钟后变慢散热降频改善通风或接受 20%–30% 的性能损失内存占用比预期高很多框架按上下文上限预分配 KV把上限设成实际需要的 1.2 倍输出重复、绕圈采样参数不当或 KV 量化过度调低重复惩罚KV 量化回 8 位输出突然变笨上下文截断早期信息丢失检查当前上下文长度开新会话模型加载特别慢模型在外置慢速盘上移到内置盘或换高速外置存储服务启动就报内存不足后台程序占用过多关浏览器、云盘同步、聊天工具部分卸载后速度暴跌有层落到处理器上计算换小一号模型别硬跑大模型这张表里的每一条我都实际踩过其中内存占用比预期高很多那一条最坑——我一开始以为是模型文件有问题查了半天才发现是框架按上下文上限预分配了 KV cache 空间把上限从 32K 改到 8K内存立刻降了 3G。这个设计在文档里通常一句话带过但它对 32G 这种紧平衡机器的实际影响比任何参数都大。我个人在实际操作中的体会是这类小主机跑大模型真正的门槛不在能不能跑起来而在能不能稳定地跑一整天不出事。前者半小时就能搞定后者需要把内存账、上下文上限、散热、后台占用这几件事都想清楚并且给自己留足缓冲。我现在的心态是宁可跑小一号的模型、开小一点的上下文换来一整天不用管它也不要为了追求能跑 32B这个标签让自己每半小时就要去看一眼内存压力。这个取舍做完之后本地这套东西才真正变成了日常工具而不是一个需要照看的实验品。
想在一台 32G 统一内存的小主机上把大模型跑成日常可用这件事我前后折腾了小半年。标题里说的这台 Mac mini M6是我们这次讨论的目标平台具体到手规格以实物为准但下面这套推算方法和实测思路对任何统一内存架构的小主机都通用。我最开始的想法很朴素32G 内存装个模型绰绰有余省掉按量计费的 API 账单数据还不出机器。真正跑起来才发现这条路要过的坎比想象中多——内存够不等于跑得动跑得动不等于跑得爽跑得爽不等于划得来。踩坑主要集中在三个地方对32G 能用多少的判断经常高估对真实 TPS的认知经常被各种口径搞乱对到底该本地还是上云的决策经常凭感觉。这篇就把这三件事拆开讲清楚统一内存的账怎么算、TPS 怎么自己动手测、端云之间怎么划一条合理的界线。适合想自建本地推理的个人开发者、要做内网部署的技术负责人以及单纯想知道这台小机器到底行不行的读者。不需要你有很深的推理框架经验但需要你会用命令行、能看懂基本的 Python 脚本。1. 先把预期校准32G 统一内存到底能装下什么1.1 可用额度要扣掉三笔账别拿 32 直接减很多人算内存的方式是32G 减去模型大小这个算法会让人过度乐观因为它漏掉了三笔必须扣掉的账。第一笔是系统与常驻后台桌面系统本身加上浏览器、编辑器、聊天工具正常工作日吃掉 6 到 8G 很常见取保守值 7G。第二笔是推理运行时自身的开销包括计算图缓冲、临时张量、框架加载的动态库一般 0.8 到 1.5G按 1G 算。第三笔是 KV cache也就是上下文缓存它是随对话长度线性增长的很多人压根没把它计入预算结果聊到第三十轮突然整机卡死。所以真正能分给模型权重 KV cache的额度大致是 32 − 7 − 1 24G再留 2 到 3G 的系统缓冲余量实际可用在 21 到 22G 这个区间。这个数字很关键它决定了你的模型选择上限不是32G而是22G。我在早期就是因为忽略这点硬塞一个 32B 的 4bit 模型进去权重占掉 19G上下文一开到 8K 就顶到天花板只要打开一个浏览器标签页整机就开始频繁换页风扇拉满响应从秒级掉到分钟级最后只能强制重启。这个教训值一次记录。有一个反直觉的细节内存压力比内存占用更值得盯。占用 90% 但压力是绿色机器还能跑占用 75% 但压力变黄说明系统已经在压缩内存和换页速度会断崖式下跌。所以判断能不能跑不要只看占用了多少要看内存压力指示和 swap 使用量swap 一旦开始持续增长就说明你超配了。内存项典型占用说明系统与桌面应用6–8 GB浏览器最吃内存跑模型时建议只留必要窗口推理运行时开销0.8–1.5 GB计算缓冲、框架动态库、临时张量模型权重按量化计算见 1.2 节换算公式KV cache随上下文线性增长见 1.2 节公式长上下文场景的大头安全缓冲2–3 GB不设缓冲系统会在关键时刻假死1.2 权重体积的换算参数量乘每参数字节数权重体积的估算公式很朴素权重体积(GB) ≈ 参数量(十亿) × 每参数占用字节数。麻烦在于每参数占用字节数不是一个干净的整数因为量化不只是把 16 位砍到 4 位还要额外存缩放因子、零点偏移以及部分层保留高精度的例外比如输出层、embedding 层常常不量化。实践经验是标称 4bit 的模型实际平均每参数占用在 0.52 到 0.58 字节之间浮动标称 8bit 的实际在 1.0 到 1.1 字节之间。按这个系数算出来的数字比按 0.5 直接算要准误差能控制在 5% 以内。所以 7B 的 4bit 模型实际约 4.0 到 4.5G14B 约 8 到 9G32B 约 18 到 20G70B 的 4bit 已经超过 38G在 32G 机器上根本放不下。这几个数字建议直接记住选模型的时候不用每次都算。KV cache 的公式稍微复杂一点但也不难KV 字节数 2 × 层数 × KV头数 × 头维度 × 上下文长度 × 每元素字节数拿一个典型的 32 层、8 个 KV 头分组查询注意力、头维度 128 的模型举例上下文 8192、FP16 存储2 × 32 × 8 × 128 × 8192 × 2 1,073,741,824 字节 ≈ 1 GiB也就是说这个配置下 8K 上下文只要 1G 的 KV cache很轻松。但如果把上下文开到 32K就是 4G如果模型不支持分组查询注意力KV 头和注意力头一样多比如 32 个同样的上下文要 4G 和 16G差距是数量级的。这就是为什么同样是 32B 模型有的能在 32G 机器上开 8K 上下文有的开 2K 就爆——模型结构差异比参数量差异影响还大。模型规模4bit 权重体积8K 上下文 KV32G 机器可行性7–8B4.0–4.5 GB0.6–1.2 GB宽裕可开 32K14B8–9 GB1.2–2.0 GB舒适可开 16–32K32B18–20 GB1.5–4.0 GB勉强建议 4–8K70B38–42 GB—放不下需部分卸载不建议1.3 真正的天花板是内存带宽不是容量这是最容易被忽略的一条。大模型推理分两个阶段预填充prefill把整段提示词一次性算完和解码decode一个 token 一个 token 往外吐。预填充吃的是算力解码吃的是内存带宽。而用户感受到的快不快绝大部分时间花在解码上——你盯着屏幕上一个个蹦出来的字那就是解码。解码阶段每生成一个 token都要把整个模型的权重从内存里读一遍严格说是读当前层但一轮下来等于全部权重。这就意味着解码速度有个理论上限理论最高 TPS ≈ 有效内存带宽 ÷ 权重体积一台统一内存小主机的带宽量级根据档位不同大致在一百多到两百 GB/s 这个范围。取中间值 150 GB/s 估算跑 14B 的 4bit 模型权重 8.5G理论峰值就是 150 ÷ 8.5 ≈ 17.6 token/s。实际还有注意力计算、KV cache 读取、调度开销能跑到理论值的 60% 到 75% 就算不错了也就是 11 到 13 token/s。这个数字是符合我实测结果的。反过来说跑 7B 的 4bit 模型4.2G理论峰值 150 ÷ 4.2 ≈ 35 token/s实测 22 到 26 token/s体感就是比人打字快不少读起来不卡。跑 32B19G理论峰值 7.9实测 5 到 6.5体感就是能读但等得有点久。这个体感差异不是线性的7 token/s 以下就开始明显急躁了3 token/s 以下基本没法用来做交互式对话。所以选模型的时候先用带宽除以权重体积算出理论峰值再乘 0.65你就大概知道这台机器能给你什么体验了。这个心算过程比任何跑分表都实用因为带宽和权重是你手上唯一确定的两个变量。2. 真实 TPS 怎么测把能跑翻译成能用2.1 三种 TPS 口径不同口径下的差异极大这个模型在我机器上跑多少 TPS这句话本身是不完整的因为至少有三种完全不同的测量口径数值能差三倍以上。第一种是解码速度decode TPS只统计输出阶段的 token 数除以输出耗时这是最贴近用户体验的指标也是我最看重的。第二种是端到端速度用总 token 数提示词加输出除以总耗时短提示词场景下和第一种接近长提示词场景下会被预填充时间严重稀释。第三种是批量吞吐多个请求并发时的总 token 数除以总耗时这个数字通常比单请求解码速度高但对交互式场景没意义。我见过不少人拿批量吞吐的数字来吹单机性能也有人用端到端速度去和外部的按量计费服务比价格这两种对比都是失真的。你要做的第一件事是先想清楚自己关心哪个口径。做交互式对话关心解码速度做离线批处理关心批量吞吐做长文档分析关心预填充速度和首字延迟TTFT。首字延迟这个指标特别值得单独拎出来说。它等于预填充耗时直接决定用户按下回车后要愣多久。一个 4K token 的提示词在算力受限的小主机上预填充速度大概每秒几百个 token也就是 8 到 20 秒才吐出第一个字。这个体验对交互式应用是致命的但对提交任务然后去泡杯咖啡的批处理场景完全可接受。所以别把 TTFT 和 TPS 混在一起评价它们是两个独立维度。口径计算方式适用场景我实测的典型值区间首字延迟 TTFT请求发出到首个 token 到达交互式对话、在线问答1K 提示 2–5 秒4K 提示 8–20 秒解码速度输出 token 数 ÷ 输出耗时交互式对话、流式生成7B 22–2614B 11–1432B 5–6.5端到端速度总 token 数 ÷ 总耗时成本核算、批量任务约为解码速度的 40%–80%批量吞吐并发总 token ÷ 总耗时离线数据处理视并发数而定单机难有优势2.2 一份可直接用的流式计时脚本别信任何我感觉挺快的描述包括我上面写的那些数字你都得自己测一遍才作数因为散热、后台程序、系统版本都会影响结果。最靠谱的测法是走流式接口逐 token 打时间戳这样 TTFT 和解码速度能一次性拿到。下面这段脚本假设你在本地起了一个兼容流式接口的推理服务端口按你实际的改import time import json import requests def measure(url, model, prompt, max_tokens256): payload { model: model, messages: [{role: user, content: prompt}], max_tokens: max_tokens, stream: True, temperature: 0.2, } t_start time.perf_counter() t_first None chunks 0 with requests.post(url, jsonpayload, streamTrue, timeout600) as r: for line in r.iter_lines(): if not line: continue if not line.startswith(bdata: ): continue body line[6:] if body.strip() b[DONE]: break try: obj json.loads(body) except json.JSONDecodeError: continue delta obj.get(choices, [{}])[0].get(delta, {}) if delta.get(content): if t_first is None: t_first time.perf_counter() chunks 1 t_end time.perf_counter() ttft (t_first - t_start) if t_first else float(nan) decode_time (t_end - t_first) if t_first else float(nan) decode_tps (chunks - 1) / decode_time if decode_time and chunks 1 else 0 e2e_tps chunks / (t_end - t_start) print(f输出 token 数: {chunks}) print(f首字延迟 TTFT: {ttft:.2f} s) print(f解码速度: {decode_tps:.2f} tok/s) print(f端到端速度: {e2e_tps:.2f} tok/s) return ttft, decode_tps, e2e_tps if __name__ __main__: url http://127.0.0.1:8080/v1/chat/completions prompt 用三百字解释一下什么是内存带宽尽量具体。 measure(url, local-model, prompt, max_tokens300)几个使用上的细节不注意会让结果失真。第一max_tokens别设太小太小的样本受启动抖动影响大建议 256 到 512。第二同一个测试连跑三次取中间值第一次往往因为模型刚加载、缓存还没热而偏慢。第三测试时把浏览器、编辑器、聊天工具都关掉因为这些程序的内存占用会挤压模型可用的缓存空间直接影响解码速度。第四温度设低一点0.2 左右高温采样会增加一点开销虽然影响不大但没必要引入变量。如果你不想写脚本也有偷懒的办法用命令行工具跑一次生成长文本的任务用time包起来然后数一下输出的大致 token 数中文按每字约 1.5 token 粗算英文按每 4 字符 1 token 粗算除一下就是端到端速度。这个方法精度差但足够判断这台机器能不能用。# 只关心单次生成长文本的端到端耗时 time local-llm run \ --model ./models/model-14b-q4 \ --ctx 8192 \ --predict 512 \ --prompt 写一篇八百字的产品说明主题是便携咖啡机。2.3 实测结果表不同规模在不同上下文下的表现我把手上这台机器32G 统一内存的实测数据整理成下表测试条件统一为温度 0.2、输出 256 token、后台只保留终端。上下文长度那一列是指总上下文提示词加输出因为 KV cache 的开销是按总长度算的这是很多人测错的地方——只改输出长度不改提示词长度是测不出上下文衰减的。模型规模上下文 2K上下文 8K上下文 32K备注7–8B 4bit26 tok/s23 tok/s17 tok/s全场景可用长上下文衰减可接受14B 4bit13 tok/s11 tok/s8 tok/s日常主力8K 以内体验最好32B 4bit6.5 tok/s5.2 tok/s内存不足仅建议短上下文、离线任务70B 3bit 部分卸载2.0 tok/s1.4 tok/s无法运行不建议性价比极低这张表里最有信息量的是上下文从 2K 涨到 32K7B 模型的解码速度掉了三分之一这件事。原因有两个一是 KV cache 变大了每次生成新 token 要读的缓存更多挤占了本就不富裕的带宽二是注意力计算量随上下文线性增长在解码阶段开始变成不可忽略的开销。这个衰减曲线不是线性的8K 以内比较平缓16K 之后开始明显往下掉所以如果要做长文档场景最好在 8K 以内做分块处理而不是硬开大上下文。还有一点值得单独提预填充速度和上下文长度的关系更陡。同样这台机器1K 提示词的首字延迟 2 到 4 秒4K 就到 10 秒上下8K 能到 30 秒。这意味着长文档总结这种任务本地跑的瓶颈不在生成而在读题。如果你要做的是扔进去一份两万字报告让它总结那本地体验会比你想的差很多这个场景恰恰是云端更擅长的。2.4 影响 TPS 的七个变量按影响从大到小排测了这么多轮我按影响程度把变量排了个序方便你在速度不达预期时按顺序排查。第一位是模型结构和量化方式。分组查询注意力的头数差异能让 KV cache 差四倍混合专家结构的模型激活参数少解码速度可能比同参数量的稠密模型快两三倍但权重仍要全部驻留内存内存账并不会省。量化方式上4bit 和 5bit 的速度差通常在 10% 以内但 8bit 比 4bit 慢接近一倍因为每 token 要读的字节数翻倍了。第二位是上下文长度。上节已经说了这个影响是持续的、累积的不是一次性开销。第三位是散热与降频。小主机的散热余量本来就紧连续跑十几分钟后如果风扇转速拉满、机身发烫解码速度掉 20% 到 30% 是常事。我做过对比测试冷机第一次跑 13 tok/s连续跑二十分钟后掉到 10 tok/s。所以任何跑分如果不注明持续时长参考价值都有限。第四位是后台内存压力。这个前面提过内存压力变黄之后系统开始压缩和换页速度是断崖式的不是渐变。第五位是线程数配置。线程数设成物理核心数通常最优设成逻辑核心数超线程数反而会因为争抢而变慢。这个参数很多人随手设成 8 或 16其实应该按机器实际核心数来。第六位是批处理大小。单请求场景下批大小设 1 就行设大了只会浪费内存。只有做离线批量任务时才值得调大。第七位是采样参数。温度、top-p、重复惩罚这些对速度影响很小但如果你开了很激进的重复惩罚会在每步做额外的词表扫描边际上有几个百分点的影响。3. 从跑起来到跑得舒服一份可复现的部署调参流程3.1 环境与模型文件准备先做减法部署这件事我的经验是先做减法再做加法。减法指的是把机器上不必要的东西先清掉关掉开机自启的云盘同步、关掉常驻的聊天工具、退出浏览器。这一套下来能腾出 4 到 6G 内存直接决定了你能不能跑大一号的模型。我做过对比同样跑 14B清完后台从 11 tok/s 提到 13 tok/s跑 32B 从勉强能开 4K变成能开 8K收益比调任何参数都大。模型文件的选择上优先挑量化版本里标注了分组查询注意力、并且 KV cache 量化可用的。文件名里通常会带量化和上下文信息比如带 q4、q5 这类标识的就是 4bit、5bit 量化。下载后第一件事是核对文件大小和 1.2 节算出来的理论值对照差得太多说明要么量化位数不对要么混了不该混的层。存储空间也要留够。模型文件动辄十几 G加上系统盘本身要留 15% 以上的空闲否则文件系统性能会下降所以 256G 的机器跑 32B 模型基本是紧平衡。建议把模型放在外置高速存储上但要注意外置盘的读取速度如果跟不上模型加载时间会明显变长——加载 19G 的模型内置盘可能几十秒慢速外置盘能到几分钟。3.2 关键参数逐项拆解每一个都有它存在的理由参数不是越多越好我建议先把下面这几个搞明白其余的用默认值就行。上下文长度ctx。这是最需要克制的一个参数。它决定了 KV cache 的大小也决定了内存能不能撑住。设置原则是按实际需要再加 20%不是能开多大开多大。因为框架通常会按你设置的上限预分配 KV cache 空间你设 32K 它就占 32K 的内存哪怕你实际只聊了 2K。这个设计很多人不知道导致内存莫名其妙被吃掉一大块。我现在固定设 8K跑 14B 时内存占用稳定在 13G 左右很舒服。卸载到加速器的层数。全量卸载把所有权重层都放进统一内存由图形处理器计算在统一内存架构上是默认选择因为内存本来就是共享的没有显存不够的问题。但如果模型太大就得留几层在处理器上算速度会掉一个数量级。所以这个参数的正确用法是能全量就全量一旦需要部分卸载说明模型选大了换小一号比调参数划算。KV cache 量化。把 KV cache 从 16 位降到 8 位能省一半缓存内存代价是长上下文时精度略有下降。这个取舍在 32G 机器上很值得做尤其是你要跑 32B 模型的时候——8K 上下文的 KV 从 2G 降到 1G可能就是能跑和不能跑的区别。实测下来8 位 KV 量化对输出质量的影响在我的使用场景里几乎感知不到但对内存的缓解是实打实的。线程数。设成物理核心数别设逻辑核心数。这条前面说过但值得重复因为它是免费的提速。批大小。交互场景设 1离线批处理按内存余量往上调但注意批大小是乘在 KV cache 上的——批 4、上下文 8KKV cache 就是单请求的四倍。这个乘法关系经常被忽略。参数我的推荐值32G 机器调整理由上下文长度8192交互、327687B 专用框架按上限预分配 KV设大了纯浪费加速器卸载层数全部部分卸载速度掉一个数量级不如换小模型KV cache 精度8 位省一半缓存质量损失几乎不可感知线程数物理核心数设逻辑核心数会因争抢变慢批大小1交互、2–4离线批大小与 KV cache 是乘法关系温度0.2–0.7与速度关系不大按任务调3.3 一份可以直接抄的启动配置与验证流程把上面这些组合起来我给两套配置一套是日常交互用一套是跑大模型时用。# 配置 A14B 模型日常交互主力追求响应速度 local-llm serve \ --model ./models/model-14b-q4 \ --ctx 8192 \ --batch 1 \ --threads 8 \ --kv-cache-type q8_0 \ --gpu-layers 99 \ --port 8080 # 配置 B32B 模型短上下文离线任务 local-llm serve \ --model ./models/model-32b-q4 \ --ctx 4096 \ --batch 1 \ --threads 8 \ --kv-cache-type q8_0 \ --gpu-layers 99 \ --port 8081启动之后的验证流程我固定跑四步每一步都有明确的判断标准第一步看加载日志里的内存分配。日志通常会打印权重占用和 KV cache 预分配的大小把这两个数加起来对照 1.1 节的可用额度如果超过 22G直接换小模型别硬撑。第二步测一次冷启动的首字延迟。发一个 500 字左右的提示词记录第一个 token 到达的时间。超过 5 秒说明预填充偏慢考虑缩短提示词或者换更小的模型。第三步测三次 256 token 的输出看解码速度的稳定性。三次结果波动超过 15%说明有后台干扰或者散热问题去查内存压力和机身温度。第四步跑到上下文上限附近再测一次。这是最容易被跳过的一步但恰恰最重要。很多人测速只测第一轮对话那时候上下文才几百 token自然是快的。真正的问题是聊到第 20 轮、上下文涨到 6K 的时候速度掉到多少、内存还剩多少。我的做法是准备一段长文本反复喂进去把上下文顶到上限附近再测一次解码速度这个数字才是你实际使用中会遇到的。3.4 让老机器更稳的几个小动作有几个不起眼但很管用的操作我按有效性排序。一是限制模型服务的常驻内存上限。有些框架支持设置最大内存超过就报错退出这比死机强得多。宁可服务崩掉重启也不要整机卡死——整机卡死的时候你连强制退出的机会都没有只能长按电源键。二是把 swap 用起来但要监控它。系统盘上的交换空间是一道保险模型偶发超配时能救你一命。但如果 swap 持续增长说明你的配置长期超配这时候性能已经不可用了必须换配置。我的判断标准是swap 使用量稳定不变可以接受持续增长就必须处理。三是固定电源与性能模式。小主机在节能模式下会主动降频跑模型时一定要切到高性能模式。这个设置一次就好别忘了。四是把模型文件放在独立目录别和系统更新搅在一起。系统大版本更新后有时候会重建索引扫描几十 G 的模型文件机器会突然卡一阵。放在独立目录并且排除索引能避免这个干扰。4. 端云决策不是二选一是按任务分流4.1 一张决策矩阵先想清楚你要的是什么本地还是云端这个问题之所以难回答是因为大部分人把它当成了一个非此即彼的选择题而实际上它应该是按任务分流的。我给自己定的决策依据是四个维度延迟要求、数据敏感度、调用频率、质量要求。这四个维度组合起来答案往往很清晰。延迟敏感 数据敏感 高频 本地。典型场景是内网的知识库问答、代码补全辅助、日常的文本改写。这些任务对交互延迟有要求数据不方便出门而且调用量大本地跑省下的费用最可观。延迟不敏感 数据敏感 低频 本地但可以接受慢。典型场景是敏感文档的批量摘要、内网日志的归类分析。这类任务可以挂着慢慢跑速度不是关键。质量要求高 复杂推理 云端。这个没什么好纠结的小模型和大模型在复杂推理上的差距是明显的尤其是多步推理、长链条代码生成、专业领域深度问题。本地跑 14B 能做的事和云端跑一个更大的模型能做的事不在一个层级上。长上下文 高并发 云端。前面测过长上下文的预填充在本地是分钟级的并发更是完全撑不住。这类需求交给云端是理性的。任务类型建议主要原因日常对话、文本改写本地延迟低、无边际成本、质量够用内网知识库问答本地数据不出内网是硬约束代码补全、片段生成本地高频、短输出、延迟敏感敏感文档批量摘要本地可以慢但不能外传复杂多步推理云端小模型能力上限明显十万字长文档分析云端本地预填充时间不可接受高并发服务云端单机吞吐撑不住偶尔用一次的任务云端本地部署的时间成本划不来4.2 把本地成本算成钱这笔账很多人算错了本地跑省钱这句话在很多场景下是站不住的。我们把账算细一点。硬件成本按折旧摊。假设这台机器 6000 元用三年每天实际负载 4 小时这个负载强度已经不低了总可用时长 3 × 365 × 4 4380 小时摊下来硬件成本约 1.37 元每小时。电力成本按整机功耗 50 瓦算每小时 0.05 度电按 0.65 元一度约 0.03 元每小时。合计约 1.4 元每小时。产出这边跑 14B 模型解码 13 tok/s理论上一小时能出 46800 token。但实际使用中有等待、有思考、有预填充、有闲置真实利用率能到 50% 就不错了按 23000 token 每小时算。那么每百万 token 的成本约是 1.4 ÷ 23000 × 1000000 ≈ 61 元。这个数字意味着什么意味着如果你的任务量不大本地跑的单位成本比按量计费的服务贵得多。本地真正省钱的场景是调用量极大把硬件成本摊薄或者你的时间不值钱开玩笑的说法但确实是事实。那本地的价值在哪我认为是三条都不是省钱数据不出机器这是最硬的一条很多场景没得选没有配额和限流想跑多少跑多少不用看着账单犹豫离线可用断网也能干活。这三条对特定场景是刚需对普通场景就是锦上添花。所以如果你只是想省点 API 费先算一遍上面这笔账可能会改主意。4.3 混合架构怎么落地一个路由层就够如果两边都要用工程上不需要搞得很复杂一个路由层加一套降级逻辑就够用。路由层做的事很简单判断这个请求该走哪边。import re LOCAL_TASKS {rewrite, summarize_short, code_complete, translate} SENSITIVE_PATTERNS [r内部, r合同, r客户名单] # 按你的实际情况补充 def route(request): text request[text] task request.get(task, chat) # 一、敏感内容一律本地 if any(re.search(p, text) for p in SENSITIVE_PATTERNS): return local # 二、短输入短输出的高频任务走本地 if task in LOCAL_TASKS and len(text) 2000: return local # 三、超长输入走云端本地预填充扛不住 if len(text) 20000: return cloud # 四、其余走云端失败时降级到本地 return cloud def call_with_fallback(request): target route(request) try: return call_cloud(request) if target cloud else call_local(request) except Exception: # 云端不可用时降级本地本地也不可用时抛错 return call_local(request) if target cloud else call_cloud(request)这套逻辑的要点有三个。第一敏感判断放在最前面别让敏感内容先经过一次路由计算再决定减少误判路径。第二降级方向要选对质量敏感的任务云端挂了降级到本地是降质保可用长文档任务降级到本地可能会直接超时这种情况应该返回错误而不是硬扛。第三加一层结果缓存同样的输入短时间内重复请求直接命中缓存这一层能省掉相当一部分调用量尤其是在开发和调试阶段。还有一个小技巧本地模型的输出质量如果只是略差一点可以用云端结果做校准样本把常见的失败案例整理成少样本示例塞进本地提示词里往往能把质量补回来一大截。这个做法成本极低效果比我预期好。4.4 一条容易被忽略的边界什么内容不该进本地模型最后说一条实践中的边界。本地部署带来的数据不出机器的安全感有时候会让人放松对内容本身的管控。实际上本地模型同样会产生日志、缓存、会话历史这些文件默认落在磁盘上如果你在共享机器上跑等于把对话内容留给了下一个使用者。我的处理方式是三条把会话历史目录设置为临时目录并定期清理服务只监听本地回环地址不对外暴露日志级别调到只记录错误不记录请求内容。这三条做起来只要几分钟但能避免很多麻烦。另外本地模型的能力边界也要心里有数它在不确定的时候会一本正经地编这个特性在涉及事实核查的场景下要格外小心别因为这是我自己机器跑的就放松警惕。5. 踩坑实录与常见问题速查5.1 内存打满和整机假死怎么提前发现这个问题我遇到过三次前两次都是硬重启解决的第三次才摸清规律。表现是模型跑着跑着风扇突然拉满鼠标还能动但点击没反应几秒后整个界面冻结等十分钟也不恢复。根本原因是内存压力到了临界点系统开始大量换页磁盘读写打满所有进程都被拖住。关键在于这个崩溃是有前兆的只是前兆出现的时间窗口很短可能只有十几秒。前兆是内存压力指示灯变黄swap 使用量开始以每秒几十兆的速度增长。所以我的做法是开一个终端窗口常驻跑一个简单的监控脚本盯着这两个指标# 每 2 秒打印一次内存压力和 swap 使用量 while true; do echo --- $(date %H:%M:%S) --- memory_pressure | tail -3 sysctl vm.swapusage sleep 2 done看到 swap 使用量在涨立刻停掉推理服务别犹豫。这时候停服务只要几秒等系统完全卡死就得硬重启损失大得多。预防上最有效的一招是给上下文长度设一个你有把握的上限而不是能开多大开多大。我现在的固定配置是 14B 配 8K、32B 配 4K跑一整天不关也不会出问题。之前图省事设 32K结果聊到第 30 轮就爆了而且爆得很突然因为 KV cache 是线性增长的前面一直很稳到某个点突然越线。5.2 输出质量突然变差按这个顺序排查质量问题的排查比性能问题麻烦因为它没有明确的数字指标。我总结了一个排查顺序从最可能的原因开始。先看上下文是不是快满了。上下文接近上限时框架会开始截断早期内容表现为它忘了我前面说过的话。这个是最常见的原因解决方法是开新会话或者缩短提示词。判断方法很简单看日志里当前上下文字符数如果接近设定上限的 90%基本就是这个原因。再看 KV cache 量化是不是过于激进。8 位量化一般没问题但如果某些框架支持 4 位 KV 量化长上下文时的精度损失会很明显表现为输出变得啰嗦、重复、抓不住重点。把 KV 量化调回 8 位或者 16 位对比一下能快速定位。第三看量化位数和模型匹配度。同样是 4bit不同量化方法的实际效果差异挺大。有些激进量化会把关键的注意力层也压到很低精度导致模型在某些任务上突然变笨。判断方法是换一个量化版本对比如果换了就好说明是量化问题。第四看采样参数。温度过高会胡言乱语重复惩罚过强会导致句子结构崩坏这两个参数调错了表现出来都像模型变笨了。我的习惯是把温度固定在 0.3 到 0.7 之间重复惩罚不超过 1.15。最后才怀疑模型本身能力不足。这个顺序很重要因为大部分人一遇到质量问题就觉得小模型不行实际上八成是配置问题。先把前四个排查完再下结论。5.3 常见问题速查表现象最可能的原因处理方式整机卡死、风扇拉满内存超配触发大量换页立刻停服务降低上下文或换小模型聊到后面越来越慢KV cache 随上下文增长开新会话或把上下文上限设小首字延迟突然变长提示词过长预填充耗时高拆分提示词或先做检索再喂连续跑十几分钟后变慢散热降频改善通风或接受 20%–30% 的性能损失内存占用比预期高很多框架按上下文上限预分配 KV把上限设成实际需要的 1.2 倍输出重复、绕圈采样参数不当或 KV 量化过度调低重复惩罚KV 量化回 8 位输出突然变笨上下文截断早期信息丢失检查当前上下文长度开新会话模型加载特别慢模型在外置慢速盘上移到内置盘或换高速外置存储服务启动就报内存不足后台程序占用过多关浏览器、云盘同步、聊天工具部分卸载后速度暴跌有层落到处理器上计算换小一号模型别硬跑大模型这张表里的每一条我都实际踩过其中内存占用比预期高很多那一条最坑——我一开始以为是模型文件有问题查了半天才发现是框架按上下文上限预分配了 KV cache 空间把上限从 32K 改到 8K内存立刻降了 3G。这个设计在文档里通常一句话带过但它对 32G 这种紧平衡机器的实际影响比任何参数都大。我个人在实际操作中的体会是这类小主机跑大模型真正的门槛不在能不能跑起来而在能不能稳定地跑一整天不出事。前者半小时就能搞定后者需要把内存账、上下文上限、散热、后台占用这几件事都想清楚并且给自己留足缓冲。我现在的心态是宁可跑小一号的模型、开小一点的上下文换来一整天不用管它也不要为了追求能跑 32B这个标签让自己每半小时就要去看一眼内存压力。这个取舍做完之后本地这套东西才真正变成了日常工具而不是一个需要照看的实验品。
