1. 为什么 Gemma 4 让本地部署这件事突然变得靠谱了本地跑大模型这件事喊了不是一年两年了。从最早拿一张 8G 显存的卡硬塞 7B 模型到后来量化技术成熟、消费级显卡能跑 13B再到现在动不动就有人在家里用 4090 跑 70B 量化版——这条路走得不算快但每一步都踩得很实。Gemma 4 发布之后我身边好几个之前一直观望的朋友都开始动手了原因很简单开源协议终于不再是绊脚石了。之前很多模型权重虽然能下载但协议里总藏着一些让人心里没底的东西——商用限制、用户量门槛、衍生模型条款。你拿来做个人项目可能没人管但一旦想放到产品里或者在公司内部用法务那边就过不去。Gemma 4 这次直接上了Apache 2.0这个协议在开源圈子里什么地位不用我多说基本上就是“你随便用出了事别找我”的意思。对于想正经把大模型集成到工作流里的人来说这一条比模型本身涨了多少分都重要。那 Gemma 4 到底能干什么简单说它是一个多模态大模型系列覆盖了从轻量级到中等规模的多个尺寸支持文本、图像输入部分版本还能处理音频。你可以在自己的笔记本上跑一个 4B 左右的版本做日常问答和文档摘要也可以在台式机上跑 26B 的 MoE 版本做更复杂的推理任务。MoE 架构的好处是推理时只激活一部分参数所以实际计算量比同等总参数量的稠密模型小很多显存占用和速度都更友好。适合谁来参考这篇内容如果你是有一定命令行基础、想在自己电脑上跑大模型但不知道从哪下手的人这篇就是写给你的。如果你已经在用 Ollama 或者 vLLM 部署过其他模型想看看 Gemma 4 值不值得换我也会把对比和实测数据放出来。如果你只是好奇“本地跑大模型到底能干嘛”我也会用实际场景告诉你这东西现在到底能做到什么程度。我自己的测试环境是一台 Windows 台式机显卡是 RTX 4070 Ti Super 16G内存 64G另外还有一台 MacBook Pro M3 Pro 36G 用来做对比。下面所有操作和结论都基于这两个环境你可以根据自己的硬件情况做调整。2. 部署方案怎么选Ollama、vLLM 还是直接上 transformers2.1 三种主流路线的适用场景对比本地跑大模型目前主流就三条路Ollama、vLLM、直接调 transformers。这三个不是互相替代的关系而是对应不同需求层次。我先把结论摆出来再解释为什么。方案适合场景上手难度推理速度显存效率多模态支持Ollama个人日常使用、快速体验极低中等中等部分支持vLLM服务化部署、多并发请求中等高高看版本transformers研究、微调、深度定制较高低低完整支持Ollama 的优势在于开箱即用。你下载安装包一行命令拉模型再一行命令跑起来整个过程不超过五分钟。它内部帮你处理了量化、显存分配、对话模板这些事情你不需要关心底层用了什么推理引擎。缺点是灵活性差你想改个采样参数或者换个量化精度能调的选项有限。vLLM 是冲着生产环境去的。它的 PagedAttention 技术能把显存利用率拉高很多并发请求下的吞吐量比朴素实现高出一个数量级。如果你想让局域网里几个人同时用同一个模型或者想把它接进自己的应用里做 API 服务vLLM 是首选。代价是配置稍微麻烦一点需要自己处理模型格式转换和环境依赖。直接上 transformers 就是研究路线了。你想做微调、想改模型结构、想深入看每一层的输出那就得走这条路。速度慢、显存占用高但控制力最强。Gemma 4 发布当天 Hugging Face 上就有权重了transformers 版本跟进得很快。提示如果你只是想在本地体验一下 Gemma 4 的多模态能力别犹豫直接 Ollama。如果你打算把它做成一个内部工具给团队用直接看 vLLM 部分。2.2 为什么我最终选了 Ollama 做主力我三个方案都试了一遍最后日常使用的主力是 Ollama。原因不复杂我的使用场景是个人问答、文档摘要、代码辅助不需要并发不需要服务化。Ollama 的响应速度对我来说完全够用而且它管理模型的方式很干净——拉下来的模型统一放在一个目录里切换模型就是换个名字的事。vLLM 我也配好了跑在另一台机器上做 API 服务主要是给家里的其他设备调用。但日常坐在电脑前干活的时候我还是直接开 Ollama 的交互界面。这不是说 vLLM 不好而是工具要匹配场景。你让一个每天就问几个问题的人去维护一套 vLLM 服务属于过度工程。transformers 那条路我用来做了一些对比测试比如看 Gemma 4 在不同量化精度下的输出差异。这个后面会细说。2.3 硬件门槛到底在哪很多人关心的是“我这台电脑能不能跑”。我直接给一个粗略的判断标准8G 显存可以跑 4B 级别的量化版本速度尚可上下文长度受限12G 显存可以跑 9B 左右的量化版本日常使用比较舒服16G 显存可以跑 26B MoE 的量化版本这是 Gemma 4 比较甜点的配置24G 及以上可以跑更大尺寸或者更高精度的版本或者做微调内存方面至少 32G因为模型加载和推理过程中会有额外的内存开销。如果你的显存不够Ollama 会自动把部分层卸载到内存里跑速度会慢很多但至少能跑起来。Mac 用户这边M 系列芯片的统一内存架构反而有优势。36G 的 M3 Pro 跑 26B MoE 量化版比我的 4070 Ti Super 还稳因为显存和内存是一体的不存在卸载的问题。速度上略慢一点但体验更连贯。3. Windows 下从零部署 Gemma 4 的完整实操3.1 安装 Ollama 和拉取模型Windows 下安装 Ollama 没什么好说的去官网下载安装包双击下一步完事。安装完成后打开 PowerShell 或者 Windows Terminal输入ollama --version看到版本号就说明装好了。然后拉取 Gemma 4 的模型。这里要注意Gemma 4 有多个尺寸命名规则一般是gemma4:尺寸-量化等级。我建议先从 4B 的默认量化版本开始ollama pull gemma4:4b这个命令会下载大约 3-4G 的文件取决于量化等级。下载完成后直接跑ollama run gemma4:4b你会看到一个交互式提示符直接输入问题就行。第一次加载模型会花几秒钟把权重读进显存之后每次响应就很快了。如果你想跑 26B MoE 版本命令是ollama pull gemma4:26b-moe这个下载量大概在 15-18G 左右取决于量化版本。我的 16G 显存跑这个版本Ollama 会自动做部分卸载速度大概在每秒 15-20 个 token日常对话完全够用。注意Ollama 默认的模型存储路径在 C 盘如果你 C 盘空间紧张可以先设置环境变量OLLAMA_MODELS指向其他盘符。这个变量在系统设置里加就行不用改配置文件。3.2 多模态输入的配置和测试Gemma 4 的多模态能力是这次升级的重点之一。Ollama 对多模态的支持是通过--image参数或者直接在对话里引用图片路径来实现的。我实测下来在交互模式下可以这样用ollama run gemma4:4b 请描述这张图片的内容/path/to/your/image.jpg模型会读取图片并给出描述。我试了几张不同类型的图片——风景照、代码截图、表格截图——识别准确率相当不错。代码截图能读出大致的语言和结构表格截图能提取出大部分数据风景照的描述比较泛但基本准确。如果你要通过 API 调用多模态Ollama 的 API 格式是这样的curl http://localhost:11434/api/generate -d { model: gemma4:4b, prompt: 描述这张图片, images: [base64编码的图片数据] }图片需要转成 base64 编码。这个在 Python 里用base64库两行代码就能搞定。我写了一个小脚本做批量图片描述跑了几百张图整体稳定性很好没有出现崩溃或者显存泄漏的情况。3.3 用 vLLM 搭建 API 服务的详细步骤如果你需要服务化部署vLLM 是更好的选择。Windows 下 vLLM 的安装稍微麻烦一点因为它对 CUDA 版本有要求。我建议用 WSL2 来跑比直接在 Windows 上折腾省事得多。在 WSL2 的 Ubuntu 环境里先装好 CUDA 驱动和 Python 环境然后pip install vllmGemma 4 的权重可以从 Hugging Face 下载也可以用 vLLM 直接在线拉取。启动服务的命令python -m vllm.entrypoints.openai.api_server \ --model google/gemma-4-9b-it \ --dtype auto \ --max-model-len 8192 \ --gpu-memory-utilization 0.9这里几个参数解释一下。--dtype auto让 vLLM 自动选择合适的数据类型一般是 bfloat16 或者 float16。--max-model-len控制最大上下文长度设得越大显存占用越高8192 是一个比较平衡的值。--gpu-memory-utilization 0.9表示用 90% 的显存来加载模型和 KV Cache留 10% 给系统和其他进程。启动之后vLLM 会暴露一个兼容 OpenAI API 格式的接口默认端口 8000。你可以用任何 OpenAI 客户端来调用from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keydummy) response client.chat.completions.create( modelgoogle/gemma-4-9b-it, messages[{role: user, content: 你好}] ) print(response.choices[0].message.content)我实测下来vLLM 在并发 4 个请求的情况下总吞吐量比 Ollama 单请求模式高出三倍多。如果你只是自己用这个差距感知不明显但如果有多个设备或者多个用户同时访问vLLM 的优势就体现出来了。3.4 量化版本的选择和实测对比Gemma 4 的量化版本主要有 Q4_K_M、Q5_K_M、Q8_0 这几种。数字越大精度越高文件也越大。我在 4070 Ti Super 上做了对比测试用同一组问题分别跑不同量化版本记录响应质量和速度。量化版本文件大小显存占用生成速度质量主观评分Q4_K_M约 2.5G约 3.5G45 tok/s8/10Q5_K_M约 3.2G约 4.2G38 tok/s8.5/10Q8_0约 5.1G约 6.5G28 tok/s9/10Q4_K_M 和 Q5_K_M 的差距在日常对话中几乎感觉不到但在需要精确推理的任务上——比如数学计算或者代码生成——Q5 明显更稳。Q8_0 的质量最好但速度下降比较明显。我的建议是日常使用 Q4_K_M 就够了做正经工作用 Q5_K_MQ8_0 除非你有特殊需求否则没必要。26B MoE 版本的量化选择逻辑类似但因为 MoE 架构的特性量化对质量的影响比稠密模型小一些。我跑 Q4_K_M 的 26B MoE在很多任务上的表现比 Q8_0 的 9B 稠密版还好速度也更快。这就是 MoE 的优势所在。4. 实际使用中会遇到的问题和排查方法4.1 显存不足的典型表现和处理显存不足是本地部署最常见的问题。表现一般是模型加载到一半卡住、推理过程中突然报错、或者系统变得极其卡顿。Ollama 在显存不足时会自动把部分层卸载到内存但这个过程不是无感的——你会看到生成速度断崖式下降。判断是不是显存问题最直接的方法是看任务管理器里的 GPU 显存占用。如果接近满载那就是了。解决办法有几个换更小的量化版本从 Q5 降到 Q4显存占用能减少 20% 左右缩短上下文长度Ollama 可以通过--num-ctx参数控制默认是 2048设成 1024 能省不少显存关闭其他占用显存的程序浏览器、游戏、视频播放器都会占显存跑模型之前最好关掉设置OLLAMA_GPU_LAYERS环境变量手动控制卸载到 GPU 的层数找到一个速度和显存的平衡点我自己的经验是16G 显存跑 26B MoE 的 Q4_K_M把上下文设成 4096GPU 层数设成 28剩下的卸载到内存速度大概在 12-15 tok/s可以接受。如果你追求速度那就得降模型尺寸或者升硬件。4.2 模型输出质量不稳定的排查思路有时候你会发现模型突然开始胡言乱语或者回答质量明显下降。这种情况一般不是模型本身的问题而是对话模板或者采样参数出了问题。Gemma 4 有自己特定的对话模板格式如果你通过 API 调用时没有正确设置模型可能会把系统提示和用户输入混淆。Ollama 内部帮你处理了模板但如果你用 transformers 直接加载就需要自己确保格式正确。检查方法是看模型的 tokenizer 配置里有没有chat_template字段。采样参数方面temperature 设得太高会导致输出发散。Gemma 4 的推荐 temperature 是 0.7 左右top_p 0.9top_k 40。如果你做的是需要确定性的任务比如代码生成或者数据提取把 temperature 降到 0.2 甚至 0.1 会稳定很多。还有一个容易被忽略的点是上下文长度超限。当对话历史超过模型的最大上下文长度时有些实现会直接截断有些会报错。Ollama 默认会保留最近的若干轮对话但如果你手动拼接了很长的 prompt就可能出问题。养成习惯长对话定期清理或者开新会话。4.3 多模态输入常见错误和解决多模态输入报错主要集中在图片格式和大小上。Gemma 4 支持的图片格式包括 JPEG、PNG、WebP 等常见格式但图片尺寸太大会导致显存暴涨。我试过一张 4000x3000 的照片直接让 16G 显存爆了。解决办法是在输入前把图片缩放到合理尺寸一般长边不超过 1024 像素就够了。另一个常见问题是图片编码错误。通过 API 传图片时base64 编码不能有换行符或者多余的空格。Python 的base64.b64encode()默认不会加换行但如果你从文件读取时用了readlines()就可能引入问题。用read()一次性读取二进制数据再编码基本不会出错。如果模型对图片内容识别不准可以尝试在 prompt 里给一些引导。比如“这是一张代码截图请提取其中的函数名”比“描述这张图片”能得到更精确的结果。Gemma 4 的多模态理解能力在同类尺寸的模型里算不错的但它毕竟不是专门的 OCR 模型对密集文字的识别还有提升空间。4.4 性能调优的几个实用技巧想让 Gemma 4 跑得更快有几个立竿见影的调整第一用 GPU 而不是 CPU。这个不用多说差距是数量级的。确保 Ollama 检测到了你的显卡ollama run的时候看日志里有没有CUDA或者Metal的字样。第二调整批处理大小。vLLM 里可以通过--max-num-batched-tokens来控制设大一点能提高吞吐但会增加显存占用和首 token 延迟。我一般设成 4096平衡得比较好。第三用更快的存储。模型加载速度受硬盘影响很大NVMe SSD 比 SATA SSD 快一倍以上比机械硬盘快一个数量级。如果你经常切换模型这个差距很明显。第四关掉不必要的后台程序。浏览器是显存和内存大户跑模型的时候关掉能腾出不少资源。我实测关掉 Chrome 之后26B MoE 的生成速度从 12 tok/s 提升到了 16 tok/s。5. Gemma 4 在实际场景中到底能做什么5.1 文档摘要和知识提取这是我用得最多的场景。把一份几十页的 PDF 转成文本丢给 Gemma 4 做摘要效果比我预期的好。4B 版本就能抓住主要论点26B MoE 版本能给出更结构化的摘要甚至能按照我指定的格式输出。具体操作上我一般会把长文档切成 2000 字左右的片段分别做摘要然后再把摘要合并做二次摘要。这样做的原因是模型的上下文长度有限一次性塞太多内容反而会丢失细节。切分的时候注意按段落或者章节切不要从句子中间断开。知识提取方面Gemma 4 对结构化信息的抽取能力不错。我试过从合同文本里提取甲乙方、金额、日期这些字段准确率在 90% 以上。对于格式比较规范的文档基本可以直接用。格式混乱的就需要加一些 few-shot 示例来引导。5.2 代码辅助和调试Gemma 4 在代码任务上的表现比上一代有明显提升。我主要用它做三件事解释代码、生成单元测试、排查报错。解释代码这个场景4B 版本就够用了。把一段函数贴进去问“这段代码在做什么”它能给出比较准确的描述。生成单元测试的话26B MoE 版本更好它能考虑到更多的边界情况。排查报错是我觉得最实用的——把错误信息和相关代码一起贴进去它经常能指出问题所在比我自己翻文档快。不过要注意Gemma 4 不是专门的代码模型在复杂算法题上不如专门的代码大模型。日常的脚本编写、bug 修复、代码审查这些任务它完全能胜任。但如果你要做 LeetCode 难题或者复杂的系统设计还是得用更大的模型或者专门的代码模型。5.3 多模态场景的落地尝试多模态是 Gemma 4 的亮点我试了几个实际场景截图问答截一张软件界面问“这个按钮在哪”模型能根据截图给出位置描述。这个在写操作手册或者做教程的时候很有用。图表解读把数据图表截图丢进去问“这个趋势说明了什么”模型能给出基本的趋势分析。对于简单的折线图和柱状图解读准确率不错。复杂的多轴图表就需要更详细的引导。图片内容审核批量跑图片让模型判断内容类型和是否包含敏感元素。这个场景对准确率要求高Gemma 4 的表现中规中矩适合做初筛最终判断还是需要人工。手写笔记识别我试了几张手写笔记的照片识别率一般。工整的印刷体没问题潦草的手写体错误率比较高。这个场景建议还是用专门的 OCR 工具。5.4 和其他本地模型的对比感受我同时也在用 Llama 系列和 Qwen 系列的本地版本简单说一下 Gemma 4 的差异。和 Llama 3 相比Gemma 4 的多模态能力是明显优势Llama 3 的纯文本版本在多语言任务上更强一些。如果你主要做中文任务Qwen 系列可能更合适因为它的中文语料更丰富。Gemma 4 的中文能力比上一代好很多但和专门优化中文的模型比还是有差距。和 Qwen 2.5 相比Gemma 4 在英文任务和代码任务上互有胜负Qwen 2.5 的中文理解和生成更自然。MoE 架构上Gemma 4 的 26B MoE 和 Qwen 2.5 的 MoE 版本思路类似实际表现也接近。选择建议如果你的场景以英文为主、需要多模态、看重开源协议Gemma 4 是很好的选择。如果以中文为主、不需要多模态Qwen 系列可能更合适。如果要做微调Gemma 4 的 Apache 2.0 协议让你没有后顾之忧。6. 关于本地大模型的一些个人体会我从最早用 8G 显卡硬跑 7B 模型开始到现在家里两台机器分别跑不同尺寸的模型中间踩过的坑不少。最大的感受是本地跑大模型这件事硬件门槛在下降但软件门槛还在。Ollama 这类工具已经把门槛降得很低了但遇到问题的时候还是需要一些基础知识才能排查。另一个感受是不要追求一步到位。很多人一上来就想跑最大的模型结果显存不够、速度太慢体验很差就放弃了。正确的做法是从小模型开始先跑通流程再根据自己的硬件和需求逐步升级。Gemma 4 的 4B 版本在 8G 显存的机器上就能跑体验已经比很多在线服务好了。还有一点本地部署的价值不在于替代在线服务而在于补充。在线服务在模型能力、响应速度、稳定性上通常更好但本地部署在隐私、成本、可控性上有优势。我的做法是日常问答用本地模型复杂任务用在线服务敏感数据绝对不走云端。这样组合下来既保证了效率又兼顾了隐私。最后说一个实际的小技巧给模型写一个好的系统提示。Gemma 4 对系统提示的遵循度不错你可以在系统提示里定义它的角色、输出格式、语言风格。比如“你是一个技术文档助手回答要简洁代码示例用 Markdown 格式”这样出来的结果会规整很多。这个技巧在 Ollama 里通过 Modelfile 实现在 vLLM 里通过 messages 数组的第一条 system 消息实现。花十分钟调好系统提示后面能省很多事。 
长河君 · 2026/9/19 22:11:32 · 阅读 1.2k Gemma 4本地部署实战：Ollama与vLLM部署及多模态应用指南
1. 为什么 Gemma 4 让本地部署这件事突然变得靠谱了本地跑大模型这件事喊了不是一年两年了。从最早拿一张 8G 显存的卡硬塞 7B 模型到后来量化技术成熟、消费级显卡能跑 13B再到现在动不动就有人在家里用 4090 跑 70B 量化版——这条路走得不算快但每一步都踩得很实。Gemma 4 发布之后我身边好几个之前一直观望的朋友都开始动手了原因很简单开源协议终于不再是绊脚石了。之前很多模型权重虽然能下载但协议里总藏着一些让人心里没底的东西——商用限制、用户量门槛、衍生模型条款。你拿来做个人项目可能没人管但一旦想放到产品里或者在公司内部用法务那边就过不去。Gemma 4 这次直接上了Apache 2.0这个协议在开源圈子里什么地位不用我多说基本上就是“你随便用出了事别找我”的意思。对于想正经把大模型集成到工作流里的人来说这一条比模型本身涨了多少分都重要。那 Gemma 4 到底能干什么简单说它是一个多模态大模型系列覆盖了从轻量级到中等规模的多个尺寸支持文本、图像输入部分版本还能处理音频。你可以在自己的笔记本上跑一个 4B 左右的版本做日常问答和文档摘要也可以在台式机上跑 26B 的 MoE 版本做更复杂的推理任务。MoE 架构的好处是推理时只激活一部分参数所以实际计算量比同等总参数量的稠密模型小很多显存占用和速度都更友好。适合谁来参考这篇内容如果你是有一定命令行基础、想在自己电脑上跑大模型但不知道从哪下手的人这篇就是写给你的。如果你已经在用 Ollama 或者 vLLM 部署过其他模型想看看 Gemma 4 值不值得换我也会把对比和实测数据放出来。如果你只是好奇“本地跑大模型到底能干嘛”我也会用实际场景告诉你这东西现在到底能做到什么程度。我自己的测试环境是一台 Windows 台式机显卡是 RTX 4070 Ti Super 16G内存 64G另外还有一台 MacBook Pro M3 Pro 36G 用来做对比。下面所有操作和结论都基于这两个环境你可以根据自己的硬件情况做调整。2. 部署方案怎么选Ollama、vLLM 还是直接上 transformers2.1 三种主流路线的适用场景对比本地跑大模型目前主流就三条路Ollama、vLLM、直接调 transformers。这三个不是互相替代的关系而是对应不同需求层次。我先把结论摆出来再解释为什么。方案适合场景上手难度推理速度显存效率多模态支持Ollama个人日常使用、快速体验极低中等中等部分支持vLLM服务化部署、多并发请求中等高高看版本transformers研究、微调、深度定制较高低低完整支持Ollama 的优势在于开箱即用。你下载安装包一行命令拉模型再一行命令跑起来整个过程不超过五分钟。它内部帮你处理了量化、显存分配、对话模板这些事情你不需要关心底层用了什么推理引擎。缺点是灵活性差你想改个采样参数或者换个量化精度能调的选项有限。vLLM 是冲着生产环境去的。它的 PagedAttention 技术能把显存利用率拉高很多并发请求下的吞吐量比朴素实现高出一个数量级。如果你想让局域网里几个人同时用同一个模型或者想把它接进自己的应用里做 API 服务vLLM 是首选。代价是配置稍微麻烦一点需要自己处理模型格式转换和环境依赖。直接上 transformers 就是研究路线了。你想做微调、想改模型结构、想深入看每一层的输出那就得走这条路。速度慢、显存占用高但控制力最强。Gemma 4 发布当天 Hugging Face 上就有权重了transformers 版本跟进得很快。提示如果你只是想在本地体验一下 Gemma 4 的多模态能力别犹豫直接 Ollama。如果你打算把它做成一个内部工具给团队用直接看 vLLM 部分。2.2 为什么我最终选了 Ollama 做主力我三个方案都试了一遍最后日常使用的主力是 Ollama。原因不复杂我的使用场景是个人问答、文档摘要、代码辅助不需要并发不需要服务化。Ollama 的响应速度对我来说完全够用而且它管理模型的方式很干净——拉下来的模型统一放在一个目录里切换模型就是换个名字的事。vLLM 我也配好了跑在另一台机器上做 API 服务主要是给家里的其他设备调用。但日常坐在电脑前干活的时候我还是直接开 Ollama 的交互界面。这不是说 vLLM 不好而是工具要匹配场景。你让一个每天就问几个问题的人去维护一套 vLLM 服务属于过度工程。transformers 那条路我用来做了一些对比测试比如看 Gemma 4 在不同量化精度下的输出差异。这个后面会细说。2.3 硬件门槛到底在哪很多人关心的是“我这台电脑能不能跑”。我直接给一个粗略的判断标准8G 显存可以跑 4B 级别的量化版本速度尚可上下文长度受限12G 显存可以跑 9B 左右的量化版本日常使用比较舒服16G 显存可以跑 26B MoE 的量化版本这是 Gemma 4 比较甜点的配置24G 及以上可以跑更大尺寸或者更高精度的版本或者做微调内存方面至少 32G因为模型加载和推理过程中会有额外的内存开销。如果你的显存不够Ollama 会自动把部分层卸载到内存里跑速度会慢很多但至少能跑起来。Mac 用户这边M 系列芯片的统一内存架构反而有优势。36G 的 M3 Pro 跑 26B MoE 量化版比我的 4070 Ti Super 还稳因为显存和内存是一体的不存在卸载的问题。速度上略慢一点但体验更连贯。3. Windows 下从零部署 Gemma 4 的完整实操3.1 安装 Ollama 和拉取模型Windows 下安装 Ollama 没什么好说的去官网下载安装包双击下一步完事。安装完成后打开 PowerShell 或者 Windows Terminal输入ollama --version看到版本号就说明装好了。然后拉取 Gemma 4 的模型。这里要注意Gemma 4 有多个尺寸命名规则一般是gemma4:尺寸-量化等级。我建议先从 4B 的默认量化版本开始ollama pull gemma4:4b这个命令会下载大约 3-4G 的文件取决于量化等级。下载完成后直接跑ollama run gemma4:4b你会看到一个交互式提示符直接输入问题就行。第一次加载模型会花几秒钟把权重读进显存之后每次响应就很快了。如果你想跑 26B MoE 版本命令是ollama pull gemma4:26b-moe这个下载量大概在 15-18G 左右取决于量化版本。我的 16G 显存跑这个版本Ollama 会自动做部分卸载速度大概在每秒 15-20 个 token日常对话完全够用。注意Ollama 默认的模型存储路径在 C 盘如果你 C 盘空间紧张可以先设置环境变量OLLAMA_MODELS指向其他盘符。这个变量在系统设置里加就行不用改配置文件。3.2 多模态输入的配置和测试Gemma 4 的多模态能力是这次升级的重点之一。Ollama 对多模态的支持是通过--image参数或者直接在对话里引用图片路径来实现的。我实测下来在交互模式下可以这样用ollama run gemma4:4b 请描述这张图片的内容/path/to/your/image.jpg模型会读取图片并给出描述。我试了几张不同类型的图片——风景照、代码截图、表格截图——识别准确率相当不错。代码截图能读出大致的语言和结构表格截图能提取出大部分数据风景照的描述比较泛但基本准确。如果你要通过 API 调用多模态Ollama 的 API 格式是这样的curl http://localhost:11434/api/generate -d { model: gemma4:4b, prompt: 描述这张图片, images: [base64编码的图片数据] }图片需要转成 base64 编码。这个在 Python 里用base64库两行代码就能搞定。我写了一个小脚本做批量图片描述跑了几百张图整体稳定性很好没有出现崩溃或者显存泄漏的情况。3.3 用 vLLM 搭建 API 服务的详细步骤如果你需要服务化部署vLLM 是更好的选择。Windows 下 vLLM 的安装稍微麻烦一点因为它对 CUDA 版本有要求。我建议用 WSL2 来跑比直接在 Windows 上折腾省事得多。在 WSL2 的 Ubuntu 环境里先装好 CUDA 驱动和 Python 环境然后pip install vllmGemma 4 的权重可以从 Hugging Face 下载也可以用 vLLM 直接在线拉取。启动服务的命令python -m vllm.entrypoints.openai.api_server \ --model google/gemma-4-9b-it \ --dtype auto \ --max-model-len 8192 \ --gpu-memory-utilization 0.9这里几个参数解释一下。--dtype auto让 vLLM 自动选择合适的数据类型一般是 bfloat16 或者 float16。--max-model-len控制最大上下文长度设得越大显存占用越高8192 是一个比较平衡的值。--gpu-memory-utilization 0.9表示用 90% 的显存来加载模型和 KV Cache留 10% 给系统和其他进程。启动之后vLLM 会暴露一个兼容 OpenAI API 格式的接口默认端口 8000。你可以用任何 OpenAI 客户端来调用from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keydummy) response client.chat.completions.create( modelgoogle/gemma-4-9b-it, messages[{role: user, content: 你好}] ) print(response.choices[0].message.content)我实测下来vLLM 在并发 4 个请求的情况下总吞吐量比 Ollama 单请求模式高出三倍多。如果你只是自己用这个差距感知不明显但如果有多个设备或者多个用户同时访问vLLM 的优势就体现出来了。3.4 量化版本的选择和实测对比Gemma 4 的量化版本主要有 Q4_K_M、Q5_K_M、Q8_0 这几种。数字越大精度越高文件也越大。我在 4070 Ti Super 上做了对比测试用同一组问题分别跑不同量化版本记录响应质量和速度。量化版本文件大小显存占用生成速度质量主观评分Q4_K_M约 2.5G约 3.5G45 tok/s8/10Q5_K_M约 3.2G约 4.2G38 tok/s8.5/10Q8_0约 5.1G约 6.5G28 tok/s9/10Q4_K_M 和 Q5_K_M 的差距在日常对话中几乎感觉不到但在需要精确推理的任务上——比如数学计算或者代码生成——Q5 明显更稳。Q8_0 的质量最好但速度下降比较明显。我的建议是日常使用 Q4_K_M 就够了做正经工作用 Q5_K_MQ8_0 除非你有特殊需求否则没必要。26B MoE 版本的量化选择逻辑类似但因为 MoE 架构的特性量化对质量的影响比稠密模型小一些。我跑 Q4_K_M 的 26B MoE在很多任务上的表现比 Q8_0 的 9B 稠密版还好速度也更快。这就是 MoE 的优势所在。4. 实际使用中会遇到的问题和排查方法4.1 显存不足的典型表现和处理显存不足是本地部署最常见的问题。表现一般是模型加载到一半卡住、推理过程中突然报错、或者系统变得极其卡顿。Ollama 在显存不足时会自动把部分层卸载到内存但这个过程不是无感的——你会看到生成速度断崖式下降。判断是不是显存问题最直接的方法是看任务管理器里的 GPU 显存占用。如果接近满载那就是了。解决办法有几个换更小的量化版本从 Q5 降到 Q4显存占用能减少 20% 左右缩短上下文长度Ollama 可以通过--num-ctx参数控制默认是 2048设成 1024 能省不少显存关闭其他占用显存的程序浏览器、游戏、视频播放器都会占显存跑模型之前最好关掉设置OLLAMA_GPU_LAYERS环境变量手动控制卸载到 GPU 的层数找到一个速度和显存的平衡点我自己的经验是16G 显存跑 26B MoE 的 Q4_K_M把上下文设成 4096GPU 层数设成 28剩下的卸载到内存速度大概在 12-15 tok/s可以接受。如果你追求速度那就得降模型尺寸或者升硬件。4.2 模型输出质量不稳定的排查思路有时候你会发现模型突然开始胡言乱语或者回答质量明显下降。这种情况一般不是模型本身的问题而是对话模板或者采样参数出了问题。Gemma 4 有自己特定的对话模板格式如果你通过 API 调用时没有正确设置模型可能会把系统提示和用户输入混淆。Ollama 内部帮你处理了模板但如果你用 transformers 直接加载就需要自己确保格式正确。检查方法是看模型的 tokenizer 配置里有没有chat_template字段。采样参数方面temperature 设得太高会导致输出发散。Gemma 4 的推荐 temperature 是 0.7 左右top_p 0.9top_k 40。如果你做的是需要确定性的任务比如代码生成或者数据提取把 temperature 降到 0.2 甚至 0.1 会稳定很多。还有一个容易被忽略的点是上下文长度超限。当对话历史超过模型的最大上下文长度时有些实现会直接截断有些会报错。Ollama 默认会保留最近的若干轮对话但如果你手动拼接了很长的 prompt就可能出问题。养成习惯长对话定期清理或者开新会话。4.3 多模态输入常见错误和解决多模态输入报错主要集中在图片格式和大小上。Gemma 4 支持的图片格式包括 JPEG、PNG、WebP 等常见格式但图片尺寸太大会导致显存暴涨。我试过一张 4000x3000 的照片直接让 16G 显存爆了。解决办法是在输入前把图片缩放到合理尺寸一般长边不超过 1024 像素就够了。另一个常见问题是图片编码错误。通过 API 传图片时base64 编码不能有换行符或者多余的空格。Python 的base64.b64encode()默认不会加换行但如果你从文件读取时用了readlines()就可能引入问题。用read()一次性读取二进制数据再编码基本不会出错。如果模型对图片内容识别不准可以尝试在 prompt 里给一些引导。比如“这是一张代码截图请提取其中的函数名”比“描述这张图片”能得到更精确的结果。Gemma 4 的多模态理解能力在同类尺寸的模型里算不错的但它毕竟不是专门的 OCR 模型对密集文字的识别还有提升空间。4.4 性能调优的几个实用技巧想让 Gemma 4 跑得更快有几个立竿见影的调整第一用 GPU 而不是 CPU。这个不用多说差距是数量级的。确保 Ollama 检测到了你的显卡ollama run的时候看日志里有没有CUDA或者Metal的字样。第二调整批处理大小。vLLM 里可以通过--max-num-batched-tokens来控制设大一点能提高吞吐但会增加显存占用和首 token 延迟。我一般设成 4096平衡得比较好。第三用更快的存储。模型加载速度受硬盘影响很大NVMe SSD 比 SATA SSD 快一倍以上比机械硬盘快一个数量级。如果你经常切换模型这个差距很明显。第四关掉不必要的后台程序。浏览器是显存和内存大户跑模型的时候关掉能腾出不少资源。我实测关掉 Chrome 之后26B MoE 的生成速度从 12 tok/s 提升到了 16 tok/s。5. Gemma 4 在实际场景中到底能做什么5.1 文档摘要和知识提取这是我用得最多的场景。把一份几十页的 PDF 转成文本丢给 Gemma 4 做摘要效果比我预期的好。4B 版本就能抓住主要论点26B MoE 版本能给出更结构化的摘要甚至能按照我指定的格式输出。具体操作上我一般会把长文档切成 2000 字左右的片段分别做摘要然后再把摘要合并做二次摘要。这样做的原因是模型的上下文长度有限一次性塞太多内容反而会丢失细节。切分的时候注意按段落或者章节切不要从句子中间断开。知识提取方面Gemma 4 对结构化信息的抽取能力不错。我试过从合同文本里提取甲乙方、金额、日期这些字段准确率在 90% 以上。对于格式比较规范的文档基本可以直接用。格式混乱的就需要加一些 few-shot 示例来引导。5.2 代码辅助和调试Gemma 4 在代码任务上的表现比上一代有明显提升。我主要用它做三件事解释代码、生成单元测试、排查报错。解释代码这个场景4B 版本就够用了。把一段函数贴进去问“这段代码在做什么”它能给出比较准确的描述。生成单元测试的话26B MoE 版本更好它能考虑到更多的边界情况。排查报错是我觉得最实用的——把错误信息和相关代码一起贴进去它经常能指出问题所在比我自己翻文档快。不过要注意Gemma 4 不是专门的代码模型在复杂算法题上不如专门的代码大模型。日常的脚本编写、bug 修复、代码审查这些任务它完全能胜任。但如果你要做 LeetCode 难题或者复杂的系统设计还是得用更大的模型或者专门的代码模型。5.3 多模态场景的落地尝试多模态是 Gemma 4 的亮点我试了几个实际场景截图问答截一张软件界面问“这个按钮在哪”模型能根据截图给出位置描述。这个在写操作手册或者做教程的时候很有用。图表解读把数据图表截图丢进去问“这个趋势说明了什么”模型能给出基本的趋势分析。对于简单的折线图和柱状图解读准确率不错。复杂的多轴图表就需要更详细的引导。图片内容审核批量跑图片让模型判断内容类型和是否包含敏感元素。这个场景对准确率要求高Gemma 4 的表现中规中矩适合做初筛最终判断还是需要人工。手写笔记识别我试了几张手写笔记的照片识别率一般。工整的印刷体没问题潦草的手写体错误率比较高。这个场景建议还是用专门的 OCR 工具。5.4 和其他本地模型的对比感受我同时也在用 Llama 系列和 Qwen 系列的本地版本简单说一下 Gemma 4 的差异。和 Llama 3 相比Gemma 4 的多模态能力是明显优势Llama 3 的纯文本版本在多语言任务上更强一些。如果你主要做中文任务Qwen 系列可能更合适因为它的中文语料更丰富。Gemma 4 的中文能力比上一代好很多但和专门优化中文的模型比还是有差距。和 Qwen 2.5 相比Gemma 4 在英文任务和代码任务上互有胜负Qwen 2.5 的中文理解和生成更自然。MoE 架构上Gemma 4 的 26B MoE 和 Qwen 2.5 的 MoE 版本思路类似实际表现也接近。选择建议如果你的场景以英文为主、需要多模态、看重开源协议Gemma 4 是很好的选择。如果以中文为主、不需要多模态Qwen 系列可能更合适。如果要做微调Gemma 4 的 Apache 2.0 协议让你没有后顾之忧。6. 关于本地大模型的一些个人体会我从最早用 8G 显卡硬跑 7B 模型开始到现在家里两台机器分别跑不同尺寸的模型中间踩过的坑不少。最大的感受是本地跑大模型这件事硬件门槛在下降但软件门槛还在。Ollama 这类工具已经把门槛降得很低了但遇到问题的时候还是需要一些基础知识才能排查。另一个感受是不要追求一步到位。很多人一上来就想跑最大的模型结果显存不够、速度太慢体验很差就放弃了。正确的做法是从小模型开始先跑通流程再根据自己的硬件和需求逐步升级。Gemma 4 的 4B 版本在 8G 显存的机器上就能跑体验已经比很多在线服务好了。还有一点本地部署的价值不在于替代在线服务而在于补充。在线服务在模型能力、响应速度、稳定性上通常更好但本地部署在隐私、成本、可控性上有优势。我的做法是日常问答用本地模型复杂任务用在线服务敏感数据绝对不走云端。这样组合下来既保证了效率又兼顾了隐私。最后说一个实际的小技巧给模型写一个好的系统提示。Gemma 4 对系统提示的遵循度不错你可以在系统提示里定义它的角色、输出格式、语言风格。比如“你是一个技术文档助手回答要简洁代码示例用 Markdown 格式”这样出来的结果会规整很多。这个技巧在 Ollama 里通过 Modelfile 实现在 vLLM 里通过 messages 数组的第一条 system 消息实现。花十分钟调好系统提示后面能省很多事。