分类： 随笔

（2024.01）本文已过时，请参考：《【2024.01】目前好用的大语言模型以及部署情况》

之前在玩 Colab 和 Stable Diffusion，所以自然而然，也会进一步拓展到 LLM 领域。

说到底，我不算技术人员，甚至连炼丹师都算不上。以下内容不涉及什么具体的模型训练或者部署，只是结合试用和一些搜索到的资料，谈谈感受，没什么技术含量。

首先是个人应用方向，主要是 LocalLLM。从应用的角度来讲，公开的 OpenAI api、Bing、Bard、Claude 已经完全够用了，只有专业内容需要微调或者“非道德”内容才需要私人模型。

这里我主要关注 ~13B 或以下模型，原因是量化后能够在 Colab 上跑，根据 Steam 的统计，目前最主流的显卡还是 3060、2060、1060，分别对应 12G、12G、6G VRAM，也就是能跑 ~13B、~13B、~7B 模型。所以 ~13B 比较具有现实意义。

路径一：直接上中文模型

先来看几个 LeaderBoard：OpenCompass、C-Eval、HF-zh_models

可以看到，公开的模型中，能力比较强的有阿里的 Qwen-14B 和清华的 ChatGLM3-6B。
其中，Qwen-14B 有个变体版本：CausalLM-14B。这个模型使用了 Qwen-14B 的权重，加入一些其他数据集，最终搓了一个无审核的版本，经过量化后刚刚好可以在 Colab 上运行。
CausalLM 的表现实在过于优秀，所以截图不便放出。

ChatGLM3-6B 是 62 亿参数蒸馏+量化后 6G VRAM 就能跑，很有潜力，但可能不是未来。

还有一些模型，诸如商汤的 SkyWork-13B，vivo 的 BlueLM-7B，也在 trending 上，不过还有待更多验证。

路径二：用英文模型+LoRA

（2024/01）纠正：早期我理解 LoRA 是一个万能插件，实际上是错误的。应该说这个方案是在英文模型上用中文数据集再训练。现在靠这个方法汉化的好像不多见了，因为已经有了比较好的中文大模型基底。

第一条路其实已经足够好了，但还有其他选择。

第二条路是英文模型+LoRA，我试了下 Chinese-Wizard-Vicuna-13B-GPTQ，这是一个使用了来自科大讯飞 Chinese-LLaMA-Alpaca 的模型，总体效果还不错。能输出流畅的中文，但不如原生接地气。

　
创作能力大概强于 ChatGPT 3.5，和 Claude-Slack 持平。这效果已经非常不错了，再回头看 CausalLM 就能理解为什么不便放出，因为太过逆天。

如果单看 Chinese-LLaMA-Alpaca，评分并不算很好，但作为一个 LoRA，配合会中文（但中文不太好）的英文模型，效果就很不错。此外，我测试用的是一期模型，现在 Chinese-LLaMA-Alpaca 已经有了二代，扩展了词表，相信效果会更好。

同理，相信 UltraLM、Nous-Hermes、Pygmalion、Mistral 等模型加 LoRA 效果也会不错。我比较好奇的是，如果这个 LoRA 和 MLewd 结合会不会变得逆天。

这里再提两个 LoRA：
一是 Llama2-Chinese，号称“最好的中文Llama大模型”，我试下来实际效果不太好。
二是 SuperHOT，一个专注于 NSFW 的 LoRA。一些英文 Uncensored 模型（例如之前的 Wizard-Vicuna-13B-Uncensored-HF）在加入中文 LoRA 后会出现轻微的 Censored 迹象，可能可以通过这个 LoRA 纠正。

路径三：RWKV+Finetune

由于 Transformer 对内存的需求是二次方增长的，而 RWKV 对内存的需求只有 O(1)，这对于本地多轮对话至关重要。

RWKV 发展神速，我在写这篇文章的时候已经有 V5 占位了，其中一个值得关注的微调模型是 LocalNSFW/RWKV-Claude。从名字就能看出是干什么的，介绍是“项目的初心是，摆脱大公司的控制，建立所有人都能涩涩的本地大语言模型。”

这个模型的参数为 7B，数据来自用户贡献的和 Claude-Slack 的对话，可以归结为通过 Claude 蒸馏的 RPG 垂直模型。这类模型在各垂直领域都比较多。

结论：

目前，在免费部署的前提下，Causal-14B 是最好的，Colab 或者 3060 都能跑。如果要在本地部署，VRAM 又比较紧张，那么通用模型选 ChatGLM3-6B，专注于涩涩用 RWKV-Claude。
我认为 RWKV 的潜力最大，尤其是在这个 VRAM 遇到严重瓶颈的时代。

英文模型+LoRA 的情况目前只能算是备选中的备选，通常中文模型本身就支持英文，而且英文不差。除非未来英文模型超越中文模型太多，这套方案才有可能成为首选。多语言模型直接融合可能是更普遍的做法。

借助 code-server 和 ngrok 给 Kaggle 上个在线版的终端，这样修改文件就很方便。

Notebook：

!curl -fsSL https://code-server.dev/install.sh | sh
!pip install pyngrok
!ngrok config add-authtoken ?authtoken_here?

# run the cell then stop it if you want to generate the password
# there is no password for default
# !code-server 

!sed -i.bak 's/auth: password/auth: none/' ~/.config/code-server/config.yaml
# !cat /root/.config/code-server/config.yaml | grep password

import subprocess
def iframe_thread():
    p = subprocess.Popen(["code-server"], stdout=subprocess.PIPE)

from threading import Thread
Thread(target=iframe_thread, daemon=True).start()

!ngrok http --domain=?your_ngrok_domain? 8080

Kaggle 好像不允许直接 ssh 连接，在线终端应该没事？

缺少 so 文件直接删除 conda 里的即可，系统一般是正常的，conda 比较残废罢了。

可能用蚁剑管理也可以，不过暂时 cs 够用了，先凑合一下。

最近收到个推送《为什么英短猫弃养率这么高》，文章说 70% 的人后悔养英短，接着细数了英短多条罪状。

我也有一只蓝白，是朋友送的。

精神的时候她长这样。

没睡醒的时候她长这样。

有人说英短心眼特小，报复心特强，我家的猫好像从来不记仇。

还有人说英短发情期会喵喵叫。我想所有猫都会这样。
不过我家的猫即使是发情期也不会随地大小便。
后来给她做了绝育，除了求猫条，平时都是哑巴了。

至于英短贪吃过于肥胖的问题，我是更加没遇到。我的猫明明一直好好吃饭，但就是长不胖，让我很苦恼。

文章最后说英短掉毛厉害。我想短毛猫都掉毛厉害，美短也是一样的。
比起长毛猫打理费劲，无毛猫洗澡麻烦，短毛猫已经很不错了。

我每天和猫贴贴的时候就会给她梳梳毛，也不是很麻烦。

这只猫不算很好看，但性格真的棒。
她很少咬人或抓人，也从来不会把东西弄在地上，还可以随便揉肚子。
猫的性格应该是随爸遗传的，这些都没有专门训练过。

2022 年封控前的一段时间，我压力非常大，是这只猫陪我度过了那段抑郁的日子。

她是一只小天使。她还有一个很霸气的名字，但现在已经退化成咪咪了（笑

2014 年，有人在知乎提了个问题：为什么直到现在 RAR 仍然比 7z 更流行？ 这个问题陆陆续续一直有人回答，直到今天，RAR 在商业上仍然比 7z 更加流行。

这个问题有很多角度，每个时期的答案也非常不同。这个时代版本的答案是，用户只需要一个打包工具，根本不关心压缩率，7z 最核心的竞争力荡然无存。

我有一个更简洁的回答，即 7z 是面向后端开发的，而不是消费者。
它虽然诞生自 Windows 平台，但它使用的是 Linux 的那套方法论，这就是它难以普及的根本原因。

Linux 的设计哲学是，所有工具都专心做自己的事，然而专一的同时，对商业化非常不友好。
7z 的功能是丑陋的，它拥有 Linux 软件的通病，即：开箱即用的默认配置不合理，无法第一时间满足用户关注的需求。明明它可以做到，但它会把一大堆参数丢给用户。比如，不看说明，有多少人知道 2021 年前 7z 要加入 cu 参数才能保证 zip 不乱码？
如果一定要类比的话，7z 可能是压缩解压界的 ffmpeg，相信没人会问出 为什么 ffplay 不如快播流行 这种鬼话。

相比 tar.gz，7z 还是做到了打包压缩一体化，但这仅仅是做到了不反人类，还远远不够。RAR 支持一步解压 tar.gz、支持分卷、支持注释、支持恢复记录、支持添加到 Email、支持记住密码、扫描病毒等等。很多功能功能是过时的、臃肿的，但是可以看出来，真正优秀的商业软件是如何在每个时代，去迎合用户的需求。反观 7z，只是能用，但不好用。

话又说回来，7z.exe 是不好用 ，但 7z.dll 又不同。一些软件经过 7z.dll 套壳后问世，功能界面几乎完全复刻 WinRAR，然后就好用了。这进一步说明，7z 是面向开发者和后端设计的。
很多软件爱好者会说，这些套壳软件是带广告的流氓软件，有些甚至是强行安装的。但市场已经证明，用户不在乎广告。RAR 弹一个试用过期，和这些软件弹一个广告，对普通用户来说有什么区别呢？用户只是想要一个解压软件，一个不需要说明书就能用好的软件，一个不太反人类、至少压缩 zip 文件名不会乱码的软件。如果一个用户的知识水平达到了认识 7z，他大概率会选择用 RAR，或者某些不带广告的 7z 套壳。

可悲的是，如今，7z 连后端的流行度也难保。尽管企业仍有压缩的需求，但已经不如早期那么极端。而且企业大部分的压缩需求源于流量昂贵，数据更多是为了传输后立刻解包的，而不是为了冷备份。能够顺序读并解压的 zip、效率更高的 zstd，又或者是 webp/webm 这种为浏览器而生的格式，才是贴近时代的解决方案。

我可能还是会用 7z 的命令行做一些极限压缩，或许只是因为好玩，但也仅限于小体积的打包。7z 只能用于个人分享，反正解压它不是难事，但是商业交付，7z 绝对不是什么好选项。不想和用户啰嗦的话，zip 是唯一正解。
最后，做商业产品，一定不要学 7z。