把云服务器变成我的第一台科研实验机
刚进入浙江大学软件学院读研的时候，我对“服务器”这件事其实没有太多概念。
本科做课程作业时，我基本都是在自己的电脑上完成。需要 Python 就装 Python，需要新的库就直接 pip install。如果项目跑不起来，大不了重新建一个虚拟环境。那时候项目周期短，代码也不复杂，所以这种方式虽然有点乱，但问题不算大。
开始读研之后，我接触到了一些多模态 Agent 相关的实验。任务逐渐变成了数据预处理、模型调用、Agent 多轮执行、结果保存和自动评测混在一起。有些实验一次会跑很久，如果全部放在自己的笔记本上，就比较麻烦。
我真正开始认真使用云服务器，也是因为这个原因。
一、找一台“不会关机的电脑”
最开始我的想法其实很简单：本地电脑不可能一直开着，那就租一台服务器跑程序。
我在阿里云上创建了一台 ECS，操作系统选择了自己比较熟悉的 Ubuntu。刚拿到服务器的时候，我做的事情也很普通：连接 SSH，安装 Git、Python，再把自己的项目拉下来。
git clone xxx
cd project
pip install -r requirements.txt
python main.py
第一次跑通的时候，我甚至觉得云服务器也没有什么特别的，无非就是换了一台远程电脑。
但很快就踩了第一个坑。
有一次我直接在 SSH 窗口里运行实验，程序预计要跑几个小时。我看到程序已经正常运行，就去做别的事情了。后来本地网络断了一次，再重新连接服务器时，才发现之前的任务已经没了。
这件事现在看起来很基础，但当时确实给我上了一课。
后来我开始使用 tmux：
tmux new -s exp1
python main.py
即使 SSH 断开，程序还是会继续执行。第二天重新登录之后，再用：
tmux attach -t exp1
就可以继续查看运行情况。
对第一次真正长期使用服务器的人来说，这种经验其实比记住多少云产品名称更有用。
二、比“程序能运行”更麻烦的是环境
第二个问题来自 Python 环境。
我一开始还是沿用本地开发的习惯，缺什么库就安装什么库。
今天：
pip install transformers
明天：
pip install accelerate
再过几天换另一个项目，又开始调整版本。
一段时间以后，我自己都不太清楚服务器里的环境到底是什么状态。
有一次项目本来可以正常运行，我升级了其中一个包之后，另一个依赖开始报版本冲突。折腾了一段时间之后，我才意识到：服务器虽然稳定，但如果环境本身没有管理好，稳定也没有意义。
后来我给不同项目分别建立虚拟环境，同时把依赖写进 requirements.txt。对于需要重复部署的项目，我又进一步尝试使用 Docker。
例如一个非常简单的 Dockerfile：
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "main.py"]
这件事最大的好处不是让程序变快，而是我终于不用每次都回忆：
上次这个项目到底装了哪些东西？
现在至少环境本身是可以重新建立的。
三、第一次理解安全组
还有一个印象比较深的问题是端口。
当时我在服务器上启动了一个简单的 Web 服务，本地一直访问不了。我检查了程序，也确认服务已经监听端口，但浏览器就是打不开。
后来才发现问题根本不在代码，而是在 ECS 的安全组。
服务器内部启动一个服务，并不代表公网就一定能够访问。还需要根据实际情况配置对应的入方向规则。
这也是我第一次比较直观地理解安全组的作用。
一开始为了方便，我甚至想过直接开放一个很大的端口范围。后来想了想还是没有这么做，只开放真正需要的端口。
SSH 也是一样。
以前我会觉得服务器反正就是自己用，安全问题离我比较远。但真正把自己的代码、API Key 和实验数据放到云端之后，就会开始在意这些事情。
例如我原来有过直接把 Key 写进 Python 文件里的习惯：
API_KEY = "xxxxxx"
后来改成从环境变量读取：
import os
api_key = os.getenv("API_KEY")
现在再回头看，这些都不算复杂的技术，但确实是我开始使用 ECS 之后才慢慢养成的习惯。
四、有选择的把事情搬到云上
刚开始使用 ECS 时，我也想过把整个开发流程全部搬到服务器上。
后来发现没有必要。
我现在更习惯把任务分成两部分。
本地主要负责：
- 写代码
- 看论文
- 调试一些小模块
- 查看实验结果
- 做可视化
ECS 主要负责：
- 长时间运行的程序
- 数据预处理
- 批量实验
- Agent 多轮任务
- 日志保存
- 自动评测
这样做以后体验反而更好。
例如我在本地修改代码，提交到 Git，然后服务器拉取最新版本运行。实验不需要一直占着自己的电脑，我也不用因为程序正在运行就不敢关机。
我觉得这个过程和“买了一台更好的电脑”还是不太一样。
云服务器真正解决的是：
让一个需要持续运行的实验，有一个稳定的位置。
五、开始给每次实验留记录
做研究和完成一次课程作业最大的区别之一，是同一个实验通常不会只跑一次。
比如修改 Prompt、修改 Agent 的最大执行步数、更换模型，最后都要进行对比。
一开始我的结果目录非常混乱：
result.json
result2.json
result_new.json
result_final.json
result_final2.json
这种命名方式非常真实，也非常难用。
过一段时间以后，我已经分不清哪个文件对应哪个实验。
后来我开始按实验名称保存：
experiments/
├── exp_001/
│ ├── config.yaml
│ ├── result.json
│ └── run.log
├── exp_002/
│ ├── config.yaml
│ ├── result.json
│ └── run.log
配置文件里面记录一些关键参数：
model: xxx
temperature: 0.2
max_steps: 8
dataset: test
这样做没有什么技术难度，却给后面的实验对比省了很多麻烦。
因为现在如果一个实验表现异常，我至少可以重新找到当时使用的参数和日志，而不是只能凭印象猜。
六、我没有一开始就追求最高配置
阿里云这次活动中推荐了搭载 AMD Turin 处理器的 u2a 实例。从产品角度看，高性能 CPU 对数据处理、并发任务和一些 CPU 密集型工作当然有价值。
但在我自己的实际使用中，我反而觉得选择云服务器之前应该先问一个问题：
我的程序到底慢在哪里？
如果实验的大部分时间都消耗在等待外部模型 API 返回，那么单纯增加 CPU 核数不一定会带来非常明显的提升。
如果任务主要是图片解码、数据预处理、并行评测或者大量 CPU 计算，那么更强的处理器才更容易体现价值。
这一点对学生尤其重要。
科研经费和个人预算都是有限的。高配置当然很好，但如果买了一台很强的实例，大部分时间却处于空闲状态，其实也是一种浪费。
所以我现在更倾向于先使用合适的配置完成开发和小规模实验，真正需要大量计算的时候再调整资源。
我觉得这也是云服务器相比自己购买硬件比较方便的一点：配置并不是一次决定以后就不能再变。
七、这次实践没有让我“科研效率提升几倍”
如果一定要给这次使用 ECS 的体验写一个很夸张的结论，例如“科研效率提高了 300%”，我自己反而觉得不真实。
因为服务器并不能替我想研究问题，也不能让一个错误的实验变成正确的实验。
它解决的是一些更具体的小问题。
例如：
- 以前实验跑几个小时的时候，我会担心电脑休眠或者网络变化
- 现在程序放在 ECS 上以后，我可以直接关掉自己的电脑
- 以前不同项目的 Python 环境容易混在一起
- 现在我会主动维护 requirements 或 Docker 环境
- 以前一次实验结束以后，只留下一个结果文件
- 现在我会顺手保存配置、日志和运行结果
这些变化单独看都不大，但对一个刚开始做科研的研一学生来说，还是比较明显的。
八、我对“云上科研”的理解发生了一点变化
我最开始觉得云服务器的价值就是“算力”。
真正用了之后，我反而觉得对于研究生早期阶段，稳定性和可复现性可能更加重要。
很多时候，科研里最浪费时间的事情不是程序多运行了十分钟，而是：
过了两周，突然发现自己已经不知道之前那个结果是怎么跑出来的。
或者换了一台机器之后，环境再也装不回去了。
又或者实验跑到一半因为 SSH 断开，需要重新开始。
这些事情不会出现在论文的方法图里，却会真实地影响每天的工作。
这次使用阿里云 ECS 的过程对我来说并不是一次特别复杂的云计算项目。我没有搭建大规模集群，也没有训练一个非常大的模型。
我做的事情更像是把自己的科研流程稍微整理了一遍：
- 把运行时间比较长的程序放到云端
- 把环境固定下来
- 把实验结果留下来
- 把代码、配置和日志分清楚
作为一名刚开始研究生生活的新生，我觉得这可能比一开始就追求复杂的技术架构更加实际。
以后如果实验规模继续变大，我可能还会继续尝试对象存储、自动化任务或者更高性能的实例。
但至少现在，这台 ECS 已经不再只是我最开始理解的那台“不会关机的远程电脑”。
它更像是我科研过程中第一台真正意义上的实验机。
