我当初购买树莓派 5并怀着一个颇为宏大的想法：把它当作一台小型本地 AI 盒子，专门用来处理编码任务。
一部分动机很实际：我想缓解 Claude API 调用限制带来的压力。另一部分原因更简单：这块价格不低的小板子，宣传称可用于 “AI 实验”，我想给它找个真正能用得上的场景。
理论上，在树莓派上运行本地编码模型，堪称完美。它功耗低、可以常年开机、放在桌面不占地方，随时能帮忙测试、写脚本、处理小型编码任务。在我设想里，它会成为一个小巧的本地编码助手。
然而，现实并非如此。
本文详细记录了我在树莓派 5 上部署 Ollama 与 Aider、进行真实编码测试的全过程，最终得出结论：即使是顶配 16GB 版本的树莓派 5，也无法真正替代一台合格的本地编码主机。
我的目标
我的期望并不算高。我并不指望它能媲美带桌面 GPU 的电脑，或是云端大模型。只希望它能在本地完成一些实用的编码工作：
生成一些单元测试
协助进行小型重构
编写小型Bash/Python工具
或许能通过Telegram上的OpenClaw处理快速交互任务
听起来很合理。如今轻量级编码模型越来越强，Ollama 让本地部署变得简单，配合 Aider 还能在命令行便捷使用。于是我决定动手搭建。
第一部分：在树莓派上安装Ollama
好消息是，设置过程其实相当简单。
我从标准的Ollama安装开始：
curl -fsSL https://ollama.com/install.sh | sh
安装完成后，检查版本：
ollama --version
接着下载几款编码模型，我选择了 Qwen-Coder 系列：
ollama pull qwen2.5-coder:1.5bollama pull qwen2.5-coder:3bollama pull qwen2.5-coder:7b
最后，我通过编辑systemd单元文件——nano /etc/systemd/system/ollama.service——将ollama暴露在树莓派之外，并添加了以下两行：
Environment="OLLAMA_HOST=0.0.0.0:11434"Environment="OLLAMA_CONTEXT_LENGTH=8192"
重启服务后，即可在局域网内访问：
curl http://<pi-ip>:11434/api/tags{"models":[{"name":"qwen2.5-coder:7b","model":"qwen2.5-coder:7b","modified_at":"2026-03-29T15:50:06.938558636+02:00","size":4683087561,"digest":"dae161e27b0e90dd1856c8bb3209201fd6736d8eb66298e75ed87571486f4364","details":{"parent_model":"","format":"gguf","family":"qwen2","families":["qwen2"],"parameter_size":"7.6B","quantization_level":"Q4_K_M"}},{"name":"qwen2.5-coder:1.5b","model":"qwen2.5-coder:1.5b","modified_at":"2026-03-29T15:30:35.122956073+02:00","size":986062089,"digest":"d7372fd828518a4d38b1eb196c673c31a85f2ed302b3d1e406c4c2d1b64a0668","details":{"parent_model":"","format":"gguf","family":"qwen2","families":["qwen2"],"parameter_size":"1.5B","quantization_level":"Q4_K_M"}},{"name":"qwen2.5-coder:3b","model":"qwen2.5-coder:3b","modified_at":"2026-03-29T14:51:00.437576892+02:00","size":1929912626,"digest":"f72c60cabf6237b07f6e632b2c48d533cef25eda2efbd34bed21c5e9c01e6225","details":{"parent_model":"","format":"gguf","family":"qwen2","families":["qwen2"],"parameter_size":"3.1B","quantization_level":"Q4_K_M"}}]}第二部分：添加Aider
接下来安装 Aider（https://aider.chat/）。我不想只在终端里和模型聊天，而是想真正检验：树莓派能否成为实用的编码助手。
安装命令：
curl -LsSf https://aider.chat/install.sh | sh
将 Aider 指向本地 Ollama 服务：
export OLLAMA_HOST=http://<pi-ip>:11434aider --model ollama/qwen2.5-coder:3b
可以看到，整套环境搭建非常简单，Ollama 和 Aider 都极易上手。这也是这个项目最吸引人的地方：从零开始，很快就能拥有一个 “本地编码助手”。
可一旦要求模型真正实用、能节省时间而非浪费时间，问题就来了。
第三部分：在实际任务中进行测试
这才是最关键的部分。我不想做无意义的基准测试，也不问琐碎问题，而是直接用日常开发里的小型真实任务测试。
任务1：生成Go测试
第一个有实际意义的测试：让模型为现有函数生成 Go 单元测试。这正是我期待本地编码模型能胜任的场景：结构化、重复性工作，结果 “够用” 即可。
我在一个不到 300 行的小型 Go 项目上测试，分别用了 1.5B、3B、7B 模型，结果全部失败 ——API 请求 10 分钟后超时，没有任何返回。
显然，等十几分钟才能得到一个编码响应，这不叫辅助，而是耽误工作，更不用说并发请求了。
于是我把任务简化到极致。
任务2：小型Python脚本
我不再让它处理已有 Go 项目，而是用一个极简的 Python 函数做测试：
def to_slug(title: str, max_length: int = 50) -> str: """ Convert a title into a URL-friendly slug. Rules: - lowercase everything - keep letters, numbers, spaces, hyphens, underscores - replace spaces/underscores with hyphens - collapse multiple hyphens - strip leading/trailing hyphens - truncate to max_length, then strip trailing hyphens again Raises: - TypeError if title is not a string - ValueError if title is empty/blank or max_length < 1 """ if not isinstance(title, str): raise TypeError("title must be a string") if max_length < 1: raise ValueError("max_length must be at least 1") title = title.strip().lower() if not title: raise ValueError("title cannot be empty") # Remove unsupported characters, but keep spaces, hyphens, underscores. title = re.sub(r"[^a-z0-9\s\-_]", "", title) # Convert spaces/underscores to hyphens. title = re.sub(r"[\s_]+", "-", title) # Collapse repeated hyphens. title = re.sub(r"-+", "-", title) # Trim edges. title = title.strip("-") # Enforce max length. title = title[:max_length].rstrip("-") if not title: raise ValueError("title produced an empty slug") return title这看起来是一个宽容度更高的测试。上下文更少、结构更简单、需要生成的代码也更少。如果树莓派无法处理小型代码库中的Go测试，也许它至少能处理一个小型Python练习。
提示如下：
> Write a small pytest test file for string_tools.py. > > Focus only on the function to_slug. > Cover: > - normal title > - uppercase letters > - multiple spaces > - underscores > - punctuation removal > - repeated hyphens collapsing > - truncation with max_length > - blank input raising ValueError > - non-string input raising TypeError > - max_length < 1 raising ValueError > > Return only the test file code.
qwen2.5-coder:1.5b
1.5B模型花了大约4分钟生成测试文件。
它确实生成了一些可用的内容：
import pytestfrom string_tool import to_slugdef test_to_slug_normal_title(): assert to_slug("Hello World") == "hello-world"def test_to_slug_uppercase_letters(): assert to_slug("HELLO WORLD") == "hello-world"def test_to_slug_multiple_spaces(): assert to_slug(" Hello World ") == "hello-world"def test_to_slug_underscores(): assert to_slug("Hello_World") == "hello-world"def test_to_slug_punctuation_removal(): assert to_slug("Hello, World!") == "helloworld"def test_to_slug_repeated_hyphens_collapsing(): assert to_slug("Hello---World") == "hello-world"def test_to_slug_truncation_with_max_length(): assert to_slug("Hello World", max_length=10) == "hello-worl"def test_to_slug_blank_input_raising_ValueError(): with pytest.raises(ValueError): to_slug("")def test_to_slug_non_string_input_raising_TypeError(): with pytest.raises(TypeError): to_slug(123)def test_to_slug_max_length_less_than_1_raising_ValueError(): with pytest.raises(ValueError): to_slug("Hello World", max_length=0)但其中一个测试完全错误：
======================================================================================= FAILURES =======================================================================================___________________________________________________________________________ test_to_slug_punctuation_removal ___________________________________________________________________________ def test_to_slug_punctuation_removal():> assert to_slug("Hello, World!") == "helloworld"E AssertionError: assert 'hello-world' == 'helloworld'E - helloworldE + hello-worldE ? +test_string_tool.py:17: AssertionError=============================================================================== short test summary info ================================================================================FAILED test_string_tool.py::test_to_slug_punctuation_removal - AssertionError: assert 'hello-world' == 'helloworld'============================================================================= 1 failed, 9 passed in 0.09s ==============================================================================从绝对意义上讲，这个结果并不糟糕。模型基本上理解了任务。但是，花费4分钟生成一个小型pytest文件，且其中包含一个错误的断言，这在实际工作流程中远远达不到我的期望。
qwen2.5-coder:3b
3B模型花了大约4分半钟。这次，它生成了一个更好的测试文件：
import pytestfrom string_tool import to_slugdef test_to_slug_normal_title(): assert to_slug("Hello World") == "hello-world"def test_to_slug_uppercase_letters(): assert to_slug("HELLO WORLD") == "hello-world"def test_to_slug_multiple_spaces(): assert to_slug(" Hello World ") == "hello-world"def test_to_slug_underscores(): assert to_slug("Hello_World") == "hello-world"def test_to_slug_punctuation_removal(): assert to_slug("Hello, World!") == "hello-world"def test_to_slug_repeated_hyphens_collapsing(): assert to_slug("Hello---World") == "hello-world"def test_to_slug_truncation_with_max_length(): assert to_slug("Hello World", max_length=10) == "hello-worl"def test_to_slug_blank_input_raises_value_error(): with pytest.raises(ValueError): to_slug("")def test_to_slug_non_string_input_raises_type_error(): with pytest.raises(TypeError): to_slug(123)def test_to_slug_max_length_less_than_one_raises_value_error(): with pytest.raises(ValueError): to_slug("Hello World", max_length=0)所有10个测试用例未经修改全部通过：
10 passed in 0.02s
输出结果不错，但对于如此简单的任务来说，延迟仍然高得离谱。我可能自己编写测试的速度比等待模型完成思考还要快。
生成的输出仍有改进空间。例如，我可能会为全空白输入添加一个额外的测试。
with pytest.raises(ValueError): to_slug(" ")qwen2.5-coder:7b
7B模型花了超过10分钟。与较小的两个模型不同，它实际上将测试放在了test/test_string_tool.py下，乍一看似乎是一个更聪明的结果：
import pytestfrom string_tool import to_slugdef test_normal_title(): assert to_slug("Hello World") == "hello-world"def test_uppercase_letters(): assert to_slug("HELLO WORLD") == "hello-world"def test_multiple_spaces(): assert to_slug(" Hello World ") == "hello-world"def test_underscores(): assert to_slug("Hello_World") == "hello-world"def test_punctuation_removal(): assert to_slug("Hello, World!") == "hello-world"def test_repeated_hyphens_collapsing(): assert to_slug("Hello--World") == "hello-world"def test_truncation_with_max_length(): assert to_slug("This is a very long title that should be truncated", max_length=10) == "this-is-a-very"def test_blank_input_raising_ValueError(): with pytest.raises(ValueError): to_slug("")def test_non_string_input_raising_TypeError(): with pytest.raises(TypeError): to_slug(123)def test_max_length_less_than_1_rasing_ValueError(): with pytest.raises(ValueError): to_slug("Hello World", max_length=0)但文件甚至无法运行：
E ModuleNotFoundError: No module named 'string_tool'
手动修正导入问题后，仍有一个测试失败：
======================================================================================= FAILURES =======================================================================================___________________________________________________________________________ test_truncation_with_max_length ____________________________________________________________________________ def test_truncation_with_max_length():> assert to_slug("This is a very long title that should be truncated", max_length=10) == "this-is-a-very"E AssertionError: assert 'this-is-a' == 'this-is-a-very'E - this-is-a-veryE ? -----E + this-is-atest_string_tool.py:23: AssertionError=============================================================================== short test summary info ================================================================================FAILED test_string_tool.py::test_truncation_with_max_length - AssertionError: assert 'this-is-a' == 'this-is-a-very'============================================================================= 1 failed, 9 passed in 0.09s ==============================================================================更令人失望的是，该工具实际上并不知道如何独立完成整个循环。它能够生成测试代码，但无法运行测试、观察失败情况，并在同一工作流程中迭代修复错误。
这一点很重要，因为本地编码助手的重点不仅仅是输出代码。它的目的是帮助你以最小的阻力获得一个可工作的结果。
到目前为止，这种体验与我日常工作中的实际需求相差甚远。仅延迟一项就使得即使是小任务也显得比实际更繁重。
第四部分：问题出在哪里
回想起来，很明显，即使是性能最强的16GB树莓派也不是为人工智能编码协助而设计的工具。这并不意味着树莓派5的硬件不好。相反，就其设计目的而言，它实际上非常出色。
但是，一旦从玩具演示转向实际使用，大语言模型（LLM）推理（尤其是编码推理）对硬件的要求就非常苛刻。编码模型需要足够的内存、足够的吞吐量以及足够的原始推理速度来保持紧密的交互。这正是树莓派所欠缺的。
即使模型在技术上能够运行，体验也会受到树莓派硬件类型的限制：与真正的台式机相比，CPU性能有限；对于此类工作负载，没有强大的GPU加速；内存带宽根本不适合与编码模型进行快速本地推理。
结论
我最初的想法很简单：使用树莓派5作为本地编码助手，稍微减轻API的使用压力，并最终为这台昂贵的小机器找到一个真正的人工智能工作。
尝试之后，我的结论也很简单：这不是执行该任务的合适机器。
如果你的目标是进行试验、了解本地模型的工作原理或构建小型演示，那么树莓派很有趣。如果你的目标是拥有一款真正有助于日常编码的工具，那么即使是16GB的树莓派5也不够用。
老实说，我认为这值得大声说出来，因为许多业余人工智能内容都聚焦于某样东西能否运行，而不是它是否应该以那种方式使用。
因此，我的树莓派现在可能有着不同的未来。它不再是“本地编码助手”，而是更多地扮演“智能家居盒子”、Home Assistant主机或其他适合其硬件的常开项目的角色。
