新闻、仓库与研究，按时间排列。
meanderinghuman 发布 storeops-copilot 项目，用 QLoRA 在免费 Kaggle T4 上微调 Qwen2.5-3B，结合代码级安全网关和大模型兜底，在 500 个held-out场景中达到 95.4% 任务成功率，94% 请求本地处理，有害动作率 0.4%。训练数据由 GLM-5.3 出题、DeepSeek-V4.1-Flash 以真实工具执行作答，过滤后保留 2,645 条；网关强制规则包括订单只能进待确认队列、产品 ID 必须来自同会话搜索、数字必须来自工具返回。项目基于 Walmart M5 数据集，附 1.5B 与 3B、多种量化精度的完整对比评测和失败复盘，代码 MIT 许可，3B 模型为 Qwen Research License。
推荐理由：原文给出完整的训练配方、评测数字和失败复盘，读者可以照着在免费 T4 上复现这条小模型本地 Agent 路线。
GitHub 用户 dosthcpp 发布 llm-pipeline 仓库，分享在单张 RTX 3090 上进行的本地 LLM 生成、训练、评估与量化实验源码快照。包含 Qwen3 系列 4B/8B 模型的 QLoRA SFT、RAFT、DPO 训练脚本，以及 GGUF 转换和 llama.cpp 部署脚本。仓库不含训练数据、模型权重与适配器，也未整理成开箱即用的安装包，使用前需自行检查脚本路径与服务控制。
GitHub 新仓库 kurtvalcorza/kandinsky-generation-pipeline 提供面向 Kandinsky 2.2 文生图（1.25B 参数 UNet，支持 512×512 与 1024×1024）的 DIMER 流水线。权重固定在不可变的 Hugging Face revision，全部为 safetensors，并附带留出集 denoising loss、CLIP 评分评估、60 张 CC0 iNaturalist 鸟类照片样本数据，以及带 safetensors 适配器的有界 LoRA 微调（rank 8，1,646,592 参数）。上游解码器与 prior 采用 Apache-2.0 许可，CLIP 评分为 MIT。
WattNot 是一个在 Meta Global AI Developer Hackathon（2026 年 10 月 26 日至 11 月 4 日）期间开发的智能体，通过尝试 batching、KV-cache、FP8、GPU 功率上限等调整来降低每次 LLM 推理请求的能耗与成本，且仅在质量与 p99 延迟保持时保留改动。它基于 vLLM 服务 Meta 开源权重的 Llama 3.1 8B Instruct，并为每个请求生成可复验的能耗与费用凭证，项目以 MIT 许可开源。
Embedl 团队发布 Qwen3.8-27B 在 Jetson Thor 上的 INT4 部署方案，batch 1 下解码 39.6 tok/s、端到端 23.6 tok/s、峰值显存 24.8 GiB。方案采用自研量化（误差约为标准 AWQ 的一半）、FlashHead 加速 262k 词表输出层、MTP 投机解码，底层为 TensorRT Edge-LLM 0.10.1；准确率与 FP16 对照为 GSM8K 96.4 对 96.1、IFEval 83.5 对 81.9、MMLU-Pro 79.1 对 79.5，并称快于 Jetson AI Lab 报告的 llama.cpp Q4_K_M + MTP 约 35 tok/s。
推荐理由：作者给出与 FP16 逐项对照的准确率和实测吞吐，并说明量化与投机解码的具体做法，便于复现比较。
GoLeM 在 GitHub 发布，这是一个让 MoE 大模型专家权重保持休眠在磁盘、使用时才逐级调入内存和 VRAM 的推理服务器，保证每个被选中专家的矩阵乘法都在 GPU 上执行。目标模型为 GLM-5.3-Flash，DeepSeek-V4.1-Flash 为实验性支持；在 RX 7900 XTX（24 GiB）+ 93 GiB DDR5 + 4TB NVMe 上，UD-Q4_K_XL 量化 262144 上下文冷/热 prefill 11.1s/13.4s，生成 2.42/2.12 token/s。
推荐理由：原文给出了 MoE 专家按需从 SSD 流式调入 VRAM 的完整实现与实测数据，读者可按硬件配置评估自己的本地部署可行性。
Praecise 在 GitHub 发布 praecise-engine，一个位于应用与推理后端之间的加速层，通过推测解码、硬件感知调优和统一服务接口加速 token 生成，首个支持的后端是 llama.cpp。实测显示 n-gram 自推测在结构化文本上带来 1.5 到 3.5 倍提升（SQL 3.5x），对散文无收益；托管后端（vLLM、SGLang、TensorRT-LLM、transformers）因掌握解码循环而无法被插入推测解码。项目还包含 praecise-host 沙箱化多引擎托管、job 引擎、视频感知管线等组件，整体采用 Apache-2.0 许可。
推荐理由：原文给出实测数据说明推测解码在结构化文本上值1.5到3.5倍、在散文上无收益，并解释了托管后端为什么在结构上无法做推测解码。
一位 Reddit r/LocalLLaMA 用户询问本地组装最低预算方案，以 Q4 量化运行约 500B 参数模型并达到约 20T/s 速度。其现有配置为 2 张 3090 提供 48GB VRAM 加 48GB DDR4 内存，但主板最多支持 128GB 内存，正在考虑是否改用 EPYC 平台。
Unsloth 发布 MiniMax-M3.1-Flash 的量化 GGUF，2-bit 版在体积缩小 45% 的同时保留 91.5% top 1 精度，可在 150GB 内存上本地运行。1-bit 版约 89.9%，4-bit UD-Q4_K_XL 达 98.0%；作者称其为同尺寸最强开源模型之一，并提供 Hugging Face 权重链接与本地运行指南。
推荐理由：给出了各量化档位的具体精度数字和内存门槛，读者可直接对照自己的硬件条件选择合适的版本。
/u/abarth23 发布了一个免费、无广告、客户端本地运行的网页版 LLM 显存计算器，主打把 KV cache 纳入估算。该工具支持 FP16、8-bit、4-bit/EXL2/GGUF 权重计算，按目标上下文长度与缓存精度（FP16 或 FP8/Q4 cache）动态估算 KV cache，加上约 1-1.5 GB 的 CUDA 运行时与系统开销，并推荐如单张 4090 24GB、双 3090 或卸载到系统内存的方案。作者称在线计算器普遍只按参数量乘量化精度，32k-128k 上下文的 KV cache 额外占 6-14 GB 显存。
推荐理由：针对常见显存计算器只算权重忽略 KV cache 的痛点，按上下文长度和缓存精度补全估算并给出 GPU 配置建议。
GitHub 开源 mobile-llm-engine，一款 iOS 优先的本地大模型推理引擎，内置基于 Qwen3 继续训练的 0.6B 中文助手模型（Q5_K_M 量化、551MB），专注日历等工具调用任务，数据不出设备。实测 40 题工具调用中 tool_call 发射率和 schema 校验通过率均为 100%，但日期参数正确率 0/15，幻觉问题修复中。目前仅支持 Apple Silicon Mac，运行内存约 1GB，可开放试用。
BigMoeOnEdge 是一个开源引擎，通过从闪存流式读取专家权重，让超过设备内存的 MoE 模型在本地运行，基于 llama.cpp 公共 API，支持 Android、iOS、macOS、Windows 和 Linux，并内置 OpenAI 兼容服务器。--auto 规划器会测量机器的内存、存储速度和各计算单元后自动设置缓存与常驻权重；实测包括 12 GB 手机上跑 91 GB 的 DeepSeek V4 Flash 284B（0.94 tok/s）、Qwen3.6-35B-A3B 达 4.8-5.0 tok/s，16 GB Apple silicon 笔记本上 Qwen3.6-35B-A3B 达 18-24 tok/s。
推荐理由：仓库给出了各设备的实测解码速度表和与全内存加载输出一致性的测试说明，便于判断流式加载 MoE 的实际可用程度。
Reddit r/LocalLLaMA 用户 boro64 发布 Ternary Nemotron 30B-A3B 的 GGUF 量化模型，这是一款 1.58-bit 三值 30B-A3B MoE 模型，可在 12 GB GPU 上运行 368K 上下文。实测解码速度 172 tok/s、prefill 超 7000 tok/s，同一文件兼容原版 llama.cpp（b11555+、b11796 验证）和 PrismML fork / Bonsai（b10793 验证）。作者称这是继 maple-preview 后第二个支持原版 llama.cpp 的三值 MoE 模型，并征集 CPU-only 和约 10 GB 小显存的测试数据。
sysofwan 在 GitHub 发布 HifzGuide 仓库，为 iOS 实时古兰经跟读校验应用 Muraja 提供数据与工具，采用 AGPL v3.0 许可。预构建资源以 GitHub Releases 分发，包含 6 段 Wav2Vec2-BERT CoreML 模型（6-bit 调色板量化，约 443 MB）、604 个 QCF2 页面字体、约 48 MB 的 quran.db 等。工具链含基于 Muaalem 音素头的 LoRA 微调与 Tadabur 质量过滤流水线，训练环境为 Linux + CUDA，CoreML 导出在 macOS/Apple Silicon 完成。
一位用户在 N1X 128GB（88GB VRAM）Windows on Arm 设备上，通过 WSL3/Ubuntu-26.04 调优 Qwen3.8-Flash-Next-W4A16-AutoRound-hybrid 模型并取得满意结果。虽然生成速度（tk/s）不算最快，但面向智能体的并发表现好于预期。
开发者推出 ThousandML 平台，用自研免校准量化 CQ 4-bit 做 QLoRA 微调以降低 GPU 成本。在 Qwen3.8-27B 的 Alpaca 微调对比中（单张 NVIDIA A40 48 GB，LoRA r=32、500 步），CQ 最终验证损失 1.0315 优于 Unsloth NF4 的 1.2484，且峰值显存略低，但每步耗时 27.60 s 远慢于 NF4 的 3.20 s，速度仍在优化中。已发布 thousandml/Qwen3.8-27B-CQ-4bit 等多个 CQ 4-bit 底座模型及复现脚本。
作者开源 llm-inference，一个面向可测量的 LLM 服务栈，包含从零实现的 continuous batching 引擎、OpenAI 兼容服务器、开环负载生成器和自动生成报告的实验集。在 T4 上对 Qwen/Qwen2.5-0.5B-Instruct 实测，continuous-32 达 6 req/s SLO 容量，为 vLLM（12 req/s）的 50%，静态 KV 槽位加 CUDA graphs 后升至 10 req/s 达 vLLM 下界 83%；附逐 token 正确性测试、精度（fp16/int8/nf4）对比与复现脚本，仓库 MIT 协议。
推荐理由：作者自建推理服务栈并与 vLLM 同卡对比，给出 SLO、CUDA graphs 和前缀缓存的消融数据，可复现。
一位 Reddit r/LocalLLaMA 用户用 8x T4 服务器部署 Qwen 3.5-9B Q5_K_XL，实现 87k 上下文、44 个 slot、单用户 35-40 tps，现想用 QLoRA 微调约 500 GB 的图像、扫描件、PDF、Word/Excel 数据。他持有 Mi50、V620、3060 等多块显卡但多台主板存在启动兼容问题，纠结于 3060 组合还是单价约 700 美元的单卡 R9700，并询问 unsloth 是否支持 Intel GPU。
作者在 RTX 4090 24 GB + 48 GB RAM 的 Windows 机器上对 Strata 0.1.43 运行 Qwen3.8-Flash-Next IQ3_S 量化包做了系统性网格调参，附完整 JSON 配置。三个关键参数 --adapt-async 1、--kv-resident 20480、STRATA_ADAPT_LAG=2 合计把 160k 上下文下的解码速度提升 45%；同时给出负面结果，--expert-cache 按 MiB 而非槽位设置（填满显存时 −72%）、--ple-io ram 在 48 GB 下 −90%、--no-prefill-borrow −46%。
推荐理由：作者用自建 A/B 测量流程在 RTX 4090 上逐项测了 Strata 各参数的真实增益与坑位，附完整可用配置。
用户在 Epyc 7402P、256GB DDR4 ECC 3200 八通道内存平台上测试了四张 R9700 运行 Strata 和 DeepSeek Flash-V4.1-1017 IQ2_XS，发现受 R9700 内存带宽偏慢影响 prefill 环节最耗时，且系统内存占用偏低。Radiance 曾将 Flash Next 在 R9700 上的 prefill 和 tok/s 性能提升 3-4x，Niko 表示该优化将很快进入 Strata。
/u/nathannguyennng 解锁了 RTX 3080 20GB 的 reBAR 与 P2P，/u/No-Refrigerator-1672 在双卡张量并行下用 vllm 0.32.0 实测验证。8k 到 261900 token 长度的 prompt 预填充速度较原厂提升 71%-115%，其中 P2P 相对仅 gpu_unlock 另有最多约 70% 提升；开启 MTP 后 decode 速度基本在噪声范围内无明显变化。作者提示 3080 用户在长 prompt 场景（含 agentic coding）可关注该解锁，且需双卡均有完整 PCIe 连接才能获得同等收益。
推荐理由：作者实测了 reBAR 与 P2P 解锁在双 RTX 308 20GB 张量并行下的 TTFT 与 ITL 数据，可看清该解锁对长上下文预填充的实际收益边界。
meshapplied 发布开源工具 Goethe，可将带 NVIDIA GPU 的 Linux 机器变成自托管 API，兼容 OpenAI、Anthropic 和 LiteLLM 客户端，数据留在自有硬件上。模型基于 SGLang 运行，支持 continuous batching、prefix caching 和 CUDA graphs，并内置面向 Blackwell、Hopper、Ada 和 Ampere 的 NVFP4 内核，4-bit 模型显存占用约为全精度四分之一；支持按客户端发 key、限速与撤销，模型重启后自动恢复加载，仓库采用 Apache-2.0 许可，链接 https://github.com/meshapplied/goethe。
推荐理由：原文给出了从安装到共享 API 的完整命令流程，并说明基于 SGLang 加自研 NVFP4 内核的推理方案，便于自建 GPU 推理服务时参考。
understudy-lm 项目发布了仅从目标 LLM 的文本输出训练的推测解码草稿模型，无需 logits、隐藏状态或更小的同族模型，草稿一次猜测 4 个 token，由目标模型一步验证，输出不变。发布的草稿针对 Qwen3.5-4B 训练，实测每步接受 1.58 个 token，投影加速 1.43x；在 llama.cpp 下因需逐 token 起草并恢复状态反而更慢（27 到 36 tok/s 对 69 tok/s），需支持 lookahead heads 的运行时才能兑现。
推荐理由：只靠目标模型的文本训练推测解码草稿模型，不用 logits 和隐藏状态，并给出接受的实测与局限说明。
hurui200320 在 GitHub 公开的 llm-ops 仓库用于管理 NAS 上的本地 LLM 部署，模型按模型族与变体目录存放 GGUF 文件和 sha256 校验文件。维护脚本以公共容器镜像 ghcr.io/hurui200320/llm-ops-toolbox:latest 发布，内置 check_updates、verify_checksums 和 download_hf 命令。另有 fetch-templates.sh 脚本可单独同步聊天模板，避免为更新模板重新下载 30GB 模型；访问 gated 仓库需设置 HF_TOKEN。
一位 LocalLLaMA 用户在 r/LocalLLaMA 询问 KV cache 量化的实际影响：其通过 strata 运行 qwen flash next 3.8 iq3xxs，KV cache 用 q8、262k 上下文，想扩到 300-400k 但显存不够，担心 q4 cache 质量下降。评论区多推荐 8k4v 方案，发帖人表示将尝试，否则维持 q8。
guregodevo 发布 janis，一个用 Go 编写的开源权重模型本地推理模块，定位为 MLX 版 Ollama：Apple Silicon 上跑 MLX 后端，其他平台用纯 Go CPU 后端。janis serve 提供 OpenAI 兼容端点（http://127.0.0.1:8090/v1），支持流式 chat completions、tool calls、运行时切换已加载模型，权重从 huggingface.co/mlx-community 拉取，支持 Qwen3、Qwen3.5、Gemma 系列，另含 whisper、bge、reranker 和约束解码等组件。它也是终端编码 agent Memdoor 的底层模块。
推荐理由：作者用单个 Go 模块把 MLX 推理和 OpenAI 兼容服务封装到一起，说明了本地部署的工程取舍与用法。
/u/Inside-Pen-8395 在 24GB M5 MacBook Air 上以 Splash 1.4.0 的约 800 行 fork 运行 Qwen3.8-Flash-Next Q2 量化，24,576 个专家槽位中约 6,800 个驻留 ~8.8 GB 内存，其余从 SSD 按需流式读取，支持 256K 上下文，解码平均 48.8 t/s（stock 为 28.8）。
推荐理由：作者实测了 Qwen3.8-Flash-Next 在 24GB 内存下的 SSD 专家流式方案，给出解码速度、预填充和 LiveCodeBench 对照数据。
anujj 向 ggml-org/llama.cpp 提交 PR #29948，在 MMQ 中以交错 gate/up 行的方式融合 FFN gate/up matmuls 与 GLU。
Swedish Embedded AB 开源 brain，用单个 Rust 程序在现有硬件上下载、运行、微调、量化模型，并通过 OpenAI 兼容 API 提供服务，无需 Python、PyTorch 或独立推理运行时。支持 Qwen3、GLM、YOLOv8、FLUX.2 Klein、Qwen3-TTS 等文本、视觉、语音和世界模型，内置 wgpu、vulkan、cuda、cpu 四个后端，可跑在 NVIDIA/AMD/Intel GPU、CPU、Intel NPU 和浏览器中；每个导入模型与参考实现逐步对比测试，训练用有限差分数值校验，后端间做一致性检查，许可证为 Apache-2.0。
推荐理由：一个 Rust 程序覆盖下载、推理、微调、量化和 OpenAI 兼容服务，不依赖 Python 或 PyTorch，并给出后端一致性等自检测试。
GitHub 项目 gb100test 在 NVIDIA GB10 / Blackwell GPU 上整合三类服务：通过 vLLM OpenAI 兼容 API 运行 Gemma 4 26B NVFP4、Llama 3.1（默认 8B Instruct NVFP4，上下文 64K）和 Qwen3.5-9B；用 Diffusers 提供支持 SDXL 与 FLUX.2-dev GGUF 的图像生成服务。项目还包含深度 QA 压测、图像生成性能测试及覆盖 10+ 类别的 100 个违禁主题安全边界测试脚本。
Ternair 是一个纯 Python/PyTorch 的三值权重推理实现，pip install 即可加载 microsoft/bitnet-b1.58-2B-4T 并启动 OpenAI 兼容 HTTP 服务，无需 C++ 构建。2B-4T 模型文件从约 5 GB 压缩到 1.1 GB（packed 存储 1.6 bits/value），CI 验证与 HuggingFace 参考实现输出一致性 Pearson 0.9958、top-1 一致率 85.7%；缺点是 CPU 推理速度约为 FP16 基线的 0.09×，WikiText-2 上 PPL 反而低于 FP16 基线（13.30 vs 23.37）。
juanqui 发布 Decidra，一个专为 26.1B 混合决策模型 vllm-sr/d3-turbo 打造的 CUDA 推理引擎，HTTP 服务与 CUDA 引擎在单个 Rust 进程内，运行路径无 Python、PyTorch 或 vLLM。状态编码一次后所有问题从缓存分叉，64 问基准比 vLLM-SR 快 2.4–5.2 倍，c8 下最高 5.2 倍吞吐；支持 RTX 4090、H100/H200、RTX PRO 6000，W4A8 视觉包需 24 GB 显存，MIT OR Apache-2.0 双许可，代码在 https://github.com/juanqui/decidra。
推荐理由：原文给出了与 vLLM-SR 同硬件同检查点的完整对比矩阵和校验方法，读者可以按自己的 GPU 档位查找对应延迟与吞吐数据。
GitHub 项目 phase 发布，可在本机直接测量本地 LLM 推理的每 token 能耗，分别报告 SoC 芯片功耗与 sys 整板 DC 输入，并扣除空闲基线，三平台后端均无需 sudo。首组数据在 Apple M5 Pro 24 GB 上测得：decode 每 token 能耗是 prefill 的 20 到 35 倍，仅计芯片封装会低估真实成本 2 倍以上。项目附 18 篇研究笔记，涵盖量化格式能耗、投机解码、批处理与长上下文等发现，Apache-2.0 许可，原始 JSON 在 results/ 目录。
推荐理由：工具把 prefill 与 decode 能耗分开实测，并给出芯片级与整板级两组数据，解释了为什么各家边缘模型能耗数字对不上。
/u/MaxDev0 将 sybil-solutions 的 GLM-5.3 低内存卸载方案移植到更轻量的 Qwen3.8-Flash-Next（125B），通过 NVMe SSD 直接卸载，在 16GB 显存加 8GB 系统内存的 RTX 4090 上实现约 20 tok/s 解码。8k 短上下文为 28–33 tok/s（散文）、19–22 tok/s（代码），prefill 约 1,080 tok/s；262k 满窗口下 20.0 tok/s 解码、约 1,627 tok/s prefill；RTX 3080 Laptop（16GB 显存、32GB 内存）100k 上下文约 18–21 tok/s，峰值显存 15.5GB。现有方案（如 Strata）需把 24k 专家全部驻留约 48–64GB 内存。
推荐理由：作者把 GLM 的高效 NVMe 卸载方案移植到 Qwen3.8-Flash-Next，给出多档显存和上下文下的实测速度数据，可复现。
GitHub 开源项目 emoji-studio 探索用后训练生成新 emoji 概念，已完成 SDXL LoRA 试点训练和 72 组盲评，确定选用 step 25 checkpoint。单张 40 GB A100 负载测试中 18 个生成任务全部成功，吞吐 6.73 images/minute，p95 延迟 35.93 秒，总支出约 $1.49。两个模型都能渲染连贯物体但难以生成双手交互，机械物体如自行车仍是已知弱点，项目尚未训练交互 adapter。
GitHub 仓库 zazuss/jetson-orin-tuning 公布了在 Jetson Orin（Nano 8GB、Super、NX、AGX）上做 LLM 推理的实测调优结论，所有数字来自 7.3 GiB Orin Nano 的真实测量。
推荐理由：全部数据来自作者在 7.3 GiB Orin Nano 上的实测，给出了瓶颈诊断表和量化格式、词表、KV 缓存的具体调优结论。
GeulPU 是一个在本地 GPU 上运行 GGUF 模型的推理引擎，通过书面精度契约保证同一请求在任意批量、slot、prompt 缓存和投机解码下输出逐位一致，exact 模式下 NVIDIA 与 AMD GPU 结果也一致。它自带调试器，可录制 agent 会话、逐位重放、从任意 token 分支并按请求对比不同量化版本；默认设置下速度多数场景快于 llama.cpp，投机解码在代码编辑任务上快 3.5-4 倍且输出逐位相同。引擎以韩语关键字编程语言 글(geul) 编写，下载约 1.5 MB，仅依赖显卡驱动，支持 Qwen3.6-35B-A3B、Qwen3.5、Qwen2.5、DeepSeek-R1-Distill、Llama 3 和 Mistral，提供 OpenAI 兼容 API，MIT 许可开源。
推荐理由：同一个请求在批量、缓存、投机解码甚至不同 GPU 上都得到逐位相同的结果，这个确定性契约让本地模型可以像程序一样调试和对比。
NeonMC23 的 forgeCORE 是一个基于 llama.cpp/ggml 的轻量 Rust 抽象层，自身不含计算逻辑，负责打开 ggml backend、管理 tensor 与计算图、通过 libllama 加载 .gguf 模型，并运行 Model → Context → Batch → decode → Logits → sample 的最小 CPU 推理路径。它暴露 tokenizer、KV/state 原语（state snapshot、position shift、KV cache dtype）、GPU offload 选项（默认 CPU，无 GPU 时显式报错），并内置冻结的标量 oracle 用于交叉验证；目前 CPU 推理路径已通过验证。
一个在 Apple Silicon 上全离线运行的 Streamlit 应用，用 IBM Granite Speech 5.0 TurboCTC（470M，encoder-only）做英语语音转写，配 Silero VAD v6 生成分段时间戳。可选开启 Granite 4.2 3B（8-bit）本地分析，生成摘要和按"是"概率排序的 yes/no 问题。30 分钟音频完整分析在 M2 Pro 上约需 23 s，双模型加载峰值约 7.7 GB 内存，仅支持英语，输出为无标点小写文本。
一位 LocalLLaMA 网友晒出由 4x 5060ti 16GB、4x 3060 12GB 和 256GB DDR4 3200（4 通道）组成的推理平台，成本与 DGX Spark 相当。其规划是 5060 组 TP4 接 pipeline 到 3060 组，把不常用的专家卸载到内存，engram 放 NVMe SSD，询问此方案能否高速高精度跑大 MoE 模型，还是远逊于统一显存/内存架构。