躺平.赢

① 获得接口链接

新建 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 秒，获得到接口地址。

示意图：

② 获得 Gemini Pro API Key

从Google Makersuite 申请 Key：点此直达

③Demo

④ 一点补充

• gemini-openai-proxy 项目提供了兼容接口
• Colab 不支持安装 Docker，所以用 udocker 作为替代
• Colab 的 8080 端口默认被占用，所以使用 8443
• 为了兼容 Kaggle，cloudflared 需要重命名，否则会引起强制重启
• 随机 url 过于繁琐，最好在 CF 绑定域名

⑤ One more thing

是否支持 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 控制有诸多不便，为了方便交互和监控资源，研究了一下通过终端交互的方式。

管理 Colab

【弃用】方案 1：通过 webshell… 对，就是木马当管理器用。

!apt install php
!nohup php -S localhost:8000 > /dev/null &
!echo '<?php @eval($_POST["shell"]);?>' > connect.php
# 然后用 ngrok（我一开始就是这样修改文件的）

结论：不会被制裁。体验一言难尽，蛋疼。

【弃用】方案 2：使用 tmate

!apt install tmate
!tmate
# 自动分配外网地址

结论：一般不会被制裁。比没有强，像 tmux 那样操作。

【在用】方案 3：使用正经 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 会有警告，虽然能绕过但制不制裁看官方心情。体验很爽。

方案 3 解释

这个方案需要本地下载一个 cloudflared，具体的 vscode 配置可以参考>这篇教程

作者给了一个修改本地 .ssh/config 的方案，实际上也可以在本地端口监听，像这样：
cloudflared.exe access tcp --listener localhost:2222 --hostname sub.trycloudflare.com

这样各种 ssh 客户端，如 Xshell，也可以通过连接 localhost:2222 来访问 colab

更多用法

1. 快速得到一个 webui 的外部地址，但仅限自己浏览器访问

   from google.colab.output import eval_js
   print(eval_js("google.colab.kernel.proxyPort(8000)"))

2. 通过 cloudflare tunnel 将任意端口暴露到外网，所有人可访问

   !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

3. 防止 colab 断连，console 自动点击 connect。

   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。

1. clone llama.cpp，然后编译出量化用的 bin

   %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

2. 通过脚本拉取模型，官方的有点慢，这里使用第三方的脚本

   %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?

3. 准备修改过的转换脚本，有两处改动。第一是 KerfuffleV2 提供的 --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

4. 开始量化。Colab 大约能提供 108G 的硬盘，量化完一个模型大约需要 90G 或更多，所以只能分批量化。根据 TheBloke 推荐，Q4_K_M、Q5_K_S、Q5_K_M 性价比较高。

   %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

5. 去 Hugging Face 上新建模型，假设名称为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 .

6. 将量化后的模型移到目录中。

   %cd /content
   !mv ./NSFW_13B_sft/nsfw-13b-sft.Q4_K_M.gguf ./NSFW_13B_sft-GGUF/
   !ls ./NSFW_13B_sft-GGUF

7. 正式发布模型。git push 可能会提示找不到用户名，借用 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

8. 重复步骤：5 清空目录 → 4 量化另一个精度 → 6 & 7 再重新移动文件、上传。

*注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，转换后无法加载，原因未知。

（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 够用了，先凑合一下。

更新：修改了一些容易卡锁的细节

一条简单的笔记。

需求：我有一批获取的 IP，要一一验证可用性。

一个个验证太慢了，需要使用多线程。
ChatGPT 给出的方法是，先用//分割文本，然后每个线程处理相等数量的 IP。但是，这个方法预分配了所有条目，总有线程特别慢，迟迟难以收尾。

之前写了一个简单的多消费者模型。先把文本全部读进列表，增加一个行计数器。每个线程一次只分配一条数据，在取任何数据前，先将计数器+1，代表对应行已被分配。处理完了再分配下一条数据。
不过，代码很奇怪，我决定用 queue 再重写一下。

以下是一个修改后的通用实现，附带一个简单的进度条。

from os import _exit
from time import sleep
from queue import Queue
from threading import Thread
from signal import signal, SIGINT
from dataclasses import dataclass
from time import time, strftime, gmtime

def consume(queue):
    while not queue.empty():
        item = queue.get()

        ''' do something here '''
        sleep(0.1)
        ''' do something here '''

        queue.task_done()

@dataclass
class QProgress:
    ''' a wget-like progress bar '''
    queue: Queue
    qsize: int = 0 # queue.qsize() by default
    width: int = 50 # characters of progress bar

    alive = True

    def interrupt(self):
        self.alive = False

    def show(self):
        data_size = max(self.queue.qsize(), self.qsize)
        start_time, showing_count= time(), 0
        while self.alive and showing_count < data_size:
            showing_count = data_size-self.queue.qsize()
            per = showing_count/data_size
            print(''.join([f"\r{('%.2f'%(per*100)).rjust(6,' ')}%[",
                f"{'='*int(per*self.width-1)}>".ljust(self.width,' '),
                f"] {showing_count}/{data_size} ",
                strftime('%H:%M:%S', gmtime(time()-start_time))]),
                end='', flush=True)

        if self.alive:
            print('', 'Done', sep='\n')

if __name__ == "__main__":

    queue = Queue()

    # 假定一些已生产的数据
    data_size = 6661
    [queue.put(i) for i in range(data_size)]

    # 进度条，启动！
    qprogress= QProgress(queue)
    Thread(target=qprogress.show, daemon=True).start()

    # 消费者们，启动！
    num_consumers = 661

    threads = [Thread(target=consume, args=(queue,), daemon=True)
        for _ in range(num_consumers)]
    [t.start() for t in threads]

    # 配合 daemon 响应 Ctrl+C
    def signal_handler(signal, frame):
        qprogress.interrupt()
        print('', 'Interrupted', sep='\n')
        _exit(0)

    signal(SIGINT,signal_handler)

    while any(t.is_alive() for t in threads):
        sleep(0)

哦，就是 base64 嘛。

最近 scaleway 服务很不稳定，终有一天它失联了。
根据以前的经验，一般是机器重启，需要去网页 TTY 重置下网络。

登录后，scaleway 问我，新的网络上线，更快更好，要不要一键 auto migrant？
一手贱，然后就双向失联了。具体表现为什么都 ping 不通，没有任何公网地址，连 apt update 也无法运行，通过 scw 分配 IP 也救不活。
此时 sacleway 后台弹出马后炮提示：您的套餐迁移时如果分配了静态 IP，需要先升级 blablabla，否则就会丢失网络连接。怎么救，没说。

这台服务器主要运行了这个博客，尽管文章在本地都有备份，但还是想着先抢救一下数据库。
我使用的是 sqlite 数据库，就一个/wp-content/database/.ht.sqlite文件。

抢救一下

网络彻底失联的情况下，我和这台机器唯一的交互手段就只有后台提供的网页版的 TTY。于是，只能靠屏幕输出了。

具体而言的话：

f=".ht.sqlite";
zip -9 -q f "$f";
base64 -w0 f.zip;echo "";

将输出保存到文件，从另一台机器

base64 -d save.txt > f.zip

进一步压缩

之前是针对空白系统的抢救办法。由于屏幕的输出空间很有限，结合一些工具的话，可以进一步缩减体积。

apt-get install sqlite3 p7zip-full python3-pip
pip install base2048

f=".ht.sqlite";
sqlite3 $f 'VACUUM;';
:<<eof
- or dump to sql -
sqlite3 $f .dump > dump.sql; f="dump.sql"; 
eof
7z a -bso0 -mx -myx -mmt=off -ms=on -mtm=off -mtc=off -mta=off -m0=LZMA:d=384m:fb=273:lc=4 -mmc=1000000000 f $f;
python3 -c "print(__import__('base2048').encode(open('f.7z','rb').read()))";

等待 TTY 狂暴输出。

其实还有更壮观的 base65536，输出的都是形似汉字的字符，但复制时可能会造成数据错乱。另一方面，base2048 屏幕输出占一个 ASCII 码的宽度，能容纳 2 个 ASCII 码的数据，而 base65536 占 2 个 ASCII 码的宽度，能容纳 3 个 ASCII 码的数据，压缩比提升不大且异常卡顿，实测还是 base2048 好。

恢复数据：将 TTY 打印的内容放入 2048.txt，然后恢复到 2048.7z。
其中明文数据大约是解码数据的 1.8 倍。

import base2048

with open('2048.txt', 'r',encoding='utf-8') as file:
    encoded_data = file.read()

decoded_data = base2048.decode(encoded_data)

with open('2048.7z', 'wb') as output_file:
    output_file.write(decoded_data)

更多可能

终端还可以展示带颜色的文字，用以进一步扩充符号数。如果能够显示图片，则可以结合一些隐写方法，将数据压缩到 RGB 值内。又或者结合屏幕刷新 + 录像，以类似二维码的原理定位和容错，并提供自动化的可能。

这样即使不需要数据线和网络，也能把电脑文件复制到手机上（当然首先要能在宿主上执行程序，听上去像是 007 会干的事）。
这些想法没什么太多应用场景，就只是想想。

PS 的 AI 试用到期，于是尝试使用 SD 平替。

使用 inpaint only+lama 进行扩图。预览时还好好的，最后一步失败。
填充内容全部变成横条，原因未知。

如果先把原图本地扩大，再通过 SD 涂抹空白区域进行填充，倒是可以正常运行。
以下是 SD 生成的效果图。

搜了一些教程，发现教程里的 UI 在局部填充的地方和我的略有区别，但不清楚具体影响。

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

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

精神的时候她长这样。

没睡醒的时候她长这样。

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

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

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

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

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

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

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

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