躺平.赢

写于2024年1月。请注意内容是否过时。

之前写了一篇《一些中文LLM的试用体验》，内容有点过时。结合目前的情况更新一下。

依然以家用环境或免费的网络服务为主，也就是说不会出现超过 40B 的模型。
这里要特别提一下 MoE 模型，以 Mixtral-8x7B 为例，这个模型一次只调用 14B，但加载消耗的硬件与 ~40B 的模型相当。MoE 对个人自用来说是不划算的，只适合作为服务部署。

目前好用的中文模型：

这里尤其特指中文模型，因为中文模型比较少，更有不少是浪得虚名。中英文混杂输出是常见病，有些连句子都输出不通顺，这种东西只能自己试了才知道。

NSFW 篇：

• CausalLM 系列，尤其是最近更新的 CausalLM/34B-preview，当然 CausalLM/14B-DPO-alpha 也不错。
• NousResearch 的 Nous-Capybara-34B 和 Nous-Hermes-2-Yi-34B。 Yi 34B 是个好模型，很多人在此基础上 Finetune，不过真正堪用的也不多。
• bagel-dpo-34b，基底同样是 Yi-34B，加上了 ToxicDPOqa 数据集，实现 Uncensored。
• RWKV 的 xiaol/RWKV-v5-12B-one-state-chat-16k 和 xiaol/RWKV-v5.2-7B-Role-play-16k。LocalNSFW/RWKV-Claude 已经过时，具体的介绍信息参考 这个文档（左上角展开目录）。RWKV-5 的指令遵从有改善，但仍待进步。

非 NSFW 篇

• DeepSeek 系列，主要是 deepseek-llm-7b-chat，当然 code 模型也很好用。体验 67B 版本可 前往官网。这个模型挺可爱的，有种早期 Sydeny 的感觉。
• 书生系列的 internlm-chat-20b，这个模型懂很多俚语。也有 7B 版本，但没试过。

不确定的小模型

• OpenBuddy-Zephyr-7b，印象中是 NSFW 的，能够流畅输出中文。
• MiniChat-3B，超小的蒸馏模型，玩具，但也可以输出流畅的中文。

※ 部分模型一直在更新版本，具体可以在使用前翻阅作者的模型列表。

当前自用部署量化的情况：

大部分人用的是 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 秒，获得到接口地址。

示意图：

② 获得 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 在局部填充的地方和我的略有区别，但不清楚具体影响。