在Jetson边缘设备部署DeepSeek-Coder：离线代码助手实战指南

1. 项目概述与核心价值

最近在折腾边缘计算设备，手头的reComputer Jetson系列（无论是Nano、Orin Nano还是NX）性能越来越强，但总感觉除了跑跑YOLO做目标检测，没把它的算力榨干。正好DeepSeek这类代码大模型火得不行，我就琢磨着能不能把这“最强大脑”直接塞进这个“边缘小盒子”里，让它变成一个离线的、本地的编程助手。这样一来，在没网的环境下调试代码、或者想快速验证一些脚本逻辑时，就方便太多了。

这个想法听起来有点“疯狂”，毕竟大模型对内存和算力要求不低。但实测下来，借助Ollama这样的工具，在Jetson设备上部署一个轻量级的DeepSeek模型（比如DeepSeek-Coder-V2-Lite-Instruct），完全是可行的。整个过程从环境准备到最终部署，顺利的话一两个小时就能搞定。它解决的不仅仅是“离线可用”的问题，更关键的是数据隐私和安全——你的代码和提问完全在本地处理，无需上传到任何云端。对于开发者、嵌入式工程师，或者任何需要在资源受限的边缘设备上进行智能代码辅助的场景，这都是一套非常实用的解决方案。

2. 环境准备与核心工具选型

在Jetson上部署任何应用，第一步永远是搞定环境。Jetson设备默认搭载的是NVIDIA JetPack系统，基于Ubuntu，但它的ARM架构和特定的CUDA环境，让一些常规的x86_64安装方法直接失效。所以，我们的所有操作都必须基于ARM64架构来考虑。

2.1 系统基础与依赖检查

首先，通过SSH或者直接接上显示器打开终端，确认一下你的系统状态。运行nvidia-smi可以查看GPU状态和JetPack版本。确保你的系统已经更新到最新：sudo apt update && sudo apt upgrade -y。接下来，安装一些必要的编译工具和Python环境：

sudo apt install -y python3-pip python3-dev build-essential curl git

这里有个关键点：Jetson上的pip默认指向Python3，但为了避免和系统Python冲突，强烈建议使用pip3来安装所有Python包。我吃过亏，用pip装了一堆东西，结果和系统包管理打架，导致一些系统工具异常。

2.2 核心工具：为什么是Ollama？

部署本地大模型的工具有不少，比如text-generation-webui、lmstudio等。但在Jetson这种资源受限的ARM设备上，Ollama几乎是当前的最优解，原因有三：

1. ARM原生支持：Ollama官方提供了ARM64的安装包，无需自己从源码编译，省去了大量配置和解决依赖的麻烦。
2. 资源占用友好：Ollama的运行时和模型管理非常轻量，内存开销相对较小。它使用Go语言编写，本身效率就比较高。
3. 生态与易用性：Ollama拥有活跃的社区，模型库丰富，并且提供了简单的REST API，部署后很容易集成到VSCode等开发工具中。

所以，我们的技术栈就确定为：JetPack系统 + Ollama + DeepSeek-Coder系列模型。

2.3 安装Ollama（ARM64版本）

Ollama的安装极其简单。官方推荐的一行命令在x86上很好用，但在ARM设备上，我们需要指定使用ARM64的安装脚本：

curl -fsSL https://ollama.com/install.sh | sh

这个脚本会自动检测架构并下载对应的安装包。安装完成后，Ollama会作为一个系统服务（ollama.service）运行。你可以用以下命令管理它：

# 启动服务 sudo systemctl start ollama # 设置开机自启 sudo systemctl enable ollama # 查看服务状态 sudo systemctl status ollama

如果看到状态是active (running)，说明Ollama服务已经成功在后台跑起来了。

注意：第一次安装后，Ollama的模型默认会下载到/usr/share/ollama/.ollama/models目录。Jetson设备的eMMC或NVMe存储空间有限，如果你用的是Jetson Nano这类存储小的设备，可能需要考虑将模型目录通过符号链接挂载到外接的USB SSD或者更大的SD卡上，具体方法后面会讲。

3. 模型拉取与适配优化

服务跑起来了，接下来就是“喂”模型给它。Ollama支持很多模型，我们需要找到适合Jetson设备，并且擅长代码的DeepSeek版本。

3.1 模型选择：在能力与资源间权衡

直接在Ollama中运行ollama run deepseek-coder会拉取默认的模型，但这个默认版本（如6.7B参数）对于Jetson Nano（4GB内存）来说压力巨大，几乎无法运行。对于Orin Nano（8GB）或NX（16GB）会好一些，但响应速度也可能较慢。

因此，我们必须进行精细化选择。访问Ollama的官方模型库网站，搜索“deepseek”，你会发现一系列标签：

• deepseek-coder:6.7b：基础版本，能力较强，但需要至少8GB以上内存才能流畅运行。
• deepseek-coder:latest：通常指向最新的大参数版本，不推荐在边缘设备使用。
• deepseek-coder:1.3b、deepseek-coder:3b：参数更少的版本，是Jetson设备的更佳选择。

对于大多数Jetson设备，我建议从deepseek-coder:1.3b或deepseek-coder:3b开始尝试。以1.3B版本为例，它的性能对于代码补全、解释、生成简单脚本已经足够，并且在Jetson Orin Nano上能够获得相对较快的响应速度。

3.2 加速下载：配置国内镜像源

直接从Ollama官方拉取模型，速度可能非常慢，甚至失败。这里有一个至关重要的技巧：使用国内镜像源。我们可以通过修改Ollama的环境变量来实现。

首先，停止Ollama服务：

sudo systemctl stop ollama

然后，编辑Ollama的服务配置文件：

sudo nano /etc/systemd/system/ollama.service

在[Service]部分，找到Environment行，或者添加一行。我们需要设置OLLAMA_HOST和OLLAMA_MODELS意义不大，关键是设置镜像源。添加或修改如下（以阿里云镜像为例，镜像地址可能需要你根据实际情况查找最新的）：

Environment="OLLAMA_HOST=0.0.0.0" Environment="OLLAMA_ORIGINS=*" # 关键：设置镜像源，加速模型下载 Environment="OLLAMA_MODEL_SOURCE=https://ollama-mirror.ghproxy.com"

提示：镜像源地址可能会变化。ghproxy.com是一个常用的GitHub文件代理。你也可以搜索“ollama 国内镜像”寻找其他可用的地址。如果镜像源设置错误，会导致拉取失败，届时需要移除此环境变量回退到官方源。

保存退出后，重新加载systemd配置并启动服务：

sudo systemctl daemon-reload sudo systemctl start ollama

3.3 拉取与运行模型

现在，可以拉取模型了。由于我们资源有限，明确指定1.3B版本：

ollama pull deepseek-coder:1.3b

这个命令会开始下载模型。有了镜像源，速度会快很多。下载完成后，你就可以运行它进行交互式对话了：

ollama run deepseek-coder:1.3b

进入交互界面后，你可以输入类似“用Python写一个快速排序函数”这样的问题来测试。

3.4 存储空间管理技巧

如果系统存储空间告急，你需要更改模型默认存储路径。假设你有一个挂载在/media/external_ssd的外部存储。

1. 停止Ollama服务：sudo systemctl stop ollama
2. 移动现有模型文件（如果有）：

   sudo mv /usr/share/ollama/.ollama /media/external_ssd/

3. 创建符号链接：

   sudo ln -s /media/external_ssd/.ollama /usr/share/ollama/.ollama

4. 重新启动Ollama服务：sudo systemctl start ollama

这样，后续所有模型都会存储在外接硬盘上。

4. 部署验证与API集成

让模型在命令行里跑起来只是第一步，我们更希望它能作为一个服务，被其他工具（如VSCode）调用。

4.1 以服务模式运行并验证API

Ollama默认会在启动服务时在11434端口开启一个REST API。我们之前已经启动了服务，现在来验证一下API是否可用。

首先，确保Ollama服务正在运行：sudo systemctl status ollama。

然后，使用curl命令测试API的生成接口：

curl http://localhost:11434/api/generate -d '{ "model": "deepseek-coder:1.3b", "prompt": "用Python写一个函数，计算斐波那契数列的第n项。", "stream": false }'

如果返回了一段包含代码的JSON响应，说明API工作正常。其中，stream: false表示我们想要一次性获取完整响应，而不是流式输出。对于调试，这样更直观。

4.2 配置远程访问（可选）

默认情况下，Ollama只监听本地（127.0.0.1）。如果你希望同一网络下的其他电脑也能访问这台Jetson上的大模型服务，需要修改监听地址。

我们之前已经在服务文件里设置了Environment="OLLAMA_HOST=0.0.0.0"，这会让Ollama监听所有网络接口。请务必注意，这样会使服务暴露在局域网中，存在一定安全风险。仅建议在可信的本地网络环境中使用。

修改并重启服务后，你可以从同一网络下的另一台电脑，使用Jetson设备的IP地址来访问API：

curl http://<你的Jetson IP>:11434/api/generate -d '{...}'

4.3 集成到VSCode（提升开发体验）

这才是生产力飞跃的关键。在你的开发电脑（可以是Windows、Mac或Linux）上安装VSCode，然后安装“Continue”或“Ollama”插件。这里以“Continue”插件为例，它功能强大且支持多种后端。

1. 在VSCode中安装“Continue”插件。
2. 按下Ctrl+Shift+P，输入Continue: 打开配置。
3. 在打开的config.json文件中，添加你的Ollama后端配置。假设你的Jetson IP是192.168.1.100：

{ "models": [ { "title": "Jetson DeepSeek Coder", "provider": "ollama", "model": "deepseek-coder:1.3b", "apiBase": "http://192.168.1.100:11434" } ] }

4. 保存配置。现在，在VSCode中选中一段代码，右键选择“Continue”的相应功能（如解释代码、生成注释等），它就会将请求发送到你的Jetson设备，并将模型返回的结果展示在VSCode中。这样，你就拥有了一个完全本地化、低延迟的AI编程助手。

5. 性能调优与监控

在资源紧张的边缘设备上运行大模型，监控和调优是保证体验的必要环节。

5.1 使用jtop监控资源

jtop是Jetson设备上最强的系统监控工具，可以直观看到CPU、GPU、内存、功耗、温度和各核频率。安装很简单：

sudo pip3 install -U jetson-stats

安装后，在终端输入jtop即可打开监控界面。在运行Ollama模型推理时，重点关注：

• GPU利用率：DeepSeek推理应该能利用到Jetson的GPU（尤其是Orin系列），你会看到GPU使用率上升。
• 内存使用：Mem和SWAP栏。如果内存接近占满，并且开始频繁使用SWAP，响应速度会急剧下降，这时就需要考虑换用更小的模型（如从3B换到1.3B）。
• 温度：长时间高负载运行，注意芯片温度是否在安全范围内（通常<85°C）。

5.2 Ollama运行参数调优

在运行ollama run时，可以附加一些参数来影响模型的行为和资源占用：

• --num-predict: 限制模型生成的最大token数量，防止它“滔滔不绝”消耗过多资源。例如ollama run deepseek-coder:1.3b --num-predict 256。
• --temperature: 控制输出的随机性（0.0到1.0）。值越低，输出越确定和保守；值越高，越有创造性。对于代码生成，通常设置较低的值（如0.2）以获得更稳定的结果。

这些参数也可以在API调用时通过JSON字段指定。

5.3 系统级优化建议

1. 关闭图形界面（针对无头服务器）：如果你通过SSH使用Jetson，不需要桌面环境，可以将其关闭以节省大量内存和CPU资源。运行sudo systemctl set-default multi-user.target然后重启。
2. 启用ZRAM：Jetson系统通常默认启用了ZRAM（一种压缩的内存交换技术）。你可以通过swapon命令查看。如果没启用，可以考虑启用它，这能在内存不足时提供一些缓冲，比直接使用磁盘SWAP快得多。
3. 电源模式：对于Jetson Orin系列，使用sudo jetson_clocks命令可以锁定CPU和GPU到最高频率，但会增加功耗和发热。在需要最高推理速度时使用，日常可以保持默认的平衡模式。

6. 常见问题与故障排除

在实际操作中，你肯定会遇到各种问题。这里记录了几个我踩过的坑和解决方法。

6.1 模型拉取失败或极慢

• 症状：ollama pull卡住不动，或报错连接超时。
• 排查：
  1. 检查网络连接：ping 8.8.8.8。
  2. 检查镜像源配置是否正确。执行sudo systemctl show ollama.service | grep Environment查看当前生效的环境变量。
  3. 尝试更换其他可用的国内镜像源地址。
• 解决：最直接的方法是取消镜像源，使用官方源配合代理（如果网络环境允许）。编辑服务文件，注释掉或删除OLLAMA_MODEL_SOURCE那一行，然后sudo systemctl daemon-reload && sudo systemctl restart ollama。如果必须通过代理，可以在系统层面配置http_proxy和https_proxy环境变量。

6.2 运行模型时内存不足（OOM）

• 症状：运行ollama run或调用API时，进程被杀死，系统日志（dmesg）中出现Out of memory错误。
• 排查：运行jtop或free -h查看可用内存。在拉取或加载模型前，内存是否已经所剩无几？
• 解决：
  1. 换更小的模型：这是最有效的办法。从deepseek-coder:6.7b降到:3b或:1.3b。
  2. 关闭其他占用内存的进程。
  3. 增加SWAP空间：虽然慢，但可以缓解。创建一个4GB的SWAP文件：

     sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile # 要永久生效，需将 `/swapfile none swap sw 0 0` 添加到 `/etc/fstab`

6.3 API调用返回400或404错误

• 症状：使用curl测试API时，返回400 Bad Request或404 Not Found。
• 排查：
  1. 400错误：通常是请求的JSON格式不对，或者model字段名称拼写错误。确保模型名与你用ollama list查看到的完全一致（包括大小写和tag）。
  2. 404错误：通常是API路径错误。Ollama的生成接口是/api/generate，聊天接口是/api/chat，确保路径正确。
  3. 检查Ollama服务是否真的在运行：sudo systemctl status ollama。
  4. 检查防火墙是否屏蔽了11434端口（Jetson默认的UFW防火墙是关闭的，但如果你启用了需要放行）。
• 解决：仔细核对请求命令。一个最简单的测试命令是：curl http://localhost:11434/api/tags，这个接口不需要请求体，会返回已拉取的模型列表，用于确认服务连通性。

6.4 推理速度非常慢

• 症状：模型能运行，但生成一个简单的回答都要几十秒。
• 排查：
  1. 用jtop查看GPU是否被使用。如果GPU利用率为0，说明模型可能在CPU上运行，速度必然慢。
  2. 检查是否正在使用SWAP（jtop中SWAP使用率是否很高），一旦开始用SWAP，速度会断崖式下降。
  3. 检查CPU频率是否被限制在低功耗模式。
• 解决：
  1. 确保GPU加速：Ollama默认会尝试使用GPU。如果没使用，可能是CUDA环境有问题。可以尝试重新安装JetPack的CUDA组件，或者查阅Ollama的GitHub Issue看是否有针对Jetson的特定问题。
  2. 释放内存：关闭不必要的进程，确保模型有足够的内存运行，避免触发SWAP。
  3. 调整电源模式：对于Orin设备，尝试sudo jetson_clocks提升性能（注意散热）。

这套流程走下来，你的reComputer Jetson就不再只是一个边缘AI推理设备，更是一个承载了大型语言模型的私有化智能终端。虽然受限于算力，它无法与云端大型号媲美速度，但在离线环境、数据安全要求高的场景，或者作为一个随手可得的代码“小助手”，其便利性和实用性是无可替代的。最关键的是，整个过程充满了动手的乐趣，让你对边缘计算和模型部署的理解更深了一层。