看起来你遇到的这个问题挺挠人的——明明按8核来算，200%的CPU限制只用到2核，剩下6核理论上完全够SSH这类系统进程跑，但实际就是会断连，常规的保活配置还不管用。我给你捋几个实际排查和解决的方向，都是玩单板机跑LLM踩过的坑：

• 先确认cpulimit是不是真的限制对了所有进程
  很多LLM框架（比如llama.cpp、text-generation-webui）跑起来会生成多个子进程，如果你只给主进程加了cpulimit，子进程可能会偷偷跑满其他核。你可以先跑ps aux | grep [你的LLM进程名]看看有没有一堆相关进程，要是有的话，别用单PID限制，改用进程名来限制整个进程组：cpulimit -e [LLM进程名] --limit=200，这样所有关联进程都会被限制住，不会出现漏网之鱼抢CPU的情况。

• 排查I/O负载过高的问题
  跑LLM的时候加载大模型、生成输出，要是用的是SD卡或者慢eMMC，磁盘I/O很容易拉满到100%，这时候系统会因为I/O阻塞，连SSH进程的响应都卡超时。你可以在跑LLM的时候开个终端输iostat 1，看看%util是不是一直飘在90%以上。要是这样的话，要么把模型移到USB3.0 SSD上，要么给模型做4bit/8bit量化，减少磁盘读写压力，也能省内存。

• 检查是不是内存不足被OOM杀了SSH进程
  有时候LLM吃内存太狠，系统内存不够就会触发OOM Killer，把占用内存少的系统进程（比如SSH相关的）先杀掉。你可以输dmesg | grep oom-killer看看日志里有没有相关记录，要是有的话，要么加个swap分区救急：

  fallocate -l 8G /swapfile
  chmod 600 /swapfile
  mkswap /swapfile
  swapon /swapfile
  

  要么换个更小的量化模型，别硬扛大模型。

• 重新配置双向SSH保活
  你之前加的保活可能只配了客户端或者服务器端？得双向配置才稳：
  服务器端（Orange Pi的Ubuntu22）编辑/etc/ssh/sshd_config，加上：

  ClientAliveInterval 10
  ClientAliveCountMax 3
  

  然后重启sshd：systemctl restart sshd
  客户端（你的Ubuntu24）编辑~/.ssh/config，加上：

  ServerAliveInterval 10
  ServerAliveCountMax 3
  

  这样两边主动发心跳，比单向保活靠谱多了。

• 试试用taskset硬绑定CPU核，比cpulimit更精准
  cpulimit是动态限制CPU使用率，有时候调度还是会抢核，不如直接把LLM进程绑定到固定的几个核，剩下的核全留给系统。比如把LLM绑定到0、1这两个核：taskset -c 0,1 [你的LLM启动命令]，这样核2到7完全归系统用，SSH进程根本不会和LLM抢资源，断连的概率会低很多。

• 排查CPU过热降频/锁核的问题
  单板机散热本来就弱，跑LLM的时候CPU温度飙升，很容易触发热 throttling，甚至临时锁核，导致系统响应变慢。你可以输sensors看看实时温度，要是超过85度，赶紧加散热——换个带风扇的散热片，或者把机器放通风的地方，温度下来了CPU调度才会稳定。

备注：内容来源于stack exchange，提问作者ekcrisp