Soup CLI Soup CLI是一款面向开发者的LLM微调工具，能在4GB笔记本GPU上高效微调8B模型，大幅降低显存需求。 热门评论 PH 用户我做了 Soup 是因为我有一台 4 GB 内存的笔记本，想微调一些装不下的模型。想法很简单。LoRA 时基础模型是冻结的，只读不写。所以它不必待在 GPU 里，它只需要在使用它的 matmul 之前到达就行。它待在系统 RAM 里，每次流入一个 decoder 层。难点不在速度，而在于证明它是对的。流式（streaming）会静默失败：切掉 autograd 路径后 loss 还是往下降，因为上层还在继续学。所以每次发布都会把流式运行和常驻运行做对比，要求 logits 完全一致。上周有人借了我 8 张 H100 用三天。这套协议在我自己发布的代码里发现了一个 bug：超过某个层大小后，梯度会悄悄出错，而 loss 曲线看起来很正常。我把它连同复现程序一起发了出去。所有东西都是 Apache-2.0，所有测量数据都在 repo 里，包括后来发现是错的那批。欢迎来问任何问题。PH 用户把后来发现是错的结果也发出来，这个细节很突出。我这个月也遇到了一个更小版本的情况：查看了三个真实站点的 AI Overview 流量，本来期待有点信号，结果全是零。诚实的做法就是把零也发出来，而不是只写那些成功的。关于流式方法有个问题：这个正确性检查——流式 logits 和常驻运行匹配——在已经 4-bit 量化的基础模型上也能成立吗？还是目前只在全精度上验证过？PH 用户@makazhanalpamys 逐层流式这个想法很妙，但真正让我信服的是那个正确性协议——要求流式运行的 logits 和常驻运行完全一致，因为“切断 autograd 路径后 loss 还是往下掉”正是大多数工具永远不会去查的那种静默失败。而且把 H100 发现的 bug（超过某个层大小后梯度悄悄出错，loss 曲线却很正常）连同复现程序一起发出来，还是在你自己的发布代码里，这比优化本身还少见。基准测试就是这样赢得信任的。在 3050 笔记本上用 3.32 GB 跑出 119.6 tok/s，对想在花钱用云 GPU 之前先在本地迭代的人来说，是一个真正有用的底线 👌 热门产品Alpamys Makazhan2026-08-09原文 打开互动版
想法很简单。LoRA 时基础模型是冻结的，只读不写。
所以它不必待在 GPU 里，它只需要在使用它的 matmul 之前到达就行。
它待在系统 RAM 里，每次流入一个 decoder 层。
难点不在速度，而在于证明它是对的。流式（streaming）会静默失败：切掉 autograd 路径后 loss 还是往下降，因为上层还在继续学。
所以每次发布都会把流式运行和常驻运行做对比，要求 logits 完全一致。
上周有人借了我 8 张 H100 用三天。这套协议在我自己发布的代码里发现了一个 bug：超过某个层大小后，梯度会悄悄出错，而 loss 曲线看起来很正常。
我把它连同复现程序一起发了出去。
所有东西都是 Apache-2.0，所有测量数据都在 repo 里，包括后来发现是错的那批。
欢迎来问任何问题。
而且把 H100 发现的 bug（超过某个层大小后梯度悄悄出错，loss 曲线却很正常）连同复现程序一起发出来，还是在你自己的发布代码里，这比优化本身还少见。基准测试就是这样赢得信任的。
在 3050 笔记本上用 3.32 GB 跑出 119.6 tok/s，对想在花钱用云 GPU 之前先在本地迭代的人来说，是一个真正有用的底线 👌