Quansloth
基于 Google TurboQuant 的 KV Cache 4-bit 量化压缩技术，让 6GB
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
基于 Google TurboQuant 的 KV Cache 4-bit 量化压缩技术，让 6GB
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象这样一个场景：你手头只有一张 RTX 3060（6GB VRAM），但你希望分析一篇 200 页的 PDF 文档——这在标准 LLM 推理框架下几乎是不可能完成的任务。随着上下文长度增长，GPU 显存会指数级膨胀，直到触发 Out-Of-Memory（OOM）崩溃，进程直接被系统 kill 掉。
这就是大模型推理领域长期存在的「VRAM Wall」问题。Google Research 在 ICLR 2026 发表的论文 TurboQuant 给出了答案：通过对 KV Cache（Key-Value 缓存）进行从 16 位到 4 位的极端量化压缩，理论上可以将显存占用降低 75%。
Quansloth 正是这一理论在本地部署场景下的工程实现——一个完全私有、无需联网的本地 AI 服务器，专为消费级 NVIDIA GPU 优化。
图1：Quansloth 的赛博朋克风格 Gradio 前端界面
Quansloth 的核心技术栈建立在三层基础之上：
第一层：算法基础。 底层算法基于 Google Research 的 arXiv:2504.19874，由 TheTom 在 turboquant_plus 项目中工程化实现。这套算法的核心创新在于对 KV Cache 采用非对称量化（Asymmetric Q8/Turbo4）和对称量化（Symmetric Turbo3）两种策略，前者对 Qwen 类 Q4_K_M 模型效果更好，后者是综合压缩效率最优选择。
第二层：CUDA 加速。 算法通过 TheTom 的 llama-cpp-turboquant（feature/turboquant-kv-cache 分支）实现为 CUDA 加速的 C++ 推理引擎。这不是普通的 llama.cpp，而是经过深度定制、支持 TurboQuant KV Cache 压缩的专用分支。install.sh 会自动 clone 该仓库并从源码编译，启用 -DGGML_CUDA=ON 和 Release 构建模式。
第三层：Python 前端。 前端采用 Gradio 4.x 构建，核心文件 quansloth_gui.py（约 16KB）承担所有交互逻辑。程序启动后会在 http://127.0.0.1:7860 提供 Web UI，底层通过 openai Python 库（base_url 指向 http://127.0.0.1:8080/v1）调用本地 C++ 引擎的 REST API。
图2：Quansloth 的聊天界面，支持长文档上下文注入
这是 Quansloth 区别于其他本地 LLM 推理工具的根本差异。大多数工具（如 ollama、text-generation-webui）优化的是模型权重量化，而 Quansloth 优化的是推理过程中的 KV Cache——这是注意力机制中存储键值对的中间状态，随着上下文增长而线性膨胀。
具体而言，Quansloth 支持两种压缩模式：
用户在 Web UI 中可以实时调整 k_cache 和 v_cache 参数，并监控实际的 VRAM 分配情况。
Quansloth 的前端设计了一个独特的「Hardware Stats」模块，它通过截取 C++ 引擎的 stdout 日志（写入 engine_stats.log），实时解析并展示 GPU 显存使用量和压缩节省比例。这个设计让用户能够直观看到 TurboQuant 带来的显存节约效果，而不是黑盒运行。
支持直接上传 PDF、TXT、CSV、MD 格式的长文档，将其内容注入到聊天上下文中，用于测试 AI 的超长上下文记忆能力。结合 TurboQuant 压缩，用户可以在 6GB 显存的 RTX 3060 上稳定运行 32K+ token 的上下文。
models/ 目录，列出所有 .gguf 文件作为可选模型Windows 用户还可以通过 Launch_Quansloth.bat 一键启动（自动处理 WSL2 + Conda 环境）。
Quansloth 的安装流程涉及从源码编译 CUDA 内核，因此对环境有明确要求：
| 组件 | 最低要求 | 推荐配置 |
|---|---|---|
| GPU | NVIDIA 6GB+ VRAM | RTX 3060 Ti / RTX 4070 |
| 显存 | 6GB | 12GB+ |
| 系统 | Linux / WSL2 Ubuntu | Ubuntu 22.04 |
| Python | 3.10 | 3.10 |
| 其他 | CUDA Toolkit, CMake, g++ | 最新驱动 |
conda create -n quansloth python=3.10 -y
conda activate quansloth
git clone https://github.com/PacifAIst/Quansloth.git
cd Quansloth
chmod +x install.sh
./install.sh
install.sh 会依次完成：检查系统依赖 → clone 并编译 llama-cpp-turboquant → 创建 models 目录 → 安装 Python 依赖（gradio、openai、PyPDF2）。
conda activate quansloth
python quansloth_gui.py
# 访问 http://127.0.0.1:7860
Quansloth 依赖的是 llama-cpp-turboquant 的特定分支（feature/turboquant-kv-cache），而非标准 llama.cpp 仓库。这意味着项目在更新上存在滞后风险——如果上游 CUDA 优化分支停止维护，Quansloth 可能面临兼容性问题。
目前 Quansloth 没有任何 Dockerfile 或 docker-compose 配置，所有依赖都需要在宿主机上原生安装（CUDA Toolkit、CMake、g++）。对于不熟悉 Linux 环境配置的用户，install.sh 的编译过程可能遇到各种系统级错误。
由于底层是 CUDA 内核，AMD ROCm 和 Intel GPU 用户完全无法使用。这是工程实现的硬性限制，而不是算法的固有问题。
截至目前，GitHub 上仅有 151 stars、14 forks、0 个 open issues。虽然这对于一个专注于特定垂直场景的工具来说是正常现象，但也意味着社区支持和第三方插件生态都比较薄弱。
Quansloth 的出现代表了本地大模型推理领域的一个细分方向：不是追求最大模型、最强性能，而是在有限的消费级硬件上实现最长上下文。
这一需求的背景是：随着各行各业开始将 AI 应用于长文档分析、法律合同审查、代码库理解等场景，32K 甚至更长的上下文窗口已经从「噱头」变成了「刚需」。而云端 API 的成本、隐私顾虑以及网络延迟，让完全私有的本地推理持续有市场。
Quansloth 巧妙地借助 Google 前沿研究 + llama.cpp 工程基础设施 + Gradio 快速 UI 搭建的组合，用最小的代码量实现了一个实用的垂直工具。虽然它不是通用 AI 推理平台，但对于拥有 NVIDIA 消费级显卡、又有隐私需求的个人用户和小型团队来说，这是一个值得关注的选项。