按兴趣浏览，循来源深入。
/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
推荐理由：作者实测同一款卡上两个模型的功耗超频收益差异，给出具体功率与频率参数，并坦承样本量与量化设置的局限。
作者在 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 和可复算测试，读者可以按需核对每个数字而不是直接信任结论。
作者开源 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 带来的容量差和每任务成本数据。
/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 涨价改变了性价比排序。
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 的吞吐与基准数据，并给出真实使用中工具调用异常的细节。
/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 做了内核调优才跑分，并给出三档输入长度的完整数据，比开箱对比更能反映真实差距。
作者用自写脚本在单张 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 的长上下文速度差异，并指出引擎配置和内存预算比引擎本身影响更大。
作者开源了在 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 分支与引擎的本地推理速度，方法、参数和完整数据公开，结果可直接对比参考。
作者在单张 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 部署的实测探针，给出各探针的真实运行结果与踩坑复盘，方法可直接复用。
作者在 AMD Ryzen AI MAX+ 395（Radeon 8060S iGPU、128 GB LPDDR5X 统一内存）一台机器上汇总了 42 个模型的生成速度实测数据。
推荐理由：作者在同一台 AMD Strix Halo 机器上实测 42 个模型的生成速度，并给出各引擎配置和测量口径，便于横向比较本地部署方案。
ggml-org/llama.cpp 收到编号 #29869 的 Pull Request，为 Metal 后端加入 few-row MMA matmul 与批量拷贝以加速推测解码。
推荐理由：原文给出了同一环境下 PR 前后 DFlash2 推测解码的 decode tok/s 对照，读者可以据此评估该 Metal 优化在不同任务下的实际收益。
作者在 36 GB M3 Max MacBook Pro 上实测 oMLX 0.7.0、Rapid-MLX 0.15.5、Splash 1.2.1 与 MTPLX 2.12.2 四款推理引擎，测试 Qwen3.8-27B-4bit 与 Qwen3.6-35B-A3B-4bit。
推荐理由：作者在同一台 M3 Max 上用统一流程实测四款 MLX 推理引擎，还指出 KV cache 跨重启保留会误导二次跑分。
/u/dh7net 发布自建基准 airbench.ai 榜单，用真实任务（数学、视觉、电脑操作、编码）实测本地模型与 harness 搭配的能力和速度，参考基准为 Claude Code Opus 5.5 的 100%（14 分 26 秒），本地 zcode/4xRTX6k/glm-5.3-flash-NVFP4 同样可达 100%（31 分 13 秒）。
推荐理由：作者用自建基准实测了多组模型与 harness 的本地搭配，给出同一模型在不同 harness 下得分差距可达 22% 到 96% 的数据。