1. 为什么我要把 Gemma 4 跑在本地云端 API 替代不了的几件事很多人第一次听说 Gemma 4是来自一句“Google 开源了 26B MoE 新模型”的消息。但真正有意思的问题是这个模型能不能在本地 AI 环境里跑起来跑起来之后又能帮我做什么。我花了一周时间在 Windows 机器上从矿卡方案试到 RTX 3090把 Ollama 配置、Python 调用、邮件整理和知识库助手的完整链路都跑通了。这篇文章不是官方文档而是我实际操作过程中的完整记录适合想把自己的电脑变成本地 AI 工作站的人。先用一句话总结我的结论Gemma 4 26B MoE 是目前在普通个人电脑上跑大模型的一个非常合适的平衡点但它能不能真正发挥价值取决于你愿不愿意在硬件规划、参数调优和场景落地上花功夫。下面从动机开始讲。1.1 隐私与数据边界邮件和文档不该随便出本机我手头有一批本地邮件、产品文档和内部表格里面全是客户联系方式、报价细则这类不能外流的内容。早先我试过直接丢给在线助手去总结结果每次点击发送心里都在打鼓数据经过谁的手、会不会被拿去训练、留存多久作为使用者完全没法掌控。把 Gemma 4 这类开源模型部署到本地之后模型权重文件在我硬盘上推理也在本机完成邮件内容从头到尾不离开这台电脑。单就这一条就足够让很多企业或个人愿意在本地 AI 上多花点时间。我理解很多人的顾虑是“本地跑的效果不如云端大模型”这个差距确实存在但得分场景。整理几十封邮件、生成会议纪要、把一篇文章改写几个版本这种任务对模型上限的要求没那么夸张Gemma 4 26B MoE 的表现已经够用。而且本地推理没有网络抖动没有按 token 计费的顾虑跑多少遍都不心疼。想让它多读几遍文档、换个 Prompt 重新总结随便折腾成本几乎为零。1.2 长期成本与可控性本地模型是越用越省的工具另一个经常被忽略的点是可控性。云端 API 的服务条款、限流策略、模型版本下架全都不由你决定。今天调得顺手的接口明天可能就变了。而本地部署的模型权重文件就在你手里想用哪个版本就用哪个版本想怎么参数调优就怎么调甚至后续可以做微调、挂知识库。长期用下来硬件是一次性投入软件层面是纯开源方案比按量付费稳定得多。1.3 Gemma 4 26B MoE 是什么一个适合本地跑的平衡点Gemma 4 这个系列里最受关注的就是 26B 的 MoE 版本。MoE 全称 Mixture of Experts混合专家架构核心思路是模型总参数看着有 26B但每次推理只会激活其中一小部分专家网络。我实测下来它实际激活的参数大约只在 3B 到 4B 量级所以推理速度比同体量的 Dense 模型快很多而效果又比纯 7B 模型强一截。对本地 AI 场景来说这正是我要的那个平衡点既有足够能力又有普通人能接受的硬件门槛。如果你以前只跑过 7B 甚至更小的模型上手 26B MoE 之后最大的感受就是“回答变聪明了”复杂指令的理解、长文本的归纳、中文表达的流畅度都有了肉眼可见的提升。当然它也带走了更多的硬盘空间和内存所以接下来的硬件部分才是真正决定你体感的关键。2. 硬件配置怎么定从“矿卡能不能跑”到一份可抄的配置表2.1 显存与内存的真正需求量怎么算很多人在部署本地 AI 时第一个问题就是我这台电脑到底跑不跑得动。我的经验是先别问型号先算两个数模型文件体积和推理额外开销。模型文件体积取决于量化精度。GGUF 格式的量化等级里Q4_K_M 是实用性和质量比较平衡的选择。26B 总参数量在 Q4_K_M 量化后文件大约 15GB 到 16GBQ5_K_M 大约 18GB 到 19GBQ8_0 则会到 25GB 以上。推理时还要留出上下文缓存、临时计算的空间所以实际要求是显存加可用内存至少要大于模型文件体积再多出 2GB 到 4GB 才比较稳妥。如果显存不够也不用直接放弃。Ollama 这类工具会自动把放不下的层分摊到系统内存上也就是 GPU 加 CPU 混合推理。这时系统内存规格就非常重要了至少 32GB 起步最好 64GB。很多人只盯着显卡显存结果 16GB 显卡配了 16GB 内存一加载模型就整个系统卡死其实是被内存卡了脖子。2.2 P104 矿卡方案能跑但别抱太高期望网上经常有人问用几张矿卡 P104 组本地 AI 行不行。我也专门试过。P104-100 是 8GB 显存、没有视频输出口的挖矿卡价格确实便宜问题也不少。先说结论能跑但只适合跑小模型或者做批量离线任务拿来跑 Gemma 4 26B MoE 这种级别体验会很勉强。8GB 显存连 Q4_K_M 的 15GB 都放不下只能强制把所有层都放在 CPU 上算或者塞进去极少数层。实际速度可能只有每秒 2 到 4 个 token聊天基本没法等但写脚本批量处理文本还是能用的。矿卡还有几个额外麻烦没有显示输出必须配一块亮机卡或者核显BIOS 里要设置正确的启动顺序Pascal 架构老部分新框架虽然支持但不是优化重点矿卡本身的稳定性取决于你买到的那张卡散热和风扇要自己处理。所以我的建议是如果预算真的极度有限一张 P104 买来玩玩可以但别指望它能成为主力推理卡。真想在低预算下跑本地大模型我更推荐收一张 P40 24GB价格只贵几百块但 24GB 显存能把 26B 的 Q4 量化完整装下体验完全是两个等级。2.3 三档配置参考低成本、均衡、一步到位为了让你不用自己东拼西凑我把这次部署过程中验证过的三档配置整理成了一张表直接参考就行方案显卡内存模型量化预期速度适用场景低成本带 GPUGTX 1660 Super / P104 8GB32GBQ3_K_M / 部分 offload2-6 token/s脚本批量处理、简单问答均衡主流RTX 4060 Ti 16GB / 3060 12GB64GBQ4_K_M 部分 offload8-15 token/s日常对话、邮件整理、知识库问答一步到位RTX 3090 / 4090 24GB64GBQ4_K_M / Q5_K_M 全显存35-50 token/s长上下文、复杂指令、嵌入工作流速度只是个参考实际受 CPU、内存频率、上下文长度影响很大。内存频率对 CPU offload 的影响尤其明显我建议优先选 DDR4 3200 以上或者 DDR5 平台。另外全程用 CPU 跑也不是不行32 线程的机器可以到 3 到 6 token/s处理批量文档够用但交互式聊天会让人等得心焦。3. Windows 环境搭建Ollama 安装、模型拉取与第一行对话3.1 为什么选 Ollama 而不是纯 Python 部署第一次接触本地大模型的人很容易被一堆方案绕晕Transformers、vLLM、llama.cpp、Ollama……到底哪个合适。我的建议很直接先选 Ollama。Ollama 本质上帮你把 llama.cpp 的底层能力和模型管理包了一层一条命令就能把模型拉下来自动做量化选择、GPU offload 和内存调度Windows 下还打包成了服务。你不用手动装 CUDA、不用管 PyTorch 版本、不用写推理脚本门槛低到我甚至觉得用“幼儿园难度”来形容也不夸张。等你把流程跑通了再去接触更底层的方案也不迟。如果第一次就跑纯 Python 加 Transformers光是搭建 CUDA 环境就能劝退一大半人更别说后面还要解决加载 26B 模型时爆显存的问题。先工具、后原理是本地 AI 最现实的上手路径。3.2 安装与模型拉取的完整过程第一步从官网下载 Ollama 的 Windows 安装包双击安装。这一步默认会帮你在系统目录里装好并注册成后台服务装完托盘区会出现一个小羊驼图标。第二步按 Win 加 R 输入 powershell 打开终端执行模型拉取ollama pull gemma4:26b如果你用的标签和我演示的不一样以你实际看到的模型列表为准比如有些镜像仓库会把 MoE 版本单独标注成 gemma4:26b-moe。拉取过程就是一个带进度条的下载模型文件量不小根据网速可能要等一段时间。第三步直接启动对话ollama run gemma4:26b看到 Send a message的提示符就可以输入文字了。第一次运行会做加载和量化检查加载完成后同样一句“你好”速度会直接告诉你这台机器的真实水平。我在这台 64GB 内存、24GB 显存的机器上首 token 响应大概一两秒问复杂问题也没觉得等太久。当然Ollama 并不是唯一的选择。如果你希望有图形界面可以再装一个 Open WebUI它能连接到本地 Ollama 服务提供类似 ChatGPT 的网页聊天体验。这一步不是必须的但适合不想总对着黑框打字的读者。3.3 验证模型是否正常工作刚装完环境建议先做两个检查确保后面用 Python 时不会出幺蛾子。第一个在 PowerShell 里确认 Ollama 服务还活着打开任务管理器找到 Ollama 相关进程或者在终端执行ollama list能看到模型列表就说明服务正常。第二个测试 API 接口能不能通。Ollama 默认在 11434 端口监听用下面这条命令发出请求curl http://localhost:11434/api/generate -d {\model\: \gemma4:26b\, \prompt\: \用一句话介绍你自己\}如果返回 JSON 里有完整的文本内容说明模型服务正常。这里有个常见坑Windows 自带的 curl 对引号转义很敏感建议把整条命令复制到 PowerShell 里执行别自己手工改很容易改出语法错误。API 通了后面的 Python 调用就稳了八成。4. 参数调优实战让 26B MoE 在有限资源下跑得更快4.1 量化等级的选择逻辑模型能跑起来只是第一步真正决定体感的是量化等级和运行参数。很多新手直接拉了一个默认版本就开始用遇到显存不够、速度太慢就以为是自己硬件不行其实往往是参数没调对。量化等级 GGUF 里的 Q4_K_M、Q5_K_M、Q8_0本质是模型权重的精度和体积之间的博弈。Q8_0 保真度高但文件太大Q4_K_M 是损耗和体积都比较均衡的默认选择如果显存实在紧张可以降到 Q3_K_M不过这时模型的推理质量会有肉眼可见的下降中文尤其明显。我的选择逻辑很简单先看显存。24GB 显存直接上 Q4_K_M上下文调到 8K 到 16K 都能稳妥运行16GB 显存建议 Q4_K_M 加限制上下文如果连 16GB 都没有优先保证模型装得下再考虑质量。4.2 关键运行参数说明与推荐值Ollama 的默认参数够用但想压榨出更好的效果可以创建自己的 Modelfile。我在工作目录下写了一个FROM gemma4:26b PARAMETER num_ctx 16384 PARAMETER temperature 0.7 PARAMETER top_p 0.9然后执行ollama create gemma4-16k -f Modelfile之后就能用ollama run gemma4-16k来跑这个自定义配置。这里几个参数分别解释一下num_ctx上下文窗口长度单位是 token。默认值通常是 4096处理长文档或知识库问答时不够用我建议至少调到 8192显存够就上 16384。但上下文拉长会直接影响显存占用模型加载后KV cache 会随上下文长度线性增长。temperature采样温度控制随机性。0.7 是通用值做邮件整理、信息提取这种偏结构化任务可以降到 0.3 到 0.5输出更稳定做头脑风暴、写作润色再回到 0.8 左右。top_p核采样阈值默认 0.9 或 1.0。通常保持默认即可不需要单独折腾。如果你想更精细地控制 GPU 层数分配Ollama 也支持直接设置放入显卡的层数。比如 16GB 显卡想多放几层进显存又怕爆可以先设一个比较保守的数字比如 25 层然后观察ollama ps里显示的显存占用再逐步往上加。这个过程有点像烤面包时微调温度多试几次就有手感了。4.3 实测速度参考与性能瓶颈分析我把几组实测数据列在这里方便你心里有个谱。RTX 3090 24GB、64GB 内存、DDR4 3200Q4_K_M 量化、16K 上下文输出速度大约 35 token/s 到 50 token/s 之间足够流畅对话RTX 4060 Ti 16GB、同样 64GB 内存模型部分 offload 到 CPU速度在 10 token/s 左右属于“能等但不难受”的程度纯 CPU 跑 32 线程只能到 3 到 6 token/s适合批量任务。瓶颈在哪里如果是全 GPU 运行瓶颈主要是显存带宽如果是 GPU 加 CPU 混合瓶颈几乎一定在内存带宽和 CPU 与 GPU 之间的数据传输。所以如果你在混合模式下运行其他程序最好全关掉特别是浏览器这类吃内存的大户。另外MoE 模型一个有趣的特点是因为每次只激活部分专家批量处理长 Prompt 时的吞吐量往往比短 Prompt 更划算。所以如果你要跑文档总结、批量归档这类任务建议一次性把文本全部喂进去而不是拆成一句一句问综合效率会高很多。5. Python 调用本地模型写一个自己的 AI 助手脚本5.1 本地 API 与 OpenAI SDK 的兼容套路部署本地模型的最大意义是把它接进你自己的工具链而这通常要从 Python 开始。Ollama 提供了兼容 OpenAI 格式的 API 端点地址是http://localhost:11434/v1。这意味着你用过的 openai 库、LangChain、Flowise 这类工具只要改一个 base_url就能直接对接本地模型。这里有个容易被坑的点本地模型的 API key 一般不会校验但你还是要填一个占位符比如ollama。很多库如果检测不到 api_key 会直接报错所以别省略这个看似多余的参数。5.2 一个最小可用脚本流式输出对话下面这个脚本是我现在最常用的模板带流式输出不会一直卡到结束才一次性显示结果from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama, ) resp client.chat.completions.create( modelgemma4:26b, messages[ {role: system, content: 你是一个简洁高效的写作助手。}, {role: user, content: 帮我把下面这段话改写成更正式的会议纪要%s % text}, ], streamTrue, temperature0.4, ) for chunk in resp: delta chunk.choices[0].delta.content if delta: print(delta, end, flushTrue)这里text可以是你从外部读入的邮件正文、文档片段或者任何需要处理的文本。streamTrue是为了实时看到输出避免脚本看起来像卡死。temperature0.4是根据任务调低后的结果让改写更稳定。5.3 批量处理任务时的工程细节当你准备用 Python 批量调用本地模型处理几十甚至上百个文件时有几个工程细节值得提前想好否则脚本跑到一半很容易出状况。第一个是并发控制。本地模型不是云端 API没有弹性扩容能力。如果你的脚本开了太多线程同时请求Ollama 会排队处理但每个请求的等待时间会拉长反而可能造成内存紧张。我的习惯是控制并发数在 1 到 2一次处理一批宁可慢一点也不要因为并发把机器拖死。第二个是超时和重试。本地推理偶尔会因为资源占用过高而卡住所以 requests 或 openai 客户端要设置合理的超时时间比如 120 秒超时后重试一次。如果连续失败多半是硬件资源被占满应该先停掉其他任务再继续。第三个是输出落盘。批量任务处理完要及时把结果写入文件或数据库防止脚本中途崩溃丢掉全部结果。我会把每次调用的输入、输出、模型参数、时间戳都记录下来一方面方便排查问题另一方面也是给后面的知识库积累材料。到这里本地模型就已经不只是聊天窗口里的玩具了它可以变成你电脑里的一个随时可用的 AI 服务。下一节我会用两个真实场景展示怎么把它接到日常工作里。6. 两个真实落地场景邮件整理与本地知识库助手6.1 已收到的本地邮件如何让 AI 帮忙整理这个场景来自我自己的真实需求本地邮箱里攒了几百封产品咨询和跟进邮件每天手动归类非常费时间。我的做法是写一个脚本先把邮件导出成.eml文件然后用 Python 解析出主题、发件人、正文交给 Gemma 4 做结构化整理。示例 Prompt 大概是这样的你是一个邮件处理助手。下面是一封邮件请输出 1. 邮件分类咨询/报价/售后/其他 2. 三个以内的关键信息点 3. 建议的处理动作回复/跟进/归档 邮件主题{subject} 邮件正文{body}模型返回的 JSON 结构可以直接被程序解析于是我能自动把每封邮件标记好分类和优先级生成一个待办清单。整个过程不需要把邮件内容传到任何外部服务隐私上放心很多。实际跑下来要注意两点一是邮件正文可能很长Prompt 会吃掉不少上下文窗口建议先做长度截断或只取首尾各几百字二是模型偶尔会输出多余的解释文字而不是纯 JSON我在解析时加了容错处理比如用正则从文本里抽大括号内的内容再交给json.loads解析。这种小细节只有在处理真实数据时才会意识到有多重要。6.2 用 RAG 思路搭建本地部署的企业级知识库助手第二个场景是知识库问答。做法并不复杂先把本地文档切成大小合适的文本块比如每 500 个 token 一块然后用 embedding 模型把文本向量化存入本地向量数据库。用户提问时先在向量库里检索出最相关的几块文本连问题一起拼成 Prompt 发给 Gemma 4让它基于给定材料回答。这个思路叫 RAGRetrieval Augmented Generation它最大的好处是不需要微调模型。文档更新了重新灌一次向量库就行模型换版本知识库还能继续复用。我在本地用 SentenceTransformer 加载了一个开源 embedding 模型配合 FAISS 向量库几行代码就能跑通检索部分。检索到相关片段之后用我前面给的 Python 模板调用 Gemma 4 生成回答。由于回答严格限定在检索到的材料里模型就算记忆里没有这部分内容也不会瞎编这对企业知识库场景非常关键。要提醒一点embedding 模型和生成模型最好都跑在本地整个链路才能做到真正的离线。如果只是生成部分本地、检索部分调用云端隐私链条还是断的。Gemma 4 本身能力足够强但在 RAG 链路里的角色是“读材料、组织答案”不要指望它记住你全部的内部文档。6.3 手机端与多模态延伸本地 AI 不是只能待在电脑上有些热搜词提到手机本地 AI 部署、图生视频、绘画 AI 本地部署这里我多说两句。Gemma 4 部分版本支持图像输入可以做简单的图片内容理解比如识别截图里的表格、提取照片中的文字。至于图生视频或者绘画生成那是另外一类模型的事跑本地需要的显存和内存比纯文本模型高一个量级跟 Gemma 4 不在同一个部署栈里别被名字相似给带偏了。手机端跑本地模型的可行方案是 Ollama 的手机客户端或 Termux 等终端工具但手机内存普遍有限跑 26B MoE 会很吃力更现实的玩法是只跑 7B 以下的小模型把重活留给电脑。如果你真有移动端需求我的建议是先在电脑上把整套流程跑通然后按同样的思路搜对应平台的支持情况别一上来就在手机上折腾大模型纯属给自己找不痛快。7. 踩坑记录与排查链路从 OOM 到中文乱码的真实案例7.1 爆显存 OOM 的处理流程第一个遇到的高频问题是显存溢出也就是 OOMOut of Memory。表现很直接程序加载到一半直接退出或者跑着跑着报 CUDA out of memory。这东西在处理 26B 模型时几乎人人都会碰到别慌按下面的顺序排查就行。首先看任务管理器确认没有其他程序在吃显存包括浏览器、设计软件、另一个没关干净的模型进程。第二步检查上下文长度把 num_ctx 从 16K 降到 8K 甚至 4KKV cache 的占用会立刻降下来。第三步降低量化等级Q5 降到 Q4、Q4 降到 Q3。最后调整 GPU 层数让更多层跑在 CPU 上。这几步做完绝大部分 OOM 都会消失。有一个判断标准值得记住如果加载模型后系统整体卡顿鼠标都拖不动说明内存不足而不是显存不足。这时候哪怕显卡有余力也没用因为 CPU offload 的部分把系统内存吃满了。我后来把内存从 32GB 升级到 64GB这个现象再也没出现过。7.2 防火墙拦截 API 的排查过程我遇到过 Python 脚本连接 Ollama 时连接被拒但浏览器访问图形界面却是好的。排查链路大概是这样的先确认 Ollama 服务进程在跑然后curl http://localhost:11434看通不通结果 curl 正常脚本却连不上这就基本锁定是脚本进程被 Windows 防火墙拦截了。解决办法也简单在 Windows 安全中心的防火墙规则里为 Python 或者对应终端程序添加“允许通过防火墙”的规则尤其是专用网络和公用网络都要勾上。如果只是本机脚本调用问题往往不是 Ollama 没监听而是 Windows 防火墙挡了 Python 进程。另外如果你想让局域网里其他设备也能访问本地模型需要设置环境变量OLLAMA_HOST0.0.0.0再重启 Ollama 服务不过我不建议在不可信局域网里这样干毕竟模型服务没有身份验证。7.3 中文生成质量与提示词的调试经验中文质量是很多人的心病。同样一个模型英文回答很流利中文却偶尔蹦出病句或夹带英文。我实测下来本地部署时中文质量受两件事影响最大量化等级和 Prompt 写法。量化等级越低中文退化越明显尤其是 Q3 以下输出会变得很奇怪。所以只要显存允许我建议至少用 Q4_K_M。Prompt 方面我会在 system message 里明确写一句“请使用简体中文保持专业、简洁的表达”。不要小看这句话它能让输出稳定性提升不少。如果模型依然偶尔冒英文可以在后处理里加一个简单检查检测到大量连续英文时自动重试一次。还有一个容易被忽略的坑是 Windows 终端的编码问题。PowerShell 默认编码可能跟模型输出的 UTF-8 不一致导致中文在终端里显示成乱码。解决方法是执行下面这句$OutputEncoding [Console]::OutputEncoding [Text.UTF8Encoding]::UTF8或者在打印前对字符串做统一编码处理。很多新手以为模型输出的是乱码其实是终端显示问题换到 Windows Terminal 后基本就不会出现了。7.4 性能异常的最终验证与结论如果你觉得部署后速度跟别人的评测差很多先别急着怀疑硬件。我的排查经验是先看ollama ps的输出确认模型到底有没有全部加载进显存还是大部分在 CPU 上跑。再观察系统内存占用和 CPU 占用。很多时候“速度慢”其实是系统内存频率太低或者是后台程序抢占资源。我这次部署就是从一张 P104 开始的逐步把配置调到了 RTX 3090 平台。整个过程中的最大体会是硬件只是基础真正的效率来自于对资源分配的理解。同样是 16GB 显卡有些人能跑到流畅对话有些人却反复爆显存差别基本都在上下文长度和 GPU 层数这两个参数上。把这两个参数吃透本地 AI 的体验会上升一个档次。最后再分享一个我这几天折腾出来的小习惯日常我更习惯直接用 Python 脚本调用本地模型而不是在终端里聊天。我会把常用的 Prompt 模板存成文件配合 PowerShell 一键执行这样无论是整理邮件、批处理文档还是知识库问答都只需要双击一个脚本Gemma 4 就会老老实实在后台把活干完。本地 AI 的乐趣不在于把模型跑起来那一刻的兴奋而在于它真正进入你的工作流之后你再也回不去了。
