前言
前几天，我一直在折腾的小项目，或者说是之前一直想做，但是又一直咕咕咕到上周才开始动工的一个个人兴趣项目GoBlog。这是一个用Go语言写的CMS，目标是对标Typecho的功能，并且做到小而美，高性能。
前面的开发我都是靠朋友搞来的GPT API接口对接codex进行编程，非常的好用，对比现在降智降成傻逼的Gemini强太多了。可惜好景不长，虽然六月初的封号潮我朋友顶过去了，但是最近一波处理又被清算了。
为了继续我的开发，我尝试了阿里云的Qwen，当然是云端模型，有免费的1000万token额度试用，但是接到codex上面基本上是一个问题就把1000万Token干没了，算了算真要正价买Token还是很恐怖的。于是我打算尝试本地部署看看效果。
硬件准备
虽然我有RTX3080Ti，但是12G的显存部署的小模型恐怕并不能有多智能，所以我还是把我的V100-SXM2-16G拉出来了，用PCIe延长线接上，这下总显存就来到了12+16=28G，应该是可以跑32B左右的模型了。
硬件配置如下：
- CPU: Intel(R) Xeon(R) E5-1680 v4
- RAM: REG ECC DDR4 16G 2133MHz x2
- GPU 1: NVIDIA GeForce RTX 3080 Ti
- GPU 2: NVIDIA Tesla V100 SXM2 16GB
软件部署
整体来说环境部署很简单，没有遇到太多的难题，首先先要部署Ollama拉取模型
Ollama配置
去GitHub下载最新的Ollama，直接启动即可。但是由于Ollama默认会把模型下在用户目录，我还是希望让模型能放在Ollama所在的目录。准备一个启动脚本run_ollama.sh即可解决问题，脚本内容如下：
export OLLAMA_KEEP_ALIVE=-1
export HOME=./data/
./bin/ollama serve把脚本放到Ollama的目录，创建好data文件夹，启动脚本即可。
如果希望后续启动快一点的话，可以提前拉取好模型，例如拉取gemma4:31b模型，进入ollama程序所在目录，运行：
./ollama run gemma4:31b --verbose Codex配置
安装好codex后，用下面的命令即可指定Ollama作为模型调用API，例如指定gemma4:31b：
codex --oss -m gemma4:31b或者指定qwen3.6:35b
./ollama run qwen3.6:35b --verbose 我测试了三个比较好的模型，qwen3.6:35b，qwen3.5:35b和gemma4:31b，实际表现的话个人感觉gemma4:31b更好一点。千问系列模型比较容易遇到的问题是还没做完就给codex发了结束信号提前结束了，虽然只做了一半，我怀疑可能是codex配套提示词的问题。而且有时候千问执行完了，代码仓库一个文件都不动，我也不知道是怎么回事。Gemma稍微好一些，但是一旦任务变得复杂，照样翻车。不过总体感觉gemma4:31b的翻车概率比qwen3.6:35b，qwen3.5:35b要低一些，比较简单的任务，开发一个简单的小程序，这三个模型都没有任何问题。
Claude配置
安装好Claude后，通过下面的命令指定Ollama作为API服务端运行，例如指定gemma4:31b模型：
ANTHROPIC_AUTH_TOKEN=ollama ANTHROPIC_BASE_URL=http://localhost:11434 ANTHROPIC_API_KEY="" claude --model gemma4:31b有时候会出现报错信息：
API Error: Claude's response exceeded the 32000 output token maximum. To configure this behavior, set the CLAUDE_CODE_MAX_OUTPUT_TOKENS environment variable.
可以添加参数CLAUDE_CODE_MAX_OUTPUT_TOKENS=128000来把限制调高，命令是这样的：
ANTHROPIC_AUTH_TOKEN=ollama ANTHROPIC_BASE_URL=http://localhost:11434 ANTHROPIC_API_KEY="" CLAUDE_CODE_MAX_OUTPUT_TOKENS=128000 claude --model gemma4:31b如果要指定qwen3.6:35b，长这样：
ANTHROPIC_AUTH_TOKEN=ollama ANTHROPIC_BASE_URL=http://localhost:11434 ANTHROPIC_API_KEY="" CLAUDE_CODE_MAX_OUTPUT_TOKENS=128000 claude --model qwen3.6:35b用Claude的话，这三个模型的表现情况和前面说的类似，小项目，代码体量小没什么问题，但是代码量一大就全部翻车。特别是千问系列的模型，经常会出现执行完成后代码一行不动的情况。感觉应该还是模型在这类工具的适配能力不太行，或者是模型能力不足。
总结
现在本地能跑的中小模型，能力相比于一年前已经有了很大的提升，但是对于写代码这种对上下文理解能力和输出稳定性要求很高的场景，还是不太行。不说本地部署了，就算是我去用华为云的CodeArts代码智能体，里面的模型是GLM5.1有时候都会犯迷糊，跟真的GPT 5.5在编程这一块根本没法比，也比不过一月份的Gemini 3 Pro（为什么我要限定是Gemini 3 Pro，还要限定是一月份呢？因为现在Gemini 3.5 Pro已经是蠢蛋了），更别说这种本地部署的小模型了，差距实在是太大了，本地部署模型玩编程也就是图一乐了。题外话：幸亏当时在Gemini的高光时刻，借朋友的Gemini Pro账号把主题的前端设计稿开发完了，要是晚几个月我估计我博客主题NekoEcho是开发不出来了（
折腾算是失败了吧，也看清楚了本地部署模型和云端满血模型的差距。虽然说华为云那边有免费版的CodeArts代码智能体可以用GLM5.1，但是和GPT驱动的Codex差距还是不小的，而且免费版执行任务到后面算力限制严重，跑一个任务要很久，因为免费版会被调低优先级，不过现阶段确实也还算是一个不错的选择。虽然我确实有想法买华为云的CodeArts代码智能体服务，因为入门套餐不贵，也算是支持华为云了，毕竟白嫖了十多年的云服务器呢。但是，看了一下我用免费版的Token消耗，入门套餐一个2000万Tokens应该顶不住两次对话，我在我的代码仓库让它帮我修几个小问题就干掉了2500万Token，然后超额被限速。感觉目前用AI编程这一块，还是得提升计算效率，压低token价格，才能真正发挥AI编程的优势。
目前看的话，想要继续开发我的GoBlog项目，只能说看看什么时候能搞个GPT的API来编程了。本地部署模型用于AI编程，目前来看就32B左右体量的模型，只能做一些相对简单的开发。
