本地代码大模型评测实战（四）：8个坑和1个崩溃

本地跑模型的8个坑（和1个崩溃恢复的故事）

系列目录
篇1: 模型选型
篇2: 评测框架
篇3: 数据挖掘的13个发现
篇4: 8个坑和1个崩溃 ← 当前
篇5: 公平对比的5个陷阱

发布后将链接替换为实际 URL

系列：本地代码大模型评测实战 · 第4篇

如果你正打算在本地跑一个27B模型做代码评测，这篇文章能帮你省两周。不是夸张——这8个坑我每一个都实打实地踩过，有的浪费了几小时调试，有的差点让整个评测报废。最后那个崩溃恢复的故事，是整个系列里最戏剧性的一集。

背景

我在Windows工作站上跑Qwen3.6-27B和ThinkingCap-27B的代码评测，用llama.cpp做推理后端，评测框架是自己写的Python脚本。硬件是一块改装过的RTX 3080 20GB显卡，跑CUDA。

评测规模：1414道题，每道题最多生成65536 tokens，预计总耗时60-80小时。

听起来不复杂对吧？实际上光是让这个流程稳定跑起来，我就花了将近两周。下面是这趟旅程里踩过的每一个坑。

坑1：思维循环（Thinking Loop）

现象

Qwen3.6-27B在Hard难度的题目上，生成的"代码"突然膨胀到150KB以上。打开一看，全是思维过程的无限重复——模型在反复"思考"同一个解法，换着措辞说同一句话，就是不写代码。

一个典型的循环长这样：

让我想想这道题...首先我需要理解题意...题意是...让我重新理解一下... 首先我需要理解题意...这道题的意思是...让我再想想...首先...

能循环几千次，直到达到max tokens上限。

根因

思维链模型（thinking model）在遇到真正困难的问题时，会进入一种"想不出来但不想放弃"的状态。它找不到好的解法，但又不愿意停止思考直接输出，于是在思维空间里打转。

这不是bug，是模型的训练目标决定的——它被训练成"遇到难题要多想"，但没有被训练成"想不出来就承认"。

解决

写一个滑动窗口循环检测器，必须配合stream=True使用：

importhashlibfromcollectionsimportdequeclassThinkingLoopDetector:def__init__(self,window_size=2000,match_threshold=3):self.window_size=window_size self.match_threshold=match_threshold self.buffer=""self.window_hashes=deque(maxlen=10)def_normalize(self,text):"""归一化：去空白、转小写"""importrereturnre.sub(r'\s+','',text.lower())defcheck(self,new_token:str)->bool:"""每收到一个token调用一次，返回True表示检测到循环"""self.buffer+=new_tokeniflen(self.buffer)<self.window_size:returnFalse# 取最近的window_size字符window=self.buffer[-self.window_size:]normalized=self._normalize(window)window_hash=hashlib.md5(normalized.encode()).hexdigest()ifwindow_hashinself.window_hashes:returnTrue# 检测到重复窗口self.window_hashes.append(window_hash)# 限制buffer大小，防止内存泄漏iflen(self.buffer)>self.window_size*3:self.buffer=self.buffer[-self.window_size:]returnFalse

使用时必须开流式输出：

detector=ThinkingLoopDetector(window_size=2000)full_output=""forchunkinllm.stream_generate(prompt):token=chunk.text full_output+=tokenifdetector.check(token):print("[LOOP DETECTED] Truncating output")break

教训

不开流式输出，等检测到循环时可能已经生成了100KB垃圾。我最初用的是非流式调用，等generate()返回时，模型已经跑了15分钟生成了一堆废话。改成流式后，循环通常在2000-4000个token内就能被捕获，节省大量时间。

另一个教训：window_size不能太小。设成500的话，正常的代码模式也会被误判为循环。2000是个经验值。

坑2：mmap双重映射

现象

打开任务管理器，发现GPU专用内存占了13GB（正常，27B Q4模型大约就这么大），但系统RAM也同时占了17.4GB。明明模型加载到显卡上了，为什么内存也吃这么多？

根因

Windows的内存映射（mmap）机制。llama.cpp默认用mmap加载模型文件，这在Linux上很高效——操作系统会按需加载页面到内存，GPU和CPU共享同一份物理页面。

但Windows的mmap实现不同。它会为GPU和CPU分别维护一份映射，导致模型权重在VRAM和RAM里各存一份。27B Q4模型大约13GB，两份就是26GB。

解决

启动llama-server时加一个参数：

llama-server-mmodel.gguf --no-mmap-ngl99

加了--no-mmap后，RAM占用从17.4GB降到了不到2GB（只剩KV cache和运行时开销）。

教训

这个问题只在Windows上存在。Linux用户用默认的mmap就好，反而是最优选择。但如果你像我一样在Windows上跑llama.cpp，--no-mmap应该是你启动命令里的标配。

顺便说一句，这个坑的发现过程很曲折。我一开始以为是内存泄漏，花了半天用各种profiler找泄漏点，最后在llama.cpp的GitHub issues里翻到了一个两年前的帖子才明白是怎么回事。

坑3：DRY采样器灾难

现象

评测脚本跑了几个小时后，我注意到每道题的生成时间从正常的4-5分钟暴涨到了33分钟。7倍的性能下降，而且是稳定复现的。

根因

我在启动llama-server时加了DRY采样器参数，初衷是防止模型生成重复内容：

# 这是错误的启动参数llama-server-mmodel.gguf --dry-penalty0.8--repeat-penalty1.1

DRY（Don’t Repeat Yourself）采样器的工作原理是检测已生成文本中的重复模式，然后降低这些模式再次出现的概率。问题在于：代码本身就是高度重复的。

想想看——每个函数都有def、return、if、for，每个类都有__init__，每个文件都有import语句。DRY把这些合法的代码模式都当成了"需要惩罚的重复"，导致模型在每个token的选择上都要花额外时间绕开这些"重复"。

解决

移除所有DRY和repeat-penalty参数：

# 正确的启动参数llama-server-mmodel.gguf--temp0.6--top-p0.95

不加任何惩罚参数。生成时间立刻恢复到4-5分钟。

教训

不要预防性地启用采样器惩罚。我加DRY的初衷是"万一模型生成重复内容怎么办"，结果它制造的问题比它预防的问题严重一万倍。

代码生成和自然语言生成有一个根本区别：代码天然是重复的，自然语言不是。适用于自然语言的采样器策略，直接搬到代码生成上可能会适得其反。

如果你确实遇到了模型生成重复内容的问题，先搞清楚是模型本身的问题还是prompt的问题，不要急着加惩罚参数。

坑4：–reasoning-budget导致输出退化

现象

用ThinkingCap-27B跑评测，想限制一下思维链的长度，加了--reasoning-budget 8192。结果模型的输出变成了全大写的乱码：

THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX...

反复出现同一句话，而且全部大写。代码完全不见了。

根因

ThinkingCap-27B这类思维链模型，内部有一个"思考阶段"和"输出阶段"的切换机制。当模型认为自己"想清楚了"，它会输出一个特殊token切换到输出模式。

--reasoning-budget 8192会在生成8192个token后强制截断思维阶段。问题是：如果模型在8192个token内还没想清楚，强制截断会让它进入一种退化生成模式——它还在"想"的状态，但被强行要求"说"，结果就是胡言乱语。

解决

移除--reasoning-budget参数，让模型自己决定思考多久。

# 错误llama-server-mThinkingCap-27B.gguf --reasoning-budget8192# 正确llama-server-mThinkingCap-27B.gguf

如果你确实担心思维链太长浪费时间，用坑1里的循环检测器就够了——它会截断真正卡住的生成，但不会干预正常（哪怕较长）的思考过程。

教训

人工干预思维长度适得其反。思维链模型的训练目标就是"想清楚再回答"，你强制截断它的思考过程，就像在一个人话说到一半时捂住他的嘴——他不会变得更简洁，只会变得更混乱。

如果真的需要控制生成时间，用max_tokens限制总输出长度，不要单独限制思维阶段。

坑5：Windows SSH进程管理

现象

通过SSH连到Windows工作站启动评测脚本，关掉SSH窗口——评测进程跟着一起死了。

根因

Windows的sshd（OpenSSH Server）在客户端断开时，会杀死所有关联的子进程。这和Linux的行为完全不同——Linux上SSH断开后，进程会收到SIGHUP，默认行为是终止，但你可以用nohup、tmux、screen等工具让它继续运行。

Windows上没有这些工具（或者说，它们在Windows上的行为不可靠）。

解决

在Windows桌面上手动运行评测脚本。写一个bat文件：

@echo off cd /d C:\eval python run_eval.py --model qwen3.6-27b --dataset humaneval 2>&1 | tee eval.log pause

双击运行，然后可以放心关掉远程桌面——进程会继续跑。

教训

我试过PowerShell的ScheduledJob、试过NSSM（Non-Sucking Service Manager）、试过在bat里用start /b——都不靠谱。ScheduledJob的问题是HuggingFace的datasets库在非交互式session里会卡住，原因不明。

最可靠的方案就是最原始的方案：在Windows桌面session里运行。如果你需要远程监控，用SSH连上去tail -f eval.log就行，但评测进程本身必须在桌面session里启动。

这个问题让我损失了整整一天——第一次启动的评测跑了8小时后因为我关SSH窗口而丢失，没有任何日志。

坑6：GBK编码问题

现象

模型生成的代码里包含Unicode字符（比如中文注释、特殊符号），Python报错：

UnicodeEncodeError: 'gbk' codec can't encode character '\u2713' in position 42

根因

Windows的默认编码是GBK（中文Windows）。当Python往文件写入内容时，如果没有显式指定编码，它会用系统默认编码——GBK。而模型生成的内容可能包含GBK无法编码的Unicode字符。

这个问题在Linux上几乎不会遇到，因为Linux的默认编码通常是UTF-8。

解决

在所有文件操作中显式指定encoding="utf-8"：

# 错误withopen("output.py","w")asf:f.write(model_output)# 正确withopen("output.py","w",encoding="utf-8")asf:f.write(model_output)

一个更彻底的方案是在脚本开头设置环境变量：

importos os.environ["PYTHONIOENCODING"]="utf-8"

或者在Python 3.15+中，可以通过PYTHONUTF8=1启用UTF-8模式。

教训

这个问题本身不难解决，但它经常和别的问题混在一起出现。比如，模型生成了150KB的思维循环内容（坑1），其中包含Unicode字符，然后在写入文件时报GBK编码错误——你一开始会以为是编码问题，实际上是循环问题。

排查顺序很重要：先检查内容是否正常（有没有循环），再检查编码。

坑7：PrismML fork的ABI不兼容

现象

用上游llama.cpp加载Bonsai Q2_0.gguf模型，报错：

gguf_init_from_file: unsupported tensor type 33 for key 'blk.0.attn_q.weight'

根因

Bonsai模型使用了group-128的量化打包方式（这是PrismML的自定义量化方案），而上游llama.cpp只支持group-64。虽然文件扩展名都是.gguf，文件格式版本也相同，但内部的tensor打包方式不兼容。

错误信息说"unsupported tensor type 33"具有误导性——它不是说tensor的类型不对，而是说tensor的量化分组方式不被识别。

解决

必须使用PrismML的llama.cpp fork来加载Bonsai模型：

# 错误：用上游llama.cppgitclone https://github.com/ggml-org/llama.cpp# 正确：用PrismML的forkgitclone https://github.com/PrismML/llama.cppcdllama.cpp cmake-Bbuild-DGGML_CUDA=ON cmake--buildbuild--configRelease-j

用PrismML的fork编译后，同一个模型文件就能正常加载了。

教训

GGUF格式虽然号称是"通用"的，但实际上不同fork可能会扩展格式。当你遇到"unsupported tensor type"错误时，第一反应不应该是"文件损坏了"，而是"这个模型是用哪个版本的工具打包的"。

看模型的HuggingFace页面或者README，通常会说明需要哪个版本的llama.cpp。忽略这个说明是很多人的本能反应——别这么做。

坑8：CUDA版本不匹配

现象

下载最新版llama-server，双击运行，报错：

The code execution cannot proceed because cudart64_12.dll was not found. Reinstalling the program may fix this problem.

根因

llama.cpp的release版本是用特定版本的CUDA编译的（比如CUDA 12.4），而你的系统安装的是另一个版本的CUDA（比如CUDA 13.x）。CUDA runtime DLL的文件名包含版本号（cudart64_12.dll对应CUDA 12.x，cudart64_13.dll对应CUDA 13.x），版本不匹配就找不到。

解决

下载对应版本的CUDA runtime DLLs，放到llama-server.exe同目录下：

# 方法1：从NVIDIA官网下载CUDA Toolkit，只取需要的DLL# 下载CUDA 12.4 toolkit，解压后找到 cudart64_12.dll# 复制到 llama-server.exe 同目录# 方法2：如果你有conda环境conda install-c nvidia cuda-toolkit=12.4# 然后从 conda 环境目录里找到 DLL 复制过去

或者，直接下载llama.cpp的CUDA 12版本release，而不是latest release。

教训

CUDA的向后兼容性做得不好。你的系统装了CUDA 13，不代表它能运行为CUDA 12编译的程序。反过来也不行。

最稳妥的做法是：在启动llama-server之前，确认你下载的release版本对应的CUDA版本，然后确保系统里有对应版本的runtime DLL。不需要完整安装CUDA Toolkit，只需要那几个DLL文件。

这个问题的坑点在于错误信息很明确（告诉你缺哪个DLL），但解决方案不直观——你可能会去重装CUDA，而不是把DLL放到程序目录。

崩溃恢复的故事

评测跑到第54个小时。

没有任何预兆——没有kernel panic，没有OOM killer，没有蓝屏。机器就是突然重启了。事后查事件日志，只找到一条模糊的"unexpected shutdown"记录。可能是电源问题，可能是驱动问题，可能是显卡过热。原因至今不明。

当时我的评测进度是901/1414——已经跑了63.7%。

如果没有断点续传机制，这54个小时就白跑了。1414道题，每道题4-5分钟，重新跑一遍需要大约95小时——接近4天。

但我只损失了重启的那几分钟。

评测脚本在设计时就考虑了长时间运行的可靠性。每完成一道题，结果就立刻写入磁盘（不是攒一批再写）。恢复时，脚本会读取已有结果，跳过已经完成的题目，从断点继续。

关键的设计决策是slug-key的唯一性。每道题的标识不是用序号（因为序号可能因排序变化而改变），而是用题目内容的slug化哈希：

importhashlibimportredefmake_slug_key(problem_id:str,problem_text:str)->str:"""生成唯一标识，用于断点续传和去重"""# 清理文本：去空白、转小写cleaned=re.sub(r'\s+',' ',problem_text.strip().lower())# 用problem_id + 内容哈希作为keycontent_hash=hashlib.sha256(cleaned.encode()).hexdigest()[:16]returnf"{problem_id}_{content_hash}"

重启后的恢复过程：

python run_eval.py--resume--modelqwen3.6-27b--datasethumaneval# 输出：# [RESUME] Found 901 completed evaluations# [RESUME] Resuming from checkpoint# [RESUME] Processing remaining 513 problems...

从901/1414处继续，最终在第78小时完成全部1414道题。0道重复，0道遗漏。

教训

长时间运行必须有断点续传机制。不是"最好有"，是"必须有"。

设计要点：

1. 每完成一步就持久化，不要攒批次。内存里的数据在崩溃时全部丢失。
2. 用内容哈希做key，不用序号。序号会因为数据集更新、排序变化而改变。
3. 恢复时做去重检查，即使理论上不会有重复，也要防御性地检查。
4. 日志要写到文件，不能只打到stdout。崩溃后你能看到的只有文件系统里的东西。

这个崩溃恢复机制救了我54个小时的计算时间。考虑到电费和GPU磨损，大约省了200块钱。但更重要的是：我不需要重新跑一遍，也不需要从头开始debug那些已经解决的问题。

总结：8个坑的速查表

如果让我给刚开始本地跑模型的人一个建议：先花半天时间搭好崩溃恢复和日志系统，再开始跑评测。这半天的投入，会在后面的几十个小时里给你回报。

下一篇，我们会聊聊评测结果的分析——模型到底在哪些类型的题目上表现好，哪些类型是它的软肋。这些数据比任何benchmark排行榜都有参考价值。