跳到正文

方向

本地部署与推理 最新动态

把模型跑在自己机器上：量化、推理引擎、显存优化、微调与蒸馏，以及让更大的无对齐模型跑得起来的工程进展。

1,568 条精选近 30 天 1,558 条共收录 5,749 条

更新

精选归档 · 第 7 页

10月23日周五第 121–140 条
  2. Hugging Face · 新模型：uncensored59

    npario 发布 gemma-4-31B 的 UDmerge 去对齐 GGUF 量化版本

    npario 在 Hugging Face 发布 gemma-4-31B-it-qat-uncensored-heretic-UDmerge-GGUF，将 llmfan46 的 abliterated 张量合并到 Unsloth 无损 Q4_0 量化中，称可获得比朴素消融量化更好的准确率和拒绝率。提供两个变体，UDmerge-Q4_K_XL 将 attn_output.weight（blk.10 至 blk.35）量化为 Q4_0，UDmerge-Q4_K_XXL 量化为 Q8_0，后者拒绝率 20%，与 QAT BF16 持平，且基本不影响 TG 速度；实测 QAT Q4_0 拒绝率为 32%。

    推荐理由：作者用统一的 PPL、KLD、拒绝率和 MMLU 数据对比了合并版与朴素消融量化的差异，Q8_0 变体把拒绝率压回 20%。

  3. arXiv · cs.CL55

    论文追溯推理模型中 wait 标记的来源：继承自数据而非 RL 发明

    arXiv 论文 2610.30882 通过频率、位置、形式与用法等无标注指标及错误注入实验，追溯推理模型中 {wait} 标记的来源，发现 zero-RL 几乎不会创造该词，在缺乏该词的 base 上 RL 大幅提升 MATH-500 准确率而 {wait} 几乎不出现。该标记主要由训练数据引入，如 OLMo-3 的 mid-training 和基于推理轨迹的微调；base 已有该标记时，OLMo-3 与 MiMo 的 RL-Zero 配方会放大其使用，而无 KL 的 GRPO 不会。论文还指出标记频率本身不能指示 RL 引发的推理，并警示 LLM-as-a-judge 修订指标可能逆转人工标注趋势。

    推荐理由：论文用无标注指标和错误注入实验区分了 RL 与训练数据对 wait 标记的来源，方法可迁移到其他推理行为的溯源分析。

  4. GitHub · 去对齐工具与仓库64

    brazen 发布：统一各 LLM 提供商协议的 Rust 命令行适配器 bz

    brazen 仓库发布 bz 命令，一个无状态的 Rust 单二进制适配器，把 OpenAI chat/completions、OpenAI responses、Anthropic messages、Google generative-ai、Ollama 等协议归一化，管道输入请求、流式输出规范响应。支持 API key 与 OAuth/SSO（内置 openai-chatgpt 登录）、模型前缀路由、bz --serve 双协议反向代理、token 统计与 cache_key 提示缓存分支标识；通过 cargo install brazen 安装，也可下载预编译二进制。

    推荐理由：仓库以配置行而非代码分支接入新厂商，并给出跨五家协议的归一化事件流测试，值得做 Agent 底层适配时参考。

  5. Reddit · r/LocalLLaMA59

    Swift-1.5-Qwen3.8-27B 推出 hipfire MQ4 量化版，7900 XT 上端到端约 2.2 倍于 Q4_K_S GGUF

    Reddit 用户 /u/Queasy_Asparagus69 将 Swift-1.5 微调版 Qwen3.8-27B 量化为 hipfire 的 MQ4 格式并附带 MTP 头用于投机解码，目标是让 AMD 用户获得比 llama.cpp 更快的速度。在 RX 7900 XT 20GB、ROCm 7.1 环境下，Prefill 快约 1.4–1.85 倍，16K 上下文约 1100 tok/s（llama.cpp 约 700）；带 MTP 的真实 prompt 解码 36.5 tok/s（τ≈1.94），16–49K 上下文为 52–59 tok/s。六个约 10–20K token 的真实 Rust 编码任务全套耗时 237 秒，对 llama.cpp 的 530 秒，端到端快 2.24 倍。

    推荐理由：作者在同一块 7900 XT 上用真实 Rust 任务给出与 llama.cpp 的逐项速度对比，数据足够具体可复现。

  6. Hugging Face · 趋势模型65

    KRAFTON 发布 Raon-1 mini preview 开源模型，30B-A4B MoE 架构，Apache 2.0 开源

    KRAFTON 从零训练的 Raon-1 mini preview 发布，为 30B-A4B（28.8B 总参数、每 token 激活 4.3B）MoE 模型，采用 Raon Delta Attention 与 Raon-mHC 的混合注意力架构，原生支持 262,144 token 上下文，以 Apache 2.0 许可开源。主打韩语对话与 Agent 任务，支持 Hermes Agent、Pi 和 OpenCode 工具调用；官方基准显示其在 IFBench、Chatbot Korean 等项目领先对比 MoE 模型。

    推荐理由：模型卡给出了与其他 MoE 和稠密模型的基准对比、架构细节和完整本地部署方案，可据此评估其真实定位。

  7. GitHub · 灵魂体仓库56

    开源自托管 AI Agent 平台 Chatter 发布，集成 Telegram 与桌面端控制

    NikitaCherepov 在 GitHub 开源了多平台 AI Agent 系统 Chatter（AGPL v3.0），Agent 跑在服务器上，通过 Telegram bot 与 Electron 桌面端连接同一账号，可一键分享给朋友或家人。系统包含 backend-api、desktop-app、Telegram bot、admin-panel、chatter-manager、webapp-notes 和可选 voice-service，各组件以 Docker Compose 编排；模型定价自动从 OpenRouter 拉取，内置 Pinecone 向量记忆、语音唤醒与 TTS、智能家居、邮件、网页浏览、多角色聊天和 Runbook 等功能，支持按用户设预算限额。

    推荐理由：原文完整给出了组件结构、安装命令与安全机制细节，读者可以直接评估这套自托管 AI Agent 平台是否值得自建。

  8. GitHub · 灵魂体仓库59

    本地个人 AI Agent 桌面应用 Bloks 3 发布，支持 Mac、Windows、Linux 和 iPhone

    Bloks 3 正式发布，这是一款运行在本机的个人 AI Agent 桌面应用，以聊天界面呈现，每个 Agent 底层是 Claude Code、Codex、Gemini CLI 等真实引擎会话或你持有密钥的任意 API。3.0 新增多工作区、Bloks Team 成员协作、按引擎和 Agent 的用量统计与月度限额、卡片化回答、多 Agent 房间协作、审批与规则引擎、可读可撤销的 Markdown 记忆、例程与 Watcher 等能力；数据全部以明文文件存于本机，无后端存储，iPhone 应用仅作为桌面端的远程窗口，配套 Apple Watch 审批。应用免费，源码以 FSL-1.1-MIT 许可公开于 https://github.com/hamedgitty/bloks ，Android 版即将推出。

    推荐理由：原文完整给出了 Bloks 3 的工作区、权限、花费限额与数据落盘结构，读者可以据此评估这套本地 Agent 方案是否值得自部署。

  9. Reddit · r/LocalLLaMA62

    llama.cpp PR #29864 重构 Intel XMX 矩阵引擎，B70 投机解码速度大幅提升

    /u/nickm_27 实测 ggml-org/llama.cpp 的 PR #29864 重构 Intel XMX 矩阵引擎后，B70 在 SYCL 下投机解码速度大幅提升，测试模型为 Muse Glimmer Q6_K (30B) 搭配 DFlash2。9 项任务总耗时从 46.86 秒降至 26.68 秒，各任务 tok/s 普遍从约 36-53 提升到约 53-88；作者说明因 token 验证成本显著降低而调大了 n-max，接受率从 0.7845 降到 0.363 属预期现象。

    推荐理由：作者实测了 llama.cpp 重构 Intel XMX 矩阵引擎后 B70 的投机解码速度，前后总耗时从 46.86 秒降到 26.68 秒，数据完整可复现。

  10. Reddit · r/LocalLLaMA63

    HuggingFaceBio 发布 Carbon-X：基于 Qwen3-14B 微调的 14.8B DNA 语言模型

    HuggingFaceBio 发布 Carbon-X，一个 14.8B 参数的 decoder-only 模型，在 Qwen3-14B 基础上用 DNA 序列与自然语言联合训练，可在普通对话中直接分析原始 DNA 并用英文回答。混合 tokenizer 用 BPE 处理文本、以 6-mer 编码 DNA，无独立 DNA 编码器；五个 DNA 基准平均 66.7%（关闭思考），比 Qwen3-14B 高 27 分，接近 GPT-6.1 Sol 的 67.5% 而推理成本约其 1/1,800；估计分析 ClinVar 240 万个意义不确定变异约需 $300，而所测前沿模型需 $32,000 至 $400 万。

    推荐理由：原文给出五个 DNA 基准的平均分、与基线模型的差距和成本对比，可据此评估这个 DNA 微调模型的实际水平。

  11. Reddit · r/LocalLLaMA58

    MemT-1.0-Nano 在 ExLlamav3 上实现对话内持续记忆

    /u/Unstable_Llama 将三天前发布的 MemTensor MemT-1.0-Nano 移植到自己 fork 的 exllamav3（exl3-qlora）上，可原生配合 tabbyAPI 运行。模型能在对话中持续学习并通过 /commit 命令把重要事实写入记忆模块、清除上下文后仍能回答记忆相关问题；作者演示了该流程并附量化版本链接（https://huggingface.co/MemTensor/MemT-1.0-Nano）。

    推荐理由：作者在 exllamav3 fork 上实测了 MemT 的持续记忆能力，给出了 /commit 命令的实操流程和量化版本地址。

  12. Reddit · r/LocalLLaMA63

    4x Intel B65 实测：调大 vLLM prefill chunk 使 Qwen3.8-Flash-Next 预填与 TTFT 提速约 30%

    /u/SamSausages 在 4x Intel B65 上用 vLLM 0.30.0 实测 Qwen3.8-Flash-Next（W4A16），把 prefill chunk 从默认 1024 调到 8192/16384 后，32K prompt 预填达 5,142 tok/s，261K 首 token 时间从 190.2 s 降到 97.6 s。代价是 KV cache 池从 587,416 tokens 缩到 337,952，多会话下最长停顿从 0.61 s 增至 2.89 s，但作者称聊天和后台 agent 场景中停顿不明显。完整数据见 https://b65.thekaiser.us/by-model/qwen38-flash-next/prefill/

    推荐理由：作者用同一套基线实测了 vLLM 不同 prefill chunk 大小的速度、TTFT 和 KV cache 代价，数据可直接迁移到多卡 XPU 部署调参。

  13. GitHub · 去对齐工具与仓库56

    Rust 从零实现的 LLM 推理服务器 denno-beta 开源，兼容 Anthropic Messages API

    ahinore 开源了用 Rust 从零实现的 LLM 推理服务器 denno-beta，推理内核不依赖 candle 等现有库，兼容 Anthropic Messages API，可直接配合官方 Anthropic Python SDK 使用。支持 GPT-2 124M 与 Qwen2.5-0.5B–7B-Instruct、Qwen3-0.6B、Qwen3.5 等模型，默认 CPU 运行，可通过 --features cuda 卸载到手写 CUDA 内核（13,252-token prefill 从 395.8s 降到 12.2s）。

    推荐理由：推理内核完全从零手写并保持精确解码约束，附 CUDA 加速与可视化遥测，适合想从代码理解 LLM 推理全流程的读者。

  14. GitHub · 灵魂体仓库58

    mlxtop 3.1.1 发布：本地 LLM 性能监控工具

    mlxtop 发布 3.1.1 版，这是一款本地 LLM 监控工具，将内存压力、分页、GPU 状态与运行时的 tokens/s、prefill 进度、队列等指标并列显示，并用一行结论指出变慢原因如重分页或显存占满。支持 oMLX、vLLM、SGLang、llama.cpp、Ollama、LM Studio 等 13 种运行时的自动检测，本地只读运行、无需 sudo、不上传数据；3.1.1 新增可即时生效的 Settings 页和 mlx-serve prefill 进度，支持 macOS（Apple Silicon）、Linux 与 Windows，MIT 协议开源。

    推荐理由：本地 LLM 排障工具把内存、分页、GPU 与运行时自身指标并排呈现，还给出健康与否的一句话结论，适合排查本地推理变慢。

  15. GitHub · 灵魂体仓库64

    千问杯多模态大赛第3名方案开源：Qwen3.5-0.8B 蒸馏 SFT + GRPO 小剂量 RL 全流水线

    参赛队「广州智行科技」开源千问杯多模态推理大赛最终第3名（获2万元奖金）的完整方案：在 Qwen3.5-0.8B 上先蒸馏 Qwen3.6-27B 的 113K 样本做 SFT（初赛 41.8 分压线晋级），再用 GRPO 30 步小剂量 RL（决赛榜 20.2 分，第 9/20），答辩后终评第 3。仓库公开训练/导出脚本、真实日志与技术报告，权重托管于 Hugging Face；核心发现包括 RL 剂量轴在 30 步达峰、同权重 ZIP CRC 消融证明采样解码白送约 3 分、0.8B 模型 RL 池内学习量与平台分强反相关。

    推荐理由：作者用同权重 CRC 消融和剂量轴实验分离出每个增量的因果证据，0.8B 小模型 RL 剂量与遗忘的权衡刻画对类似场景可迁移。

  16. Reddit · r/LocalLLaMA60

    两台 £300 骁龙迷你主机实测：ToRc 引擎跑 Qwen3.6 35B A3B 达 315/43 tok/s

    作者用两台 £299.99 的 Lenovo IdeaCentre Mini（Snapdragon X X1-26-100，32GB LPDDR5，无 GPU）以 USB4 相连，实测 llama.cpp、Janas 和自研 ToRc 引擎跑量化模型的读写速度。统一测试负载下，ToRc 双机跑 Qwen3.6 35B A3B Q4_0 达 315/43.3 tok/s（读/写），编码对话 59.6 tok/s；95GB 的 Qwen3.8 Flash Next IQ4_NL 靠 NVMe 流式读取专家权重，双机达 46.2/20.3 tok/s。MTP 加速依赖文本类型，代码任务普遍提速而 Alice 散文上 llama.cpp 反而变慢。整套方案约 £600、负载功耗各约 35W，ToRc 引擎尚未发布。

    推荐理由：作者在两台 300 英镑的骁龙迷你主机上实测多款推理引擎跑 Qwen 大量化模型的读写速度，并给出统一测试负载和完整数据。

10月22日周四
  1. Hugging Face · 新模型：uncensored56

    AtomicChat 发布 Ling-3.0-flash-Sante 无对齐 GGUF 量化版

    AtomicChat 发布 inclusionAI/Ling-3.0-flash-Sante（127B bailingmoe3 医疗模型）的 abliterated GGUF 量化版，用投影 rank-1 LoRA 移除单一拒绝方向并烘焙进权重。在 W* 点实测：英文有害指令拒绝率 0.0%，俄语误拒率 3.0%（较基线降 1.2 pp），MMLU 基本不变，对基线 BF16 的 KL 为 0.060，工具调用 20/20 有效。注意开启思考模式时拒绝率仍约 40%，建议关闭思考模式使用；提供 IQ4_XS（约 78 GB）与 IQ3_S（约 61 GB）两种量化，MIT 许可。

    推荐理由：原文给出消融方法与拒绝率、MMLU、KL 等前后对照数据，还提示思考模式下拒绝率仍高，读者可据此判断实际效果。

  2. Hugging Face · 新模型：uncensored76

    candor-lab 发布 Qwen3.8-27B Candor Uncensored GGUF 去对齐权重

    candor-lab 在 Hugging Face 发布 Qwen3.8-27B 的去对齐版本 Qwen3.8-27B-Candor-Uncensored-GGUF，用其自研权重编辑工具 Candor 移除原版的拒答方向，以单一 Q4_K_M GGUF（16.81 GB）形式在 llama.cpp 上实测。方法是对 26-63 层注意力输出矩阵和 22-56 层 MLP 输出矩阵做 rank-3 修改（共 73 个矩阵），经 600 次搜索试验筛选。实测显示：288 个 StrongREJECT 有害提示下原版拒答 281 次，该模型仅 1 次（8B 判官口径）；300 个无害提示拒答 2 次、GSM8K 答对 1287 题，与原版差异不超噪声；KL 散度 0.038。

    推荐理由：原文给出了消融方法的层级改动细节和与原版、huihui-ai 版的拒绝率与 KL 散度对照数据，可据此评估这个去对齐版本的实际取舍。

  3. Reddit · r/LocalLLaMA69

    Kapitsa 0.2.7 实测 2021 款 M1 Pro 16GB 跑 Qwen3.5 与 Nemotron 编码速度

    Kapitsa 贡献者 Ye 发布 0.2.7 版本，针对老款 Apple Silicon 芯片优化，并在 2021 款 MacBook Pro 14（M1 Pro、16GB）上对六个模型做了与同机最快竞品引擎的基准对比。Qwen3.5 4B/9B 解码达 97.2/56.8 tok/s，分别为 mlx-serve 的 1.56×/1.52×；Qwen3.6 35B-A3B 2-bit 达 52.2 tok/s，解码 1.21-1.35× llama.cpp；六个模型峰值内存均低于对手，Dory 4B 为 4.4 vs 11.5 GB。Nemotron Dory 4B 长上下文解码被 mlx-lm 反超，作者已开 issue 跟进。

    推荐理由：作者给出六个模型在 16GB M1 Pro 上与最快竞品的逐项对比数据，含长上下文衰减和内存占用，可复现可查证。

  4. Reddit · r/LocalLLaMA70

    capy-flash v0.7.1 发布：Qwen3.8-Flash-Next 125B MoE 可在 64 GB 内存上运行

    开源推理引擎 capy-flash 发布 v0.7.1，让 Qwen3.8-Flash-Next（125B MoE）在 64 GB 内存加一或两张 16 GB GPU 上运行，双卡实测 234 tok/s；Qwen3.8-27B 3-bit 版可放进单张 16 GB 卡（174 tok/s，64k 上下文）。Flash-Next 的 routed experts 直接使用 ISTA-DASLab 的 GSQ-RCO 3-bit 量化（约 48 GiB 驻留内存，峰值约 57 GB），27B 的 3-bit 量化 MMLU-Pro 从 0.78 降至约 0.72，GSM8K 与 NVFP4 持平；代码与权重见 https://github.com/ValerioDolci/capy-flash。

    推荐理由：作者给出了具体显存占用和双卡实测速度，还附上 3-bit 量化与 NVFP4 的质量对比数据，方便判断取舍。