“一个用户报告了故障，我才得以顺着兔子洞深入修复。”开发者在博客里这样写道。折腾本地应用是一回事，但要构建一个终端用户能忍受的应用，面对“本地AI”时就得考虑更多边界情况。这趟调试之旅最终引向了硬件极限的发现、对量化重要性的一次粗浅理解，以及一个叫flippycard的学习工具上线——它用自定义上传的内容帮用户记忆知识点，而这工具的底座就架在Jetson Orin Nano上。
乐观派会说：把Ollama跑在这种边缘计算板子上，不是顺理成章吗？ARM64架构、CUDA生态、低功耗，摆明是本地推理的理想载体。然而现实第一步就撞了墙：Ollama卡在Cloudflare隧道里，陷入本地死循环。即便绕开系统服务管理器，想从外部访问，还需要另建配置文件。最致命的是运行速度——用CPU推理慢到无法接受，必须把数值计算扔给GPU。
悲观派由此断言：8GB内存、精简性能的Orin Nano，压根不是为这种规模的服务准备的。Docker容器本是打包利器，可在这预算级设备上，Docker本身就成了资源黑洞。哪怕只是跑一个轻量服务，内存随时可能顶到上限，稍不留神板子就会崩溃。于是开发者不得不一边盯紧系统资源，一边在techdocs页面上专门新增笔记分区，把踩到的坑一一记录在案。
两条路似乎都是死胡同。但实际动手后的判断是：裁切得当，仍有生路。她的方案是从源码构建Ollama，把Docker这层开销全部砍掉。四步走完，耗时约30分钟：先用apt装好CUDA Toolkit 13和cmake；接着下载Go 1.24.4的ARM64二进制包并解压到/usr/local；再把Go和CUDA的bin路径写进.bashrc；最后克隆Ollama仓库，显式指定CUDA_ARCHITECTURES=87执行cmake构建。整个过程都押在“sm_87”这个算力架构标记上，等于明明白白告诉编译器：别猜了，直接用GPU。
资源数字没有说谎。32分钟构建一结束，Ollama就可以通过配置文件打通Cloudflare隧道，并在外部访问时不再被服务管理器限制。切换算力后速度立刻起飞，CPU的龟速变成了GPU的可用帧数。为了不把8GB内存压垮，开发者在Ollama编译期间还顺手新做了一个只用于技术发现的页面，前提是Claude帮忙生成时不能把小服务器的资源推向极限——她把资源红线看得很死。
这种“抠到极致”的效率意识还延续到后续运维中。她连接了Gmail的MCP服务器，让Claude直接把过程摘要发到自己邮箱，省去手动整理步骤。记录也不再散落各处，新techdocs页面统一收纳了配置笔记，包括如何给Ollama新建配置文件、如何保持Cloudflare隧道畅通，以及显式切换GPU的指令备忘。整件事揭示了一个事实：在Orin Nano这类设备上跑本地AI，胜负手不在模型大小，而在能否用编译时决策、显式硬件指定和全程资源监控，把每一MB内存和每一帧算力都用在刀刃上。
热门跟贴