Qwen3.5-9B本地编程实测：Ollama部署与参数调优指南

1. 为什么我要花一整个周末测这个模型

上周五晚上十一点，我盯着终端里 qwen3.5-9b 吐出来的第 47 行 Python 代码，心里只有一个念头：这玩意儿到底能不能替我把那堆重复的 CRUD 接口写完。作为一个写了十年代码、最近两年把大量精力放在本地模型部署上的老油条，我对"9B 参数级别模型能写代码"这件事一直持保留态度。7B 到 14B 这个区间我踩过太多坑了——要么补全像模像样但一跑就崩，要么逻辑对了但 API 记错版本，要么干脆在思考模式里绕圈子绕到天荒地老。

但 qwen3.5-9b 这个尺寸很微妙。它卡在一个"显存友好"和"能力够用"的甜蜜点上：量化到 q4_k_m 之后大概 6GB 出头，一张 8GB 显存的卡就能跑，甚至 16GB 内存的笔记本用 CPU 推理也能凑合。这意味着它可以直接塞进大多数开发者的本地环境，不依赖任何云端服务。我这次实测的核心目标就三个：第一，它在真实编程任务上的可用率到底有多少；第二，Ollama 部署时那些 temperature、思考模式开关到底怎么调才不翻车；第三，它和那些动辄 30B+ 的模型比，差距是不是真的到了"不能用"的地步。

先说结论方向，免得你看到一半发现不是自己要的：qwen3.5-9b 在结构化代码生成（写函数、写类、写 SQL、写正则）上表现超出我对 9B 的预期，在多文件工程理解和复杂算法推导上会明显吃力，而思考模式是一把双刃剑——用对了场景能救命，用错了场景纯属浪费 token 和时间。下面我把整个测试过程、参数配置、踩的坑和最终的一套"抄作业"配置全部摊开讲。

这篇内容适合三类人：一是手里有张中端显卡、想搞本地编程助手的开发者；二是已经在用 Ollama 但总觉得模型"不太聪明"、想调参的人；三是正在纠结要不要为了写代码专门上一台大显存机器、想先看看 9B 能顶多少事的人。我会尽量把每个参数背后的逻辑讲清楚，而不是甩一堆命令让你自己猜。

2. 测试环境搭建与模型拉取的完整流程

2.1 硬件与软件基线配置

先把底子交代清楚，不然所有性能数据都没有参照意义。我这次用了两台机器做对照：

A 机是主力测试环境，B 机用来验证"纯 CPU 推理到底能不能用"。Ollama 版本用的是 0.5.x 系列，这个版本对 qwen 系列的支持已经比较成熟，尤其是对思考模式标签的解析做了优化。如果你还在用 0.3.x 甚至更早的版本，建议先升级，否则模型输出的thinking标签可能会原样吐到结果里，非常影响体验。

关于 Ollama 的安装，Windows 用户直接下安装包就行，但有个细节很多人忽略：默认安装路径在 C 盘，模型文件也会堆在 C 盘。qwen3.5-9b 的 q4_k_m 大概 6GB，加上你后面可能拉的其他模型，C 盘很快就红了。我的做法是安装前先设置环境变量OLLAMA_MODELS指向 D 盘或外置盘，比如D:\ollama\models。这个变量必须在启动 Ollama 服务之前设置好，装完再改的话，已经下载的模型不会自动迁移，得手动搬。

Linux 用户如果遇到下载慢的问题，可以配置镜像源加速。这里我不展开具体地址，思路是找国内可访问的模型仓库镜像，把OLLAMA_HOST或者拉取源指向镜像即可。实测下来，配好镜像之后拉 6GB 的模型从"半小时起步"变成"几分钟搞定"，体验差距巨大。

2.2 拉取 qwen3.5-9b 并确认量化版本

拉模型这条命令看起来简单，但里面有个坑：

ollama pull qwen3.5:9b

默认拉下来的可能是 q4_0 或者 q4_k_m，取决于 Ollama 的模型库配置。q4_k_m 和 q4_0 的区别在于量化时的分组策略，k_m 版本对权重矩阵的分块更细，精度损失更小，代价是推理速度略慢一点点。对于编程任务，我强烈建议用 q4_k_m，因为代码生成对数值精度比聊天敏感得多——一个 token 的偏差可能导致变量名拼错或者运算符搞混。

拉完之后用这条命令确认：

ollama list

你会看到模型名、ID、大小和修改时间。如果大小在 6GB 左右，基本就是 q4_k_m；如果只有 4GB 多，那可能是更激进的量化，编程能力会打折扣。想强制指定版本的话，可以显式写 tag，比如qwen3.5:9b-q4_k_m，前提是模型库里有这个 tag。

这里插一句关于"模型存放路径"的排查技巧。很多人拉完模型找不到文件在哪，Windows 下默认在C:\Users\你的用户名\.ollama\models，Linux 在/usr/share/ollama/.ollama/models或~/.ollama/models。如果你改了OLLAMA_MODELS环境变量，就去那个路径找。想确认某个模型到底占了多少空间，直接看 blobs 目录里对应的大文件就行。

2.3 验证模型是否正常加载

拉完之后别急着写代码，先做个冒烟测试：

ollama run qwen3.5:9b "用 Python 写一个快速排序，只输出代码"

如果它开始输出thinking标签然后一堆推理过程，说明思考模式默认是开的。这时候你会看到两种输出风格：一种是先想一大段再给代码，另一种是直接给代码。这个差异直接关系到后面的参数调优，先记住这个现象。

3. 编程能力实测：从简单函数到多文件工程

3.1 基础代码生成：函数、类与 SQL

我设计了一组递进式任务，从最简单的开始。第一题是"写一个 Python 函数，输入一个整数列表，返回其中所有偶数的平方，要求用列表推导式"。这题太基础了，qwen3.5-9b 几乎是秒回，代码正确，甚至主动加了类型注解。这个级别的任务对它来说没有挑战。

第二题升级到"写一个线程安全的单例装饰器，支持带参数和不带参数两种用法"。这题开始有坑了，因为带参数和不带参数的装饰器写法不一样，很多人会写混。qwen3.5-9b 第一次给出的版本用了functools.wraps，逻辑基本对，但在判断"是否带参数"时用了一个比较绕的if callable(arg)判断，边界情况处理得不够干净。我追问了一句"如果被装饰的类本身是可调用的呢"，它立刻意识到问题，改成了用*args, **kwargs长度判断的写法。这个交互过程说明它的上下文理解能力是在线的，能根据反馈修正。

第三题是 SQL："有一张订单表 orders，字段有 id、user_id、amount、created_at、status，写一个查询，找出每个用户最近一笔成功订单的金额"。这题考察窗口函数。qwen3.5-9b 用了ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)，然后外层过滤status = 'success'和rn = 1。逻辑完全正确。但我注意到一个细节：它把status过滤放在了窗口函数内部还是外部，第一次写的时候放在了内部，这会导致如果最近一笔订单不是 success，该用户就查不出来。我指出后它改到了外层。这个错误其实很多中级开发者也会犯，说明模型学到的是"常见写法"而不是"绝对正确写法"。

3.2 中等难度：正则、算法与 API 调用

正则题我出的是"匹配一个合法的中国大陆手机号，要求 1 开头，第二位是 3-9，后面 9 位数字"。qwen3.5-9b 给的 pattern 是^1[3-9]\d{9}$，完全正确。我又加码问"如果要同时支持带 +86 前缀和不带前缀两种情况呢"，它给出了^(\+86)?1[3-9]\d{9}$，也对。这个表现让我有点意外，因为正则的边界处理是很多小模型的弱项。

算法题我选了"实现一个 LRU 缓存，要求 get 和 put 都是 O(1)"。这题的标准解法是哈希表加双向链表。qwen3.5-9b 给出的 Python 版本用了OrderedDict，这是 Python 特有的偷懒写法，逻辑正确但不是面试官想看的"手写双向链表"。我要求它"不要用 OrderedDict，手写链表"，它给出的版本节点定义、指针操作、容量淘汰逻辑都写对了，但在删除节点时漏了一个del操作导致内存泄漏隐患。这个级别的 bug 说明它在复杂指针操作上还不够严谨，需要人工 review。

API 调用题我让它"用 requests 写一个带重试和超时控制的 GET 请求封装"。它用了requests.adapters.HTTPAdapter配合Retry，这个写法是生产级的，比简单的for循环重试要专业。超时设置也分了 connect 和 read 两个维度。这题我给高分。

3.3 高难度：多文件工程与框架代码

到了这个级别，qwen3.5-9b 开始露怯了。我给它一个简化的 Flask 项目结构描述，要求它"在现有 users 蓝图里加一个分页查询接口，复用已有的 db session 和 response 工具函数"。它生成的代码语法没问题，但没有正确导入项目里已有的工具函数，而是自己重新定义了一个 response 包装。这说明它对"项目上下文"的理解是缺失的——它不知道你项目里已经有什么，只能基于通用知识生成。

我又试了一个更极端的：给它一段 200 行的 Django view 代码，让它"找出其中的 N+1 查询问题并修复"。它确实指出了for循环里调用obj.related.all()的问题，建议用select_related或prefetch_related。但具体该用哪个，它给的建议不够精准——对于一对多关系应该用prefetch_related，它一开始说成了select_related。这个错误很典型，说明它在框架细节上记忆有偏差。

综合下来，我给 qwen3.5-9b 的编程能力画个像：

4. 思考模式与 temperature 的调参实战

4.1 思考模式到底在思考什么

qwen3.5-9b 的思考模式是通过在输出前插入thinking标签实现的。开启后，模型会先输出一段推理过程，再给最终答案。这个机制对数学题、逻辑题、复杂算法有帮助，因为相当于给了模型一个"草稿纸"。但对简单代码补全来说，纯属浪费时间——你让它写个print("hello")，它可能先想 200 个 token 再输出。

Ollama 里控制思考模式的方式有几种。最直接的是在 prompt 里加指令，比如"不要思考，直接输出代码"。但实测下来，这种方式不稳定，模型有时候会"假装没看见"。更可靠的是用 API 参数。Ollama 的/api/generate接口支持think字段（部分版本叫reasoning），设成false可以强制关闭。命令行下可以用：

ollama run qwen3.5:9b --think=false "写一个冒泡排序"

如果你用的是 OpenAI 兼容接口，可以在请求体里加"think": false。我实测下来，关闭思考模式后，简单代码任务的响应时间从平均 8 秒降到 2 秒左右，token 消耗减少 60% 以上。

但注意，不是所有场景都该关。我测了一道"判断一个数是不是快乐数"的题，开启思考模式时它一次就对了，关闭后它给出的代码在循环终止条件上写错了。原因是快乐数需要检测循环，这个逻辑需要一点推理，思考模式帮它理清了。所以我的建议是：简单生成关思考，算法逻辑开思考。

4.2 temperature 对代码质量的影响

temperature 控制输出的随机性。代码生成这个场景很特殊：你需要一定的多样性来避免陷入死胡同，但又不能太随机导致语法错误。我做了三组对照：

我的结论是0.2 到 0.4 之间最合适，具体看任务。写业务代码用 0.2，写算法用 0.4。设置方式：

ollama run qwen3.5:9b --temperature 0.3 "你的 prompt"

或者在 Modelfile 里固化：

FROM qwen3.5:9b PARAMETER temperature 0.3 PARAMETER think false

然后ollama create my-coder -f Modelfile，以后直接用my-coder就是调好的配置。这个做法我强烈推荐，省得每次敲一长串参数。

4.3 context 长度与显存占用的权衡

Ollama 默认的 context 长度是 2048 或 4096，取决于版本。qwen3.5-9b 支持更长的 context，但context 越长，显存占用越大。我实测在 12GB 显存的 3060 上，context 设到 8192 时，q4_k_m 模型加 KV cache 大概占 9GB 多，还能跑；设到 16384 就接近爆显存了，开始用共享内存，速度断崖式下跌。

调整方式：

ollama run qwen3.5:9b --context 8192 "你的 prompt"

或者在 API 请求里传num_ctx。对于编程任务，我的建议是4096 起步，需要喂大文件时临时调到 8192。超过 8192 的话，考虑换更小的量化版本或者上更大显存的卡。

5. 常见问题排查与避坑经验实录

5.1 模型输出带标签、格式混乱怎么办

这是最常见的问题。表现是输出里混着thinking、<|im_start|>、<|im_end|>这些特殊 token。原因通常是 Ollama 版本和模型模板不匹配。解决办法有三个：升级 Ollama 到最新版；在 Modelfile 里显式指定TEMPLATE；或者用--format json让输出结构化。我遇到过一次，升级到 0.5.7 之后自动就好了。

5.2 下载慢、拉取中断的处理

下载慢是本地部署的头号拦路虎。除了配镜像源，还有个技巧是分批拉取。Ollama 支持断点续传，中断了重新pull会接着下。如果某个 blob 一直卡住，可以手动去模型仓库下载对应的 gguf 文件，然后通过 Modelfile 的FROM ./path/to/model.gguf导入。这个方式适合网络环境特别差的情况。

5.3 显存不够的降级方案

8GB 显存跑 q4_k_m 的 9B 模型其实有点紧。如果爆显存，有几个选择：换 q4_0 量化（省 1GB 左右）；降低 context 到 2048；或者用--num-gpu参数控制放多少层到 GPU，剩下的用 CPU。最后这个方案速度会慢，但至少能跑起来。我在 B 机纯 CPU 上测过，生成速度大概 3-5 token/秒，写个简单函数要等十几秒，应急可以，日常用还是算了。

5.4 常见问题速查表

5.5 几个我踩过的坑

第一个坑：不要用默认的 system prompt。Ollama 默认的 system prompt 比较通用，对编程任务不够聚焦。我建议在 Modelfile 里加一句SYSTEM "你是一个严谨的编程助手，输出代码时不要解释，直接给可运行的代码块"，效果立竿见影。

第二个坑：中文注释会拖慢速度。qwen3.5-9b 对中文支持很好，但生成中文注释比英文慢，而且偶尔会出现中英混杂。如果你不介意，让它用英文注释，速度能快 20% 左右。

第三个坑：别指望它记住整个项目。9B 模型的 context 再长，注意力也是有限的。喂给它超过 3000 行的代码，它就开始"忘事"。正确用法是只喂相关文件，把不相关的模块用一句话描述代替。

6. 我的最终配置与使用建议

折腾了两天，我最终固化的 Modelfile 是这样的：

FROM qwen3.5:9b PARAMETER temperature 0.3 PARAMETER num_ctx 4096 PARAMETER think false SYSTEM "你是一个严谨的编程助手。输出代码时直接给可运行的代码块，不要解释。遇到算法题时先简要说明思路再给代码。"

日常用法分两档：写业务代码、补全函数、写 SQL 用这个配置，快且稳；遇到复杂算法或者需要推理的题，临时用--think=true --temperature 0.4跑一次，拿到思路后再切回来。

关于它和更大模型的取舍，我的真实感受是：qwen3.5-9b 能覆盖我日常 60% 到 70% 的代码生成需求，剩下的 30% 要么是它能力不够，要么是我需要更精准的控制。对于个人开发者、学生、或者想在内网环境搞编程助手的小团队，这个尺寸的模型是性价比极高的选择。它不需要你买昂贵的显卡，不需要联网，数据不出本地，调好了之后确实能省下大量敲重复代码的时间。

最后分享一个我最近发现的小技巧：把常用的代码模板、项目规范、API 文档片段整理成一个context.md，每次提问时用cat context.md | ollama run my-coder的方式喂进去，模型的输出会明显更贴合你的项目风格。这个做法比微调便宜得多，效果却立竿见影。