哟，庙前冰室，连续几年拿过大陆 TOP1 酒吧的，没预约能喝上就不错了，虽然我觉得他家的特调相当一般。。。

@kaidong21 一楼正确个锤子，这种车轱辘话回答上到点子了？有半点信息量？ GGUF 的量化的资料特别少，学术界也不怎么研究，答案基本都只在代码里，问大模型能问出个锤子。

回楼主：

对单个张量而言，GGUF K-量化方法常见的只有 Q2_K / Q3_K / Q4_K / Q5_K / Q6_K 。而同一个模型里面包含了多个张量，每个张量的精度都可以不同。

而后缀 _S / _M / _L / _XL 的意思就是，如果这个量化模型里含有的高精度张量越多，就把他的规模标得越大。比如 Q4_K_M ，大部分张量是 Q4_K ，但对于小部分重要的张量（如注意力部分），就使用 Q6_K 。比如 Q4_K_S ，默认 Q4_K ，重要的张量用 Q5_K 。所以 Q4_K_M 的大小和精度都比 Q4_K_S 要好一些。

但是 _S / _M / _L / _XL 的具体定义可从来没有标准而言。这些规模根本不能说是一个标准，只能说这是一个预设。甚至 llama.cpp 中根本就没有预先定义好 Q4_K_L 和 Q4_K_XL 这两个预设，所以某某预设下的 _XL 甚至不如另一种预设下的 _M 大，也是正常的，因为这些东西本来就没有标准。

回到你说的那个模型，你点进 huggingface 的文件详情能看到每个张量的格式，Q4_K_M 中的张量有 Q4_K 和 Q6_K ，这应该是 llama.cpp 默认的预设。而那个 Q4_K_XL 中的张量基本只有 Q4_K 和 Q5_K ，是 UD 自己定义的预设。所以前者体积大，就这么简单。

这就是楼主想要的准确的回答（并且撰写过程中完全没有使用任何 AI ）

停产了所以涨价了，停产前全新价格最低 300 不到。

目前的价格已经没有购买价值了，同样的 SoC 方案不如买磊科 n60 pro ，国补后的价格也是 300 出头，同样能刷机，但是还带双 2.5G 的网口，规格就比红米的高一档。

Rust 开发人员和（不愿意写 Rust 的）Ｃ 开发人员的矛盾是不可调和的。

内核内部没有稳定 API ，这赋予了维护者想改什么东西就改什么东西的权力，可以随时改进、重构。如果改 X 模块的时候 Y 模块炸了，那 X 的维护者只需要顺带着把 Y 模块弄好就行。这事儿是很常见的。而加入 Rust 之后那可就不一样了：维护者改了 X 的 C 代码，Y 模块那边的 Rust 代码炸了，这谁负责？

按照原有规矩，C 的人就不得不去弄那个 Rust 代码，基本等于强迫 C 的人写 Rust 了，C 的人当然不愿意。所以 Rust 的人就承诺，如果改 C 代码把 Rust 改炸了的话，Rust 代码由 Rust 的人负责修。

这个承诺是很扯淡的。原本没有 Rust 的情况下，改炸了顺手修就完了，反正都是 C 语言。现在 C 的人要重构一下，还得要给 Rust 的人发邮件、等 Rust 的人来修。这要是 Rust 的人回复晚了赶不上合并窗口怎么办，这要是一两个星期都不回复（比如在度假）怎么办，要是跳出来扯皮那怎么办。而且说，有些 C 写的模块，都存在十几甚至几十年了，C 的人也维护了十几甚至几十年了，允许他们随时改进、重构代码，这确实是应该的，原有的规矩也确实如此。现在好了，重构得看 Rust 的人的脸色了。舆论上出事的模块都是这些，什么 FS 什么 DMA ，老模块了，被各个其他模块调用，一改就炸一片，未来哪天炸在 Rust 模块的头上那是必然的。

既然不可调和，那这事儿也简单，Rust 的人和（不愿意写 Rust 的） C 的人两边之间选一边开除就是了。别说什么得罪人，Linus 和 Greg K-H 连 Chinese 和 Russians 都能开除，那没有什么是不能开除的。

但是一转炒币真的有点绷不住。。。

rprx 最早开发的协议都有缺陷，有些缺陷属于前人早就踩过、甚至写进了论文明确指出有坑，然后那几个协议硬是踩进去。

说实话，发明几个不太圆的轮子也完全 OK ，毕竟开源免费，又没收大伙儿钱，不圆就不圆吧。可每次推出新协议，描述里永远是自吹自擂，秒天秒地秒空气，声量大得很。其他人给他指出缺陷吧，也不是好好说话的样子，有问题反正是不会承认的，协议也是从不附带文档的，想审查协议只能去翻代码。

评论区也是一股饭圈味，一边倒帮着说话，这楼里就有一个骂坛友屌毛不如的，粉丝骂人这件事我真的是从 2020 年看到 2025 年，真的无语。“一届一届换了多少新协议了，改过吗？换汤不换药啊！”

@coefuqin 4x V100 我想过。V100 的张量核心只支持 fp16 ，开了量化 tensor core 就是纯摆设，不开量化就更扯淡，64G 显存连 32b 模型都放不下，唯一能期待的就是 NVLink 全互连后低并发 decode 加速。6000 应该买不到 NVLink 底板 + 显卡吧，如果是 SXM 转 PCIe 的话我觉得还不如多买几张 2080 Ti 22G 。

其实也没那么难，这个模拟器只用运行 bootloader 和 hypervisor ，大概率是不需要支持浮点指令和 SIMD 指令的，起码能省下三分之二的工作量。

@qq316107934 楼主的这个问题就是因为 Windows 系统不支持 overcommit 策略导致的，这种情况下换个别的应用照样分配不出内存。

回楼主：
正经的回复是：多开点 swap （ Windows 叫虚拟内存）就能解决。
不正经的回复是：换个好点的操作系统吧，能开 overcommit 的那种，比如 Linux 。

@geelaw 谢谢提醒，之前只知道 return std::move(local_variable); 会有不好的效果

这个和 move 没有任何关系，std::move(std::string(...)) 中的 std::string(...) 本身就已经是可移动的右值了。在这个场景下有没有 std::move 都是一样的

file_ 变 eof 是因为 istreambuf_iterator 把文件流的内容读完了，读完之后就是 eof 。

@rulagiti 自己改 odhcp6c 的源代码，其实不算复杂，我改过。