目录
[一、使用 python app.py 运行脚本但命令无法被识别](#一、使用 python app.py 运行脚本但命令无法被识别)
[二、使用 python3 app.py 运行脚本但报错缺少依赖库 streamlit](#二、使用 python3 app.py 运行脚本但报错缺少依赖库 streamlit)
三、服务器的Python版本与项目支持的Python版本不一致，能不能直接替换？
[四、在EmoLLM项目主目录下使用python3 -m venv venv命令时报错权限不够（Permission denied）](#四、在EmoLLM项目主目录下使用python3 -m venv venv命令时报错权限不够（Permission denied）)
[五、在自己的家目录的EmoLLM项目下使用python3 -m venv venv命令创建虚拟环境失败](#五、在自己的家目录的EmoLLM项目下使用python3 -m venv venv命令创建虚拟环境失败)
六、在venv虚拟环境下安装依赖库报错，某个依赖(metagpt)需要的Python版本与当前版本不一致
[七、使用 pip 安装 requirements.txt 里的依赖库时因为网络超时问题安装失败](#七、使用 pip 安装 requirements.txt 里的依赖库时因为网络超时问题安装失败)
[八、使用 pip 安装 requirements.txt 里的依赖库时因为服务器空间不够报错](#八、使用 pip 安装 requirements.txt 里的依赖库时因为服务器空间不够报错)
[九、使用 pip 安装 requirements.txt 里的依赖库结果失败了，会不会影响重新安装？](#九、使用 pip 安装 requirements.txt 里的依赖库结果失败了，会不会影响重新安装？)
Δ前言
1.EmoLLM介绍：
(1) EmoLLM是Github上开源的一个大模型落地应用，是一个专注于心理健康领域的大语言模型（LLM）。项目不但采用了多个业界主流的开源大模型作为基座，包括 InternLM2 系列 (20B, 7B, 1.8B)、Qwen、Deepseek、GLM、Llama 等，还广泛应用了多种微调策略如全量微调 (Full Fine-tuning) 和LoRA / QLoRA 这些高效参数微调技术 。
(2) EmoLLM的目标是实现 理解用户、支持用户、帮助用户的心理健康辅导链路。项目强调了三大特质：温暖 (Warm)、共情 (Sympathetic)、支持 (Supportive)。
(3) 最开始这个项目是由南开大学 的一个竞赛团队整出来的，在2024浦源大模型系列挑战赛春季赛中得到了创新创意奖 ，也确实比较创新。后来这个团队本着开源精神就把这个项目放在Github了。一开始也没多少人关注，后来这个项目越来越火，截至2025年国庆，Github上开源的项目已经有超过1600stars了，甚至学术界也出现了一些成果，可以预见在不远的将来，这个项目会越来越火。Github链接如下图所示：
2.部署的要求：
(1) 本地部署大模型对硬件 的要求比较高，所以最好是在一台服务器上进行远程部署 ，具体的部署教程官方团结已经在Github进行了详细说明，链接如下：https://github.com/SmartFlowAI/EmoLLM/blob/main/quick_start/quick_start.md
https://github.com/SmartFlowAI/EmoLLM/blob/main/quick_start/quick_start.md (2) 远程部署 需要有 sudo权限的用户，因为如果要安装一些工具包或者依赖库的时候需要用到 sudo权限。
(3) up的情况是这样的------在up部署之前已经有负责人进行了部署，但是由于被错删了几个文件，EmoLLM项目跑不起来，up的目的就是让项目重新跑起来，重新完成部署工作。鉴于官方团队已经给出了详细的部署过程，本篇博文将侧重于在部署过程中可能遇到的一些问题，并提供对应的解决方案。
(4) 这篇博文 up 花了很大心思，因此会设置成粉丝可见，up在CSDN上写了这么多文章，但是粉丝可见的文章不超过十篇，只有up非常用心且非常满意的文章才会设置为粉丝可见，还望大家理解，感谢阅读！
一、使用 python app.py 运行脚本但命令无法被识别
1.问题描述及原因：
在项目官方的部署教程中提到，最后一步是使用 python app.py 来运行模型对应的脚本，模型启动后即可通过浏览器来访问。但是当我们在服务器上使用 python app.py 命令时，出现了如下图所示的问题：
在过去，Linux 系统里同时存在着老旧的 Python 2 和新的 Python 3。为了区分它们，python 这个命令通常指向 Python 2，而 python3 指向 Python 3 。
而现在，Python 2 已经完全被淘汰了。为了避免混淆和让旧脚本出错，很多新的现代 Linux 系统（特别是 Ubuntu） 干脆就不再默认设置 python 这个命令了。所以我们必须明确的使用 python3 来告诉服务器"我要用的是Python3的版本"。图片里面也可以看到服务器给我们的提示------"您的意思是：command 'python3'？"。使用"python3 --version"命令可以看到服务器当前系统使用的Python版本是 Python3.8.10。
2.解决方案及步骤：
改为 python3 app.py 来运行模型对应的脚本。
由于EmoLLM的部署要求是Python 3.11.5这个版本，和我们服务器上的Python 3.8.10版本不匹配，所以更可能的情况是项目不是直接运行在系统环境下的，而是运行在一个独立的虚拟环境（例如 Conda）中。
以 Conda 为例，首先通过 conda --version 命令来查看当前的Conda版本，如果显示了版本号（比如 conda 4.12.0），说明 Conda 存在；接着运行 conda env list ，这个命令会列出服务器上所有的环境名称和路径，如果找到了 emollm 相关的虚拟环境，就通过 conda activate emollm 命令来激活它。不过up部署的这台Linux服务器上并没有安装 Conda，所以后来up是用 venv来配置的虚拟环境（请看后面的问题）。
二、使用 python3 app.py 运行脚本但报错缺少依赖库 streamlit
1.问题描述及原因：
从 python app.py命令 改成 python3 app.py 命令，但是运行模型后提示缺少streamlit，如下图所示：
streamlit 是一个用来快速搭建 Web 页面的 Python 库，这个项目的前端界面就是用它做的。not found 表示当前使用的这个 Python 3.8.10 环境（也就是系统的"大环境"）里，根本没有安装 streamlit 这个工具。这更加证明了，我们不能直接用系统的 python3 来运行这个项目。项目必须在一个已经安装了所有依赖库 （比如 streamlit）的独立"小环境"里运行。
而 python: not found 则说明 app.py 这个脚本内部，尝试去调用一个名字叫 python 的命令，但是我们之前已经知道了，服务器的Ubuntu系统里只有 python3，没有 python。
2.解决方案及步骤：
因为我们已经确定了服务器上没有安装 Conda ，但是根据目前的线索又有理由推理服务器上存在一个为 EmoLLM 项目专门配置的、独立的 Python 虚拟环境。那到底有没有呢？
如果不是 Conda，那么最可能的就是 Python 自带的虚拟环境工具 venv，用 venv 创建的环境，通常就是一个文件夹 ，它就藏在项目目录里。
我们可以通过在 EmoLLM-main 目录下运行 ls -la 命令，并仔细查看列出的所有文件和文件夹，看是否有 venv, env, .venv 这种看起来像是环境相关的文件夹，如果找到了，就通过 source 找到的文件夹名/bin/activate 命令来激活它，激活成功的标志就是命令行的前面会出现一个**(venv)**标识。
这里再来补充一下 ls, ls -l, ls -a 和 ls -la 这些命令有什么区别------
(1) ls : list ，用于列出当前目录（或指定目录）下的非隐藏文件和目录的名称。默认情况下，它不会显示以 .开头的隐藏文件和目录，它只显示名称 ，并且也不提供详细信息（如权限、所有者、大小、修改时间等）。ls 命令的返回结果通常是以多列的形式显示，并可能根据文件类型显示不同的颜色。
(2) ls -l ：list long format ，它的用途是以长格式（详细信息）列出当前目录（或指定目录）下的非隐藏文件和目录。ls -l 在 ls 的基础上，增加了文件或目录的详细信息，但仍然不会显示以 .开头的隐藏文件和目录 ，每个文件或目录各自占据输出结果的一行。
使用 ls -l 后会发现，输出的每条记录的最前面都有十个字符，其中，第一个字符用于表示文件的类型，具体类型如下表所示：
| 第一个字符 | 所代表的类型 |
|---|---|
| - | 普通文件 |
| d | 目录 |
| l | 符号链接（软链接） |
| b | 块设备文件 |
| c | 字符设备文件 |
| p | 命名管道 |
| s | 套接字文件 |
第一个字符后面的连续九个字符表示权限：分为三组，每组三个字符 。具体表示内容如下：
第一组：文件所有者 的权限 (rwx = 读写执行)
第二组：文件所属组 的权限 (rwx = 读写执行)
第三组：其他用户的权限 (rwx = 读写执行)
前十个字符之后分别是：
1.一位类型 + 九位权限
2.硬链接数：文件或目录的硬链接数量。
3.所有者：文件或目录的所有者用户名。
4.所属组：文件或目录所属的组名。
5.文件大小：文件的字节数（默认）。
6.最后修改时间：文件或目录的最后修改日期和时间。
7.文件/目录名：文件或目录的名称。
eg : ++-rwxr-xr-x 1 user group 120 Sep 25 10:10 script.py++
再补充一个重要的 Linux 知识点------在Linux中，ls -l 显示的文件夹大小，只是文件夹这个"目录文件"本身的大小，而不是里面所有文件的总大小。无论文件夹里装了1KB还是100GB的文件，这个目录文件本身的大小通常都只是4KB。如果想计算文件夹内所有文件的总大小 ，应该使用 du -sh <文件夹名> (disk usage)命令。
(3)**ls -a : list all，用于列出当前目录（或指定目录）下的所有文件和目录，包括隐藏文件和目录** 。ls -a 命令其实就是在 ls 的基础上，增加了显示隐藏文件和目录的功能，但不会提供详细信息，而是只显示名称。ls -a 会显示两个特殊的隐藏目录 ：. (代表当前目录 ) 和 .. (代表父目录)。
(4)**ls -la：list long all，其实就是结合了前面的 -l 和 -a 选项，以长格式（详细信息）**列出当前目录（或指定目录）下的所有文件和目录，包括隐藏文件和目录。这种方式是最全面的一种列表方式，因为它既显示所有文件（包括隐藏文件），又提供详细信息。
ls -la 的示例输出如下图所示：
up通过 ls -la 命令查找后，发现想找的 venv 或 env 文件夹确实不存在。这可以说明原先的负责人没有在项目文件夹内部创建任何虚拟环境。
三、服务器的Python版本与项目支持的Python版本不一致，能不能直接替换？
1.问题描述及原因：
刚才我们看到服务器的Python版本是 3.8.10，而部署 EmoLLM 需要的Python版本是 3.11.5；既然 Python 版本不匹配，为什么我们不设法将服务器的Python版本卸载掉，然后重新装一个 3.11.5 的Python，这么一来不就匹配了吗？
2.解决方案及步骤：
虽然 Python 3.8.10 是这台 Ubuntu 服务器的系统级 Python 版本， 但是它是操作系统自带的，很多系统底层的工具和服务（比如 apt 包管理器、防火墙脚本等）都依赖它。
所以我们绝不能把它卸载、换成Python 3.11.5。请记住------永远，永远不要去修改或卸载系统自带的 Python。这是在服务器上最危险 的操作之一，动了它，轻则某些软件无法使用，重则整个操作系统都会崩溃，甚至可能导致我们无法再进行远程登录。
在服务器上，我们永远不应该动系统的 Python。正确的做法是：为我们的项目创建一个独立、干净、版本正确的 Python 环境。 这就是为什么我们之前要查看系统有没有安装 conda，有没有创建好 venv 虚拟环境。既然找不到现成的，那么最可靠的方法就是------**我们自己来创建一个！**如果你接手了一个不完整的项目，那么与其苦苦挣扎于寻找一个不存在的环境，不如我们自己动手，按照官方在 Github 上的部署教程，干净利落地把环境配置好，这不仅能解决问题，还能让我们更好地掌握整个项目的部署流程。
首先确保我们还处于项目目录/EmoLLM-main下，然后使用系统的 python3 (3.8版本) 创建一个名为 venv 的虚拟环境，指令为 python3 -m venv venv，执行这条命令后，你会发现当前目录下多了一个 venv 文件夹，venv 就是我们的"独立小环境"。
接着，用 source venv/bin/activate 命令激活虚拟环境，如果执行后看到命令行前面出现了 (venv)，表示我们已经进入了创建的虚拟环境中。在虚拟环境中通过 pip install -r requirements.txt 命令安装所需要的各种依赖库，现在这个pip是虚拟环境独有的，不会影响到系统，当然，下载依赖库这一步会下载并安装 requirements.txt 文件里列出的所有库（包括 streamlit 等），可能要花费几分钟甚至十几分钟往上。
四、在EmoLLM项目主目录下使用python3 -m venv venv命令时报错权限不够（Permission denied）
1.问题描述及原因：
当up在EmoLLM-main所在的目录使用 python3 -m venv venv 命令安装依赖库时，报错 Permission Denied，如下图所示：
权限不够，这是因为我们当前登录的用户和项目所在的用户目录不一致，在 Linux系统中，为了安全，默认情况下，一个普通用户是不能在另一个用户的家目录里随意创建文件或文件夹的。当我们执行 python3 -m venv venv 这个命令，本质上就是要创建一个名为 venv 的新文件夹。系统检查了一下，发现up居然想在其他用户的目录下"搞事儿"，于是立刻拒绝了up，并告诉up"权限不够"。这其实完全是正常的，也说明服务器的权限设置是正确的。
2.解决方案及步骤：
既然不能在其他用户的目录下直接修改文件，那我们就回自己的用户目录下操作。最好的做法是把整个项目复制到自己的家目录 (/home/cyan) 下（cyan用户就是up），然后在自己家目录里完成所有的配置。
首先，输入 cd 回到自己的家目录，然后输入 pwd 命令（print working directory 打印当前工作目录，注意打印的是绝对路径 ），我们会看到当前目录已经在 /home/cyan 了。
然后，把项目文件夹完整地复制过来，命令："cp -r /home/用户名/EmoLLM-main ."（注意，这个命令最后有一个点 .），其中 cp 表示复制；-r 表示递归复制，会把整个文件夹和里面的所有东西都复制过来；最后的 **.**表示复制到当前目录（也就是当前登录用户---cyan的家目录）。因为项目和模型文件很大，所以整个复制过程可能会持续几分钟以上。
接着，执行下面的命令：
bash
# 进入到项目主目录
cd EmoLLM-main
# 创建虚拟环境
python3 -m venv venv
# 激活环境
source venv/bin/activate最后在虚拟环境（venv）中安装所需的依赖库并运行项目，具体命令如下：
bash
# 安装所有依赖
pip install -r requirements.txt
# 运行！
python app.py五、在自己的家目录的EmoLLM项目下使用python3 -m venv venv命令创建虚拟环境失败
1.问题描述及原因：
当up已经将完整的EmoLLM项目拷贝到了自己的家目录，然后运行 python3 -m venv venv 命令时，又报错了安装虚拟环境失败，如下图所示：
报错信息"++The virtual environment was not created successfully because ensurepip is not available.++ " 它的意思是 "虚拟环境创建失败了，因为一个叫做 ensurepip 的核心工具不见了。"
后面又紧接着给出了我们提示 "++On Debian/Ubuntu systems, you need to install the python3-venv package...++ "，它的意思是 "在这台 Ubuntu 服务器上，你需要安装一个叫 python3-venv 的软件包来找回这个工具。"。
这意味着，系统管理员在安装 Python 3.8 的时候，也许是为了节省服务器的硬盘空间，只安装了最核心的运行部分，却没有安装用来创建虚拟环境的"扩展工具包 "（也就是 python3-venv）
2.解决方案及步骤：
既然报错信息已经顺便把解决方案给出了，那么我们需要的就是管理员权限了。正好up我有sudo权限。
首先在命令行中输入 sudo apt install python3.8-venv 命令，来安装venv工具包。执行指令后，系统会提示你输入密码 [sudo] password for cyan: ，我们就老老实实输入登录服务器的密码，注意，输入密码时屏幕上不会显示任何东西（连星号都没有），这是正常的安全措施，我们只管输完按回车就完事儿。接着，系统会告诉我们需要下载和安装一些东西，并问我们 Do you want to continue? [Y/n] ，这时候只需要输入一个大写的 Y，然后按回车即可。
安装 venv 成功后，我们就重新执行 python3 -m venv venv 命令，然后使用 source venv/bin/activate 命令来激活虚拟环境。这里再次强调一遍，激活虚拟环境成功的标志是------命令行提示符前面出现了 (venv) 提示符。
六、在venv虚拟环境下安装依赖库报错，某个依赖(metagpt)需要的Python版本与当前版本不一致
1.问题描述及原因：
当up通过sudo成功安装 venv 工具包，并成功进入创建好的虚拟环境 后，输入 pip install -r requirements.txt 命令安装依赖库，但是刚开始安装就报错了。如下图所示：
这次的报错信息是：ERROR: Package 'metagpt' requires a different Python: 3.8.10 not in '>=3.9'，它的意思是在安装 metagpt 这个库（它是 requirements.txt 清单里的第一个）时，系统发现 这个库要求的 Python 版本必须大于等于3.9 (>=3.9)，而当前环境的 Python 版本是 3.8.10 ，所以安装直接失败。 还记得我们刚开始说的"项目官方教程要求 Python 3.11.5 "吗？项目跑不起来的根本原因 ，从始至终就只有一个：Python 版本不对！
2.解决方案及步骤：
因为up有 sudo 权限，所以我们完全可以在不破坏系统原有 Python 3.8 的前提下，安装一个全新的、我们需要的 Python 3.11。
第一步，退出当前虚拟环境：deactivate 执行指令后会发现命令提示符前面的 (venv) 消失了。
第二步，删除旧的 venv 文件夹：rm -rf venv
第三步，使用 Ubuntu 官方推荐的 PPA 源来安全地安装 Python 3.11，注意，我们执行的命令 sudo apt install python3.11 用的是apt包管理器，它非常智能，不会 去动那个老的系统自带的 Python 3.8，而是会把 Python 3.11 作为一个全新的、独立的软件 安装到系统里。安装完成后，服务器上会同时存在 两个 Python，老的 python3 命令，仍然指向 python3.8；新的 python3.11 命令，专门指向我们新装的 python3.11。具体指令如下：
bash
# 1.更新软件包列表并安装 PPA 管理工具 (中间如果提示输入密码，就输入你的登录密码)
sudo apt update
sudo apt install software-properties-common
# 2.添加 deadsnakes PPA 源，这是一个专门提供新版本 Python 的可靠源
sudo add-apt-repository ppa:deadsnakes/ppa
# 3.安装 Python 3.11 和它对应的 venv 工具包
sudo apt install python3.11 python3.11-venv第四步，用全新的安装好的 Python 3.11 重新创建虚拟环境，具体指令如下：
bash
# 1.验证一下 Python 3.11 是否安装成功（应该能看到 Python 3.11.x 的输出）
python3.11 --version
# 2.使用 python3.11 来创建虚拟环境（文件夹名为 venv）
python3.11 -m venv venv
# 3.激活创建的虚拟环境（激活后将看到 (venv) 出现在命令提示符前）
source venv/bin/activate第五步，在虚拟环境下安装所需的全部依赖库并运行项目，具体指令如下：
bash
pip install -r requirements.txt
python app.py七、使用 pip 安装 requirements.txt 里的依赖库时因为网络超时问题安装失败
1.问题描述及原因：
当up在Python 3.11.13 对应的虚拟环境下运行 pip install -r requirements.txt 命令时，又报错了，如下图所示：
可以看到，pip 安装依赖库没有成功，原因在提示的最后，如下图所示：
可以看到核心的报错信息 ------"pip._vendor.urllib3.exceptions.ReadTimeoutError: HTTPSConnectionPool(host='files.pythonhosted.org', port=443): Read timed out"。它的意思是"pip 尝试从 files.pythonhosted.org 这个网站（这是 Python 官方的软件仓库服务器，在国外）下载一个文件时，连接等待时间太长了，超时了，所以安装失败。"
2.解决方案及步骤：
采用国内清华大学的镜像，把安装命令改为 "pip install -i https://pypi.tuna.tsinghua.edu.cn/simple -r requirements.txt"（前提是确保当前命令行仍处于虚拟环境下）。
八、使用 pip 安装 requirements.txt 里的依赖库时因为服务器空间不够报错
1.问题描述及原因：
up 用清华大学的镜像替换掉官方的软件仓库服务器后，网络超时问题解决了。依赖库开始飞速地下载，但就在即将收尾时，安装过程突然终止，并报错服务器空间不够了，如下图所示：
报错信息是：ERROR: Could not uninstall packages due to an OSError: [Errno 28] 设备上没有剩余空间，直白地说，这台服务器上 /hom 目录所在的硬盘被塞满了！
2.解决方案及步骤：
可以先用 df -h 命令来看看是哪个分区的硬盘满了，这个命令会列出所有硬盘分区的使用情况，根据报错信息不难推理出：一定存在某个分区，它的使用率是 100%。
下一步，可以使用两个十分安全的命令来尝试腾挪出一些空闲空间，具体命令如下：
bash
# 1.删除 pip 的缓存
rm -rf ~/.cache/pip
# 2.删除 apt 的缓存
sudo apt clean更牛逼的方式 ：因为我们当前的 EmoLLM-main 是从之前的用户那里拷贝 过来的，这里面包含了模型文件（模型文件会占用几十个G的存储空间 ），而模型文件会占用很大的空间，因此我们可以单独将项目中存放 模型文件 的那个文件夹删除掉，并通过软链接的方式，用一个快捷方式指向之前那个用户的 EmoLLM-main 项目里面的存放模型文件的那个文件夹。
按照这个思路，首先 ，删除掉存放模型文件的EmlLLM_model文件夹，具体命令如下：
bash
# The -r means "recursive" (delete folder and everything inside), the -f means "force" (don't ask for confirmation). Be very careful with this command.OK？
rm -rf ~/EmoLLM-main/EmoLLM_model这会直接为我们腾出几十个G的空间，然后 ，创建软链接，具体命令如下：
bash
ln -s /home/之前的那个用户的用户名/EmoLLM-main/EmoLLM_model ~/EmoLLM-main/EmoLLM_model其中，"ln -s" 表示创建软链接；"第一个路径" 代表目标路径target（也就是软链接要挂载到哪里），对应到我们这里，就是原来的用户部署的 EmoLLM-main 项目中的 EmoLLM_model文件夹；"第二个路径" 代表了这个软链接的名字，也就是所要创建的这个快捷方式的名称。
up通过这个方法直接腾挪出来59G的空间，妥妥足够安装剩下的依赖库了，直接一波 pip install -i https://pypi.tuna.tsinghua.edu.cn/simple -r requirements.txt 搞定！
九、使用 pip 安装 requirements.txt 里的依赖库结果失败了，会不会影响重新安装？
1.问题描述及原因：
如果某一次安装 requirements.txt 里面依赖库失败，那么这次失败会不会对下一次重新安装依赖库有影响？
2.解决方案及步骤：
完全不会。上一次的安装失败，对我们重新安装没有任何负面影响。 这是因为pip的功能很强大，当我们再次运行 pip install ... 命令时，pip 会做的第一件事，就是把 requirements.txt 上的每一项，和创建好的虚拟 venv 环境里已有的依赖库进行核对。
对于在上一次失败的尝试中，已经成功下载并安装好的库（比如 pip 可能在下载 sentencepiece 失败前，已经成功装好了其他几个小库），pip 会看到它们已经在了，并告诉你 Requirement already satisfied (需求已被满足)，然后直接跳过，不会重复下载安装。也就是说，pip 会接着处理那些上次没有成功安装的库。
Δ总结
- 🆗，以上就是博文的全部内容了，感谢阅读！
- 这篇文章主要是记录一下 up 在远程部署 EmoLLM 中的排错过程，自我感觉还是比较干货的哈哈😂。
- 后面如果还有 EmoLLM相关的创作思路，up还会尝试与大家分享，谢谢大家。
System.out.println("END-----------------------------------------");