08·09 - AI 午报：Kimi K3 瘦身至 478GB，DS V4 Flash 本地量化跑分超 Opus 5

周末社区讨论围绕「把大模型装进消费级硬件」展开：Kimi K3 被社区裁掉多语言权重后从 711GB 缩到 478GB，DeepSeek V4 Flash 的本地量化在 SlopCodeBench 上跑出比 Opus 5 更高的严格通过率。硬件侧，有人在阿里巴巴上发现了 96GB 版 RTX 5090 的踪迹，另有人实测 PCI-E P2P 能给消费级多卡带来约 25% 的免费预填提速。

本地模型与评测

硬件与优化

工具与洞察

#1 Kimi K3 被社区裁掉多语言权重，IQ2-XXS 量化从 711GB 缩至 478GB

社区用户 hellohazime 将 Kimi K3 的 Unsloth IQ2-XXS 量化中的多语言权重移除，仅保留英文部分，模型体积从 711GB 降至 478GB，其余权重结构不变。 发布者表示模型智能水平未见明显下降，并在 Hugging Face 上提供了可直接下载的 GGUF 文件。

另一位用户用同一批权重另做了一个 576GB 的 IQ2-XXS 版本（reap576），在 SWE-Lancer 的三个任务上全部成功，而标准 2-bit 版本全部失败。测试者指出这很可能是环境因素所致，但也无法完全排除裁掉部分专家权重反而改善了编码表现的可能性。

来源：Reddit r/LocalLLaMA · 2026-08-08
原文：https://www.reddit.com/r/LocalLLaMA/comments/1vjanps/kimi_k3_unsloth_iq2xxs_from_711gb_down_to_478gb

#2 本地量化 DeepSeek V4 Flash 在 SlopCodeBench 严格通过率超过 Opus 5

社区用户用 antirez 的 Q2-Q4 imatrix 量化版本在 MacBook M5 Max 上跑 DeepSeek V4 Flash 0731，搭配 pi 0.84.0 作为编码 harness，SlopCodeBench 严格通过率达到 5/17（29.4%），超过 Opus 5 在 Claude Code 下的 4/17（23.5%）。

同一模型切换到 OpenCode 1.18.10 时严格通过率降为 3/17（17.6%），说明 harness 的选择对评测结果有明显影响。本地量化速度慢于云端 API，但测试者认为 pi 的智能补偿弥补了部分量化损失。需注意这是单人单机的一次性评测，不代表普遍水平。

来源：Reddit r/LocalLLaMA · 2026-08-09
原文：https://www.reddit.com/r/LocalLLaMA/comments/1vjiypj/updated_benchmark_deepseek_v4_flash_on

#3 RTX 5090 96GB 出现在阿里巴巴，真实性待确认

Reddit 用户 panchovix 在阿里巴巴上发现了标称为 RTX 5090 96GB 的显卡列表，但帖子未提供链接或截图等可核实的信息。 目前尚不清楚这是工程样品、改装卡还是虚假列表，建议在出现更多证据前保持谨慎。

英伟达尚未公布 96GB 消费级 GPU 的官方计划。

来源：Reddit r/LocalLLaMA · 2026-08-09
原文：https://www.reddit.com/r/LocalLLaMA/comments/1vjcljq/rtx_5090_96gb_spotted_on_alibaba

#4 消费级 Nvidia 多卡开启 PCI-E P2P 后预填速度提升约 25%

Reddit 用户 BidonPomoev 在 4 张 RTX 5060 Ti 16GB 的 AMD EPYC 服务器上测试发现，开启 PCI-E P2P 后 vLLM 的 prompt processing 速度提升约 25%，且完全免费。

配置方法：在 BIOS 中开启 ReBAR，安装来自 aikitoria/open-gpu-kernel-modules 的补丁驱动，然后在 vLLM 启动时设置 NCCL_P2P_DISABLE=0、VLLM_SKIP_P2P_CHECK=1 和 NCCL_P2P_LEVEL=SYS。测试使用的模型为 Qwen3.6-27B-FP8，以张量并行模式运行。Token 生成速度变化不大（约 90-120 t/s），但预填延迟在 32K 上下文下从约 20.6 秒降至约 15.2 秒。

来源：Reddit r/LocalLLaMA · 2026-08-08
原文：https://www.reddit.com/r/LocalLLaMA/comments/1vj7wey/enabling_pcie_p2p_for_consumer_nvidia_cards_will

#5 纯 C99 的 BitNet 推理引擎在 Xeon CPU 上跑到 36 tok/s

shifu_legend 用纯 C99（无 Python、无 CUDA、无 BLAS）从头构建了一个 BitNet 1.58-bit 推理引擎，在 Intel Xeon 上用 4 线程跑到 36.25 tok/s。 项目使用 AVX2/AVX-512 的 VNNI 指令将三元权重（-1, 0, +1）直接累积到整数寄存器，绕过了传统的 float32 解包步骤。线程池采用 C11 原子操作加自旋后退策略，token 生成阶段线程同步开销几乎为零。

测试者指出，单序列解码速度已被内存带宽卡在理论峰值的约 95%，更快的计算核心不会带来端到端延迟改善。代码已在 GitHub 开源，编译为单个无依赖二进制并提供 OpenAI 兼容 API。

来源：Reddit r/LocalLLaMA · 2026-08-08
原文：https://www.reddit.com/r/LocalLLaMA/comments/1vj1cin/building_a_zerodependency_c_inference_engine_for

#6 实测发现 Qwen 对代码的 tokenizer 效率约为 Gemma 的 2.6 倍

Reddit 用户 WhoRoger 将同一段 330 行的 HTML/JS 代码分别输入 Qwen 35B A3B 和 Gemma 26B A4B，Qwen 将其 tokenize 为 1609 个 token，Gemma 则为 4258 个 token，相差约 2.6 倍。 该用户认为这从 tokenizer 层面解释了 Qwen 在编码任务上表现更好的原因：Qwen 似乎将代码视为特定结构化的输入/输出格式，而 Gemma 则按普通语言逐词拆分。

在文本文档上（55 行说明文档），两者的 token 数差异不大（1025 vs 1039），表明差异主要来自代码标记化的效率。

来源：Reddit r/LocalLLaMA · 2026-08-09
原文：https://www.reddit.com/r/LocalLLaMA/comments/1vjb15v/no_wonder_qwen_and_gemma_are_so_different

#7 LFM 2.6B 在 3090 上跑到 260 T/s，适合快速扫描长文本

用户 Borkato 报告 LFM 2.6B 在 RTX 3090 上达到约 260 t/s 的生成速度和约 20K t/s 的预填速度。 该模型最初为手机端设计，体积小但上下文支持到 128K。用户反馈它适合快速任务，如扫描长文本中是否提及某关键词、总结短文或快速补全相似结构内容，但不适合需要高质量推理的重要任务。

来源：Reddit r/LocalLLaMA · 2026-08-09
原文：https://www.reddit.com/r/LocalLLaMA/comments/1vjgp6r/lfm_26b_is_a_lot_of_fun

本文由AI辅助生成，可能存在幻觉