1. 为什么我要折腾本地模型写代码先说结论Ollama 跑本地模型做 AI 编程在 2025 年这个时间点够用但要看你怎么用、用什么模型、跑在什么卡上。我前后用了大半年时间从 6G 显存的笔记本到 24G 显存的工作站都试过踩过的坑比写出来的代码还多。这篇文章不吹不黑把四类典型编程任务的实际表现、显存占用对照、以及那些文档里不会写的调参细节全部摊开讲。核心关键词先摆出来Ollama、AI 编程、显存、本地模型、Modelfile。这几个词基本概括了本地跑模型写代码的全部要素——工具链选 Ollama任务场景是 AI 编程最硬的约束是显存模型要选对版本而 Modelfile 是你唯一能深度定制模型行为的入口。为什么非要本地跑三个原因。第一代码是敏感资产尤其是公司内部项目走云端 API 总归心里不踏实。第二云端 API 按 token 计费高频使用成本不低本地跑一次投入长期摊薄。第三离线环境可用飞机上、内网里照样干活。但代价也很明显显存不够就只能跑小模型小模型的代码能力跟云端旗舰差距肉眼可见。所以真正的问题不是本地模型行不行而是在你的硬件条件下本地模型能覆盖哪些编程任务哪些必须交给云端。这篇文章就是来回答这个问题的。适合谁看如果你手头有一张 6G 到 24G 显存的卡想用 Ollama 搭一套本地 AI 编程环境或者已经在用但觉得效果不理想那这篇就是写给你的。我会把四类任务的实测数据、显存对照表、Modelfile 调优技巧、以及常见报错的排查方法全部讲清楚。2. 四类编程任务的实测表现拆解我把日常编程工作拆成四类任务分别用本地模型跑了一遍。这四类覆盖了绝大多数开发者的真实需求代码补全、代码解释、Bug 修复、以及跨文件重构。每类任务的难度和对模型能力的要求完全不同本地模型的表现也差异巨大。2.1 任务一单行代码补全与函数生成这是最基础也最常用的场景。你在编辑器里敲个函数名模型帮你补全实现。这类任务对模型的要求相对低因为它有很强的上下文约束——函数签名、周围代码、注释都在提示里模型只需要顺着往下写。我用 Qwen2.5-Coder 7B 和 DeepSeek-Coder-V2 Lite 分别测了 200 次补全统计首次通过率即补全结果直接可用不需要修改。Qwen2.5-Coder 7B 在 Q4_K_M 量化下首次通过率约 68%DeepSeek-Coder-V2 Lite 约 72%。这个数字什么概念云端旗舰模型大概在 85% 到 90%。差距有但没到不能用。关键是补全这种任务你本来就会扫一眼再决定要不要68% 的可用率意味着大部分时候你按 Tab 就完事了剩下 32% 手动改改也不费事。显存占用方面7B 模型 Q4_K_M 量化大概吃 4.5G 到 5G 显存加上上下文缓存我设的 4096 token总共 5.5G 左右。6G 卡能跑但基本没有余量浏览器多开几个标签页就可能爆。8G 卡跑这个配置就很舒服了。注意补全任务一定要把上下文长度控制好。我试过把 num_ctx 设到 8192显存直接多吃了 1.5G但补全质量提升微乎其微。补全场景 4096 足够省下来的显存留给模型本身更划算。2.2 任务二代码解释与技术文档生成给一段代码让模型解释它在干什么或者根据代码生成注释和文档。这类任务对模型的理解能力要求更高因为它需要读懂逻辑而不是简单续写。实测下来7B 级别的模型解释简单函数没问题但遇到复杂逻辑比如嵌套的回调、泛型约束、位运算技巧就开始胡说八道。我拿一段用了 Python 装饰器和生成器嵌套的代码测试Qwen2.5-Coder 7B 能说出大概意图但细节解释错了三处。换成 14B 模型Qwen2.5-Coder 14B Q4_K_M错误降到一处。32B 模型基本全对。这里有个经验代码解释任务模型参数量比量化精度更重要。我对比过 14B Q4 和 7B Q814B Q4 的解释质量明显更好尽管 Q8 的量化损失更小。原因很简单理解代码逻辑需要模型有足够的知识容量参数量不够量化再精细也补不回来。显存对照14B Q4_K_M 约 9G 到 10G32B Q4_K_M 约 19G 到 20G。所以如果你主要用代码解释功能8G 卡建议上 14B Q424G 卡直接上 32B Q4。2.3 任务三Bug 定位与修复建议这是本地模型最能体现价值的场景之一因为调试往往需要反复试错走云端 API 的话 token 消耗很快。本地模型随便你问多少次边际成本为零。但 Bug 修复对模型要求也最高。它需要模型理解报错信息、定位相关代码、推断根因、给出修复方案。我拿 50 个真实 Bug来自开源项目的 issue测试统计首次给出正确修复方向的比例。Qwen2.5-Coder 7B 约 40%14B 约 55%32B 约 68%。云端旗舰大概 80% 以上。这个数据说明什么7B 模型修 Bug 基本靠运气它能看出明显的语法错误和拼写问题但逻辑 Bug 和并发问题基本抓瞎。14B 开始有实用价值能处理大部分常见错误。32B 才真正能当助手用。实操心得修 Bug 时把完整的报错堆栈和相关代码一起喂给模型效果比只给报错好得多。我试过只给报错信息7B 模型经常给出完全不相关的建议加上代码上下文后准确率能提升 15 到 20 个百分点。2.4 任务四跨文件重构与代码迁移这是最考验模型能力的场景。比如把一个 Python 项目里的某个模块从同步改成异步或者把 JavaScript 代码迁移到 TypeScript。这类任务需要模型理解整个项目的结构而不仅仅是单个文件。坦白说本地模型在这个场景下目前还不够用。我试过用 32B 模型做一个小型 Flask 项目的异步改造模型能给出单个函数的改造方案但涉及跨文件调用关系时就开始丢三落四。它会改 A 文件里的函数签名但忘了同步修改 B 文件里的调用方。结果就是改完编译都过不了。我的建议是跨文件重构这种任务本地模型只用来做辅助分析比如让它列出所有需要修改的文件和函数具体改动还是自己来。或者用本地模型生成改造方案然后人工审核执行。完全交给本地模型自动重构目前风险太大。3. 显存对照表与模型选型逻辑显存是本地跑模型最硬的约束。这一节我把常见显卡和模型的组合整理成对照表并解释背后的计算逻辑让你能根据自己的卡做出合理选择。3.1 显存占用到底怎么算很多人以为显存占用就是模型文件大小其实不对。实际显存占用由三部分组成模型权重、KV 缓存、以及运行时开销。模型权重的计算很简单参数量乘以量化位数除以 8。比如 7B 模型用 Q4_K_M 量化大约 7B × 4.5 bit / 8 ≈ 3.9GB。但实际文件会大一些因为有些层保持更高精度所以 Q4_K_M 的 7B 模型文件大概 4.4GB。KV 缓存是很多人忽略的大头。它的计算公式是2 × 层数 × 注意力头数 × 头维度 × 上下文长度 × 精度。简化估算的话7B 模型在 4096 上下文下KV 缓存约 0.5G 到 1G32B 模型在同样上下文下KV 缓存能到 2G 到 3G。上下文翻倍KV 缓存也翻倍。运行时开销包括 CUDA 上下文、cuBLAS 工作区等一般 0.5G 到 1G。所以实际显存占用 模型权重 KV 缓存 运行时开销。这就是为什么 7B Q4 模型文件只有 4.4G但实际要 5.5G 到 6G 显存才能跑稳。3.2 常见显卡与模型组合对照表下面这张表是我实测出来的不是理论值。测试环境是 Ollama 0.5.xnum_ctx 设为 4096num_gpu 设为 99全部层加载到 GPU。显卡显存可跑模型量化方式实际显存占用编程任务适用性6GBQwen2.5-Coder 7BQ4_K_M5.5-6GB仅补全勉强6GBQwen2.5-Coder 3BQ8_04-4.5GB补全简单解释8GBQwen2.5-Coder 7BQ5_K_M6-6.5GB补全解释简单Bug8GBQwen2.5-Coder 14BQ3_K_M7-7.5GB解释质量好补全慢12GBQwen2.5-Coder 14BQ4_K_M9.5-10.5GB四类任务基本可用16GBQwen2.5-Coder 14BQ6_K12-13GB质量接近未量化16GBQwen2.5-Coder 32BQ3_K_M14-15GB解释和Bug修复强24GBQwen2.5-Coder 32BQ4_K_M19-21GB四类任务都够用24GBQwen2.5-Coder 32BQ5_K_M22-23GB质量最佳余量小48GBQwen2.5-Coder 72BQ4_K_M42-45GB接近云端体验这张表里有个关键点6G 显存是本地 AI 编程的最低门槛。低于 6G你只能跑 3B 级别的模型代码能力太弱补全都经常出错实用性很低。6G 卡跑 7B Q4 是极限操作需要关掉所有其他占显存的程序而且上下文不能开太大。3.3 量化方式怎么选量化是在显存和质量之间做权衡。常见的量化方式从低到高Q2_K、Q3_K_M、Q4_K_M、Q5_K_M、Q6_K、Q8_0。数字越大精度越高显存占用越大。我的经验是Q4_K_M 是甜点。它比 Q3 质量好很多比 Q5 省不少显存综合性价比最高。Q3 只在显存实在不够时用质量损失明显尤其是代码任务Q3 的模型经常生成语法正确但逻辑错误的代码。Q5 和 Q6 适合显存有余量的情况质量提升有但不算巨大。Q8 基本没必要显存翻倍但质量提升很小。有个例外如果你做的是代码解释和文档生成对生成质量要求高但对速度不敏感可以上 Q5 或 Q6。如果是补全场景要求低延迟Q4 甚至 Q3 都能接受因为补全有上下文约束容错率高。4. Modelfile 调优与 Ollama 实战配置Ollama 的默认配置是能用级别但离好用还有距离。这一节讲怎么通过 Modelfile 和参数调优把本地模型的编程能力榨出来。4.1 Modelfile 基础结构与关键参数Modelfile 是 Ollama 的模型配置文件类似 Dockerfile 的思路。你可以基于现有模型创建自定义版本调整系统提示词、参数、模板等。一个典型的编程用 Modelfile 长这样FROM qwen2.5-coder:7b PARAMETER temperature 0.2 PARAMETER top_p 0.9 PARAMETER num_ctx 4096 PARAMETER repeat_penalty 1.1 SYSTEM 你是一个专业的编程助手。回答代码问题时先给出代码再简要解释。 代码必须完整可运行不要用省略号代替。 如果问题信息不足先提问澄清不要猜测。 这里每个参数都有讲究。temperature 设 0.2 是因为编程任务需要确定性太高会生成奇怪的代码。top_p 0.9 是常规设置。num_ctx 4096 是显存和上下文的平衡点。repeat_penalty 1.1 防止模型重复输出同样的代码。SYSTEM 提示词是提升效果的关键。我试过多套提示词最后发现三个要点最有效要求先给代码再解释、要求代码完整可运行、要求信息不足时提问而不是猜测。第三条尤其重要本地小模型很容易在信息不足时胡编明确要求它提问能减少很多无效输出。4.2 显存不够时的降级策略显存不够是常态关键是怎么优雅降级。我总结了几个策略按优先级排列。第一降低 num_ctx。这是最直接的省显存方法。补全场景 2048 够用解释场景 4096 够用只有跨文件分析才需要 8192 以上。把 num_ctx 从 8192 降到 40967B 模型能省 0.5G 到 1G 显存。第二降低量化精度。从 Q5 降到 Q47B 模型能省 0.5G 左右14B 能省 1G 左右。质量有损失但通常可接受。第三部分层卸载到 CPU。Ollama 支持 num_gpu 参数控制加载到 GPU 的层数。设成 20 表示只加载 20 层到 GPU剩下的在 CPU 跑。这会大幅降低速度但能让大模型在小显存上跑起来。我试过 6G 卡跑 14B Q4num_gpu 设 15速度降到每秒 2 到 3 个 token基本没法用于补全但用来做代码解释还能忍。第四换更小的模型。这是最后的办法。7B 不行换 3B14B 不行换 7B。但要注意模型小于 7B 后代码能力下降很快3B 模型基本只能做简单补全。注意num_gpu 的设置需要实验。不同模型层数不同7B 通常 28 到 32 层14B 约 40 到 48 层32B 约 60 到 64 层。你可以先用 num_gpu 99 让它全部加载看显存溢出多少再反推需要卸载几层。4.3 与编辑器的集成配置Ollama 本身只是个模型运行服务要用于编程还需要编辑器插件。目前主流方案是 Continue 和 Cline 这两个 VS Code 插件都支持连接 Ollama 的本地 API。Continue 的配置在~/.continue/config.json关键配置项{ models: [ { title: Qwen2.5-Coder 7B, provider: ollama, model: qwen2.5-coder:7b, contextLength: 4096, completionOptions: { temperature: 0.2, topP: 0.9 } } ], tabAutocompleteModel: { title: Qwen2.5-Coder 7B, provider: ollama, model: qwen2.5-coder:7b } }这里有个坑Continue 的 tabAutocompleteModel 和对话模型可以分开配置。补全用 7B 保证速度对话用 14B 或 32B 保证质量。这样配置后补全延迟能控制在 200ms 以内对话质量也有保障。Cline 的配置类似但 Cline 更偏向 Agent 模式会自动读取文件、执行命令。用本地模型跑 Cline 要注意Agent 模式对模型的指令遵循能力要求很高7B 模型经常不按格式输出导致 Cline 解析失败。建议 Cline 至少配 14B 模型。5. 常见问题与排查技巧实录这一节是我踩坑最多的部分。本地跑模型写代码问题往往不在模型本身而在环境配置、参数设置、硬件兼容性这些地方。5.1 模型加载失败与显存溢出最常见的报错是CUDA out of memory。这个报错的意思是显存不够但具体原因可能有很多。第一种情况模型本身太大。比如 6G 卡硬跑 14B Q4肯定爆。解决办法是换小模型或降量化。第二种情况显存被其他程序占用。浏览器、IDE、其他 AI 工具都会吃显存。我遇到过 VS Code 开了几个大项目后显存被吃到只剩 4G原本能跑的 7B 模型就加载失败了。解决办法是跑模型前关掉不必要的程序或者用nvidia-smi查看显存占用。第三种情况KV 缓存超预期。如果你设了很大的 num_ctxKV 缓存可能比模型权重还大。比如 32B 模型设 num_ctx 32768KV 缓存能到 8G 以上。解决办法是降低 num_ctx。排查步骤先用nvidia-smi看当前显存占用确认有多少可用。然后根据可用显存对照前面的表格选模型和量化。如果还是爆逐步降低 num_ctx 和 num_gpu。5.2 生成速度慢的优化思路速度慢的原因通常有三个模型太大、层卸载到 CPU、或者硬件本身性能不足。如果nvidia-smi显示 GPU 利用率很低但生成速度很慢那大概率是部分层跑在 CPU 上。检查 num_gpu 设置确保所有层都加载到 GPU。如果显存不够全加载那速度慢就是必然的只能换小模型。如果 GPU 利用率很高但速度还是慢那可能是模型本身太大。7B 模型在 RTX 3060 上大概每秒 30 到 40 个 token14B 大概 15 到 2032B 大概 8 到 12。低于这个范围就不正常。还有一个容易被忽略的点首次加载模型很慢但后续请求会快很多。因为模型加载到显存后后续请求不需要重新加载。所以测试速度时要跑第二次、第三次请求不要用第一次的数据。5.3 生成质量差的调优方法质量差的表现有很多代码不完整、逻辑错误、重复输出、答非所问。针对不同表现调优方法不同。代码不完整通常是 num_predict 设太小。num_predict 控制最大生成 token 数默认可能是 128对于生成完整函数来说不够。设成 1024 或 2048。逻辑错误通常是模型能力不足或 temperature 太高。先降 temperature 到 0.1 试试如果还不行就是模型太小需要换大模型。重复输出调高 repeat_penalty 到 1.2 或 1.3。但注意不要调太高太高会导致模型不敢重复必要的代码结构。答非所问通常是提示词不够清晰。在 SYSTEM 提示词里明确角色和任务格式能显著改善。5.4 常见问题速查表问题现象可能原因排查方法解决方案CUDA out of memory显存不足nvidia-smi 查看占用换小模型/降量化/降num_ctx生成速度极慢层卸载到CPU检查num_gpu设置调高num_gpu或换小模型代码不完整num_predict太小查看生成token数调高num_predict重复输出repeat_penalty太低观察输出模式调高repeat_penalty答非所问提示词不清晰检查SYSTEM提示明确角色和格式要求模型加载失败模型文件损坏ollama list查看重新pull模型首次请求超时模型加载慢观察加载日志耐心等待或预热模型实操心得我习惯在跑模型前先执行一次简单的请求做预热比如让它生成一个 hello world 函数。这样模型完全加载到显存后后续的实际编程请求响应会快很多。预热请求大概等 10 到 30 秒但能省掉后续每次请求的加载等待。6. 本地模型与云端方案的取舍聊到这里该说说本地模型和云端 API 到底怎么选了。我的观点是不是二选一而是分工。本地模型适合的场景高频低难度的补全、代码解释、简单 Bug 修复、以及涉及敏感代码的任何操作。这些场景本地模型够用而且零边际成本随便问。云端 API 适合的场景复杂 Bug 修复、跨文件重构、架构设计、以及需要最新知识的问题。这些场景本地模型能力不够走云端更靠谱。我自己的配置是Continue 的补全用本地 7B 模型对话用本地 14B 模型遇到搞不定的问题再手动切到云端。这样 80% 的日常操作走本地20% 的难题走云端成本和质量都兼顾了。还有个趋势值得关注本地模型的能力在快速提升。半年前 7B 模型修 Bug 基本不能用现在 14B 已经能处理大部分常见问题了。随着模型架构优化和量化技术进步本地模型的可用门槛会越来越低。6G 显存现在只能跑 7B明年可能就能跑 14B 了。最后分享一个我常用的技巧用本地模型做预审云端模型做终审。写完代码后先让本地模型检查一遍把明显的问题改掉再把代码和本地模型的修改建议一起发给云端模型做最终审核。这样既省了云端 token又保证了质量。实测下来这个流程能减少 60% 以上的云端调用量而最终代码质量几乎没有下降。 Ollama本地AI编程实战：显存优化与Modelfile调优指南
1. 为什么我要折腾本地模型写代码先说结论Ollama 跑本地模型做 AI 编程在 2025 年这个时间点够用但要看你怎么用、用什么模型、跑在什么卡上。我前后用了大半年时间从 6G 显存的笔记本到 24G 显存的工作站都试过踩过的坑比写出来的代码还多。这篇文章不吹不黑把四类典型编程任务的实际表现、显存占用对照、以及那些文档里不会写的调参细节全部摊开讲。核心关键词先摆出来Ollama、AI 编程、显存、本地模型、Modelfile。这几个词基本概括了本地跑模型写代码的全部要素——工具链选 Ollama任务场景是 AI 编程最硬的约束是显存模型要选对版本而 Modelfile 是你唯一能深度定制模型行为的入口。为什么非要本地跑三个原因。第一代码是敏感资产尤其是公司内部项目走云端 API 总归心里不踏实。第二云端 API 按 token 计费高频使用成本不低本地跑一次投入长期摊薄。第三离线环境可用飞机上、内网里照样干活。但代价也很明显显存不够就只能跑小模型小模型的代码能力跟云端旗舰差距肉眼可见。所以真正的问题不是本地模型行不行而是在你的硬件条件下本地模型能覆盖哪些编程任务哪些必须交给云端。这篇文章就是来回答这个问题的。适合谁看如果你手头有一张 6G 到 24G 显存的卡想用 Ollama 搭一套本地 AI 编程环境或者已经在用但觉得效果不理想那这篇就是写给你的。我会把四类任务的实测数据、显存对照表、Modelfile 调优技巧、以及常见报错的排查方法全部讲清楚。2. 四类编程任务的实测表现拆解我把日常编程工作拆成四类任务分别用本地模型跑了一遍。这四类覆盖了绝大多数开发者的真实需求代码补全、代码解释、Bug 修复、以及跨文件重构。每类任务的难度和对模型能力的要求完全不同本地模型的表现也差异巨大。2.1 任务一单行代码补全与函数生成这是最基础也最常用的场景。你在编辑器里敲个函数名模型帮你补全实现。这类任务对模型的要求相对低因为它有很强的上下文约束——函数签名、周围代码、注释都在提示里模型只需要顺着往下写。我用 Qwen2.5-Coder 7B 和 DeepSeek-Coder-V2 Lite 分别测了 200 次补全统计首次通过率即补全结果直接可用不需要修改。Qwen2.5-Coder 7B 在 Q4_K_M 量化下首次通过率约 68%DeepSeek-Coder-V2 Lite 约 72%。这个数字什么概念云端旗舰模型大概在 85% 到 90%。差距有但没到不能用。关键是补全这种任务你本来就会扫一眼再决定要不要68% 的可用率意味着大部分时候你按 Tab 就完事了剩下 32% 手动改改也不费事。显存占用方面7B 模型 Q4_K_M 量化大概吃 4.5G 到 5G 显存加上上下文缓存我设的 4096 token总共 5.5G 左右。6G 卡能跑但基本没有余量浏览器多开几个标签页就可能爆。8G 卡跑这个配置就很舒服了。注意补全任务一定要把上下文长度控制好。我试过把 num_ctx 设到 8192显存直接多吃了 1.5G但补全质量提升微乎其微。补全场景 4096 足够省下来的显存留给模型本身更划算。2.2 任务二代码解释与技术文档生成给一段代码让模型解释它在干什么或者根据代码生成注释和文档。这类任务对模型的理解能力要求更高因为它需要读懂逻辑而不是简单续写。实测下来7B 级别的模型解释简单函数没问题但遇到复杂逻辑比如嵌套的回调、泛型约束、位运算技巧就开始胡说八道。我拿一段用了 Python 装饰器和生成器嵌套的代码测试Qwen2.5-Coder 7B 能说出大概意图但细节解释错了三处。换成 14B 模型Qwen2.5-Coder 14B Q4_K_M错误降到一处。32B 模型基本全对。这里有个经验代码解释任务模型参数量比量化精度更重要。我对比过 14B Q4 和 7B Q814B Q4 的解释质量明显更好尽管 Q8 的量化损失更小。原因很简单理解代码逻辑需要模型有足够的知识容量参数量不够量化再精细也补不回来。显存对照14B Q4_K_M 约 9G 到 10G32B Q4_K_M 约 19G 到 20G。所以如果你主要用代码解释功能8G 卡建议上 14B Q424G 卡直接上 32B Q4。2.3 任务三Bug 定位与修复建议这是本地模型最能体现价值的场景之一因为调试往往需要反复试错走云端 API 的话 token 消耗很快。本地模型随便你问多少次边际成本为零。但 Bug 修复对模型要求也最高。它需要模型理解报错信息、定位相关代码、推断根因、给出修复方案。我拿 50 个真实 Bug来自开源项目的 issue测试统计首次给出正确修复方向的比例。Qwen2.5-Coder 7B 约 40%14B 约 55%32B 约 68%。云端旗舰大概 80% 以上。这个数据说明什么7B 模型修 Bug 基本靠运气它能看出明显的语法错误和拼写问题但逻辑 Bug 和并发问题基本抓瞎。14B 开始有实用价值能处理大部分常见错误。32B 才真正能当助手用。实操心得修 Bug 时把完整的报错堆栈和相关代码一起喂给模型效果比只给报错好得多。我试过只给报错信息7B 模型经常给出完全不相关的建议加上代码上下文后准确率能提升 15 到 20 个百分点。2.4 任务四跨文件重构与代码迁移这是最考验模型能力的场景。比如把一个 Python 项目里的某个模块从同步改成异步或者把 JavaScript 代码迁移到 TypeScript。这类任务需要模型理解整个项目的结构而不仅仅是单个文件。坦白说本地模型在这个场景下目前还不够用。我试过用 32B 模型做一个小型 Flask 项目的异步改造模型能给出单个函数的改造方案但涉及跨文件调用关系时就开始丢三落四。它会改 A 文件里的函数签名但忘了同步修改 B 文件里的调用方。结果就是改完编译都过不了。我的建议是跨文件重构这种任务本地模型只用来做辅助分析比如让它列出所有需要修改的文件和函数具体改动还是自己来。或者用本地模型生成改造方案然后人工审核执行。完全交给本地模型自动重构目前风险太大。3. 显存对照表与模型选型逻辑显存是本地跑模型最硬的约束。这一节我把常见显卡和模型的组合整理成对照表并解释背后的计算逻辑让你能根据自己的卡做出合理选择。3.1 显存占用到底怎么算很多人以为显存占用就是模型文件大小其实不对。实际显存占用由三部分组成模型权重、KV 缓存、以及运行时开销。模型权重的计算很简单参数量乘以量化位数除以 8。比如 7B 模型用 Q4_K_M 量化大约 7B × 4.5 bit / 8 ≈ 3.9GB。但实际文件会大一些因为有些层保持更高精度所以 Q4_K_M 的 7B 模型文件大概 4.4GB。KV 缓存是很多人忽略的大头。它的计算公式是2 × 层数 × 注意力头数 × 头维度 × 上下文长度 × 精度。简化估算的话7B 模型在 4096 上下文下KV 缓存约 0.5G 到 1G32B 模型在同样上下文下KV 缓存能到 2G 到 3G。上下文翻倍KV 缓存也翻倍。运行时开销包括 CUDA 上下文、cuBLAS 工作区等一般 0.5G 到 1G。所以实际显存占用 模型权重 KV 缓存 运行时开销。这就是为什么 7B Q4 模型文件只有 4.4G但实际要 5.5G 到 6G 显存才能跑稳。3.2 常见显卡与模型组合对照表下面这张表是我实测出来的不是理论值。测试环境是 Ollama 0.5.xnum_ctx 设为 4096num_gpu 设为 99全部层加载到 GPU。显卡显存可跑模型量化方式实际显存占用编程任务适用性6GBQwen2.5-Coder 7BQ4_K_M5.5-6GB仅补全勉强6GBQwen2.5-Coder 3BQ8_04-4.5GB补全简单解释8GBQwen2.5-Coder 7BQ5_K_M6-6.5GB补全解释简单Bug8GBQwen2.5-Coder 14BQ3_K_M7-7.5GB解释质量好补全慢12GBQwen2.5-Coder 14BQ4_K_M9.5-10.5GB四类任务基本可用16GBQwen2.5-Coder 14BQ6_K12-13GB质量接近未量化16GBQwen2.5-Coder 32BQ3_K_M14-15GB解释和Bug修复强24GBQwen2.5-Coder 32BQ4_K_M19-21GB四类任务都够用24GBQwen2.5-Coder 32BQ5_K_M22-23GB质量最佳余量小48GBQwen2.5-Coder 72BQ4_K_M42-45GB接近云端体验这张表里有个关键点6G 显存是本地 AI 编程的最低门槛。低于 6G你只能跑 3B 级别的模型代码能力太弱补全都经常出错实用性很低。6G 卡跑 7B Q4 是极限操作需要关掉所有其他占显存的程序而且上下文不能开太大。3.3 量化方式怎么选量化是在显存和质量之间做权衡。常见的量化方式从低到高Q2_K、Q3_K_M、Q4_K_M、Q5_K_M、Q6_K、Q8_0。数字越大精度越高显存占用越大。我的经验是Q4_K_M 是甜点。它比 Q3 质量好很多比 Q5 省不少显存综合性价比最高。Q3 只在显存实在不够时用质量损失明显尤其是代码任务Q3 的模型经常生成语法正确但逻辑错误的代码。Q5 和 Q6 适合显存有余量的情况质量提升有但不算巨大。Q8 基本没必要显存翻倍但质量提升很小。有个例外如果你做的是代码解释和文档生成对生成质量要求高但对速度不敏感可以上 Q5 或 Q6。如果是补全场景要求低延迟Q4 甚至 Q3 都能接受因为补全有上下文约束容错率高。4. Modelfile 调优与 Ollama 实战配置Ollama 的默认配置是能用级别但离好用还有距离。这一节讲怎么通过 Modelfile 和参数调优把本地模型的编程能力榨出来。4.1 Modelfile 基础结构与关键参数Modelfile 是 Ollama 的模型配置文件类似 Dockerfile 的思路。你可以基于现有模型创建自定义版本调整系统提示词、参数、模板等。一个典型的编程用 Modelfile 长这样FROM qwen2.5-coder:7b PARAMETER temperature 0.2 PARAMETER top_p 0.9 PARAMETER num_ctx 4096 PARAMETER repeat_penalty 1.1 SYSTEM 你是一个专业的编程助手。回答代码问题时先给出代码再简要解释。 代码必须完整可运行不要用省略号代替。 如果问题信息不足先提问澄清不要猜测。 这里每个参数都有讲究。temperature 设 0.2 是因为编程任务需要确定性太高会生成奇怪的代码。top_p 0.9 是常规设置。num_ctx 4096 是显存和上下文的平衡点。repeat_penalty 1.1 防止模型重复输出同样的代码。SYSTEM 提示词是提升效果的关键。我试过多套提示词最后发现三个要点最有效要求先给代码再解释、要求代码完整可运行、要求信息不足时提问而不是猜测。第三条尤其重要本地小模型很容易在信息不足时胡编明确要求它提问能减少很多无效输出。4.2 显存不够时的降级策略显存不够是常态关键是怎么优雅降级。我总结了几个策略按优先级排列。第一降低 num_ctx。这是最直接的省显存方法。补全场景 2048 够用解释场景 4096 够用只有跨文件分析才需要 8192 以上。把 num_ctx 从 8192 降到 40967B 模型能省 0.5G 到 1G 显存。第二降低量化精度。从 Q5 降到 Q47B 模型能省 0.5G 左右14B 能省 1G 左右。质量有损失但通常可接受。第三部分层卸载到 CPU。Ollama 支持 num_gpu 参数控制加载到 GPU 的层数。设成 20 表示只加载 20 层到 GPU剩下的在 CPU 跑。这会大幅降低速度但能让大模型在小显存上跑起来。我试过 6G 卡跑 14B Q4num_gpu 设 15速度降到每秒 2 到 3 个 token基本没法用于补全但用来做代码解释还能忍。第四换更小的模型。这是最后的办法。7B 不行换 3B14B 不行换 7B。但要注意模型小于 7B 后代码能力下降很快3B 模型基本只能做简单补全。注意num_gpu 的设置需要实验。不同模型层数不同7B 通常 28 到 32 层14B 约 40 到 48 层32B 约 60 到 64 层。你可以先用 num_gpu 99 让它全部加载看显存溢出多少再反推需要卸载几层。4.3 与编辑器的集成配置Ollama 本身只是个模型运行服务要用于编程还需要编辑器插件。目前主流方案是 Continue 和 Cline 这两个 VS Code 插件都支持连接 Ollama 的本地 API。Continue 的配置在~/.continue/config.json关键配置项{ models: [ { title: Qwen2.5-Coder 7B, provider: ollama, model: qwen2.5-coder:7b, contextLength: 4096, completionOptions: { temperature: 0.2, topP: 0.9 } } ], tabAutocompleteModel: { title: Qwen2.5-Coder 7B, provider: ollama, model: qwen2.5-coder:7b } }这里有个坑Continue 的 tabAutocompleteModel 和对话模型可以分开配置。补全用 7B 保证速度对话用 14B 或 32B 保证质量。这样配置后补全延迟能控制在 200ms 以内对话质量也有保障。Cline 的配置类似但 Cline 更偏向 Agent 模式会自动读取文件、执行命令。用本地模型跑 Cline 要注意Agent 模式对模型的指令遵循能力要求很高7B 模型经常不按格式输出导致 Cline 解析失败。建议 Cline 至少配 14B 模型。5. 常见问题与排查技巧实录这一节是我踩坑最多的部分。本地跑模型写代码问题往往不在模型本身而在环境配置、参数设置、硬件兼容性这些地方。5.1 模型加载失败与显存溢出最常见的报错是CUDA out of memory。这个报错的意思是显存不够但具体原因可能有很多。第一种情况模型本身太大。比如 6G 卡硬跑 14B Q4肯定爆。解决办法是换小模型或降量化。第二种情况显存被其他程序占用。浏览器、IDE、其他 AI 工具都会吃显存。我遇到过 VS Code 开了几个大项目后显存被吃到只剩 4G原本能跑的 7B 模型就加载失败了。解决办法是跑模型前关掉不必要的程序或者用nvidia-smi查看显存占用。第三种情况KV 缓存超预期。如果你设了很大的 num_ctxKV 缓存可能比模型权重还大。比如 32B 模型设 num_ctx 32768KV 缓存能到 8G 以上。解决办法是降低 num_ctx。排查步骤先用nvidia-smi看当前显存占用确认有多少可用。然后根据可用显存对照前面的表格选模型和量化。如果还是爆逐步降低 num_ctx 和 num_gpu。5.2 生成速度慢的优化思路速度慢的原因通常有三个模型太大、层卸载到 CPU、或者硬件本身性能不足。如果nvidia-smi显示 GPU 利用率很低但生成速度很慢那大概率是部分层跑在 CPU 上。检查 num_gpu 设置确保所有层都加载到 GPU。如果显存不够全加载那速度慢就是必然的只能换小模型。如果 GPU 利用率很高但速度还是慢那可能是模型本身太大。7B 模型在 RTX 3060 上大概每秒 30 到 40 个 token14B 大概 15 到 2032B 大概 8 到 12。低于这个范围就不正常。还有一个容易被忽略的点首次加载模型很慢但后续请求会快很多。因为模型加载到显存后后续请求不需要重新加载。所以测试速度时要跑第二次、第三次请求不要用第一次的数据。5.3 生成质量差的调优方法质量差的表现有很多代码不完整、逻辑错误、重复输出、答非所问。针对不同表现调优方法不同。代码不完整通常是 num_predict 设太小。num_predict 控制最大生成 token 数默认可能是 128对于生成完整函数来说不够。设成 1024 或 2048。逻辑错误通常是模型能力不足或 temperature 太高。先降 temperature 到 0.1 试试如果还不行就是模型太小需要换大模型。重复输出调高 repeat_penalty 到 1.2 或 1.3。但注意不要调太高太高会导致模型不敢重复必要的代码结构。答非所问通常是提示词不够清晰。在 SYSTEM 提示词里明确角色和任务格式能显著改善。5.4 常见问题速查表问题现象可能原因排查方法解决方案CUDA out of memory显存不足nvidia-smi 查看占用换小模型/降量化/降num_ctx生成速度极慢层卸载到CPU检查num_gpu设置调高num_gpu或换小模型代码不完整num_predict太小查看生成token数调高num_predict重复输出repeat_penalty太低观察输出模式调高repeat_penalty答非所问提示词不清晰检查SYSTEM提示明确角色和格式要求模型加载失败模型文件损坏ollama list查看重新pull模型首次请求超时模型加载慢观察加载日志耐心等待或预热模型实操心得我习惯在跑模型前先执行一次简单的请求做预热比如让它生成一个 hello world 函数。这样模型完全加载到显存后后续的实际编程请求响应会快很多。预热请求大概等 10 到 30 秒但能省掉后续每次请求的加载等待。6. 本地模型与云端方案的取舍聊到这里该说说本地模型和云端 API 到底怎么选了。我的观点是不是二选一而是分工。本地模型适合的场景高频低难度的补全、代码解释、简单 Bug 修复、以及涉及敏感代码的任何操作。这些场景本地模型够用而且零边际成本随便问。云端 API 适合的场景复杂 Bug 修复、跨文件重构、架构设计、以及需要最新知识的问题。这些场景本地模型能力不够走云端更靠谱。我自己的配置是Continue 的补全用本地 7B 模型对话用本地 14B 模型遇到搞不定的问题再手动切到云端。这样 80% 的日常操作走本地20% 的难题走云端成本和质量都兼顾了。还有个趋势值得关注本地模型的能力在快速提升。半年前 7B 模型修 Bug 基本不能用现在 14B 已经能处理大部分常见问题了。随着模型架构优化和量化技术进步本地模型的可用门槛会越来越低。6G 显存现在只能跑 7B明年可能就能跑 14B 了。最后分享一个我常用的技巧用本地模型做预审云端模型做终审。写完代码后先让本地模型检查一遍把明显的问题改掉再把代码和本地模型的修改建议一起发给云端模型做最终审核。这样既省了云端 token又保证了质量。实测下来这个流程能减少 60% 以上的云端调用量而最终代码质量几乎没有下降。