你想在自己的电脑上运行一个 763B 参数的大模型，就像想把一座图书馆塞进书房：真正麻烦的不只是计算，还要先放得下全部“书”。ISTA-DASLab 这次把 DeepSeek-V4.1-Flash-1017 的主体权重压到平均 1.75 至 2.25 比特，并做成面向本地工具链的 GGUF 文件。已有用户在消费级电脑上把它跑了起来，llama.cpp 的适配也已进入拉取请求阶段。这让“超大模型本地运行”从规格表上的可能，向可重复的工程路线迈了一步。
不过，标题里的“2 比特”需要先拆开看：它只指模型 backbone——也就是承担主要计算的主体网络——并不代表完整模型整体只有 2 比特，更不代表整台电脑只需 12 GB 内存。模型规格、压缩成绩和 12 GB 显存运行能力目前主要来自发布方，实际速度则只有少量用户个案。
763B，为什么还能放进个人电脑？
DeepSeek-V4.1-Flash-1017 是稀疏 MoE（Mixture of Experts，混合专家模型）。它每层有 384 个“专家”子网络，但处理一个 token——模型阅读和生成文字时使用的基本单位——只激活其中 6 个。可以把它理解为一家公司养着许多专业顾问，每次只叫最相关的几位开会。
这能减少一次推理实际动用的计算量，却没有消除存储问题：全部专家的权重仍然要放在某处。这个模型共有 763.2B，也就是 7632 亿参数，并支持最长 100 万 token 的上下文窗口。
ISTA-DASLab 提供了三档量化版本。量化就是用更少的二进制位保存权重，以降低文件和内存体积，代价可能是模型能力或运行速度发生变化。三档主体网络分别是 IQ1_M、IQ2_XXS 和 IQ2_XS，平均位宽为 1.75、2.00 和 2.25 bpw（bits per weight，每个权重平均占用的比特数），文件大小约为 120.7、138.2 和 155.2 GB。
它们采用 GGUF——llama.cpp 生态常见的模型文件格式，负责把权重和运行所需信息装进便于本地加载的文件。与给所有权重套用同一种压缩方式不同，这次的 RCO 会在总容量预算内，根据不同张量对精度的敏感程度分配量化类型；GSQ 再负责执行低位标量量化。说白了，不是把所有行李一律压扁，而是把更怕挤坏的东西多留一点空间。
“2 比特”之外，还有一大块
模型的 backbone 包含 551.9B 参数，宣传中的 1.75 至 2.25 bpw 只按这部分计算。模型另有两个 Engram lookup tables——可按 token 查询的查找表——合计包含 196.6B 参数，以 4.50 bpw 保存，形成约 110.6 GB 的共享文件。
因此，2.00 bpw 版本的完整文件总量不是 138.2 GB，而是约 248.84 GB；最小的 1.75 bpw 版本也约为 231.32 GB。Engram 表每次只读取一行，可以通过内存映射留在 SSD 上，不必整体装入显存或系统内存，但文件仍然需要下载和存储。
发布方称，借助 Strata，三个版本都能在一张只有 12 GB VRAM（显存）的 NVIDIA GPU 上运行。这里的关键是“运行”，不是“整个模型装入 12 GB”：主体网络的其余部分仍由系统内存承接，Engram 文件则留在 SSD 上按需读取。
压得这么狠，能力还剩多少？
ISTA-DASLab 在 reasoning effort 50 的设置下测试了三个任务。发布方称，2.00 bpw 的 IQ2_XXS 在 AIME25、GPQA-Diamond 和 LiveCodeBench v6 上都与原始版本相同，三项平均分均为 93.54。
更小的 1.75 bpw 版本在 AIME25 得到 100.00，GPQA-Diamond 为 88.38，LiveCodeBench v6 为 88.57，平均分 92.32。发布方据此称它保留了 98.7% 的效果，同时比 2.00 bpw 主体文件少约 17.5 GB。
这些数字说明极低位量化至少没有在这组三项测试中造成明显崩塌，但还不足以证明“几乎无损”。AIME25 的各版本都达到 100 分，测试已经饱和，很难继续显示细小差异；目前材料也没有独立的 KLD、PPL 或更广泛任务复测。
真正的变化，是有人已经跑起来了
至少两名独立用户报告在本地消费级硬件上成功运行该模型。一名用户在 R9700、RTX 5060 和 128 GB RAM 的机器上，给 GSQ GGUF 额外打补丁后通过 llama.cpp 运行，测得提示处理速度 31.32 tokens/s，生成速度 6.55 tokens/s。
另一名用户使用 RTX 5090、64 GB DDR5 内存、4 TB NVMe SSD 和 Windows 10，通过 Strata 运行 8K 上下文，报告约 10 tokens/s。两组数字不能直接比较：后端、硬件、上下文和测试口径都不同。它们更可靠地说明了一件事——这个规模的模型确实能在个人电脑上启动并生成文本，而不只是存在于发布方的模型卡里。
llama.cpp 是一个强调跨平台和消费级硬件支持的 C/C++ 本地推理项目。目前已有 PR #31086 尝试加入 DEEPSEEK41 架构及相关 GSQ GGUF 适配，但仍处于 PR 状态。前述用户也明确提到需要额外补丁，因此还不能说它已经进入 llama.cpp 的稳定正式版本。
这条路线并非突然出现。据 ICLR 与 Institute of Science and Technology Austria 的材料，DASLab 在 2022 年提出 GPTQ 时，曾估算旧方法压缩一个 175B 模型至少需要六个月；分块处理把同等规模的工作缩短到约四个 GPU 小时。四年后，GSQ 与 RCO 又把这场工程竞赛推向更低位宽：不只压缩权重，还自动决定有限的比特应该花在哪里。
为什么值得关注
这次进展的重要性，不是“12 GB 显卡拥有了 763B 模型”，而是超大模型本地化所需的几块拼图开始接上：极低位量化负责缩小权重，稀疏 MoE 控制每次计算量，内存映射让大文件按需读取，GGUF 和 llama.cpp 则把它接入普通用户熟悉的本地生态。
它离轻松、便宜和即装即用仍有距离，但“能否运行”已经开始由独立用户用具体机器和速度回答。对本地模型而言，这是比一张漂亮的 benchmark 表更实在的进展。
局限与未知
- 量化质量、12 GB 显存运行能力和主要 benchmark 成绩仍缺少独立复测；现有三项测试也不足以覆盖真实使用。
- 完整模型仍需约 231 至 266 GB 文件空间，并依赖系统内存和 SSD。材料没有给出统一的总内存、功耗或成本测算。
- llama.cpp 支持尚在 PR 阶段，当前成功案例涉及额外补丁，距离稳定、通用的正式支持还有工程工作。