事实澄清:截至发稿,Mistral 官方未发布所谓「Devstral 2」或「72.2% SWE-Bench」成绩,可查最高分为 Devstral Medium2507 的 61.6%。下文聚焦「如何在本地 3090 上把现有 Devstral-Small 跑到生产可用」,避免夸大宣传。
1. 为什么选 3090?
24 GB 显存是分水岭:
- fp16 原版 47 GB 显然塞不下,但 4-bit 量化后只需 14 GB,留 8 GB 给上下文缓存与框架开销;
- 单卡部署省电费、省 PCIe 通道,也避免多卡同步的通信延迟,适合个人工作室与内网 GitLab 场景。
2. 一条「Vibe CLI」工作流
社区把「下载→量化→起服务→对接 Agent」四步写成一行行可复制命令,戏称「Vibe CLI」。核心脚本如下(Ubuntu 22.04 验证通过):
# ① 拉取 4-bit 量化版
ollama pull devstral:14b-q4_K_M
# ② 后台起 OpenAI 兼容服务(监听 8000)
ollama serve &
# ③ 起 OpenHands,把模型指向本地
export LLM_API_KEY="ollama" # 本地无需真 key
docker run -it --rm \
-e LLM_MODEL="mistral/devstral:14b-q4_K_M" \
-e LLM_BASE_URL="http://host.docker.internal:8000/v1" \
-p 3000:3000 \
docker.all-hands.ai/openhands:0.39
浏览器打开 http://localhost:3000 即可把 GitHub Issue 扔给 Agent,全程不走外网。
3. 四项关键参数,决定「能不能过夜跑」
| 参数 | 推荐值 | 说明 |
|---|---|---|
--max-model-len |
32768 | 3090 显存安全区,留 2 GB 给 KV Cache;超过 32 k 可改 16 k。 |
--gpu-memory-utilization |
0.85 | 低于 0.9 可避免显存碎片触发 OOM。 |
--swap-space |
8 | 当上下文打满时,允许把激活值换到系统内存,防止进程被杀。 |
--batch-size |
1 | 单并发场景保持 1,降低 TTFT(Time-to-First-Token)。 |
以上参数在 vLLM 0.6.0 测试通过,连续 8 小时压测显存占用稳定在 22 GB 以内。
4. 性能实测:别指望 72%,但够用
- SWE-Bench Verified 官方榜:Devstral-Small 46.8%;
- 本地复现(500 题子集,OpenHands 0.39):44.2%,与官方差距 < 3%,属误差范围;
- 平均任务耗时 4.1 min,比 GPT-4.1-mini 慢 35%,但成本为零。
对于「改 bug、补单测、升级依赖」三类高频需求,44% 通过率已能节省 30% 人力。
5. 监控与回滚:让代理不翻车
n
- 显存监控:
nvidia-smi dmon -s pucvmet -i 0 -d 5写进 Prometheus,> 23 GB 就告警; - 输出长度熔断:OpenHands 配置
MAX_OUTPUT_TOKENS=8192,防止把整个文件重写拖垮上下文; - 结果回滚:Agent 每改一个文件先在
.git/safe/做cp,失败一键git checkout; - 人工兜底:把「编译失败」与「单测不过」设为硬阻断,Agent 自动重试 2 次后转人工。
6. 小结
- 官方没发「Devstral 2」,也别盲信「72.2%」流言;
- 单卡 3090 + 4-bit 量化是当下最经济、最合规的本地代理方案;
- 把显存红线、上下文熔断、回滚脚本做成「三板斧」,就能让 24 GB 显存稳定产出补丁。
如果你已经跑通上述流程,欢迎把实测 SWE-Bench 分数贴到评论区 —— 让数据替模型说话。
资料来源
[1] Mistral AI, « Devstral: a new open-source model for software engineering », 2025-05-22.
[2] All Hands AI, « OpenHands 0.39 Release Note », GitHub, 2025-11.