分类： 软件分享

将FastCopy整合进系统

目前主流的复制工具有 TeraCopy 和 FastCopy，我不是要讨论谁更强大，而是要解决 Windows 卡死的问题。我看了下知乎上的评测文章，很多评论和我的情况是一样的。大家对差个几秒并没有太多感知，只是 Windows 在多线操作时经常会降速到不可忍受，有时还会卡在最后 1% 无法完成。罪魁祸首是那个该死的进度条，但系统又不让关闭。

文件操作主要是复制和删除（移动可以看作复制+删除）。FastCopy 同时支持两种操作，整合得不太好；TeraCopy 不支持删除，但很好集成。

我的方法是，同时安装两个软件，然后在 TeraCopy 中勾选集成复制功能-接管拖放操作/默认使用 TeraCopy 复制文件。
此时粘贴文件，TeraCopy 会弹出一个窗口，右上角有个设置，点击后可以“Edit Menu”（即修改软件目录下的 PasteMenu.ini）。
添加几个选项，原始内容按序号顺延，FastCopy.exe改为自己的路径：

[1]
title=FastCopy - Copy - !!Just Overwrite!!
path=C:\Users\YOUR_USERNAME\FastCopy\FastCopy.exe
copy=
cut=
parameters=/auto_close /cmd=diff /srcfile="{list}" /to="{target}"
[2]
title=FastCopy - Move - !!Overwrite!!
path=C:\Users\YOUR_USERNAME\FastCopy\FastCopy.exe
copy=
cut=
parameters=/auto_close /cmd=move /srcfile="{list}" /to="{target}"
[3]
title=FastCopy - Copy (Not Overwrite)
path=C:\Users\YOUR_USERNAME\FastCopy\FastCopy.exe
copy=
cut=
parameters=/auto_close /cmd=noexist_only /srcfile="{list}" /to="{target}"
[4]
title=FastCopy - Copy (Keep the Newer File)
path=C:\Users\YOUR_USERNAME\FastCopy\FastCopy.exe
copy=
cut=
parameters=/auto_close /cmd=update /srcfile="{list}" /to="{target}"

再次复制或移动时，就可以默认调用 FastCopy 了。

TeraCopy 也不算纯粹的工具人，稍微复杂一些的调度用 TeraCopy 还是挺方便的。

接下来是删除，我用 AutoHotKey 接管了 Shift + Delete，代码如下：

#IfWinActive ahk_exe explorer.exe
+Del::
fastCopyPath := "C:\Users\YOUR_USERNAME\FastCopy\FastCopy.exe"
selectedFiles := ""
for window in ComObjCreate("Shell.Application").Windows {
    if (window.HWND = WinExist("A")) {
        for item in window.document.SelectedItems
            selectedFiles .= """" item.Path """ "
    }
}
if selectedFiles
    Run, % fastCopyPath . " /force_close /cmd=delete " . selectedFiles
return

从原理上讲 del / robocopy 都可以实现快速删除，但 FastCopy 默认会弹一个确认窗口，和系统自带的 Shift+Delete 操作习惯完全一致。

在Huggingface上跑代理

Huggingface 给每个人无限量的临时 Space 配额，试了试居然可以运行代理：一个简单的 Trojan 示例。

直接 Dumplicate，然后修改 PASSWORD 和 WS_PATH 两个 secret 就能启动了。
WS_PATH（伪装路径）不是必须的，删掉它就等同于跑在首页上。

HF Space 踩坑记录

① websocket 问题
代理协议要套用 websocket 才能连接成功。由于很多聊天 Demo 的流式输出都基于 websocket，倒是不用担心像 Colab 那样被掐。

② binding host 问题
始终使用 0.0.0.0 而非 127.0.0.1，否则可能会出现奇奇怪怪的状况。Space 必须要 Public，否则知道 hf.space 地址也不能连接成功。

③ 卡 Starting 问题
即使 Space 内的程序已经正常 Running，仍有可能卡在 Starting。
如果一切正常，且有服务占用 7860 端口（默认端口），Space 状态理应切换为 Running。但 HF 对端口占用检测有 Bug，此时 Space 就会无限 Starting。由于只有 Running 状态，端口才会转发数据，所以此时即使服务正常也无法访问。
解决办法：在启动脚本里加上一句 python -m http.server 7860 & kill $! 。也就是用一个 HF 能识别的服务进程占用 7860 端口后立刻杀掉，再在这个端口上运行其他服务。

④ 保活问题
每个 Space 的运行时间是 48h，之后”不活跃“的 Space 将进入睡眠。之前我猜测只要 .hf.space 有访问就能保活，后来看到确实有人引入 upapp 来检测自己保活。这样的话应该也可以用 UptimeRobot 这类第三方检测来定期访问保活。

⑤ 滥用问题
HF 好像没有具体说明代理是否属于滥用，不过大规模滥用应该是不可能的，只适合自用或备用。第一，HF 给每个用户（对，是账户下所有 Space）分配了 3 个 固定 IP，没有 AnyCast，所以不太可能被批量白嫖。第二，所有 IP 都在美国，延迟一般，也无法绑定域名。

将官方Qwen1.5接入Chatbot

之前提到，Qwen 官方提供了一个在线 Demo。本来是基于 Gradio 的，我将它转换成了 OpenAI 的接口，并且直接部署在了 HF 上： Qwen 1.5 minimal Chat

虽然名字叫 minimal，实际接入的是 110B…… 本地连 7B 都费劲，只能白嫖官方勉强维持生活。

碎碎念：HF space 的 Docker 还是有点奇怪的，调试完了新建项目再部署，就出现 .sh 文件找不到。折腾了半天用 bash 就可以，直接 ./ 就不行，莫名其妙。

因为 HF space 有 48h 不访问就 sleep 的限制，我加上了一个每隔一小时访问自己的脚本，看看能不能绕过这个限制。

仅通过wget在两台机器间传输文件

发现一个有意思的网站：station307.com

该网站用于两台机器间传输文件，只需要 wget 或 curl 即可。流式传输，而非临时网盘。

接收端输入 wget 命令，在输出中有一行随机生成的 web.url，在浏览器中打开这个地址，选文件发送即可。也可以不经过浏览器直接 post 数据过去。

这有什么好处呢？有时环境比较简单，可能没有 server 或者 ssh 权限，典型的如 kaggle，有了这个网站就可以很方便地发送本地文件。
最近还遇到的一个场景是，目标机器只能 ipv6 访问，正好手上的网络不支持，也用这个网站完成了快速分享。

【2024.01】目前好用的大语言模型以及部署情况

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

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

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

目前好用的中文模型：

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

NSFW 篇：

非 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，视其生态发展而定。

修复 TinyPNG GUI 应用

腾讯 TGideas 和 LOL 前端重构规范中，曾经有一个 TinyPNG GUI 工具，它调用网页版的 shrink 而非 API 批量压缩图片。不过在这些页面中，工具的下载链接已失效。

该工具由 Adobe Air 开发，尽管技术过时，但本身仍非常好用。然而，今年四月起，因官网接口改变，该工具彻底无法工作。

研究后发现，尽管官网本身已不再使用默认使用 shrink 接口，但仍保留了这个方法，只是修改了路径。新的接口是 /backend/opt/shrink。我修改了该工具的 bin，使其可以重新工作，并做了一点补充。

你可以 > 点此下载修改后的版本

TinyPNG mod screenshot

修改详情：

  1. 替换了新的 API
  2. 将版本号 TinyPNG 1.0.0 修改为 TinyPNG mod 1.0.1
  3. 跟随官方增加了 webp 格式支持，补全了 jpeg 格式
  4. 去除了启动 Logo，直接进入程序
  5. 将 About 中的二维码图片修改为官方吉祥物熊猫
  6. 将程序图标从恐怖片截图改为了官方吉祥物熊猫
  7. 一点体积上的优化

如果你对 mod 本身有兴趣，仍可以通过某些网站下载到原版，并通过 jpexs-decompiler 和 RisohEditor对比具体的改动。