Qwen3.8 这个 27B 版本放出来那天，我第一时间就把权重拖回了本地。原因很简单，我手头有一批内部文档要做结构化整理，涉及合同条款和代码片段，这些东西丢到在线接口里转一圈，心里总归不踏实。本地部署大语言模型这件事我前前后后折腾过不少次，从最早的七 B 小模型到现在的中量级版本，踩的坑能写满两页纸。这次 Qwen3.8 的部署过程尤其典型——前四个小时我一直在翻车，OOM、卡死、输出乱码轮着来，后面才慢慢摸到门道。这篇东西就是把这整个过程摊开讲，包括我为什么选这条路线、参数怎么算、显存怎么省、哪些坑是可以提前绕开的。如果你手上有 16G 到 24G 显存的消费级显卡，或者一台内存够大的工作站，想把这套东西跑起来，下面的内容基本可以直接抄。
1. 先想清楚：本地部署这件事到底解决了什么问题
1.1 三个真实动机，别为了部署而部署
我见过太多人上来就问"哪个模型最强，我要本地跑一个"，跑完之后发现除了截图发个朋友圈，日常根本用不上。所以在动手之前，先把自己的需求对齐一下，比选模型重要得多。
第一个动机是数据边界。我处理的文档里有客户名称、报价、内部接口设计，这些东西一旦离开本地网络，合规上就说不清楚。本地部署最核心的价值就在这——推理全程在自己机器上，数据和网络完全隔离，拔了网线照样能跑。这一点是任何在线服务都给不了的。
第二个动机是离线可用。我经常在出差路上改方案，酒店网络时好时坏，有时候干脆连不上。本地模型装好之后，断网状态下它就是一个随时能问的助手，写提纲、改文案、翻译段落、解释一段看不懂的代码，响应速度还比等网络请求稳定。
第三个动机是长期成本与可定制性。如果你每天要跑几十万字的内容处理，按量付费的成本会慢慢累积起来，而本地部署是一次性硬件投入，跑得越多越划算。更关键的是可定制——你可以改 system prompt 定死输出风格，可以挂本地知识库做检索增强，可以写脚本批量调用，这些都是在线接口很难做到的灵活度。
把这三条想清楚，你就会明白自己要的到底是"能跑起来"还是"跑得好用"。这两个目标对应的硬件和方案完全不同。
1.2 你的机器到底能不能扛住：一张配置对照表
Qwen3.8 的 27B 版本，参数规模摆在那儿，光模型权重就不是小数目。我先把最关键的账算给你看，免得你下载到一半发现硬盘不够。
模型加载占用的显存，可以按这个粗略公式估：
模型显存 ≈ 参数量 × 量化位数 ÷ 8
以 27B 为例，不同量化档位对应的大致情况如下：
| 量化档位 | 每参数位数 | 权重体积 | 建议显存 | 实际体验 |
|---|---|---|---|---|
| Q4_K_M | 约 4.5 bit | 约 15-16 GB | 18 GB 以上 | 性价比最高，日常首选 |
| Q5_K_M | 约 5.5 bit | 约 18-19 GB | 22 GB 以上 | 质量略好，显存吃紧 |
| Q6_K | 约 6.6 bit | 约 22 GB | 26 GB 以上 | 消费级卡基本无缘 |
| Q8_0 | 8 bit | 约 27 GB | 32 GB 以上 | 接近原始精度，跑不动 |
| F16 | 16 bit | 约 54 GB | 64 GB 以上 | 专业卡或双卡 |
这张表里我只算了权重。真正加载的时候还要加上KV Cache和上下文窗口的开销。KV Cache 的算法是：
KV Cache ≈ 2 × 层数 × KV 头数 × 头维度 × 上下文长度 × 精度字节
27B 这类模型通常用了分组查询注意力，KV 头数远小于注意力头数，所以这部分开销比想象中小。经验值大概是每 1K 上下文占用 30 到 60 MB，跑 8K 上下文差不多 0.3 到 0.5 GB，跑 32K 就会到 1.5 到 2 GB。加上运行时缓冲、CUDA 上下文这些固定开销，一般再留 1.5 GB 余量比较稳妥。
所以结论是：16G 显存跑 Q4_K_M 只能刚好把权重塞进去，上下文一开长就爆显存；24G 显存跑 Q4_K_M 加 16K 上下文是比较舒服的配置；如果是 8G 显存，那只能靠 CPU 分担，速度会掉一个数量级。
注意：别信"最低显存"这种宣传数字，那通常是指权重刚好装下、上下文压到 2K 的极限状态，实际用起来非常难受。按建议显存那一列配，才是能长期用的配置。
2. 硬件与方案选型：为什么最后落在 Ollama 加量化 GGUF 上
2.1 四条路线的实际对比
本地跑大模型，主流的路线大概有这么几条，我都试过，说说各自的真实感受。
第一是原生的 transformers 加载。这条路最"正统"，Python 写几行就能加载模型跑推理。但问题是，它对显存管理几乎是放任的，一旦爆显存直接抛异常，没有优雅降级；量化还得自己装 bitsandbytes，版本兼容能折腾你一晚上。适合做研究和微调，不适合日常使用。
第二是 LM Studio 这类图形化工具。上手确实快，界面友好，模型下载、参数调节、对话全在 GUI 里点。缺点是每一个参数都藏在菜单里，你想批量调用、想写脚本接入自己的流程就很别扭，而且后台服务本身也占资源。适合纯体验和偶尔用用。
第三是 llama.cpp 原生编译。性能最好，控制粒度最细，参数全部命令行显式指定。代价是编译过程对新手不友好，不同显卡后端要选不同的编译开关，我上次为了开启某个显卡加速，光解决编译报错就花了两个小时。
第四是 Ollama。它本质上是把 llama.cpp 包了一层，做成了服务化的形态：一条命令拉模型，一个 HTTP 接口对外提供能力，Modelfile 管理参数，环境变量控制显存策略。牺牲了一点点极致性能，换来的是"配置一次，到处调用"的便利。对我这种要把它接进自动化流程的人来说，这是最划算的选择。
所以这次我选的是Ollama + GGUF 量化权重这条路。下面所有配置都基于这个组合。
2.2 量化档位怎么挑：不要无脑上最高
量化档位的选择，本质是精度和资源之间的取舍。我的建议非常明确：先跑 Q4_K_M，觉得质量不够再往上升。
原因在于，现代量化方法在 4 bit 左右这个区间做得相当成熟，Q4_K_M 这种混合量化策略会把关键层保留到更高精度，非关键层压得更狠，实际输出质量和 Q5、Q6 的差距，在大多数任务上肉眼几乎分辨不出来。但显存占用差了 3 到 4 GB，这 3 GB 决定你是能开 16K 上下文还是只能开 4K。
具体怎么判断呢？我的经验是分任务类型：
- 信息抽取、分类、翻译、改写：Q4_K_M 完全够用，这类任务对精度不敏感。
- 代码生成、数学推理：可以升到 Q5_K_M，长链条推理里量化误差会被放大。
- 需要严格格式输出：优先保证上下文长度，别为了量化精度牺牲窗口。
还有一个容易被忽略的点：同一个模型版本的不同量化文件，输出风格会有细微差异。我在 Q4 和 Q5 上跑同一段 prompt，Q4 更容易出现重复句式，Q5 相对稳一些。所以如果你发现模型说话开始"车轱辘"，除了调重复惩罚，也可以换个量化档试试。
2.3 显存不够时的三个止血手段
不是每个人都有 24G 显存。显存不够的时候，按下面的顺序逐个上手段，效果和代价都是递增的。
手段一：部分层卸载到 CPU。Ollama 里的num_gpu参数控制有多少层放到显卡上。默认是全部，不够就往下调。比如 27B 模型大约 60 多层，你设成 40，剩下的就在内存里算。代价是速度断崖式下降，因为 CPU 推理和 GPU 推理之间要反复搬运数据。但至少能跑起来。
手段二：量化 KV Cache。把 KV Cache 从 16 位压到 8 位，显存占用直接减半。这个操作在长上下文场景下收益非常明显。设置方式是加环境变量OLLAMA_KV_CACHE_TYPE=q8_0。质量损失很小，我实测下来基本感觉不到。
手段三：压上下文长度。num_ctx从 32768 降到 8192，KV Cache 直接省掉四分之三。很多人的显存爆掉根本不是权重的锅，是上下文开太大了。日常对话 8K 完全够，只有处理长文档才需要往上加。
实操心得：这三个手段的优先级顺序是"先压上下文，再量化 KV，最后才卸层"。因为卸层对速度的伤害是不可逆的，而前两个对体验的影响小得多。我见过太多人一上来就把层卸了，然后抱怨本地模型太慢，其实问题出在开场就用错了方案。
3. 第一次翻车现场：从下载到崩溃的完整复盘
3.1 翻车一：拉到一半磁盘满了
第一个坑特别低级，但特别常见。我兴冲冲地敲下拉取命令，看着进度条跑到 60% 多突然报错，一查磁盘——系统盘只剩不到 8G 了。
这里有个很多人不知道的细节：Ollama 的模型默认存在用户目录下的隐藏文件夹里，Windows 在C:\Users\你的用户名\.ollama\models，Linux 和 macOS 在~/.ollama/models。这个位置默认在系统盘，而你系统盘通常是最小的那块。
解决办法是改环境变量把模型目录挪走：
# Linux / macOS export OLLAMA_MODELS=/data/ollama/models # Windows PowerShell（需要设置用户级环境变量） [Environment]::SetEnvironmentVariable("OLLAMA_MODELS", "D:\ollama\models", "User")改完之后重启 Ollama 服务才生效。有个坑是：改路径之前已经下了一半的模型文件不会自动迁移，你得先手动删掉残留目录，否则新目录下重新下载会报路径冲突。
另外提醒一句，下载 27B 的量化文件，算上解压和临时文件，最好留出文件体积两倍以上的空间。我那次是留了刚好够，结果解压阶段又卡了一次。
3.2 翻车二：显存不够，加载直接崩
磁盘问题解决后，模型拉下来了，我满怀期待地敲下运行命令。结果是屏幕上刷了一屏红字，核心意思是显存分配失败。
这里要理解一个概念：大模型加载是"全有或全无"的。它不像游戏可以动态降画质，权重必须整体映射到显存或内存里才能开始推理。所以当你看到 OOM，说明你的配置和模型规格差得太远，不存在"加载一半"这种可能。
我当时的配置是 16G 显存，模型 Q4_K_M 权重约 15.5G，看起来刚好够。但实际上：
- 权重 15.5G
- 运行时缓冲约 0.8G
- KV Cache（默认上下文）约 0.6G
- 系统和其他程序占用约 1.2G
加起来 18.1G，超了 2G 多。这就是典型的"理论够用，实际爆掉"。解决办法是先把num_ctx压到 4096，同时开 KV Cache 量化，再把num_gpu从 99 调到 45 左右，让一部分层走内存。
调完之后的启动命令长这样：
OLLAMA_KV_CACHE_TYPE=q8_0 OLLAMA_FLASH_ATTENTION=1 ollama run qwen3.8:27b配 Modelfile 里的：
PARAMETER num_ctx 4096 PARAMETER num_gpu 45终于，这次它没报错，进到了交互界面。但新的问题又来了。
3.3 翻车三：能跑了，但慢得像蜗牛
模型加载成功那一刻我是真高兴，然后我发了第一句话，等了将近一分钟才看到第一个字蹦出来。速度大概在 2 到 3 token 每秒，基本没法用。
排查思路是这样的：先确认瓶颈在哪。用ollama ps看模型加载状态，会发现 GPU 占用率很低，说明大部分计算落在 CPU 上。因为我把 45 层卸到了 CPU，数据在内存和显存之间来回搬，PCIe 带宽成了瓶颈。
这里必须讲清楚一个原理：大模型推理是内存带宽敏感型任务，不是算力敏感型任务。每生成一个 token，都要把参与计算的那部分权重过一遍。权重在显存里，走的是显卡的显存带宽，动辄几百 GB/s；权重在内存里，走的是 DDR 带宽，只有几十 GB/s。两者差了一个数量级，所以层一旦卸到 CPU，速度就是十倍二十倍地掉。
所以正确的优化方向不是"把层尽量塞进显卡"，而是"在能塞进去的前提下，尽量少卸层"。如果实在塞不下，那就得考虑换更小的量化档，或者换更小的模型。
我最后的方案是：把量化换到 Q4，关掉一些后台程序腾显存，num_gpu调到 55，上下文压到 8K，速度回到了 12 token/s 左右，能用了。
3.4 翻车四：中文输出开始断句混乱
速度问题解决后，我以为可以收工了，结果发现中文输出偶尔会出现奇怪的断句和符号混排，有时候还会在回答里插一段像是模板残留的内容。
这个问题通常出在对话模板不匹配上。GGUF 文件里一般会带一份 chat template 元数据，Ollama 会自动读取。但如果你的 GGUF 是从别处转过来的，或者转格式的时候没带模板，就会用一个通用模板硬套，结果就是角色标记错位、特殊 token 被当成正文输出。
判断方法很简单：直接问模型"你是谁"，看它输出的开头有没有多余的角色标记。如果出现类似系统标记被原样打印的情况，那就是模板问题。
修复方式是在 Modelfile 里显式指定模板：
TEMPLATE """{{ if .System }}<|im_start|>system {{ .System }}<|im_end|> {{ end }}{{ if .Prompt }}<|im_start|>user {{ .Prompt }}<|im_end|> {{ end }}<|im_start|>assistant """同时把停止标记也配好：
PARAMETER stop "<|im_end|>" PARAMETER stop "<|im_start|>"改完之后重建模型，乱码问题就消失了。
注意：模板里的特殊 token 必须和模型训练时用的完全一致，差一个符号都会出问题。如果你不确定，去模型卡片的说明里找，别凭感觉写。
4. 跑通方案：一份可以直接抄的完整配置
4.1 环境准备和依赖安装
把前面几个坑都趟过之后，我把整套流程重新梳理了一遍。下面这份是从零开始的可复现流程。
先装 Ollama：
# Linux 一键脚本 curl -fsSL https://ollama.com/install.sh | sh # macOS 用 brew brew install ollama # Windows 直接下安装包，装完会在后台起服务装完之后验证一下：
ollama --version ollama serve # 如果服务没自动起，手动拉起Windows 用户要注意，Ollama 装完默认作为后台服务运行，端口是 11434。如果被别的程序占了，可以用环境变量OLLAMA_HOST换端口。
然后是模型文件。有两条路：一条是直接从模型库拉，省事；一条是自己下载 GGUF 再导入，灵活。
# 路线一：直接拉 ollama pull qwen3.8:27b # 路线二：本地 GGUF 导入，先写 Modelfile # 文件内容见下一节 ollama create qwen3.8-local -f ./Modelfile4.2 Modelfile 参数逐条讲清楚
这是整套配置的核心，每个参数我都标了为什么这么设：
FROM ./qwen3.8-27b-q4_k_m.gguf # 上下文窗口。8K 是日常和长文的平衡点，处理长文档再往上加 PARAMETER num_ctx 8192 # 卸载到显卡的层数。99 表示全部，显存不够就往下调 PARAMETER num_gpu 99 # 单次最多生成多少 token，防止模型刹不住车 PARAMETER num_predict 2048 # 温度。0.7 是通用值，写代码可以降到 0.3，创意写作用 0.9 PARAMETER temperature 0.7 # 核采样，和温度配合用，0.8 到 0.9 比较稳 PARAMETER top_p 0.85 # 候选词范围，20 到 40 之间，太小容易死板 PARAMETER top_k 30 # 重复惩罚。中文任务建议 1.05 到 1.1，太高会破坏正常重复 PARAMETER repeat_penalty 1.08 # 停止标记，必须配 PARAMETER stop "<|im_end|>" PARAMETER stop "<|im_start|>"这里几个参数的关系值得多说两句。温度和 top_p 不要同时调高，两个都拉满会让输出发散得没法看。我的习惯是固定 top_p 在 0.85，只调温度来控制创造性。
repeat_penalty 是把双刃剑。设得太低，模型会反复说同一句话；设得太高，它会为了避开重复而强行换词，导致语义扭曲。中文因为分词颗粒度的问题，比英文更容易触发重复，所以这个值我给到 1.08，比英文场景常见的 1.1 略低。
num_predict 一定要设。不设的话，模型有时候会陷入"我再补充一点"的循环，把显存和上下文全占满。2048 对大多数对话够用，长文生成可以临时调到 4096。
4.3 启动和验证
配置写好之后，启动并验证：
# 用自定义模型启动 ollama run qwen3.8-local # 查看当前加载状态和资源占用 ollama ps # 查看日志，排查加载问题 journalctl -u ollama -f # Linux systemd tail -f ~/.ollama/logs/server.log # 通用ollama ps这个命令值得单独说，它会显示模型当前的size、processor和until。重点看processor那一列，如果是 100% GPU 说明全在显卡上，如果显示百分比说明有部分在 CPU。这个信息比任何监控软件都直观。
验证跑通之后，可以做个简单的压力测试，发一段长文本让它总结，观察响应时间和显存占用曲线。如果显存占用一直稳定在一个值附近，说明配置合适；如果持续爬升最后崩掉，说明上下文设太大了。
4.4 接入自己的流程
本地部署最大的价值在于能接进自己的工具链。Ollama 对外提供 HTTP 接口，调用方式和在线接口几乎一样：
curl http://localhost:11434/api/chat -d '{ "model": "qwen3.8-local", "messages": [ {"role": "system", "content": "你是一个严谨的技术文档助手"}, {"role": "user", "content": "把下面这段改写成正式表述"} ], "stream": false, "options": { "temperature": 0.3, "num_ctx": 8192 } }'Python 里调用也一样简单：
import requests resp = requests.post("http://localhost:11434/api/chat", json={ "model": "qwen3.8-local", "messages": [{"role": "user", "content": "帮我梳理这段代码的逻辑"}], "stream": False, "options": {"temperature": 0.3} }) print(resp.json()["message"]["content"])这样你就可以把它接到批量文档处理、IDE 插件、笔记软件里，做成自己的工作流。我目前是把它挂在本地的一个小服务上，配合文件监听，丢进去的文档自动过一遍摘要和标签，省了不少手动整理的功夫。
5. 性能调优：把速度从 3 token/s 拉到 12 token/s
5.1 瓶颈到底在哪一层
调优之前，先学会定位瓶颈。本地推理的耗时可以拆成两块：预填充和解码。
预填充是把你的输入 prompt 一次性过一遍模型，这个过程是并行计算的，吃的是显卡算力，通常很快。解码是一个 token 一个 token 往外蹦，这个过程是串行的，吃的是显存带宽。
所以判断方法很直接：如果首字延迟很长、后面吐字很快，瓶颈在算力，说明输入太长或显卡太弱；如果首字很快、但吐字慢吞吞，瓶颈在显存带宽，说明有层被卸到了 CPU，或者显存频率被限制了。
我的情况是后者。定位方法就是上面提到的ollama ps看 processor 分布。
5.2 显存带宽之外的隐藏杀手
除了层卸载，还有几个容易被忽略的因素会拖慢速度。
第一个是散热。显卡在高温下会自动降频，显存频率一降，解码速度立刻跟着掉。我一开始没注意，跑长任务的时候机箱风扇转速都没拉起来，跑十几分钟后速度会明显下降。后来把风扇曲线调激进一些，速度就稳定了。这个坑很隐蔽，因为短期测试看不出来。
第二个是电源。有些小功率电源在显卡满载时供电不稳，显卡会主动降频保护。如果你发现速度忽快忽慢，可以去看看电源功率够不够。这个我用功耗表实测过，27B 全速推理时显卡功耗能冲到标称的 90% 以上。
第三个是后台程序。浏览器、设计软件、其他占用显存的程序，都会挤占你的可用显存。我现在的习惯是跑大任务之前先把浏览器标签清一遍，能省出 1 到 2G 显存，这点空间在临界配置下就是"能开 8K 上下文"和"只能开 4K"的区别。
5.3 上下文长度和速度的关系
这里有个反直觉的现象：上下文开得越大，速度越慢，而且是随着对话轮次累积而变慢的。
原因在于，每次生成新 token，模型都要对当前全部上下文做注意力计算。上下文从 4K 涨到 16K，每次计算的量就翻了四倍。所以你会感觉聊到十几轮之后，模型明显变迟钝了。
应对办法有几个：
一是控制对话轮次。长对话在合适的时候开新会话，别让上下文无限累积。
二是开 Flash Attention。这个优化能显著降低长上下文下的显存占用和计算量，设置环境变量OLLAMA_FLASH_ATTENTION=1即可。我实测在 8K 上下文下能省 15% 左右的时间。
三是量化 KV Cache。前面提过，省显存的同时也能略微加速，因为要搬运的数据变少了。
5.4 关于"思考强度"的控制
Qwen3.8 这类带推理链输出能力的模型，有时候会在正式回答前先输出一段内部推演过程。这个机制对复杂问题是加分项，但对简单问题就是纯粹的浪费——问它"今天星期几"它都要想半天。
控制方式有两种。一种是在系统提示里直接约定：
对于简单的事实性问题，直接给出答案，不需要展开推理过程。 对于需要多步分析的问题，先简要说明思路再给结论。另一种是通过参数控制生成长度上限，间接限制推理链的长度。我一般把num_predict设成 2048，复杂问题手动放开，简单问答让它自己刹住。
这里要提醒的是，推理链的长度和质量不是正相关的。我对比过同一批问题，强制它"想久一点"和"直接回答"，在事实类任务上准确率没有差别，反而长推理链更容易绕进死胡同。所以别迷信"想得越多越准"，按任务类型分流才是正解。
6. 常见问题速查表与排查思路
6.1 一张表覆盖八成问题
| 现象 | 大概率原因 | 处理动作 |
|---|---|---|
| 拉取模型时磁盘报错 | 模型默认目录在系统盘 | 改OLLAMA_MODELS环境变量并重启服务 |
| 加载时 OOM 崩溃 | 权重加缓存超过显存 | 降num_ctx、开 KV 量化、调低num_gpu |
| 首字很慢、吐字很快 | 输入过长或算力不足 | 缩短 prompt，或提高显卡优先级 |
| 首字很快、吐字极慢 | 有层卸载到 CPU | 提高num_gpu，或换更小量化档 |
| 中文输出乱码、角色标记外泄 | 对话模板不匹配 | Modelfile 里显式指定 TEMPLATE 和 stop |
| 回答开始重复同一句 | 重复惩罚过低或上下文过长 | 提高repeat_penalty，或开新会话 |
| 跑一段时间后变慢 | 显卡降频或显存被挤占 | 调风扇曲线、关后台程序 |
| 接口调用超时 | 首次加载耗时长或模型未常驻 | 提前发请求预热，设置常驻参数 |
6.2 分层定位的思路
遇到问题别乱试，按层排查效率最高。我的心法是从下往上查：
第一层看服务有没有起来。ollama ps能不能连上，端口通不通。这一层不通，后面都白搭。
第二层看模型有没有加载成功。日志里有没有报错，显存占用有没有涨上去。这一层的问题基本都是资源配置不对。
第三层看输入输出是否正常。也就是模板、特殊 token、停止标记。这一层的问题表现为"能跑但输出怪"。
第四层看性能和稳定性。速度、温度、长任务下的表现。
按这个顺序走，九成的坑都能在三分钟内定位。我见过很多人一遇到问题就去搜"XX 模型跑不动怎么办"，结果搜到的方案和自己的情况根本不匹配，白折腾半天。
6.3 几个只有踩过才知道的细节
细节一：模型常驻和自动卸载。Ollama 默认在闲置一段时间后会把模型从显存里卸掉，下次调用要重新加载，这个加载时间可能是几十秒。如果你想让它一直待命，设置OLLAMA_KEEP_ALIVE=-1。代价是显存一直被占着，其他程序用不了显卡。
细节二：并发请求的显存陷阱。Ollama 支持设置并行处理的请求数，参数是OLLAMA_NUM_PARALLEL。听起来很美，但每个并发请求都要独立的 KV Cache，显存占用是成倍增长的。默认配置下，单请求显存刚够的机器，开两个并发必崩。要么加显存，要么把上下文压到最低再开。
细节三：模型文件的完整性。从第三方渠道下载 GGUF 的时候，一定要比对文件哈希。我遇到过一次下载中断导致文件不完整，模型能加载但输出全是乱码，排查了半天才发现是文件坏了。校验哈希是最省事的预防手段。
细节四：Windows 下的路径和权限。Windows 上改环境变量之后，一定要确认 Ollama 后台服务重启了，否则它读的还是旧配置。有时候服务重启不彻底，需要去任务管理器里手动结束进程再拉起。
7. 折腾完这一圈，我的几点真实体会
从头到尾算下来，这套 Qwen3.8 的本地部署我大概花了两个晚上，其中真正有效的操作不到半小时，剩下的全在填坑。回头复盘，我觉得最大的教训是别把"能跑"和"好用"混为一谈。第一次看到模型吐出字的时候我特别兴奋，但 2 token/s 的速度根本没法做正事。真正让它变得可用的，是后面那些枯燥的参数调整和资源规划。
我现在固定下来的配置是这样一套：Q4_K_M 量化、8K 上下文、KV Cache 量化开到 8 位、Flash Attention 打开、常驻不卸载。这套配置在 16G 显存上跑 27B 模型，日常问答和文档处理都够用，速度稳定在 10 到 13 token/s，长文批量处理会慢一些但能接受。
有一个经验我想单独说说：先跑起来，再优化，别反过来。我见过不少人卡在选型阶段，纠结一周要 Q4 还是 Q5、要 Ollama 还是 LM Studio，结果一个都没跑起来。正确的顺序是先用一个最低配的版本把流程打通，确认端到端没问题，再逐步升级配置。这样每一步都有反馈，出问题也容易定位。
最后再分享一个我一直在用的小技巧：把每次调参的配置和对应的实测结果记在一个表格里，包括量化档、上下文、num_gpu、实测速度、显存峰值。看起来麻烦，但当你需要在下一次换模型或者换机器时快速找到可用配置，这份记录能省下大把时间。我从开始做这件事到现在，这份表里已经躺了三十多组数据，每次上新模型，翻一翻上次同规格的记录，基本能一次配对。
