发现一个有意思的网站：station307.com
该网站用于两台机器间传输文件，只需要 wget 或 curl 即可。流式传输，而非临时网盘。
接收端输入 wget 命令，在输出中有一行随机生成的 web.url，在浏览器中打开这个地址，选文件发送即可。也可以不经过浏览器直接 post 数据过去。
这有什么好处呢？有时环境比较简单，可能没有 server 或者 ssh 权限，典型的如 kaggle，有了这个网站就可以很方便地发送本地文件。
最近还遇到的一个场景是，目标机器只能 ipv6 访问，正好手上的网络不支持，也用这个网站完成了快速分享。
一个很特殊的需求。 有一些上游的 APK 包，这些包都有固定的 url。上游升级 APK 时会覆盖原文件，我需要监控它们的版本号以更新到数据库。 有时候，一些 APK 包会特别大，例如游戏，动辄上 G。所以需要一些办法，不下载整个 APK 来提取信息。
脚本如下：
@echo off
goto :_Preparation
1. Install remotezip:
`pip install remotezip`
2. Download aapt2:
`remotezip https://dl.google.com/dl/android/maven2/com/android/tools/build/aapt2/8.3.1-10880808/aapt2-8.3.1-10880808-windows.jar aapt2.exe`
:_Preparation
set /p name="APK url: "
remotezip "%name%" AndroidManifest.xml 1>nul
zip -0 AM.zip AndroidManifest.xml 1>nul
aapt2 d badging AM.zip 2>nul|grep package| awk -F "'" "{print $6}{print $4}
del AM.zip AndroidManifest.xml
原理很简单，就是通过 remotezip 提取包内的 AndroidManifest.xml，将其打包进空的 zip，最后通过 aapt 解析。
之前写了一个在 Colab 上通过 udocker 部署 zhu327/genmini-openai-proxy，最近发现还有更方便的方式。
直接将代理地址改为 https://gemini-openai-proxy.deno.dev 即可接入支持 OpenAI 的客户端。
这是利用了 zuisong/gemini-openai-proxy。上面是公共的，自己搭也很方便。在 deno.dev 新建一个 Playground，直接粘贴进去就部署完毕了，还可以更换二级域名或绑定自己的域名。
和 Colab 相比，好处自然是长期在线。这个项目还有个 CF 版本，不建议使用，因为 CF 会根据地区就近访问，可能会碰到 Google 地区限制。
如果要本地跑，首选还是 zhu327/genmini-openai-proxy。可以编译一个本地版本，UPX 可以压缩到 10M 左右，安全又便携。以下是通过 Colab 编译 Linux / Windows 版本的示例：
%cd /content !wget -c https://go.dev/dl/go1.21.1.linux-amd64.tar.gz !tar -xvf go1.21.1.linux-amd64.tar.gz !chmod +x go/bin/go !git clone https://github.com/zhu327/gemini-openai-proxy %cd /content/gemini-openai-proxy # compile binary for linux !/content/go/bin/go build -o gemini main.go # compile binary for windows !CGO_ENABLED=0 GOOS=windows GOARCH=amd64 /content/go/bin/go build -o gemini.exe main.go ### compress with upx # !wget https://github.com/upx/upx/releases/download/v4.2.2/upx-4.2.2-amd64_linux.tar.xz # !tar xvf upx-* # !chmod a+x upx-4.2.2-amd64_linux/upx # !upx-4.2.2-amd64_linux/upx --ultra-brute ?? -o??
之所以不用客户端自带的 Gemini 模型，是因为接口默认带有审核，而客户端一般不支持设置相关参数。
众所周知，有大语言模型讲话喜欢各种语言混杂，一般是因为融合。
另外，现在有一些公开的未对齐的英文数据集，可以用于对模型本身去审查，但也会造成上述问题。
归根到底，都是因为一开始喂的语料前后文就是混杂的（例如 翻译文章）。
所以我决定对已有的数据集做一些翻译，这样就可以方便其他人直接用中文 de-censored。因为普通数据集有很多，所以我就专注于一些 NSFW 数据。
第一个成果是 unalignment/toxic-dpo-v0.2，一共有 500 多条内容：
中英文对照版：unalignment-toxic-dpo-v0.2-zh_cn
我使用了一个 34B 模型来翻译，小部分来自 Google / DeepL，然后对一些明显有问题的内容做了校对（主要是统一人物称呼、专有名词等）。
全文都是意译的，甚至允许演绎，主要关注是否通顺。
例如，这个数据集中有大量有关迷幻剂和药物的制备内容，我不可能去校对原文或译文是否准确，读起来像是那么回事就行了，目的是用来 Roleplay 或闲聊，而不是真的用于生产环境。其中的故事我通读了一遍，不一定多有文采，但保证能够理解。
其实一开始是想做 NobodyExistsOnTheInternet/ToxicDPOqa，因为有个很喜欢的模型就是用了这个数据集，但是量有点大，我打算先把流程跑通。
最终，500 多条也跑了将近 10 小时才跑完，校对又花了大概 5 小时。原本计划用两个模型各跑一遍，然后让第三个模型来评判哪个通顺，现在看来不太现实。
之后打算看看 athirdpath/DPO_Pairs-Roleplay-Alpaca-NSFW。这个数据集没有分类，我打算只做 sexual content，已经用 mistral 标记好了内容，但打算再找找有没有更好的数据。
写于2024年1月。请注意内容是否过时。
之前写了一篇《一些中文LLM的试用体验》，内容有点过时。结合目前的情况更新一下。
依然以家用环境或免费的网络服务为主，也就是说不会出现超过 40B 的模型。
这里要特别提一下 MoE 模型，以 Mixtral-8x7B 为例，这个模型一次只调用 14B，但加载消耗的硬件与 ~40B 的模型相当。MoE 对个人自用来说是不划算的，只适合作为服务部署。
这里尤其特指中文模型，因为中文模型比较少，更有不少是浪得虚名。中英文混杂输出是常见病，有些连句子都输出不通顺，这种东西只能自己试了才知道。
※ 部分模型一直在更新版本，具体可以在使用前翻阅作者的模型列表。
大部分人用的是 text-generation-webui，但我很少用“懒人包”，因为我需要在服务器部署，然后通过兼容 OpenAI API 的接口给本地使用。
目前主流的量化格式包括 GGUF（llama.cpp）、GPTQ、AWQ、exl2（ExllamaV2）。RWKV 另说。
具体推理速度和硬件需求参考这篇 对比文章。
总结：exl2 作为 GPTQ 的改良版非常快，GPTQ 和 AWQ 很接近，但 GPTQ 在处理 prompt 阶段明显更快，这对于超长文本比较重要，GGUF 是最慢的。
所以我推荐的是 GGUF。是的，GGUF 是最慢的，但是推荐。
先说 GGUF。家用硬件性能有限，使用模型都是奔着榨干性能上限去，而量化需要更多的资源，大量现成的 GGUF 就很实用。GGUF 还可以混合 CPU 和 GPU 部署，实在没显卡的话，慢总比不能用好。
GGUF 虽然慢，但也没有非常慢，相对 GPTQ 和 AWQ 并没有量级差。只要输出速度没有拖累阅读速度，就不会感觉到卡顿。
最最最重要的是独立二进制文件，不会存在依赖问题。
GGUF 如果部署为 server，有两种方案。
第一种最简单，用 llama.cpp-python，并且有现成的 cuBLAS wheel。
# 以colab环境为例 !pip install llama-cpp-python[server] --prefer-binary --extra-index-url=https://jllllll.github.io/llama-cpp-python-cuBLAS-wheels/AVX2/cu118 !python -m llama_cpp.server --model ./model.gguf --n_gpu_layers 1000 --chat_format chatml --host 0.0.0.0 --port 8000
不过这里有个问题，chat_format 是写死在代码里的，要改需要改源代码，自己重新编译。如果模板里正好有对应的格式，那这个最方便。
第二种是直接从 llama.cpp 编译 server。这里我以 Kaggle 环境为例，因为它的 libcuda.so 位置比较刁钻，需要修改一下源码才能编译。
%cd /kaggle !git clone https://github.com/ggerganov/llama.cpp %cd /kaggle/llama.cpp !sed -i 's| -lcuda | -L/usr/local/nvidia/lib64 -lcuda |g' /kaggle/llama.cpp/Makefile !make -j server LLAMA_CUBLAS=1
编译完成后的二进制文件可以保存下来，下次就可以直接拿来用了。
server 提供的接口不是 OpenAI 格式的，可以启动项目中的 api_like_OAI.py 兼容。这里可以参考 llama-cpp-oai-like-server。我做了一个不太优雅的兼容，重点是很容易定义聊天格式，直接替代原始的 api_like_OAI.py 使用。
然后说 GPTQ 和 AWQ。比较常见的是用 auto-gptq 和 auto-awq 加载。但是这两个模块经常会受到上游包更新的影响，例如 transformer。一旦出现冲突，就需要等作者更新。
如果经常在 Colab 这种环境跑，每次都是新安装，部署就容易出问题。
此外，GPTQ 要求所有模块使用 GPU 版本，不然只能关闭 Exallma，这会很影响推理速度。
如果一定要用的话，推荐 AWQ+fastllm（不要用 vllm，问题实在太多）
Colab 版本大致如下：
!pip install "fschat[model_worker,webui]" !pip install auto-awq !python -m fastchat.serve.controller --host 0.0.0.0 &\ python -m fastchat.serve.model_worker --model-path Author/M-AWQ --host 0.0.0.0 &\ python -m fastchat.serve.openai_api_server --host 0.0.0.0 --port 8000
接着说 exl2。很快，但资源很少，量化是最最最耗时的，一个次量化几小时不算长。除非是决定日常要一直用某个模型，或者要部署成在线服务，否则不太推荐。
最后说 RWKV。RWKV 属于比较奇怪的存在，有两种方法在服务器上部署。
第一种是用 cgisky1980/ai00_rwkv_server。比较有意思的是这个项目用的是 webGPU 而不是 CUDA。
Colab 环境的重点是要安装 libnvidia-gl-XXX 这个包。其他跟随项目介绍就行了。
并不太推荐。一是不能多卡部署，二是报错不太友好有问题难定位，三是 KV Cache 有点问题。
第二种是用 josStorer/RWKV-Runner。要分两步执行，大致如下：
# 启动一个后端 import os os.environ['RWKV_CUDA_ON'] = '1' !python ./RWKV-Runner/backend-python/main.py --port 8000
# 通过 API 加载模型
curl http://your.site/switch-model -X POST -H "Content-Type: application/json"\
-d '{"model":"./RWKV-Runner/models/the_model.pth","strategy":"cuda:0 fp16 *20 -> cuda:1 fp16"}'
加载策略（strategy）参考 这个指南。怎么量化就只能怎么加载，想要改只能重新量化。
支持多卡，但多卡推理时会遇到一点问题，输出结果有折扣，暂不清楚原因。
结论就是：RWKV 在多卡方面都会遇到挫折。
当前非常推荐 GGUF，尽管相比其他量化慢一些，但最不容易随升级出问题。而且在线临时环境部署非常轻松，可以直接使用以前生成的 binary，而不需要每次都安装很多依赖。
未来可能会推荐 exl2，视其生态发展而定。
新建 Colab 笔记：
把以下内容粘贴进去：
!wget -q -c https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -O c !chmod a+x c !pip install udocker !udocker --allow-root pull zhu327/gemini-openai-proxy:latest !udocker --allow-root create --name=gemini zhu327/gemini-openai-proxy:latest !./c tunnel --url http://localhost:8443 & udocker --allow-root run -p 8443:8080 gemini
启动，等待 30 秒，获得到接口地址。
示意图：
从Google Makersuite 申请 Key：点此直达
是否支持 NSFW？有限支持。我没有特别写过越狱 prompt，Gemini 并没有拒绝回答。
有其他用户提到模型会拒绝回答，对此，我的经验是伪造 AI 一轮或多轮的回复（当然这需要客户端支持）。
运行 server 端，以 colab 为例：
首先用 CF-Tunnel、Ngrok 之类的工具穿透，然后加载模型：
!mkdir -p /root/.tabby !wget https://github.com/TabbyML/tabby/releases/download/v0.6.0/tabby_x86_64-manylinux2014-cuda117 !chmod +x tabby_x86_64-manylinux2014-cuda117 !TABBY_DISABLE_USAGE_COLLECTION=1 ./tabby_x86_64-manylinux2014-cuda117 serve --model TabbyML/DeepseekCoder-6.7B --device cuda --port 8443 # change the default port due to 8080 is occupied by colab
在 vscode 中安装 Tabby 插件，填入远程地址，即可：
问题：经常会超时，多次后就会拒绝连接。修改 config.toml 似乎无效，不知道什么原因。
Colab 使用 cell 控制有诸多不便，为了方便交互和监控资源，研究了一下通过终端交互的方式。
!apt install php !nohup php -S localhost:8000 > /dev/null & !echo '<?php @eval($_POST["shell"]);?>' > connect.php # 然后用 ngrok（我一开始就是这样修改文件的）
结论：不会被制裁。体验一言难尽，蛋疼。
tmate!apt install tmate !tmate # 自动分配外网地址
结论：一般不会被制裁。比没有强，像 tmux 那样操作。
ssh!echo $($(echo "pip install colab""_ssh --upgrade")) from colab_ssh import launch_ssh_cloudflared, init_git_cloudflared launch_ssh_cloudflared(password="X")
结论：直接安装 colab_ssh 会有警告，虽然能绕过但制不制裁看官方心情。体验很爽。
这个方案需要本地下载一个 cloudflared，具体的 vscode 配置可以参考>这篇教程
作者给了一个修改本地 .ssh/config 的方案，实际上也可以在本地端口监听，像这样：
cloudflared.exe access tcp --listener localhost:2222 --hostname sub.trycloudflare.com
这样各种 ssh 客户端，如 Xshell，也可以通过连接 localhost:2222 来访问 colab
from google.colab.output import eval_js
print(eval_js("google.colab.kernel.proxyPort(8000)"))
!wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -O cloudflared
!chmod a+x cloudflared
import nest_asyncio
nest_asyncio.apply()
import subprocess
f = open("stdout", "w")
p = subprocess.Popen(['./cloudflared', '--url', 'http://localhost:8000'], bufsize=0, stdout=f, stderr=subprocess.STDOUT)
import time
time.sleep(3)
!grep -F trycloudflare stdout
var startClickConnect = function startClickConnect(){
var clickConnect = function clickConnect(){
console.log("Connnect Clicked - Start");
document.querySelector("#top-toolbar > colab-connect-button").shadowRoot.querySelector("#connect").click();
console.log("Connnect Clicked - End");
};
var intervalId = setInterval(clickConnect, 60000);
var stopClickConnectHandler = function stopClickConnect() {
console.log("Connnect Clicked Stopped - Start");
clearInterval(intervalId);
console.log("Connnect Clicked Stopped - End");
};
return stopClickConnectHandler;
};
var stopClickConnect = startClickConnect();
// In order to stop, call:
// stopClickConnect();
Colab 虽然限制 ssh，但并不是特别严格，还是可以变相使用。不过，Colab 似乎不支持 websocket，所以诸如 ttyd、code-server 等基于网页的终端无法使用。
Kaggle 严格限制 ssh，用了直接封号。不过，Kaggle 支持 websocket，所以可以使用 code-server。
以上就是在两者直接使用终端交互的方式。
最后，连接时最好检查一下本地防火墙。如果火绒处于免打扰模式，很可能会自动拦截 ssh 或者 cloudflared。
- vscode连接Google colab
- cloudflare-tunnel-to-colab.ipynb
- Quick Tunnels · Cloudflare Zero Trust docs
- Arbitrary TCP · Cloudflare Zero Trust docs
- How can I prevent Google Colab from disconnecting?
本文主要介绍如何使用 Colab 从在 Hugging Face 上拉取模型，经 llama.cpp 量化，再发布到 Hugging Face。
假定已经注册了 HuggingFace，并已经生成了具备 write 权限的 API Token。
以下例子用到的模型是 zxbsmk/NSFW_13B_sft。这是一个基于百川的 Uncensored 模型，需要权限才能抓取，所以需要先注册 Hugging Face 并准备相应权限的 API Token。
%cd /content !git clone https://github.com/ggerganov/llama.cpp %cd llama.cpp !mkdir build %cd build !apt install cmake !cmake .. !cmake --build . --config Release
%cd /content !apt -y install -qq aria2 !wget https://gist.github.com/padeoe/697678ab8e528b85a2a7bddafea1fa4f/raw/5542d6c7ea6544b296dfcec770a74c74c5c01325/hfd.sh !bash /content/hfd.sh zxbsmk/NSFW_13B_sft --tool aria2c -x 4 --hf_username ?USERNAME? --hf_token ?hf_API-TOKEN?
--pad_vocab 参数，用于修正 vocab mismatch 错误；第二是修正部分模型需要从 config.json 中读取 model_max_length 作为 n_ctx。
!pip install sentencepiece %cd /content # download a patched converter.py !wget https://pastebin.com/raw/bedgE0Px -O ./llama.cpp/convert.py !python ./llama.cpp/convert.py --padvocab --outtype f16 ./NSFW_13B_sft/ #default name:ggml-model-f16.gguf
%cd /content %cd NSFW_13B_sft !../llama.cpp/build/bin/quantize ./ggml-model-f16.gguf ./nsfw-13b-sft.Q4_K_M.gguf Q4_K_M # !../llama.cpp/build/bin/quantize ./ggml-model-f16.gguf ./nsfw-13b-sft.Q5_K_S.gguf Q5_K_S # !../llama.cpp/build/bin/quantize ./ggml-model-f16.gguf ./nsfw-13b-sft.Q5_K_M.gguf Q5_K_M
NSFW_13B_sft-GGUF。清理目录，clone 所有非模型文件。
%cd /content %rm -rf ./NSFW_13B_sft-GGUF !GIT_LFS_SKIP_SMUDGE=1 git clone https://huggingface.co/?USERNAME?/NSFW_13B_sft-GGUF %cd NSFW_13B_sft-GGUF !huggingface-cli lfs-enable-largefiles .
%cd /content !mv ./NSFW_13B_sft/nsfw-13b-sft.Q4_K_M.gguf ./NSFW_13B_sft-GGUF/ !ls ./NSFW_13B_sft-GGUF
expect 可以顺利上传，密码是 API Token（注意要有 write 权限），可能需要输入两遍用户名密码。
%cd /content
%cd ./NSFW_13B_sft-GGUF
!git lfs track "*.gguf"
!git config --global user.email "?EMAIL?"
!git config --global user.name "?USERNAME?"
!git add .
!git commit -m "GGUF model commit (made with llama.cpp)"
# !git push
!apt install expect
context = """
spawn git push
interact
"""
with open("/content/push.txt", "w") as f:
f.write(context)
!expect /content/push.txt
*注1：如需使用 API 登录，可使用单行命令
!python -c "from huggingface_hub.hf_api import HfFolder; HfFolder.save_token('?hf_API-TOKEN?')"
注2：Kaggle push 大文件有问题，可以使用官方 API 上传，但文件必须 <5G。详情见官方文档。
注3：国内有很多非标的 llama 模型，如 01-ai/Yi、vivo-ai/BlueLM，无法直接转换，或需要用到各种奇怪的技巧甚至修改推理代码，还有一些模型如 chatglm3，转换后无法加载，原因未知。
之前在玩 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，我试了下 Chinese-Wizard-Vicuna-13B-GPTQ，这是一个使用了来自科大讯飞 Chinese-LLaMA-Alpaca 的模型，总体效果还不错。能输出流畅的中文，但不如原生接地气。
以下是我对 Uncensored 的测试，其实还是用了一些 Jailbreak Prompt
创作能力大概强于 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 纠正。
由于 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 的情况目前只能算是备选中的备选，通常中文模型本身就支持英文，而且英文不差。除非未来英文模型超越中文模型太多，这套方案才有可能成为首选。多语言模型直接融合可能是更普遍的做法。