主要观点：作者看到“J”在 o565.com 上的DRINK ME后，认为用 LLM 的下一个令牌概率连接算术编码器可制作不错的压缩器，虽不是原创想法但想自己尝试，因 LLM 和算术编码的复杂性最终改为用 llama.cpp 支持的 LLM 作为 zlib 的预处理程序制作压缩器，代码在GitHub且不用于严肃用途；介绍了压缩和解压缩的工作原理，压缩时根据最可能的令牌选择进行编码，解压缩时反向操作；给出了不同文本和图像的压缩结果，LLaMA 3 在多数情况下优于 LLaMA 2，rot13 处理的 Alice in Wonderland 示例说明不同压缩方式的效果，图像示例只是为了好玩且因图像大小受限；讨论了使用限制（HTTP API 导致只能使用 512 个令牌的有限上下文）及可改进之处。

关键信息：

• 相关链接：DRINK ME、lobste.rs/s/fkzupi/drink_me_ab_using_llm_compress_text、GitHub
• 使用的模型：LLaMa-2-7B、LLaMa-3-8B（均量化为“Q5_K_M”）、Gemma-2B（未得到好结果被舍弃）
• 压缩工作原理：取近期上下文给模型求下一个令牌的 128 个最可能候选，根据情况编码，ULEB128 字节用 zlib 编码
• 解压工作原理：先 zlib 解码再 ULEB128 解码，根据值输出相应字符或令牌
• 结果对比：不同文本和图像在各种压缩方式下的大小对比
• 讨论内容：LLaMA 3 表现优于 LLaMA 2 的情况，rot13 处理对不同压缩方式的影响，图像示例及使用限制原因

重要细节：

• 压缩时若 top 最可能令牌是剩余输入前缀则选择，否则选 128 个中最长的，令牌索引占 1 字节，字面码点占 2 - 3 字节
• 输出的 ULEB128 字节用 zlib 的“deflate”模式无 gzip 头编码
• LLaMA 3 在多数情况下性能更好，rot13 处理使 Brotli 和 LLaMA 效果变差
• 因 HTTP API 限制只能使用 512 个令牌的有限上下文，虽有输入缓存机制但有碰撞导致数据无法往返，需关闭缓存以保持可接受速度（约 15 - 35 字节/秒）