Jetson Nano 跑 Ollama 这种极限操作，显存不够真的会直接让系统原地崩溃
为了在 Jetson Nano 上跑那个 AI 复习卡片生成任务，我差点被显存溢出搞到心态爆炸。这设备内存实在太紧巴了，如果不预先手动搞个 Swap 分区当“救命稻草”，模型加载的一瞬间系统基本就挂了。
下一篇
Agent逻辑错位导致的“伪指令”陷阱与校验方案 →
我原本想试试 Llama 3.2，结果实测数据直接打脸。我用 OSI 模型知识做了一套测试集，对比了不同量化版本的准确率，结果发现量化权重越低，智商掉得越离谱。特别是那个 qwen3.5:2b，量化到 q4_K_M 居然直接给我输出空白，这很不稳定。
Model | Quant | Accuracy
qwen2.5:3b-instruct | q4_K_M | 100%
qwen2.5:3b-instruct | q5_K_M | 100%
qwen2.5:3b-instruct | q8_0 | 100%
qwen3.5:2b | q4_K_M | 0% (空输出)
llama3.2:3b-instruct | q2_K | 40%
llama3.2:3b-instruct | q4_K_M | 90%
llama3.2:3b-instruct | q8_0 | 90%
mistral:7b-instruct | q2_K | 80%
mistral:7b-instruct | q4_K_M | 100%看这个数据我当时挺纳闷的，结果跑下来发现 qwen2.5:3b-instruct 在这个特定任务上的表现竟然是满分，跟其他模型完全不是一个量级的。
折腾这一圈我明白了一个道理：在边缘计算这种资源受限的场景下，别迷信什么大厂 Benchmark，盯着显存占用和特定任务的实测准确率才是硬道理。
# 还没设 swap 的 Nano 用户别急着跑，否则必崩
建议先测试这个模型
ollama run qwen2.5:3b-instruct