跳转到主要内容
创建 experiments/my-grpo/，配置继承自该方法的模板，附一份记调参笔记的 README，以及一个钉住 方法版本的 lock 文件。这一步还不涉及 GPU。

​
开始之前

在一个项目里运行它。tp init my-lab --yes 建一个，之后每条需要项目的命令都会从当前目录向上找 tuneplane.yaml。
tuneplane.yaml 里的 name 就是控制台归拢你作业的那个项目。字符限于 [A-Za-z0-9._-]。提交时 不要传 --project，它来自这里。 在 CI 里设 TUNEPLANE_CLIENT_REPO_ROOT，而不是切目录。tp login、tp logout 和 tp status 是全局的，不需要项目。

​
一个实验里有什么

custom/custom 实验还会有 train.sh，那是它唯一的入口。你可以在旁边放一个 train.py。 tp plugin install … --exp 会加上 plugins.lock.json。 lock 文件就是方法。往目录里放一个 framework 文件不会有任何作用。

​
只写差异

一个实验继承官方基线，只保留你改动的部分：
experiments/my-grpo/config.yaml
并行度、显存调优和 NCCL 设置不在这个文件里。它们在你传 --profile 时从服务端硬件注册表 过来，所以同一个实验换到另一种卡型不用改一个字。分层怎么解析见 config.yaml。 脚手架最上面有一段注释，列出人们改得最多的键和有用的取值范围。

​
从一个已经能跑的实验出发

复制源实验的配置和它的 lock。--method 被忽略，因为 lock 跟着一起来了。

​
排队之前先校验

对照方法声明检查四件事： tp submit 会跑同一套校验。--no-validate 跳过它，代价通常是排一次队再看到同一个错误。

​
看你能调什么

控制台的方法页是同一份目录，多一个搜索框。

​
实验目录里还能放什么

​
确认成功

tp validate my-grpo 没有报错，且 experiments/my-grpo/recipe.lock.json 里写的是你要的方法。 然后提交它。

​
下一步

config.yaml 继承 · 提交作业 · 参数扫描
tp submit 记录 commit，工作树不干净时会拒绝，除非你加 --allow-dirty。这就是你六个月后 读一个结果、还能知道是哪份代码产生它的原因。提交本身不要求有 git。没有仓库时，这次运行以”无 commit”记录下来，而且文件清单的来源变了： 不再是 git 应用 .gitignore，而是按平台内置的排除规则遍历，超过 64 MB 直接拒绝，这样一个 checkpoint 目录不会悄悄变成一次上传。项目确实要带很大的东西时，用 TUNEPLANE_CLIENT_MAX_PACKAGE_MB 抬高这个上限。