这段时间一直在折腾本地大模型，前后试了好几个方案，最后稳定下来的一套组合就是 Windows 上跑 Ollama，用 Qwen3.5-9B 做主力模型。除了写这篇教程分享给同样想入坑的朋友，也想把我在部署过程中踩过的坑、算过的账、调过的参数一次性整理清楚——因为网上的碎片教程太多了，但大多数只说“怎么装”，不讲“为什么这么选”“出了问题怎么办”，结果就是把门槛看似降低了，实际上新手该卡住的地方一个都没少。
如果你是第一次在 Windows 上搞本地大模型，完全没碰过 Linux，也没配过 Python 环境，这篇照着做就行。文中的所有命令、参数、排查思路，都是我在实际机器上一遍遍试出来的，属于那种“拿走就能用”的落地经验。
1. 为什么选 Ollama + Qwen3.5-9B：这套组合解决了什么问题
1.1 本地部署的核心痛点：隐私、成本、断网可用
先说清楚一个事：你为什么要费劲在本地跑模型，而不是直接用网页版或者在线 API？
我的理由很简单，三条。第一，数据隐私。对话内容会出网这件事，对很多场景是致命的，比如处理个人财务信息整理、写未公开项目的技术文档、分析一份公司内部数据，你绝对不希望这些东西经过第三方服务器。第二，成本。在线 API 是按 token 计费的，长对话、批量文档处理，一个月下来不是小数目。本地部署是一次性硬件投入，模型文件免费下载，之后调多少次都不再花钱。第三，可用性。断网的时候，在线服务全废，本地模型照样跑，出差在高铁上、网络不稳的会议室里，该干活还是干活。
1.2 为什么用 Ollama 而不是直接装 Python 推理框架
很多人一听说“本地部署大模型”，第一反应是去配 Python、PyTorch、CUDA 这一套，然后再用 Transformers 库把模型拉下来跑推理。这套路在 Linux 上还好，在 Windows 上真的是一言难尽——光是版本兼容问题就能耗掉一下午。
Ollama 把这一切都打了包。它是专门为本地模型部署设计的运行环境，把框架依赖、量化策略、推理服务、内存管理全部内置好了。你不需要知道它内部用的是哪一个推理引擎，也不需要关心模型文件以什么精度存储，只需要两条命令：一条拉模型，一条跑对话。尤其是 Windows 用户，Ollama 对系统的侵入性很低，卸载也干净，不会在你机器上留下一堆乱七八糟的依赖。
另外，Ollama 自带一个类 OpenAI 的 API 接口，部署完成后你写的任何脚本都能通过 HTTP 请求调用模型，这给后面的自动化留了很大的空间，不只是一次性的“聊天玩具”。
1.3 Qwen3.5-9B 这个模型定位：性价比很合适的“个人主力”
9B 这个参数量，放在现在的开源模型里属于什么水平？比它小的 1.5B、3B 模型，处理简单任务还行，一旦涉及逻辑推理、代码生成、长文本理解，明显力不从心。比它大的 14B、32B 甚至 72B 模型，能力更强，但对硬件的要求直线上升，普通人一台电脑基本告别了。
Qwen3.5-9B 刚好卡在一个让我很舒服的点上：推理能力、中文水平、指令遵循能力都足够日常使用，量化之后的内存占用又压在普通消费级硬件能承受的范围里。类似的 8B、9B 级开源模型有好几个，但 Qwen3.5 系在中文场景的表现一直很稳，这也是我最终把它定为“日常主力”的原因。
2. 硬件摸底：9B 模型到底需要什么配置，以及怎么算显存
2.1 基础概念：FP16、INT8、INT4 这些量化级别到底是什么
在选硬件之前，你至少得懂一个概念：模型参数在硬盘/内存里不是只用一种精度存储的。
原始模型训练出来，参数一般用 FP16（16位浮点数）保存，一个 90 亿参数的模型，光参数文件就是 90 × 2 = 180 亿字节，换算下来约 18GB。普通人的显卡显存根本没这么大，所以 Ollama 在加载模型时会做一层“量化”——先把参数精度降低，用更少的比特数去近似表达每个参数，模型体积和控制内存占用都会大幅下降。
常见的量化格式有三种：Q4 系列（约 4bit/参数）、Q5 系列（约 5bit/参数）、Q8 系列（约 8bit/参数）。量化位越低，内存占用越小，精度损失越大；位越高，质量越好，硬件压力越大。以 9B 模型为例，不同量化等级的内存需求大致如下：
| 量化等级 | 参数精度 | 模型文件大小 | 加载时内存占用估算 | 设备要求 |
|---|---|---|---|---|
| Q4_K_M | 约 4bit | 5.2GB 左右 | 6GB 及以上 | 6GB 显存及以上 |
| Q5_K_M | 约 5bit | 6.1GB 左右 | 7GB 及以上 | 8GB 显存较稳 |
| Q8_0 | 约 8bit | 9.8GB 左右 | 11GB 及以上 | 12GB 显存较稳 |
| FP16 | 16bit | 18GB 左右 | 20GB 及以上 | 基本劝退大部分家用机 |
Ollama 默认拉取的一般是 Q4 系版本，这也是目测性能和硬件需求之间比较平衡的选择。如果你机器配置一般，就老老实实跑默认版本；如果你显存很大，再考虑手动指定 Q8 或 FP16 标签。
2.2 显存、内存、硬盘三者的分工
很多人搞混一个事情：模型跑起来到底占用的是哪块存储？
简单说，模型文件存在硬盘上，是安装包；加载时会被读入显存（GPU 运行时）或内存（CPU 运行时），这部分是实际干活用的空间；如果显存不够，Ollama 会把部分层放在内存里，用 CPU 计算，但速度会明显下降。
我自己的经验公式是这样的：想要流畅跑 Q4 量化后的 9B 模型，至少要有 8GB 显存或者 16GB 内存，二选一够用，两个都够那是最好。硬盘空间留 15GB 以上比较稳妥，因为模型下载需要临时空间，后续你还可能下其他模型。
举两个具体例子。第一台机器：8GB 显存 + 16GB 内存。这种配置跑 Q4 量化版很舒服，默认的 2048 上下文窗口下，生成速度能到每秒 20 到 35 个 token。第二台机器：没有独立显卡，纯 32GB 内存。跑同样模型，CPU 模式也能出结果，但速度会掉到每秒 4 到 8 个 token，干简单问答可以，写长文就有点煎熬了。
2.3 纯 CPU 到底能不能跑，值不值得试
纯 CPU 跑 9B 模型，我的结论是：可以跑，但只适合“偶尔问一两个问题”的场景。为什么速度会慢这么多？因为大模型推理的矩阵乘法，天生就是为 GPU 的并行架构设计的，CPU 的核心数量和计算方式都不适合这种工作负载。
实测也是这样：同一台机器，GPU 模式下生成一个 200 字的回复只需要十几秒，切到 CPU 模式可能要两三分钟，体验差别非常明显。所以我给新手的建议是：先看自己的显卡显存，6GB 以下可以直接放弃 GPU 路线转纯 CPU 尝鲜，但别抱太高期望；6GB 到 8GB 是目前最舒服的起步值；12GB 以上基本可以做到“指哪打哪”。
3. Windows 安装 Ollama 的完整过程：从下载到跑通
3.1 下载安装包时容易忽视的几个细节
安装 Ollama 其实很简单，去官网下载 Windows 安装包，双击，一直下一步，装完就完事。但有几个细节我建议你多留个心眼：
第一个是安装路径。默认装到 C 盘，而模型文件默认也在 C 盘用户目录下。如果你的 C 盘剩余空间不足，后面拉模型时会直接显示磁盘空间不足，很尴尬。我习惯在一开始就把安装目录改到数据盘。
第二个是系统版本。Ollama 对 Windows 版本的最低要求不算高，Win10 较新的版本都能装，但如果你是那种常年不更新的 Windows 10 老系统，可能会遇到服务启动失败的情况，先检查系统更新再装。
第三个是“安装完成后是否立刻启动”。安装向导最后一步通常会让它直接运行，建议先不勾选，因为安装完的第一件事，是要先把模型存储路径改好，免得模型文件已经下到 C 盘了再折腾迁移。
安装完成后，它会在系统服务列表里注册一个后台服务，也就是说开机就自动运行，你随时打开命令行都能直接用，不需要每次手动启动。
3.2 安装后的第一件事：确认服务正常
装完之后，打开一个新的命令提示符或者 PowerShell 窗口，执行：
ollama --version如果显示版本号，说明安装成功。再执行一条：
ollama list这条命令是查看本地已有的模型列表，现在应该是空的，没关系，能正常返回不报错就行。如果这两步就走不下去了，多半是后台服务没起来，可以试试重新打开命令行窗口，或者重启一次系统。
3.3 修改模型存储路径：把大文件挪到数据盘
模型文件动辄好几个 GB，全放在 C 盘是迟早会炸的。Ollama 允许我们通过修改系统环境变量来改变模型文件的存放目录，以下是完整操作：
- 打开系统设置 → 高级系统设置 → 环境变量
- 在“系统变量”区域点击新建，变量名为
OLLAMA_MODELS，变量值填你准备存放模型文件的完整路径，比如D:\ollama\models - 设置完环境变量后，务必重启系统，或者至少注销再登录一次
设置好之后，之后所有拉取的模型文件都会落到这个新目录里，C 盘负担小很多。这一步强烈建议在第一次拉模型之前就做完，否则模型已经下到 C 盘了，你还得手动移动，非常麻烦。
3.4 验证安装：跑通一次完整的模型加载
模型还没下，怎么验证？其实安装完成后你先不用着急拉 Qwen3.5-9B，可以先拿一个极小的模型试运行，比如 0.5B 级别的测试模型：
ollama run qwen3:0.6b这一步的意义是：验证整个运行链路通不通，模型能不能正常加载，输出是否流畅。它体积小，下载快，就算出问题也不会浪费太多时间。等这台机器确认能跑通之后，再替换成 9B 正式模型，心境完全不一样。
我第一次搞的时候直接上 9B，结果因为之前路径没改好，一边下载一边往 C 盘灌，最后 C 盘满了报错，还得清盘重来。这种低级错误完全可以在 0.6B 阶段提前发现。
4. 拉取并运行 Qwen3.5-9B：命令行实操与参数选择
4.1 拉取模型：命令格式与标签选择逻辑
确认环境没问题后，正式拉取 Qwen3.5-9B 模型。命令非常简单：
ollama pull qwen3.5:9b如果你在模型仓库页面看到还有其他标签，比如qwen3.5:9b-q4_K_M、qwen3.5:9b-q8_0之类的，它们对应不同的量化精度。命令里的:9b默认会拉取官方推荐的“平衡版”，对大部分人来说就是最合适的那个，不用太纠结。
拉取过程会有进度条，因为模型文件比较大，第一次下载可能要等几分钟到十几分钟，取决于网络情况。下载完成后执行ollama list就能看到这个模型已经在列表里了。
4.2 启动对话：两种方式各有适用场景
方式一：交互式对话模式。直接输入：
ollama run qwen3.5:9b进去之后就是一个类似聊天的命令行界面，你输入什么它回答什么。输入/bye可以退出会话，输入/clear可以清空当前对话历史。这种模式适合临时问问题、快速验证模型效果。
方式二：通过 API 调用。Ollama 启动时会默认在本机开一个服务，监听在11434端口。你可以在另一个命令行窗口用curl测试：
curl http://localhost:11434/api/generate -d "{\"model\":\"qwen3.5:9b\",\"prompt\":\"用一句话介绍你自己\"}"返回的 JSON 里就包含模型生成的答案。推荐的做法是后面写脚本时直接走这个 HTTP 接口，灵活度比交互式命令行高得多，可以做批处理、接其他应用。
4.3 关键运行参数：上下文长度、温度、GPU 层数
交互模式下的默认参数是“能用但不算最优”的初始状态。真到自己用顺的时候，有几个参数值得手动调。
第一个是上下文长度。默认的num_ctx一般是 2048，也就是模型最多只能“记住”大约 2000 多个 token 的历史对话内容。如果你经常做长文分析、多轮复杂对话，2048 会明显感觉“失忆”，这时候可以临时调高，例如 8192。代价是显存占用增加、生成速度略降。
第二个是温度temperature。这个参数控制回答的随机性：数值越高回答越发散，越低越发保守。我日常做技术问答、代码解释，把它调到 0.6 左右比较合适；如果就是想聊聊天、找点灵感，可以拉到 0.9 到 1.0。
第三个是 GPU 层数。如果你显存不大，又想强行跑大模型，可以通过设置num_gpu让部分网络层跑 GPU、部分跑 CPU 来降低显存压力，例如指定 20 层放 GPU，剩下的交给 CPU。不过这种混合模式速度提升有限，更推荐直接选择更低的量化等级。
在交互模式下，可以通过/set parameter num_ctx 8192这种命令临时设置；如果想把参数固化下来，更推荐通过 API 请求时带上 options 字段，这样每次调用都是同样的参数。
4.4 首次运行的正常与异常现象
首次运行 9B 模型，加载时间会比较长，大概要等十几秒，你可能会看到磁盘狂转、风扇起飞，这些属于正常现象，因为它在把好几个 GB 的参数从硬盘读入显存。
如果加载完成后，你输入第一句提问，发现回复速度很慢或者长时间没动静，先不要急。在纯 CPU 模式下，9B 模型生成第一个字可能就需要好几秒，这是硬件瓶颈，不是模型卡死。还有一点，如果你输入完问题，命令行一直没有输出，检查一下模型是不是还在“想”而不是“卡”了，可以通过显卡监控软件查看显存是否被大量占用来判断。
5. 部署完成后的各种坑：完整排查链路
5.1 坑一：模型下载到一半卡住，进度条不动
这个坑我遇到过一次，而且群里也经常有人问。现象是：拉取模型到 60% 左右，进度条长时间不动，最后直接报错。
排查思路是这样的：
- 先判断是不是网络的问题。断网或网络不稳定会让下载中断，先
ping一下外网看看通不通。 - 再查看磁盘空间。模型临时下载文件会占用额外的空间，C 盘满了也可能导致全部下载暂停。用系统自带的磁盘空间查看工具确认一下。
- 如果空间充足，最狠的一招是删除本地未下载完的残留，重新拉取。
我这里说的网络问题，是指访问模型仓库的网络状况。如果你在下载模型时遇到速度慢到几乎不动，除了换个时间断重新下，也可以试试让 Ollama 使用系统配置好的自定义网络设置，有时候能有明显改善。
5.2 坑二：显存不足，一跑就 OOM 或直接闪退
如果显卡显存只有 4GB，跑默认 Q4 量化 9B 模型会非常吃力，现象是对话框刚加载完模型，输入一句话，程序直接退出，或者系统提示显存不足。
排查链路如下：
- 先确认模型到底是什么量化版。执行
ollama list看一下模型标签，确认是不是默认 Q4 版。 - 如果确认是 Q4 版还跑不动，那就是显存真的不够。解决方向是把模型的量化等级再降到更低，比如一些以极小体积为目标的量化变体，或者干脆换更小的模型，比如 3B 级别。
- 还有一个可以临时救急的办法：在运行命令中限制 GPU 层数，让一部分计算落到 CPU 和内存上。虽然不是最优解，但至少能跑起来。
说实话，如果显卡只有 4GB 显存，我不建议硬刚 9B。把它当“默认硬件不可用”的速度标杆，老老实实换小模型，体验比折腾强得多。
5.3 坑三：中文回答质量差，或者时不时夹杂英文
很多人把 Qwen3.5 系列拉下来以后，发现中文回答并没有想象中好，甚至会出现中英夹杂的情况。
我的排查结论是：大概率不是模型本身的问题，而是使用方式不对。大模型在回答时，会参考你的提问语言和场景。如果你提问用的是英文系统默认风格或者前后文掺杂英文，模型就可能跟着输出英文。强行让它“用中文回答”最直接的方法，是在提问末尾加上“请用中文回答”，或者在系统提示里写好“你是一个中文助手，始终使用中文回复”。
如果加上约束后还是中文差，那才需要考虑是不是量化级别过低导致质量下降，这时候可以试试更高精度的量化版本，比如 Q8 系，质量会明显提升，代价是显存占用变大。
5.4 坑四：后台服务莫名占用端口，或者开机启动反而成了烦恼
Ollama 装完后会在后台启动一个服务，固定监听 11434 端口。有时候你用别的开发工具，比如本地 Web 应用，也占了 8080 之类的端口，两者本来井水不犯河水，但如果你习惯了“所有服务都自己手动启停”，就会觉得一个后台驻留服务挺碍眼的。
我不建议新手去关闭它。因为 Ollama 的 API 服务必须常驻才能让其他脚本和应用随时调用，关了反而制造麻烦。你真正需要做的是记住这个端口号，在排查端口冲突时心里有数：11434 是 Ollama 的，别误杀。
如果你实在不想让它开机自启，可以去系统服务里把 Ollama 的服务启动类型改成“手动”，需要用时再一键启动。这个操作只对“烦恼”有效，不影响模型本身的运行。
6. 部署完之后的进阶玩法：从聊天到自动化工作流
6.1 用 Python 写一个调用本地模型的脚本
模型部署好了，一直停留在“命令行聊天”的水平有点浪费。我建议下一步做一个小脚本，用 Python 调 Ollama 的 API 实现“批量文本处理”。
以下是一个任何时候都能跑的骨架脚本，核心就十来行：
import requests import json def ask_ollama(prompt, model="qwen3.5:9b", temperature=0.7): url = "http://localhost:11434/api/generate" payload = { "model": model, "prompt": prompt, "stream": False, "options": { "temperature": temperature, "num_ctx": 8192 } } resp = requests.post(url, json=payload, timeout=300) data = resp.json() return data.get("response", "") if __name__ == "__main__": text = input("输入你想处理的内容：") result = ask_ollama("请对下面的文本做摘要，要求简洁清晰：\n" + text) print(result)这段脚本干了一件很关键的事：把“人工在命令行输入问题”变成了“程序自动传文本、自动拿结果”。你可以把它接入剪贴板工具，实现“选中一段文本，按键调模型总结”；也可以把它接进一个文件夹监听器，实现“文档落入目录后自动分类”。
6.2 让模型成为“团队知识库问答入口”
一个比较实用的思路：把团队的 FAQ 文档、接口说明、历史决策记录整理成几个 Markdown 文件，每次提问前先做检索，把相关段落拼进请求里，再让模型基于这些内容回答。
这样操作之后，模型回答就不再是通用大模型那种“好像什么都懂但什么都不敢保证”的风格，而是变成基于你们自己文档的、有据可查的内容。9B 模型在个人团队级别的知识库场景下，出幻觉的概率是可控的，关键是你要把检索这一步做好，而不是指望模型凭空记住文档。
6.3 进一步优化：换更高量化精度、开长上下文、多模型并存
9B 模型跑顺之后，如果你想“再压榨一下机器性能”，可以做三件事：
第一，尝试更高精度版本。如果你的显存有 12GB 以上，可以拉取 Q8 量化版本，体验一下质量的提升。第二，把上下文长度拉到 8192 或 16384，处理长文本时的连贯性会显著好于默认 2048。第三，多拉一个不同用途的模型并存，比如一个 3B 小模型用来做轻量分类，一个 9B 主力模型用来深聊，一个更大的模型留作“疑难杂症专用”，互不干扰，按需调用。
Ollama 允许你同时安装多个模型，切换时只需要在ollama run后面加上不同模型名即可，非常灵活。
我在实际使用中发现，本地部署大模型最值钱的不是那几条命令，而是“需要私有化的数据终于有了一个能理解的入口”。我现在很多重复性的文本整理、初稿起草、格式转换，都是先拿 Qwen3.5-9B 跑一遍，再人工修改。相比以前全部手工弄，效率提升非常明显。你如果也把这套跑通了，建议日常多挖掘“拿文本给模型做初加工”的场景，很多时候你会惊奇地发现，它可以帮你把最不想干的杂活接过去一大半。
