新闻、仓库与研究，按时间排列。
/u/iam31337 在 RTX PRO 4000 Blackwell SFF（24 GB，工厂 70 W 无辅助供电）上用修改版 VBIOS 将功率提至 120 W，Qwen3.8 27B 生成从 35.04 提升到 58.53 tok/s（+67%），Qwen3.6 35B A3B 显存 +33.3% 时生成 +19.8%。158 次请求、每配置仅 1-3 次，两模型量化与投机解码设置不同，非严格受控对比；作者提醒 120 W 超出 PCIe 75 W 槽位预算，属实验性结果。全文与 CSV 见 https://piszczek.pl/blog/rtx-pro-4000-blackwell-sff-120w-qwen-benchmark
推荐理由：作者实测同一款卡上两个模型的功耗超频收益差异，给出具体功率与频率参数，并坦承样本量与量化设置的局限。
Reddit 用户 /u/Individual_Page9676 让云端 Agent 通过 Tailscale + LM Studio 调用本地 Mac 上的 Qwen3.6-35B-A3B，构建了一套验证式数据管线：模型自编 800 道数学题后在新会话中盲解，分歧交由 Qwopus 3.5 122B 仲裁，Agent 用 Python 暴力核算，最终得到 793 道可用题。盲解者在仲裁分歧中 56 次正确、作者 12 次，说明出题写官方答案比解题更易出错；第三轮复验中 793 个答案有 774 个被直接确认，甚至抓出 Agent 自己暴力核算写错的一道题。
作者在 M3 Max 36GB 上用统一协议实测 Kapitsa 0.2.12、oMLX 0.7.2、Rapid-MLX 0.16.8、Splash 1.4.0、MTPLX 2.12.2 五个引擎。稠密 Qwen3.8-27B-4bit 上 Kapitsa 41.3 tok/s 领先，oMLX 34.1；MoE Qwen3.6-35B-A3B 上 oMLX 122.9 与 Kapitsa 122.7 打平；Flint 40B-A2.5B 在 36GB 上由 Kapitsa 跑出 134.2 tok/s。oMLX 稠密从 17.9 提到 34.1 主要归功于 oQ4e-mtp 检查点加 Lightning MTP 的投机配置而非引擎本身；MTP 接受率稠密 75-78%、MoE 81-85%。
推荐理由：同一台 Mac 上五个推理引擎用统一协议实测，还标明各引擎权重与投机配置差异，数字可直接对照自家硬件选型。
matnum 发布 local-llm-benchmarks 仓库，在 128 GB 统一内存的 AMD Ryzen AI Max+ 395（Strix Halo）上用 llama.cpp 对 10 个 GGUF 模型/量化组合在 Vulkan 与 ROCm 两个后端测吞吐、延迟、内存、功耗与 tokens-per-watt。结果显示 Vulkan 在 10/10 单元生成更快（6 个领先 2.1–18.0%），ROCm 在 9/10 单元 prefill 更快（6.2–56.8%）；MoE 模型生成速度和每瓦效率是同体量稠密模型的 5–8 倍，gpt-oss-120b（MXFP4，约 59 GiB）达 55.3 tok/s。
推荐理由：原文公开了完整测试矩阵、固定 commit 和可复算测试，读者可以按需核对每个数字而不是直接信任结论。
作者让 Kimi K3.1 与 GPT-6 Astra 各跑一次相同的 Three.js 3D 飞行 Agent 任务并对比数据。K3.1 用时 12:28、20 步、读 725K prompt tokens、输出 49.2K tokens，Astra 用时 9:17、35 步、读 1.2M prompt tokens、输出 22.2K tokens；K3.1 推理占比 56%、成本约 $1.1-1.4（估算），Astra 约 $2.63。作者指出步数少可减少 prefill 负担但 decode 更重，并提醒本地部署需在所有子调用中固定 temperature 为 1；K3.1 因图像审查工具参数错误盲跑，Astra 首跑因工具参数问题被拒 29 次调用。各仅一次运行，成本为估算。
作者在单张 RTX 5090（400 W）加 128GB 内存的 Linux 机器上，对 Strata、Infernix、capy-flash、ninfer-ext、ninfer、llama.cpp 和 Basalt 七个 Qwen 3.8 FN 推理引擎做了基准测试，每个引擎各自转换 NVIDIA NVFP4 权重后跑相同的七个 greedy 请求，每个请求独立冷启动。
作者实测 DeepSeek-V4.1-Flash-1017 后认为不如 Qwen3.8-Flash-Next：DSF 坚称 Broadwell-EP 有 AVX-512、拒绝从 libgen 下载论文，而 QFN 20 分钟完成同样任务。让四个模型对比 AI 泡沫与历史泡沫后，Opus 5.5 评审发现 DSF 与 Opus 5.5 报告最相似：TF-IDF 相似度 0.572、共享 200 个四词短语，分析方法几乎一致。
作者在单张 RTX 5090 上对 Qwen3.8-Flash-Next NVFP4 的 basalt、capy-flash、ninfer-ext 三个引擎做了 262,144 token 全上下文对照测试，统一开启 MTP 推测与 int8 KV。结果 basalt 在所有上下文深度最快，prefill 8.1k-9.2k tok/s、greedy decode 176-265 tok/s；decode 排名与 MTP draft 接受率一致（0.74/0.57/0.56），采样解码使各引擎 decode 下降 7-10%。
作者开源 agents-per-gpu 仓库，在单张 48 GB A40 上以 Agent 形态负载实测 vLLM 0.32.0、SGLang 0.5.9 和 TensorRT-LLM 1.2.1 服务 Qwen3-4B 的并发容量。开启 prefix caching 后三个引擎均能承载 6 个并发 Agent 会话，关闭时仅 2 到 3 个，且每任务成本降至原来的三分之一到五分之二；8 秒 step SLO 下 SGLang 以 4 个会话领先。INT4-AWQ 量化的 Qwen3-8B 在工具调用精度持平的情况下比 BF16 的 4B 承载更多 Agent。所有数字可用 apg report 从 results/ 复现，方法与细节见 reports/REPORT.md。
推荐理由：作者在单张 A40 上实测三种推理引擎的 Agent 并发容量，并给出 prefix caching 带来的容量差和每任务成本数据。
Reddit 用户实测 LFM2.5-24B-A2B-Q4_K_M.gguf 后给出负面评价：在 llama.cpp 优化版上 RTX A4500 跑出 130tk/s 但反复循环，换 LM Studio 后行为稳定。在 Hermes 桌面端测试 Microsoft Garnet 插件任务时，经 GPT 检查发现代码残缺、缺少必要功能且未做端到端测试就声称验证通过，模板修复后改善有限。
GitHub 本地 LLM 热度榜显示，Qwen3.8-27B-Instruct（Apache 2.0）以 100.2 热度居首，在 RTX 5090 上经专用推理引擎达 500 t/s 单智能体、约 2000 t/s 多智能体，支持最高 1M token 上下文。Qwen3.8-Flash-Next-125B（MoE）以 60.4 热度次之，在 AMD Strix Halo 上 prefill 达 938 t/s。Ternary Bonsai 2 27B 经 1.75-bit 三值压缩至 5.9GB，保留约 98.2% 能力，5 天下载 11,792 次。
AIMultiple 团队推出 AIM System One Index，用于评测以单次前向返回带概率决策的决策模型（System One models），榜单综合浏览器任务、1,655 道单决策分类题和偏差测试三项基准，以 z-score 计分。57 个模型中 AutoJev-27B、d1-ultra 和 decider-12b 并列第一（60 分）；d1-ultra 浏览器任务得分 74%，成本 $0.026 per 1,000 decisions；Decider Flash V1.2 最便宜，为 $0.007 per 1,000 decisions；Laya 最快，每决策 30 ms。
/u/SamSausages 因 Intel B65 几乎没有公开跑分，自建 4x B65 平台，用 vLLM 对 Flash-Next W4A16 和 Qwen3.8-27B 的 INT4、FP8、BF16 等配置做长上下文吞吐扫描，覆盖 0 到 200K 上下文和 1 到 16 并发请求。数据显示 Flash-Next 开启 MTP-3 后单请求吞吐约翻倍（0 上下文 84.5 对 42.7 tokens/sec），200K 上下文下降到 45.8；Qwen3.8-27B INT4 在 4 卡下 8 并发可达 468.2 tokens/sec。
推荐理由：作者自建 4x Intel B65 平台，实测多款模型在 16K 到 200K 上下文下的吞吐数据，并给出 MTP 开关与不同精度的对照。
作者以 HF transformers 的 F16 参考输出为基准，在 Neoverse-N1 ARM 和 AVX2 x86 上实测低比特 GGUF 的正确性与速度。BitNet b1.58 2B4T 的 bitnet.cpp main（0b341e5）在 x86 上困惑度约为参考的 6 倍、ARM 上输出 ?，#588 激活函数修复加 isHuangXin/llama.cpp#2 可解决，#642 第三版已同时修复两个平台；Bonsai/Ternary-Bonsai 1.7B 在 llama.cpp、Prism fork 和 ik_llama.cpp 中均与参考一致，27B 在 Prism 与 ik_llama.cpp 结果一致。
推荐理由：作者用困惑度和 KL 对照参考实现逐项验证低比特模型输出正确性，并给出各运行时的实测速度数据，方法可复用。
kevinelong 在 GitHub 发布 local-llm-lab 仓库，记录在一台 64 GB DDR5、RTX 5070 12 GB 的 Windows 桌面机上对本地大模型的系统实测，并列出 693 项检查的九套基准。最佳配置为 Qwen3.6-35B-A3B Q4_K_M 经 llama.cpp 预配置（context 131,072、--cpu-moe），以及由 Strata 流式从磁盘服务的 Qwen3.8-Flash-Next Q2_0，两者在排名指标 414/414、全部九套 692/693 上逐格持平，后者的 1,100 项知识测试快 31%。
推荐理由：作者在固定一台桌面机上实测本地模型的匹配度、速度和分数，并公开预测记录与纠错，方法可迁移到自己跑本地评测时参考。
/u/FeydRowan 在 2× RTX 5070 Ti + 96 GB DDR5 上整理了可运行 Qwen3.8-27B 和 Flash-Next（125B MoE、6B 激活）的各推理引擎 decode 速度，区分了本人验证与作者自报数据，capy-flash（DFlash2）在 27B 上达 379 tok/s。文中指出 TP 比层切分更快、drafter 可带来 2–3× 加速、单模型内核在 batch 1 下比通用引擎快 2–6×；按本月欧盟含税价折算，两张中端卡每欧元性能比 5090 高 3–10×，且 96 GB DDR5 涨价后约占专家放内存方案成本的 40%。
推荐理由：作者在同一台机器上实测多款推理引擎并按欧元换算每千欧元的 tok/s，还指出 2026 年 RAM 涨价改变了性价比排序。
作者在单张 RTX 3080 20 GB 上用 llama.cpp 实测了 Qwen3.8-27B 的 Huihui 与 Heretic RVN 两个 abliterated 量化版本，仓库不含模型权重。结果显示 RVN IQ4_XS 在 MTP 下最快（代码 69.4 tok/s、散文 58.2 tok/s，比 Huihui 快约 5–7%），德语困惑度略低，通过 88.6K 上下文与全部 6 项工具调用测试，但多占 1.1 GB 显存导致 n-max 3 无法启动；MTP 草稿深度 n-max 2 是综合最优设置，MTP 对 prefill 无帮助反而约损失 5%。
Reddit r/LocalLLaMA 用户 Dany0 自测 DeepSeek V4.1 Flash 1017 的 token 效率：最高思考强度下 CoT 长度无变化，高强度下 CoT 明显更短但幅度不大；各强度下 CoT 质量更高、废话更少，解题所需轮数更少。作者认为值得一试，并希望 Artificial Analysis 重新测试。
Reddit 用户 /u/Sanbi_Ai 复盘 Kimi K3 发布三个月后的实际使用状况：全模型 1.56 TB，Unsloth 推荐的最小量化为 594 GB，需约 610 GB RAM+VRAM，装不进 512 GB；1-bit 量化与全模型下一 token 一致率 79%，2-bit 达 90% 但需 861 GB。其在 Artificial Analysis 指数已从 57 降至 44，GLM-5.3（753B）得 45，Step 5 Preview（600B）以 44 追平；自家 API 仅 43 tok/s，AA agentic 基准平均每任务近一小时、超 $10。许可证非 MIT，公司若 12 个月内总收入超 $20M 需与 Moonshot 另行签约。
推荐理由：作者用 Unsloth 量化文档和 AA 数据逐项核算了 Kimi K3 的本地运行门槛、API 速度和许可证限制，信息可直接用于部署决策。
作者在 RTX Pro 6000 Blackwell 上对比 Ninfer6000、vLLM（NVFP4）与 llama.cpp（Q4_K_XL）运行 Qwen3.8-Flash-Next 的表现。Ninfer6000 平均 decode 238 tok/s，约为 vLLM 的 1.59 倍、llama.cpp 的 2.21 倍，但 prefill 低于 vLLM（约 10k 对 16k tok/s）；BFCL v4、IFEval、MMLU-Pro、HumanEval+、MBPP+、Arena-Hard、RULER 等基准三者基本持平。
推荐理由：作者在 RTX Pro 6000 上实测三套引擎跑 Qwen3.8-Flash-Next 的吞吐与基准数据，并给出真实使用中工具调用异常的细节。
作者在双 AMD AI Pro R9700（Lenovo P620、Threadripper Pro 3945WX、128 GB DDR4）上对比了 Qwen3.8-Flash-Next 的三种推理方案：radiance 1.4.0、Strata 0.1.42 和 Unsloth 的 llama.cpp fork。radiance 生成速度最快达 147.2 tps，Strata 为 79.1 tps，llama.cpp 仅 17.6 tps；三者与 OpenRouter 上 Alibaba 托管的 Qwen3.8-Flash 输出一致性接近，作者认为可视为等效并按速度选择。
/u/isoos 与朋友发布了自托管模型的首轮往返翻译基准结果，涵盖 8 个语言对、12 条测试提示词，用嵌入向量距离打分并惩罚不一致与指令遵循错误，测试了 15 个模型的不同量化版本，结果见 selfhostedintelligence.com。观察包括：16GB VRAM 足以自动化翻译；推理模式对 Qwen 模型提升巨大；大型 MoE 模型最低量化档与上一档差距明显；abliteration（huihui quants）对大模型通用能力的影响远小于小型稠密模型。测试在 1-2 台 Strix Halo 上运行。
推荐理由：实测覆盖 15 个模型不同量化版本，并给出量化层级与 abliteration 影响的具体观察，可按硬件条件选型。
Reddit 用户 /u/Tx8aker 对 AMD MI350P 与 RTX Pro 6000 (Blackwell) 跑 Qwen3.8-27B 推理对比，称 MI350P 开箱表现极差，经内核与调优优化后性能提升超过 2 倍。在 3k 输入 8 并发、50k 输入 20 并发、200k 单用户三档冷启动测试中，MI350P 输出吞吐分别为 889/130.6/79.8 tok/s，对 RTX Pro 6000 的 596/50.4/45.1 tok/s 达 1.49x/2.59x/1.77x，TTFT 也全面更快；作者指出 MI350P 显存利用率仅解锁 50%，仍有提升空间。
推荐理由：作者实测前先对 MI350P 做了内核调优才跑分，并给出三档输入长度的完整数据，比开箱对比更能反映真实差距。
一位 Reddit r/LocalLLaMA 用户在 128GB M1 Ultra Mac Studio 上对比 DeepSeek-V4 Flash 与 Qwen 3.8 Flash Next 的使用体验。DeepSeek-V4 的 benchmark 成绩略低于 GPT 5.5 high，Flash Next 略高于 5.4/5.5 xhigh，但 Flash Next 完成任务耗时明显更长，大约 5 个任务的时间才能换来 1 个任务的完成度。该用户仍在使用 Qwen 3.8 27b，因其占用资源更少，可腾出机器做图像生成等其他工作。
Reddit r/LocalLLaMA 用户用 evalscope 对比 Qwen3.8-Next IQ3_S（MI50 32GB）与 Qwen3.8-27B UD-Q4_K_XL（RX 7900 XTX 24GB）。166 题总成绩 Next 151 对 27B 145，AIME26、IFEval、BFCL v4、LiveCodeBench v6 均略胜，但 14 题单解差异 sign test p=0.18，仅属倾向而非定论。速度上 27B 达 47.9 tok/s，Next 为 36.8 tok/s。
一位 Reddit 用户在 R9700 上实测了三个 Qwen3.8 27B 量化版本，用 gsm8k（数学）和 humaneval（代码）评测。结果出乎意料：Swift-1.5-Qwen3.8-27B-MXFP4-A-outQ6_K 在数学上最佳，Qwen3.8-27B-UD-Q6_K_L 反而最差，而 Swift-Qwen3.8-27B-Q6_K 速度最慢。作者表示需跑完整测试套件才能得出更精确结论。
作者用自写脚本在单张 Tesla V100-SXM2 32GB 上实测了 Ollama 与 llama.cpp 跑 llama3.2:1b、Qwen3-30B-A3B-Thinking、Gemma 4 31B、Qwen3-Coder-30B-A3B 等模型的生成与 prefill 速度，请求长度从 1K 到约 118K token。数据显示引擎加配置才是对比单位，如 Qwen3-30B 上 Ollama 生成随上下文增长快 17% 到 49%，而 llama.cpp 用 q8_0 KV 缓存才装下 131072 窗口；作者还发现 Ollama 对 gemma4-32k 报告的 56 tok/s 和 2.1GB 显存不可信，超过 31B 稠密模型约 44 tok/s 的物理上限。
推荐理由：作者在单卡 V100 上实测了多款模型在 Ollama 与 llama.cpp 的长上下文速度差异，并指出引擎配置和内存预算比引擎本身影响更大。
Reddit r/LocalLLaMA 用户在单张 RTX PRO 6000（96GB）上用 Strata 后端运行 Unsloth 的 Qwen3.8-Flash-Next UD-Q4_K_XL，配置 INT8 KV cache、256K 上下文和 MTP-4 投机解码。单请求解码速度较 vLLM（NVFP4 量化）提升约 46%-49%，四类任务均达 185.8-320.4 tokens/s。作者称该模型编码任务表现高效出色。
tgarg01 在 GitHub 开源了 silybench 网站背后的数据集，收录在租用 GPU 上实测的 LLM 服务性能、按日期记录的 GPU 租金与 API 价格表，以及由此推导的自托管与 API 成本对比。每个实验文件夹保留实验配置、硬件指纹、当日报价和原始证据（vllm bench serve JSON、GPU 遥测 CSV、vLLM 日志、lm-eval 结果），价格表每 6 小时由 CI 自动刷新，数据以 CC BY 4.0 许可发布，可用 SQLite、CSV 或 JSON 直接查询。
5.3B 参数的 Aplomb 1 登顶 Hugging Face 官方 Typed Decisions 概率决策基准，KL from gold 为 0.123，Brier score 为 0.065，均居榜首，低于约为其五倍规模的 27B 第二名模型（KL 低 40%）。模型支持文本、JSON、图像、视频和音频单次输入，上下文达 1M tokens，API 上 1M-token 文档约 3 秒读完，输入价格 $0.02 per 1M tokens 且输出免费。权重已在 Hugging Face 开源。
GitHub 上的开源项目 CAGE（Cache-Augmented Generation Evaluation）提出在统一协议下同时衡量 KV-cache 复用（CAG）、检索（RAG）及其混合方案的服务性能与答案质量，指标包括 TTFT、吞吐量和 grounding、faithfulness、abstention。项目以"服务产出 Y"（按时且正确的请求每秒数）为核心指标，并附上 truth tax 等归因分析，覆盖 vLLM、SGLang、LMDeploy 四种引擎、十二条基线与八个数据集。工程链路已建成并配有 3,000+ 测试的离线套件，但正式评测活动尚未运行，早期数据仅为试点、不可作为结果引用。
Reddit r/LocalLLaMA 用户讨论多 GPU 上运行 NVFP4 量化的工具选择：作者目前只能跑通 unsloth，认为 vLLM 加载太慢，TensorRT-LLM 问题太多。对 Qwen 3.8 的 NVFP4 版初步测试中，代码表现一般，但视觉和 tool calling 印象深刻，复杂场景略优于 Q6 gguf。在 2x5060ti 上以 197k ctx 运行速度出色，模型加载仅需 4-6 秒。
一项开源项目让六个决策模型（jev 1.13、Kev 4B、Clef、Clef Flash、GPT-6 Luna 和 Laya）实时对玩 Pac-Man。jev 1.13 以平均分 2,750、最高分 6,380 居首，GPT-6 Luna 平均分 2,568、平均延迟 179 ms。每个模型跑 100 次取均值（95% 置信区间），排行榜和仓库均已开源，玩家也可亲自扮演吃豆人、由这些模型操控幽灵。
作者开源了在 RTX 3060 12GB 与 RTX 3090 24GB 两套本地平台上、用 llama.cpp、ik-llama.cpp、moe-cache 分支、vLLM 0.29.0 容器栈和 Strata 引擎跑本地模型的基准报告，含量化档位、上下文长度、prefill/decode 速度表，以及一个基于 Shoko-WebUI 重写任务的 agentic 编码基准，附完整测量方法与逐引擎参数说明。
推荐理由：作者在两套消费级 GPU 配置上实测多个 llama.cpp 分支与引擎的本地推理速度，方法、参数和完整数据公开，结果可直接对比参考。
GitHub 上的 llm-intelligence-monitor 是一个轻量回归测试项目，用于监控 GPT 等大模型是否出现能力下降。自 2026-10-05 起自动日测 schedule 已停用，改为按需人工运行：默认 8 道固定锚点题 + 8 道分层轮换题，每题运行中英文镜像，四模型（GPT-6 Astra、GPT-6.1 Sol、GPT-6 Luna、GPT-5.6 Sol X High）并行测试，每模型每轮执行 32 个测试。项目还增加了基于轻量 Agent Harness 的应用型评测通道，评分以客观隐藏检查点为主，不依赖 LLM Judge。
开源项目 eval-connections 提供基于《纽约时报》Connections 谜题的语言推理评测框架，通过 OpenRouter 支持 200+ AI 模型（含 GPT-5、o3、Grok-4 等推理模型）。4.0.0 版新增 one-shot 模式，模型一次提交全部 4 组，含陷阱检测加分，每题最高 5 分、20 题满分 100 分。框架支持并行执行（默认 8 线程）、prompt 缓存、成本追踪和可复现评测，并有人机交互模式。
Massed Compute 开源了 gpu-benchmark 仓库，收录多款 LLM 及图像/视频模型在 RTX PRO 6000 Blackwell、H100、H200 NVL、L40S 等 GPU 上的推理速度评测数据，涵盖 Llama 3 系列、DeepSeek V4.1 Flash、Qwen3.8 27B、GLM 5.3 Flash 等模型。2026 年新增测试改用 vLLM 和 SGLang 引擎，固定输入 128 / 输出 128 tokens，并在 concurrency 1 / 8 / 32 下运行，Wave 5 的复现脚本位于 scripts/wave5/。
作者在单张 RTX 2080 Ti 22GB 上用 Unsloth UD-IQ4_XS 4-bit 量化实测 Qwen3.6-35B-A3B，HumanEval 全部 164 题 pass@1 达 89.63%（147/164）。随后对自制的 MoE expansion 路由补丁做受控 A/B：在最后 15 层（25–39）每 token 激活 20 个专家而非原生 top-8，无需重训或改文件，pass@1 升至 90.85%（149/164），解码速度从 69 tok/s 降至 56 tok/s（约 -19%）。作者提示 +2 题在 164 题的统计噪声范围内，且用的是原始 HumanEval 而非 EvalPlus，不能与 EvalPlus 榜单直接对比。
推荐理由：作者给出了同机同量化下的受控 A/B 数据和解码速度代价，读者可以据此自行判断该路由补丁是否值得用。
halu-sys 在 GitHub 开源 llm-probes，为本地 llama.cpp/llama-swap 栈提供部署级评测探针，回答只有本机才能回答的问题，如 IQ3_S 量化下 262k 上下文是否真实、长上下文格式遵循、循环退化率、MTP 投机解码是否无损、跨上下文事实组合与多跳 Agent 委托链等。所有探针运行时程序化生成（可复现、无训练数据污染），由代码评分而非 LLM 评分。实测显示 Qwen3.8-Flash-Next IQ3_S 在 8k–256k 各探针多数通过，并总结了推理预算不足会静默吞掉答案、参数剥离使评测失效、探针自矛盾曾误导结论等六起生产事故复盘。
推荐理由：针对本地 llama.cpp/llama-swap 部署的实测探针，给出各探针的真实运行结果与踩坑复盘，方法可直接复用。
Reddit 用户在 4 卡混合主机（3x P102-100 + RTX 3060 12GB）上对比 ik_llama.cpp 与 mainline llama.cpp，运行 Qwen 3.8 Flash-Next 177B（IQ3_XXS，约 89 GB，35 层卸载 GPU、13 层走 AVX-512 CPU、32k context）。mainline 达到 prompt eval 19.70 tokens/sec、生成 10.86 tokens/sec，ik_llama.cpp 分别只有 5.48 和 8.43 tokens/sec，且未启用 CUDA graphs。