Qwen3.6-27B 本地代码能力评测（一）

Qwen3.6-27B 本地代码能力评测从零搭建自动化评测框架作者一个本地跑大模型的普通开发者设备单卡 20GB 显存llama.cpp 推理部署时间2026 年 7 月0. 缘起我在本地用 llama.cpp 部署了 Qwen3.6-27B日常测试感觉不错但感觉不错太模糊了。作为一个前程序员我习惯用数据说话——那就给它写一套代码能力评测吧。这个过程中遇到了不少问题从模型输出的格式坑到评测框架的 bug都记录在这篇文章里。1. 环境组件配置模型Qwen3.6-27B推理框架llama.cppOpenAI 兼容 APIAPI 地址http://localhost:8080显存20GB评测脚本Python 3 requests subprocess评测任务15 个覆盖 7 个类别2. 评测方案设计2.1 任务选择选了 15 个任务覆盖日常编程中常见的 7 个类别类别任务难度基础算法斐波那契数列、快速排序⭐字符串处理回文判断、词频统计⭐数据处理JSON 解析筛选、CSV 数据聚合⭐⭐正则表达式邮箱提取、手机号验证⭐⭐文件操作读取文件最后 N 行⭐⭐数学质数判断、最大公约数⭐进阶LRU 缓存、二叉树层序遍历⭐⭐⭐SQL分组聚合查询⭐⭐Shell查找大文件⭐⭐2.2 验证方案分两种模式模式 A隔离执行验证Python 任务模型生成代码 → 合并验证代码 → 写入临时文件 → subprocess 执行 → 检查输出 PASS具体来说把公共导入re、os、tempfile、collections 模型生成的代码 验证断言合并成一个完整的 Python 脚本用subprocess在隔离环境中执行。输出包含PASS就算通过。模式 B内容检查SQL/Shell 任务模型生成代码 → 关键词匹配 → 包含必要元素即通过SQL 任务检查是否包含SELECT、FROM、表名/字段名等Shell 任务检查是否包含find、路径、排序命令等。3. 踩坑记录坑 1推理模型会输出思维过程Qwen3.6-27B 是推理模型reasoning model它回答时会先输出思考过程格式是think 嗯用户让我写一个斐波那契数列函数... 大量推理文字 /think一开始max_tokens设为 1024结果模型的思考过程就占了 1000 多 token代码只写了一半就被截断了。第一次跑评测15 个任务全部失败。修复max_tokens从 1024 提升到 2048在clean_code函数中增加思维标签过滤defclean_code(raw:str)-str:# 去掉思维过程标签注意模型用 think 非标准闭合rawre.sub(rthink.*$,,raw,flagsre.DOTALL)# 尝试从代码块中提取code_blocksre.findall(rpython\s*\n(.*?),raw,re.DOTALL)ifcode_blocks:returncode_blocks[0].strip()# 从 def/class/import 关键字开始提取code_matchre.search(r(def \w|class \w|import |from \w).*,raw,re.DOTALL|re.MULTILINE)ifcode_match:returncode_match.group().strip()returnraw.strip()坑 2评测框架的 exec 设计有 bug修复了思维过程问题后第二次跑评测模型生成的代码肉眼看起来都是正确的但15 个任务仍然全部失败。错误信息全是同一个invalid syntax. Perhaps you forgot a comma? (string, line 1)排查了半天发现问题出在验证框架的设计上。原来的思路是这样的# 错误的验证方式verify_globals{run_code:lambdaccode:run_code(c),}eval(verify,verify_globals)# verify 代码长这样result eval(run_code(fibonacci))\nassert result(10) 55run_code(fibonacci)本意是执行生成的代码然后返回 fibonacci 函数但实际实现中run_code把传入的字符串当作 Python 代码写入临时文件执行。所以run_code(fibonacci)写入的是字符串fibonacci执行后什么都没有。修复彻底推翻这个设计改为最简单直接的方式——把生成的代码和验证代码合并到一个文件里执行# 合并后的临时文件内容# from collections import deque, OrderedDict - 公共导入# def fibonacci(n): ... - 模型生成的代码## # 验证 # assert fibonacci(10) 55 - 验证代码# assert fibonacci(0) 0# print(PASS)defexecute_code(full_code:str)-tuple:withtempfile.NamedTemporaryFile(modew,suffix.py,deleteFalse,encodingutf-8)asf:f.write(full_code)tmpf.nametry:resultsubprocess.run([python3,tmp],capture_outputTrue,textTrue,timeout15)returnresult.stdout,result.stderr,result.returncodeexceptsubprocess.TimeoutExpired:return,TIMEOUT,-1finally:os.unlink(tmp)坑 3SQL 和 Shell 任务的验证SQL 和 Shell 任务不生成 Python 代码不能直接执行。最初的设计是用字符串替换把 SQL 内容注入到 Python 的三重引号中# 错误方式脆弱的字符串替换full_codetask[verify].replace(,f#{code}#)这在模型输出包含引号或特殊字符时就会崩溃。Shell 任务用内联 lambda 做关键词检查# 问题clean_code 可能去掉 shell 命令中的关键词content_check:lambdacode:findincodeand/var/logincode修复统一用内容检查函数并且用原始输出未经clean_code处理做匹配def_check_sql(code:str)-bool:uppercode.upper()returnSELECTinupperandFROMinupperand\departmentincode.lower()andsalaryincode.lower()def_check_shell(code:str)-bool:has_findfindincode has_path/var/logincode has_size-sizeincode has_sortsortincodeorlsincodeorduincodereturnhas_findandhas_pathand(has_sizeorhas_sort)# 在 run_task 中ifcontent_checkintask:check_textrawifrawelsecode# 用原始输出passedtask[content_check](check_text)4. 最终评测脚本完整脚本放在ai-benchmark/run_benchmark.py核心流程main() ├── 测试 API 连通性 ├── 遍历 15 个任务 │ ├── call_model() → 调用 llama.cpp API │ ├── clean_code() → 提取纯净代码 │ └── run_task() → 执行验证 │ ├── Python 任务合并代码 → execute_code() → 检查 PASS │ └── SQL/Shell 任务content_check() → 关键词匹配 └── generate_report() → 输出 Markdown 报告关键配置API_URLhttp://localhost:8080/v1/chat/completionsrequests.post(API_URL,json{messages:[{role:system,content:你是一个编程助手。直接给出代码不要加解释不要用 markdown 代码块标记。},{role:user,content:prompt},],temperature:0.1,# 低温度保证输出稳定max_tokens:2048,# 给推理过程留足空间})5. 评测结果5.1 总览指标结果总任务数15通过15失败0通过率100%平均响应时间73.9s5.2 分类统计分类通过/总数通过率平均耗时基础算法2/2100%76.7s字符串处理2/2100%73.4s数据处理2/2100%48.0s正则表达式2/2100%74.5s文件操作1/1100%89.1s数学2/2100%50.7s进阶2/2100%99.2sSQL1/1100%103.9sShell1/1100%115.2s5.3 详细结果✅ 斐波那契数列77.89sdeffibonacci(n):计算第n个斐波那契数ifn0:return0elifn1:return1a,b0,1for_inrange(2,n1):a,bb,abreturnb迭代实现时间复杂度 O(n)空间复杂度 O(1)。标准答案。✅ 快速排序75.54sdefquick_sort(arr):快速排序iflen(arr)1:returnarr pivotarr[len(arr)//2]left[xforxinarrifxpivot]middle[xforxinarrifxpivot]right[xforxinarrifxpivot]returnquick_sort(left)middlequick_sort(right)用列表推导式的三路划分Pythonic 的实现。不是原地排序但在 Python 中这种写法更常见。✅ 回文判断68.18sdefis_palindrome(s):cleanedre.sub(r[^a-zA-Z0-9],,s).lower()returncleanedcleaned[::-1]一行搞定用正则过滤非字母数字字符然后反转比较。✅ 词频统计78.58sdefword_count(text):wordstext.lower().split()count{}forwordinwords:count[word]count.get(word,0)1returncount标准字典计数。✅ JSON 解析与筛选39.12sdeffilter_users(users,min_age):return[userforuserinusersifuser[age]min_age]列表推导一行解决。✅ CSV 数据聚合56.97sdefaggregate_sales(data):result{}forrecordindata:productrecord[product]amountrecord[amount]result[product]result.get(product,0)amountreturnresult分组聚合正确。✅ 邮箱提取67.47sdefextract_emails(text):returnre.findall(r[a-zA-Z0-9._%-][a-zA-Z0-9.-]\.[a-zA-Z]{2,},text)标准邮箱正则。✅ 手机号验证81.55sdefis_valid_phone(phone):returnbool(re.match(r^1[3-9]\d{9}$,phone))11 位、1 开头、第二位 3-9完全符合中国大陆手机号规则。✅ 按行读取文件89.09sdefread_last_n_lines(filepath,n):ifn0:return[]withopen(filepath,r,encodingutf-8)asf:returnlist(deque(f,maxlenn))用deque(maxlenn)优雅地读取最后 N 行比读全部再切片省内存。✅ 质数判断76.73sdefis_prime(n):ifn2:returnFalseifn2:returnTrueifn%20:returnFalseforiinrange(3,int(n**0.5)1,2):ifn%i0:returnFalsereturnTrue包含偶数优化和 sqrt 边界优化写得很好。✅ 最大公约数24.74sdefgcd(a,b):whileb:a,bb,a%breturna欧几里得算法最快响应。✅ LRU 缓存118.1sclassLRUCache:def__init__(self,capacity:int):self.capacitycapacity self.cacheOrderedDict()defget(self,key:int)-int:ifkeynotinself.cache:return-1self.cache.move_to_end(key)returnself.cache[key]defput(self,key:int,value:int):ifkeyinself.cache:self.cache.move_to_end(key)self.cache[key]valueiflen(self.cache)self.capacity:self.cache.popitem(lastFalse)用OrderedDict实现move_to_end更新访问顺序popitem(lastFalse)淘汰最久未使用的。LeetCode 146 题的标准解法。✅ 二叉树层序遍历80.33sdeflevel_order(root):ifnotroot:return[]result[]queue[root]whilequeue:level_sizelen(queue)level[]for_inrange(level_size):nodequeue.pop(0)level.append(node.val)ifnode.left:queue.append(node.left)ifnode.right:queue.append(node.right)result.append(level)returnresult标准 BFS 层序遍历每层一个子列表。✅ SQL 生成103.9sSELECTu.name,u.salaryFROMusers uINNERJOIN(SELECTdepartment,MAX(salary)ASmax_salaryFROMusersGROUPBYdepartment)dept_maxONu.departmentdept_max.departmentANDu.salarydept_max.max_salary;用子查询 JOIN 实现每个部门最高薪资员工逻辑正确。✅ Shell 查找大文件115.23sfind/var/log-typef-size10M-execls-lh{}\;|sort-k5-hrfind-size 10M找到超过 10MB 的文件ls -lh显示详细信息sort -k5 -hr按大小倒序排列。6. 性能观察响应时间差异很大最快 24.7sGCD最慢 118.1sLRU 缓存。这与任务复杂度有关但更主要的原因是 llama.cpp 的推理速度受限于KV Cache 大小20GB 显存装完模型后留给 KV Cache 的空间有限推理长度模型先输出思考过程token 越多越慢首 token 延迟llama.cpp 在 GPU 上的首 token 生成速度取决于模型层数和量化方式平均 73.9s/任务对于本地推理来说在预期范围内。7. 总结Qwen3.6-27B 在代码生成方面表现扎实。15 个任务全部通过包括 LRU 缓存和二叉树遍历这类需要理解数据结构的题目。代码风格偏 Pythonic会主动使用OrderedDict、deque等标准库工具。作为 27B 参数的本地模型这个表现在 20GB 显存的约束下是不错的。日常编程辅助、代码审查、算法练习等场景完全够用。评测框架的教训推理模型的输出格式要特殊处理——思维过程会吃掉大量 token代码验证框架要简单——合并到单文件执行比 eval/exec 可靠得多非 Python 任务用内容检查——别试图把 SQL/Shell 代码塞进 Python 里执行后续方向增加更复杂的任务多线程、异常处理、API 设计加入 LeetCode 中等/困难题目对比不同量化精度Q4_K_M vs Q8_0对代码质量的影响尝试用这个框架评测其他本地模型