# 本地模型部署

学习在电脑、手机和浏览器运行模型，适合重视离线可用与自主部署的用户。

- 所属：[部署与推理优化](<https://oplearnx.com/md/topics/deployment-inference.md>)
- 网站：[https://oplearnx.com/topics/local-model-deployment](<https://oplearnx.com/topics/local-model-deployment>)

## 推荐学习顺序

1. [观点：本地部署会在企业里爆发式增长](<https://oplearnx.com/resources/pk_9af2f0684c00>)（帖子 · 入门）：这是 r/LocalLLaMA 的一篇社区帖子，作者援引一条 X 帖子提出观点：企业希望保守自己的机密，而大型本地模型对多数任务已经足够好，企业所需要的只是一个即插即用的方案。评论区中一位自称从事企业 AI 部署的用户反驳称，目前这远非常态，也不认为一年内会改变：多数“科技”公司缺乏构建、维护和优化自托管部署所需的机器学习与 IT 能力，本地可用的模型并不适合普通员工使用，为各类硬件和用户需求优化环境也很麻烦，多数企业会依靠数据处理协议或企业级服务来保护机密。适合在企业中从事 AI 部署或选型、关注本地部署落地障碍的人阅读。
2. [把 Spark 带到欧洲：本地智能驱动下一代智能体](<https://oplearnx.com/resources/pk_98c9ddcc6ac1>)（博客 · 入门）：这是 NVIDIA 官方博客的一篇文章，汇总其在柏林 GTC 上公布的本地 AI 硬件与软件动态。文中提到面向 Windows PC 的 RTX Spark、面向 Linux 开发者的 DGX Spark 以及面向企业前沿负载的 DGX Station（Windows 版将于 12 月推出），并列出 DGX Spark 软件更新、NVIDIA Sync、开源机器人参考工作流、新模型支持与推理引擎加速等多项发布。
3. [model-cache-cleaner：用于查找并安全清理本地 AI 工具占用存储的 Claude skill](<https://oplearnx.com/resources/pk_0f49ea521c7c>)（项目 · 入门）：一个 GitHub 项目，README 将其描述为 Claude skill：查找本机本地 AI 工具占用的存储，展示找到的全部内容，并且只把用户挑选并确认的项目移入废纸篓。它覆盖 \~/.cache/lm-studio、\~/.cache/huggingface、\~/.ollama、\~/.omlx 等目录，支持 macOS 与 Linux，脚本要求 Python 3.8\+。项目作者在帖文中提到 macOS 常把 .cache 隐藏为系统文件，因此做了这个工具，并表示欢迎 issue 和 PR。
4. [介绍 Zest：模型服务器 \+ 智能体 \+ 友好的图形界面](<https://oplearnx.com/resources/pk_b4d215264dba>)（项目 · 入门）：r/LocalLLaMA 的社区帖子，作者介绍其用 Claude 辅助开发的 Zest：一个把 Lemonade 服务器（负责安装 llama.cpp 等后端）和 Pi 智能体打包在一起的图形界面，目标是让不想折腾命令行服务器和参数的人也能跑本地模型。帖子称只需下载 appimage、走完新手引导即可使用，内置 128k 上下文等默认设置，并提供在 10GB 至 26GB 显存上测试过的模型推荐；项目开源，作者也说明了选择 Lemonade 和 Pi 的理由。适合想向他人介绍本地模型、或关注本地推理易用化工具的人关注。
5. [关于 Qwen 3.5 4B 和 llamaparse 的问题](<https://oplearnx.com/resources/pk_824f762742a4>)（帖子 · 入门）：r/LocalLLaMA 上的一个求助帖，发帖者为附近实体店店主搭建一套包含员工出入记录、现金与发票、二维码扫描等功能的流程，主要顾虑是店主设备多为 16GB 内存、少数为 8GB，询问适合这类设备的本地模型，并考虑 Qwen 3.5 4B 用于简单的发票处理判断。发帖者原本想用云端解析工具 llamaparse 处理不同格式发票表格，也在询问其它本地替代方案。
6. [24GB 显存 \+ 48GB 内存能跑 qwen3.8-flash-next 吗？](<https://oplearnx.com/resources/pk_fafee04a81b6>)（帖子 · 入门）：r/LocalLLaMA 社区帖子。发帖者尝试运行一次失败，求问配置建议。评论中有人称在 12GB 显存 \+ 64GB 内存上能跑 IQ3\_XXS；有人给出可完全放在内存中的 GGUF 链接、ngram 表放 SSD；有人称 IQ3\_XXS 在 RTX 4090 \+ 48GB 内存上用 Strata 刚好装下、约 70t/s，但没有给其他程序留余量；还有人提到 32GB 显存 \+ 32GB 内存跑 swift IQ3\_xxs 效果不错、升级到 48GB 内存后跑 IQ3\_S，并建议用 Strata 自动检测机器并推荐量化版本。适合在消费级显存/内存条件下部署该模型、需要参考量化与放置方案的人阅读。
7. [140TB 存储与 640GB A100 GPU 服务器，该下载哪些模型](<https://oplearnx.com/resources/pk_c08558ae324b>)（帖子 · 入门）：r/LocalLLaMA 上的一篇求助帖。发帖者称在 Hugging Face 相关限制变化后想下载重要模型，已列出 GLM5.3 \(Flash\)\(abliterated\)、DS4 Flash 等，并询问在剩余存储空间下应保存哪些模型和量化版本，还表示想涉足图像和视频模型，同时征集其他人的使用情况。适合关注本地模型部署与硬件配置的读者。
8. [Muse Spark 开放版](<https://oplearnx.com/resources/pk_9e419d4c1175>)（博客 · 入门）：Meta AI 研究博客介绍新发布的开放权重模型 Muse Spark Open，称其总参数 816B、激活 42B，上下文窗口为 100 万 token，原生多模态，面向编程与智能体任务。文中还称它可通过两台搭载最新 MLX 框架的 Apple M5 Ultra Mac Studio 在本地桌面运行，并已在 Baseten、Fireworks AI、Groq、Modal、Nebius 等 API 平台上线。
9. [提示：llama.cpp CVE-2026-116096](<https://oplearnx.com/resources/pk_d62ef0d33cff>)（帖子 · 进阶）：这是 r/LocalLLaMA 的社区帖子，引用 NVD 条目说明 llama.cpp 中 Pocket-TTS 组件 pockettts-gen.cpp 的 list\_pockettts\_state\_slots 函数在操纵 mmproj 参数时存在越界写问题，攻击需本地访问，且声称漏洞利用已公开，建议升级到 b11796 版本并给出补丁提交。发帖人补充说，在当前 master 与最新发布 b11871 上，恶意 mmproj 会触发 release 生效的 GGML\_ASSERT 而中止，已不再是静默的堆越界写，但推荐的根本性修复 PR \#29360 仍未合并。适合部署和运行 llama.cpp、关心其安全公告与版本升级的人阅读。
10. [1000 英镑预算下，本地大模型整机的主流配置是什么？](<https://oplearnx.com/resources/pk_160b09001159>)（帖子 · 进阶）：r/LocalLLaMA 的社区帖子，作者询问含主机在内的 1000 英镑预算下本地大模型机器的常见配置，表示不太在意新硬件特性和能耗，只看重算力和智能水平。评论区中一位回复者分享了自己的方案及欧盟价格：两张 3060 12GB 约 400–500 欧元、64GB DDR4 内存 200–300 欧元、Ryzen 3600 60 欧元、AM4 主板 100 欧元、机箱与电源 100 欧元、若干 SATA 固态约 100 欧元，合计约 960–1160 欧元，多为二手件，显存加内存共 88GB，并建议直接上 5700x–5800x；同时指出升级到 128GB 因 32GB 内存条稀少而昂贵、预填充速度约 700 tps 等局限。适合预算有限、准备自行组装本地推理机器的人阅读。
11. [只有 8GB 显存和 32GB 内存？你也能以最高 900 t/s PP 和 30 t/s TG 运行 Qwen 3.8 Flash Next](<https://oplearnx.com/resources/pk_6570ddde3abb>)（帖子 · 进阶）：这是一篇经验分享帖，作者在 RTX 5060 笔记本 GPU（8GB 显存）、Ryzen 9 8945HX、32GB DDR5、1TB SSD 的 Linux 机器上，用 Strata 运行 Qwen 3.8 Flash Next Q2 量化版。作者称其基准与实测结果优于自己测过的 Qwen 3.6 35B A3B 微调版和 Qwen 3.8 27B，速度也快于现有 Qwen 3.6 35B A3B 配置，并说明 Strata 可将负载分布到显存、内存和 SSD。帖子提供了系统配置、Chat 与 Agentic 两套 Strata 配置文件链接及运行指引。适合显存有限、想自行部署本地模型的人阅读。
12. [8 GB 显卡、262K 上下文、3.5 BPW 的 Qwen-Flash-Next Coder，用 llama.cpp 达到 70 T/s](<https://oplearnx.com/resources/pk_4fcc8532917f>)（帖子 · 进阶）：r/LocalLLaMA 的一篇社区帖子。作者介绍其做法：Qwen-Flash-Next 有 n-gram 和 MOE，激活参数为 6B，因此把大部分 MOE 放在内存、最小的 MOE 放进显存以提速、n-gram 放在最快的 SSD 上；配置为 8 GB 显存加 24 GB 内存，约 32 GB 总内存也能运行但需降低上下文长度，并需按硬件调整启动参数。帖子补充说明 CUDA 在 8 GB 显存下可能跑不起来，建议改用 Vulkan 后端，同时减小上下文并关闭浏览器硬件加速等占用显存的程序。作者还说明所用模型是 ISTA DASLab 的 3.5 BPW “Coder”变体、采用 GSQ RCO 量化，移除了一半专家，折算为原模型参数量的 1.89 比特有效速率，但没有任何单个权重以 1.89 比特存储。适合用 llama.cpp 在低显存消费级硬件上部署量化 MoE 模型的人阅读。
13. [Lean-QwenFlash：通过直读 NVMe SSD 卸载，在 16GB 显存和 8GB 内存上以约 20 tok/s 运行 Qwen3.8-Flash-Next（125B）](<https://oplearnx.com/resources/pk_bd507e3a9480>)（帖子 · 进阶）：r/LocalLLaMA 社区帖子，作者介绍自己基于 sybil-solutions 的 glm-flash-lite 卸载思路改编出的 lean-qwenflash，让 125B 的 Qwen3.8-Flash-Next 在低内存机器上运行，而不是像 Strata 等方案那样把 24k 专家全部固定在系统内存中。帖中给出 RTX 4090（16GB 显存、8GB 系统内存）与 RTX 3080 笔记本（16GB 显存、32GB 内存）在 8k 至 262k 上下文的解码与预填充速度，并附 GitHub 仓库地址，包含安装说明、模型下载器与打包脚本。适合在低显存/低内存设备上尝试本地运行大模型的人关注。
14. [本地运行 Qwen3.8 FN 的建议](<https://oplearnx.com/resources/pk_c075b9564510>)（帖子 · 进阶）：r/LocalLLaMA 的社区帖子，作者列出可用硬件：两张 24GB 的 3090（已解锁）、一张 16GB 的 4070 Ti Super（已解锁）、18 核 CPU、130GB DDR4 内存和 1TB NVMe。帖子记录其运行 Qwen3.8FN 的速度：仅用 4070 Ti 加 NVMe 约 8–9 T/s，仅从 NVMe 运行约 2 T/s，三张 GPU 加内存一起跑约 18 T/s，并询问在不买新硬件的前提下如何提高速度。适合用多卡消费级显卡跑本地大模型、关注推理速度调优的人阅读。
15. [如何在 Strata 中为低量化版本的 Qwen 3.8 Flash Next 使用 Q8 ngram 并避开报错](<https://oplearnx.com/resources/pk_9fa4b077e8b2>)（帖子 · 进阶）：r/LocalLLaMA 社区帖子，介绍在 Strata 中通过 --ple-gguf 参数或 Docker 环境的 STRATA\_SET 变量旁加载更高精度的 Q8 ngram，以在声称不增加显存与内存占用、不牺牲预填充/解码速度的情况下提升输出质量；作者说明直接使用 Hugging Face 上的原始 ngram gguf 会报架构不匹配错误，需要把 general.architecture 键改为 strata-ple（可下载已修改好的 gguf，或用 gguf-editor-gui 修改），并声明自己尚未验证模型是否真的更聪明、速度与资源影响也未做充分测试。适合在本地用 Strata 跑量化模型、折腾 GGUF 元数据与 ngram 加速的人阅读。
16. [单块 3090 跑 27B：10 万 token 处仍达 110\+ TPS，上下文可达 400k](<https://oplearnx.com/resources/pk_c4a667659b2d>)（帖子 · 进阶）：这是一篇 Reddit r/LocalLLaMA 社区帖子，介绍 LlamAmpere v0.6 版本发布内容：TPS 提升约 13%（100–105K token 区间平均 112 TPS）、提示处理提升约 20%（前 10 万 token 平均预填充从约 1080 提升到约 1300 TPS）、推出新的 Ampere Integer\+ 文件格式并与 XS、EXL3 作 KLD 与速度对比，以及借助 SJKVaRN 在约 23.5GB 占用下实现超过 400K 总上下文。适合在单块 3090 上运行本地推理、关注量化格式与长上下文性能的人阅读。
17. [RTX PRO 4000 Blackwell SFF：Qwen3.8 27B 生成速度提升 67%，Qwen3.6 35B A3B 呈现不同扩展规律](<https://oplearnx.com/resources/pk_527c2a9b0c00>)（帖子 · 进阶）：这是 Reddit r/LocalLLaMA 上的一则本地推理实验记录。作者在单张 RTX PRO 4000 Blackwell SFF（24GB GDDR7、出厂 70W、无辅助供电接口）上，通过加载修改后的 VBIOS 将功耗上限提高到 120W，并测试显存与核心偏移，未刷写 EEPROM 或焊接。共 158 次基准请求，测试 Qwen3.8 27B（DFlash2）与 Qwen3.6 35B A3B：27B 在 120W 并调校后生成速度从 35.04 tok/s 升至 58.53 tok/s（\+67%），而 35B A3B 在 106W 至 120W 之间几乎持平；显存偏移对两者影响不同，prefill 变化很小。适合关注本地推理性能调优的读者。
18. [能否把 TabbyAPI 配置得像 Strata 那样跑 Qwen 3.8 Flash Next 的 exl3 量化？](<https://oplearnx.com/resources/pk_cea70cebe9bf>)（帖子 · 进阶）：r/LocalLLaMA 社区帖子，发帖人听说 exl3 量化比 Unsloth 的 UD 量化更精确，并给出 Hugging Face 上 Qwen3.8-Flash-Next exl3 版本的链接。他提到 TabbyAPI 和 Exllamav3 已支持 MoE 的 CPU 专家卸载，自己用 UD Q4 能跑到 70\+ t/s，但按 q4 加卸载配置 TabbyAPI 只得到 20 t/s，询问是否只是配置问题、速度能否接近 Strata。补充说明中引用了 TabbyAPI 的 cpu\_moe\_split\_experts 选项（把每层 MoE 的部分路由专家放到 CPU、按冷热动态放置）正是他达到 20 t/s 时用的设置，并猜测 Strata 可能用了别的 gguf 优化。适合在本地部署量化 MoE 模型、折腾 TabbyAPI/Exllama 配置与推理速度的人阅读。
19. [真的有人在 1–3 bpw 以下使用 deepseekv4.1f 吗？](<https://oplearnx.com/resources/pk_2e291539cafe>)（帖子 · 进阶）：r/LocalLLaMA 社区帖子，发帖人看到很多关于在低价硬件上以低 bpw 运行 deepseekv4.1 1017 且速度尚可的帖子，想做一次实际使用情况的核实：除了当作新奇玩意，是否真有人在低比特量化下用它做事。他回顾此前用 v4-0731 的 Q2 经验，认为相比完整的 Q8 差距明显，而那个 Q8 本身已等于约 90% 的 QAT 后 Q4，再降两个 bpw 后表现不佳。他征询使用 1–3 bpw v4.1-1017 的人分享体验，最好与 3.8FN 更高量化版本作对比。适合在有限硬件上运行低比特量化大模型、比较不同量化方案实际可用性的人阅读。
20. [好得不像真的？ISTA 的 GSQ-RCO 2-bit DeepSeek-V4.1-Flash 得分与基座模型相同](<https://oplearnx.com/resources/pk_aa8c32b89f0e>)（帖子 · 进阶）：r/LocalLLaMA 的一篇社区帖子。作者询问是否有人试过 ISTA 为 DeepSeek-V4.1-Flash 发布的 GSQ-RCO GGUF 量化模型，以及实际质量是否与榜单成绩相符（IQ2\_XXS 与基座持平）。作者指出其基准已饱和（90% 以上，AIME25 各版本均为 100），可能无法体现性能退化，也找不到 GSQ-RCO 模型的 KLD 数据，因此询问是否有人测过 KLD 或 PPL，以及在约 2 bpw 下预期的 KLD 是多少，并附上 Hugging Face 模型页链接。适合在本地部署低比特量化大模型、关注量化后质量评估的人阅读。
21. [在 4 块 R9700 上对比 Qwen 3.8 27B 与 Nanbeige 4.3 33B：我的工作负载下的实际 TPS 与每小时任务数](<https://oplearnx.com/resources/pk_c5b1d5a17f51>)（帖子 · 进阶）：这是 r/LocalLLaMA 的一篇社区帖子，作者此前发布过用 127 美元二手 EPYC 搭建 4 卡 R9700 机器的方案，本次在同一套硬件上对比 Qwen 3.8 27B 与 Nanbeige 4.3 33B。他以自己公司维护枪械相关商家信息（营业时间、价格、设施等）的实际工作为负载，让两套配置各跑同样的 2,484 个案例，以审计员身份输出接受、拒绝或弃权，并统计吞吐、每日经核实的正确任务数、准确率，以及 1/4/8 路并发下的 token 速度。帖子还提到 Qwen 在思考模式下审计自身结果的表现优于 Nanbeige，并在结尾向做编程或创意写作测试的人征询情况。适合关注本地多卡推理部署、按实际业务任务而非纯跑分评估模型的人阅读。
22. [VecSzn/PolyStrata](<https://oplearnx.com/resources/pk_1a6b745d5cbe>)（项目 · 进阶）：一个在个人电脑上本地运行大模型的方案，其中 Qwen3.8-Flash-Next 运行在 Strata 引擎上，另有一套为 PolyStrata 编写的第二引擎支持 GLM 5.3 Flash、DeepSeek V4 Flash、LFM2.5、Qwen3.6、Ornith 1.5、Gemma 4、Tiel Coder 和 MiniCPM-V 等模型。提供 Windows 和 Linux 一键安装，并在 localhost 暴露 OpenAI/Anthropic 兼容 API。
23. [StartLuxLabs/StartLux-Decision](<https://oplearnx.com/resources/pk_f7e1a4f4dfeb>)（项目 · 进阶）：这是一个开源决策模型系列的项目仓库，模型规模从 0.8B 到 27B，一次推理即为每个选项给出校准概率，仅在不确定时输出简短思考。项目提供面向 vLLM、llama.cpp 和 MLX 的推理引擎，并提供 Hugging Face 模型页、arXiv 技术报告、API 文档与博客链接。
24. [在喜马拉雅山麓用离线 AI 智能体写代码](<https://oplearnx.com/resources/pk_254b25a91927>)（博客 · 进阶）：这是一篇作者自述文章，作者是 Thomson Reuters 的首席工程师，一年前搬到喜马拉雅山麓居住，因网络和供电经常中断，尝试在笔记本上完全离线运行编码智能体。文章探讨了在断网条件下对本地已有项目可以做哪些工作，例如解释陌生函数、排查失败的测试、重构小段代码或协助完成功能。
25. [使用本地编码智能体](<https://oplearnx.com/resources/pk_8a0618eb8ec0>)（博客 · 进阶）：Sebastian Raschka 的短笔记，链接到一篇关于用开放权重模型搭建本地编码智能体的新文章。文章内容为完全本地运行，介绍如何将本地 LLM 接入本地编码 harness（如 Claude Code 或 Codex），并列出选择模型时可用的评估清单：长上下文下的内存占用、prefill 与解码 tok/s 速度、工具调用能力、对智能体框架的安全审计，以及在编码 harness 中解决较难任务的能力。
26. [本地胜过云端：Qwen 3.8 FN](<https://oplearnx.com/resources/pk_71e1c97819ed>)（帖子 · 进阶）：这是一篇社区案例帖，作者描述在高校硕士论文模块中用本地模型 Qwen 3.8 flash next（运行在 opencode 中，vllm 后端，Docker 沙箱、输入只读、工作区可写）处理学生、导师、课题、评审与成绩的匹配事务和多种格式 CSV 数据导入，因为学生姓名邮箱与早期研究项目信息不便上传云端。帖子称本地模型以接近前沿云端模型的水平完成了该任务。适合关心数据隐私场景下本地模型落地应用的人阅读。
27. [用本地 LLM 做关卡设计时，你用什么方法来保证几何形状的遵循度？](<https://oplearnx.com/resources/pk_10536a3a649e>)（帖子 · 进阶）：一篇 r/LocalLLaMA 社区帖子，作者在用本地模型（Q3.8-FN-NVFP4，基于 Ninfer-v3 的分支）辅助设计 Halo Infinite Forge 地图，并征询如何保证模型输出在几何上符合关卡设计。帖子介绍了背景：Forge 只能通过节点图脚本、无法输入代码，地图保存为 MVAR 文件，反作弊机制阻止直接推送修改后的文件，因此开发需在游戏内手动完成；作者用 harness 建立专门的项目文件夹让代理参与制作。适合关注本地 LLM 在游戏关卡设计与代理工具链中应用的人阅读。
28. [我为语音转文字应用微调了一个 LLM，用来清理转写文本](<https://oplearnx.com/resources/pk_3f547b3941fb>)（帖子 · 进阶）：一篇 r/LocalLLaMA 社区帖子，作者为自己开发的语音转文字应用 WhisperNow 微调本地 LLM 做文本清理，去除口头填充词、误起头、自我纠正并格式化列表。帖子介绍了 66,557 行的数据集（合并公开数据与合成听写内容），说明训练中发现的薄弱点及补充样本的做法，并给出 LFM2.5 1.2B/2.6B、Qwen3.5 4B 三个全量微调模型在 GPU 与 CPU 上的耗时对比，以及与若干云端 API 的延迟对照。适合在做本地语音输入或文本后处理模型微调的人阅读。
29. [我对自托管 AI 智能体做了一次盲测，结果如下，猜猜谁是谁 \[D\]](<https://oplearnx.com/resources/pk_9e7f82eae7d9>)（帖子 · 进阶）：这是 r/MachineLearning 的社区帖子，作者在 M5 Max MacBook Pro（64GB）上，让五个自托管智能体（OpenCode、goose、Atomic Agent、Hermes、OpenClaw）使用同一个 Qwen 3.8 27B 非审查版 Q4\_K\_M 模型在 llama.cpp 中运行，执行合并联系人列表、跨文件重命名函数、修复带隐藏测试的 bug、统计日志错误数、把收据 PDF 转成表格五项任务，并给出各智能体的逐项通过情况与耗时。作者提到其中一个智能体把“Q3/Q4”写成“q3q4”，另有智能体未经询问就安装缺少的 Python 库，并邀请读者猜字母与智能体的对应关系。适合对自托管编码智能体的实际任务表现和自主性取舍感兴趣的人阅读。
30. [推出 Gemma 4 12B：统一的无编码器多模态模型](<https://oplearnx.com/resources/pk_349839732b57>)（博客 · 进阶）：Google DeepMind 发布 Gemma 4 12B，定位为可直接在笔记本电脑上运行智能体式多模态能力的模型，介于轻量 E4B 与 26B MoE 之间，内存占用更小，是其中等规模模型中首个支持原生音频输入的。文章称其采用无多模态编码器的统一架构，视觉和音频输入直接进入 LLM 主干，并提到 Gemma 4 系列累计下载量已超过 1.5 亿次。
31. [AnyLanguageModel 1.0：Apple 平台上本地模型的一年](<https://oplearnx.com/resources/pk_7decc164dc40>)（博客 · 进阶）：博客文章，回顾 AnyLanguageModel 发布一年后的 1.0 版本。它是 Apple Foundation Models 框架的兼容替代品，只需把 import FoundationModels 改为 import AnyLanguageModel，同一套会话代码即可用于系统模型、经 llama.cpp、MLX 和 Core ML 运行的开源权重模型，以及文中列出的托管服务商。文中还提到一年内新增的工具调用等功能，并同时发布 swift-huggingface 1.0 和 swift-xet 1.0。面向在 Apple 平台上开发应用的开发者。
32. [PyTorch 2.15 中的 MPS](<https://oplearnx.com/resources/pk_1de346a35051>)（博客 · 进阶）：Hugging Face PyTorch 团队撰写的博客文章，介绍 PyTorch 2.15 中 Apple MPS 后端的更新，包括 MPS 支持 FP8、语言模型解码在线性层与 softmax 上获得更快路径、以及针对音频、视频和训练工作负载中新 Metal 内核。文中说明该团队以 Hugging Face Hub 上的真实模型排查 MPS 不足并向上游修复，并提到 MoE 模型解码速度较 2.14 提升 5–6.5 倍。适合在 Mac 上运行或训练 PyTorch 模型的读者。
33. [面向 Qwen3.5-4B 的交互式神经元操控实验台，基于 WebGPU 在浏览器本地运行](<https://oplearnx.com/resources/pk_e0dbe0316bb3>)（项目 · 进阶）：这是一篇社区分享帖，作者受 X 上关于用极少量神经元（常为一两个）操控大模型行为的讨论启发，制作了一个交互式实验台，可在浏览器中通过 WebGPU 完全本地运行 Qwen3.5-4B，让用户自行尝试不同神经元组合对模型输出行为的影响，并给出 Hugging Face Space 链接。适合对模型内部机制、神经元级行为操控和浏览器端本地推理感兴趣的人阅读。
34. [用 LFM3-VL-2B 在浏览器内通过 WebGPU 本地实现实时视频描述](<https://oplearnx.com/resources/pk_31dd535ddfe1>)（帖子 · 进阶）：r/LocalLLaMA 社区帖子，分享了 LFM3-VL-2B 的 Hugging Face 模型集合与一个在浏览器里通过 WebGPU 本地运行的演示 Space，用于实时视频描述；评论区讨论把它用作 LLM 的近实时视觉输入（每 1–2 秒一次，或作为快速视觉调用后按需调用更强的视觉模型），也有评论提到同为 2B 规模的 LFM3 Omni 模型支持实时并可直接输入音频。适合在浏览器端本地部署小模型、做实时视觉/语音多模态应用的人阅读。
35. [构建带端侧记忆的 AI 助手](<https://oplearnx.com/resources/pk_7e436a231c55>)（课程 · 进阶）：DeepLearning.AI 平台上的课程页面。课程指出依赖云端记忆的 AI 应用需要联网并把数据发往远程服务器，而本课程教授端侧替代方案：学习者构建把文本、语音和图像等经历以向量形式存储、按语义检索的记忆系统，并让助手能从少量照片中识别新物体而无需重新训练模型。课程标注为中级，时长 1 小时 4 分钟，含 8 个视频课、5 个代码示例和 1 个评分作业，讲师为 Dylan Couzon，页面显示更新日期为 2026 年 10 月 15 日。适合想学习本地向量检索与离线多模态助手实现的开发者。
36. [统一边缘 AI：Coral NPU 的开放标准如何把可移植、能耗可行的智能从模型带到芯片](<https://oplearnx.com/resources/pk_e4d0d8fab1c0>)（博客 · 进阶）：Google Developers Blog 文章。介绍 Google Research 通过引入 Matrix Execution Unit 完成了 32 位开源 Coral NPU RISC-V 架构，边缘推理性能最高 1 TOPS、目标平均功耗 10 mW；同时发布 v1.0 开源 IREE/MLIR 编译器，使开发者可将 JAX、PyTorch、TensorFlow 模型直接部署到 Coral NPU 硬件而无需编写自定义汇编。文中还提到可借助 Synaptics Astra SR200 MCU 系列和 Coralboard 开发套件来原型验证和部署多模态边缘应用。适合做边缘 AI 推理、编译器或嵌入式硬件开发的开发者阅读。
37. [kanaworksai-hue/audio-studio-mcp](<https://oplearnx.com/resources/pk_4c9a6bfa5ce3>)（项目 · 进阶）：为 Claude Code 及任意 MCP 客户端提供本地 AI 背景音乐与音效生成的 MCP 服务器，基于 Stable Audio 3，在 Apple Silicon 上使用 MLX、在 Windows NVIDIA GPU 上使用 PyTorch，无需云端服务和 API Key。适合需要本地音频生成（如游戏音频）的开发者使用。
38. [PaperPilot：零云端、纯 Rust 的 PDF 引擎，支持 WASM 与 MCP](<https://oplearnx.com/resources/pk_4d33da73acc7>)（项目 · 进阶）：一个本地文档 AI 助手项目，用纯 Rust 编写 PDF/文档工具，宣称文件不离开用户机器。同一引擎可用于 MCP 服务器（供代码智能体合并、拆分、OCR、压缩 PDF）、命令行、浏览器 WASM 版、Tauri \+ Svelte 桌面应用以及本地 REST API，采用 Apache 2.0 许可。
39. [漫画翻译工具——一起看懂日语吧！](<https://oplearnx.com/resources/pk_49d0292fc8d0>)（项目 · 进阶）：这是 r/LocalLLaMA 的一篇社区帖子，作者介绍自己开发的开源桌面应用 Manga Translator Tool，用于在本地阅读和翻译日文漫画，灵感来自看字幕版动画时保留原文并附译文的做法。工具整合了漫画阅读器、OCR、译文覆盖层和可就当前页提问的本地 LLM：OCR 用 Qwen3.5 的日语 OCR 微调版本，翻译与对话用 Gemma 4 E2B 的某个变体，推理基于 llama.cpp 并支持 CPU 与 GPU。功能方面提到在不擦除原文字的前提下在文本框内显示译文、把译文存为图片元数据以在原文与译文视图间切换、搜索提取出的文本，以及能识别日文拟声词等；帖中还包含安装过程的演示视频。适合想在本地离线阅读并翻译日文漫画、或用小模型串联 OCR 与翻译流程的人阅读。
40. [Show HN：为 macOS 上每张照片和每帧视频提供 AI 搜索](<https://oplearnx.com/resources/pk_28550c4d64f0>)（项目 · 进阶）：这是一个 macOS 应用的 GitHub 仓库，项目名为 SCM（Screen Memories），定位为多模态视觉记忆智能体。它使用在 Mac 本地运行的视觉模型，支持用自然语言检索照片、截图、视频和音频，并可对视频按场景切分定位到具体镜头，同时提供 OCR 文字搜索和基于 Whisper 的语音台词搜索。项目还说明支持监视文件夹自动导入、内容哈希去重和后台重新嵌入，媒体文件不上传，保持本地离线运行。
41. [JunWan666/astrbot-for-android](<https://oplearnx.com/resources/pk_f7eaa7d0c6a4>)（项目 · 进阶）：这是一个 Android 应用项目，用于在手机上本地部署和管理 AstrBot 与 NapCat，内置 PRoot Ubuntu 运行环境，无需 Root。据仓库说明，它提供原生管理界面、WebUI、日志、备份恢复和独立更新，采用 Kotlin 与 Jetpack Compose 开发，项目标签涵盖 QQ 机器人、OneBot、LLM 等，要求 Android 8.0 及以上。
42. [jackwener/DeepseekHarness-Android](<https://oplearnx.com/resources/pk_4113df1cdf64>)（项目 · 进阶）：这是一个安卓应用项目，可免 ROOT、免 Termux 通过单个 APK 在手机上运行 DeepSeek Harness：引擎内嵌于 App 进程，能读屏操作 App、修改系统设置、执行定时或条件自动化，可选安装 Shizuku。使用需登录 DeepSeek 账号或填 API key，也可在设置中添加其他模型服务商，支持 arm64 与 Android 10 及以上。适合想在安卓手机上布置手机端 AI 代理、做自动化操作的人阅读。
43. [cobanov/PS5LM](<https://oplearnx.com/resources/pk_44c95c1b4f8d>)（项目 · 进阶）：该项目把 llama.cpp 移植到已越狱的 PlayStation 5 上，允许主机原生运行 GGUF 格式模型，从 Qwen 3.8 开始。README 说明它借助主机 GPU 推理，提供 OpenAI 与 Anthropic 兼容 API 和适配电视的界面，可在无 PC、无云端、无账号的情况下为局域网内设备提供模型服务，另新增了 Ollaya 的决策模型支持。适合拥有越狱 PS5、想在家搭私有模型服务的读者。
44. [在 Mac 上用本地 AI 模型构建应用](<https://oplearnx.com/resources/pk_45a90a5a5230>)（书籍 · 进阶）：这是 Manning Publications 出版的书，作者 Keiji Kamigusa，出版日期 2026-09-28，296 页，ISBN 9781633433700，主题词为 AI。简介称其以在任意近期 Mac（从基础款 Mac mini 到 Mac Studio）上构建语音聊天机器人为逐步实践项目，串联音频采集、语音转写与语言模型推理三项本地技术，涵盖 Homebrew 配置、下载本地大模型等内容，主题是本地运行 AI 带来的隐私与免订阅优势。适合想在 Mac 上做本地 AI 应用开发的读者阅读。
45. [调优后的 Strata 配置：2000 PP、平均 tg 95–105](<https://oplearnx.com/resources/pk_4e58d877f7b3>)（帖子 · 深入）：一篇 r/LocalLLaMA 社区帖子，作者在 RTX 4090 \+ 48 GB 内存、Ryzen 3900X、Windows、200k 上下文的环境下运行 IQ3\_S Qwen3.8-Flash-Next，对 Strata 0.43 的大量参数做了近似网格搜索。帖子称 decode 从 97 tok/s 提升到 142 tok/s（\+45%），列出最有效的几个参数（--adapt-async 1、--kv-resident 20480、STRATA\_ADAPT\_LAG=2）和最差的几个（--expert-cache 单位是 MiB、--ple-io ram、--no-prefill-borrow），并指出 Windows 无法用 cuda 固定内存。适合在单卡上折腾 Strata 推理引擎参数调优的人阅读。
46. [我用 Qwen 3.8FN IQ3\_S 测试了 Strata 的路由优化在编程、数学和指令遵循上的表现](<https://oplearnx.com/resources/pk_5f93984a7ed6>)（帖子 · 深入）：这是 r/LocalLLaMA 的一篇社区帖子，作者在自有机器的 Qwen 3.8 Flash Next IQ3\_S 上测试 Strata 0.2.7.1 版本的两项路由优化。STRATA\_ROUTE\_PRIOR 会给已缓存于显存的专家加 1.5 的分数加成（约 4.48 倍有效系数），使分数接近时可用缓存中的专家替换原本会选中的专家；STRATA\_ROUTE\_TAIL\_SKIP=7（默认值）则在某些专家不在显存时跳过第 7 至第 10 个专家的计算，从而丢弃次要专家的贡献。帖子给出关闭两项、仅尾跳、仅路由优先、两者同开四种配置在 IFEvalCode、AIME 2026、IFEval 上的解码速度与得分表格，并说明第二轮用更大思考预算重跑了首轮答案不同的题目。适合在本地运行 MoE 模型、关心显存受限下路由与专家缓存取舍的人阅读。
47. [Qwen3.8-Flash-Next：Swift 1.5 与 Unsloth 在 Strix Halo 上的对比（Halogen、gufo、llama.cpp、UD-Q4\_K\_XL 与 IQ4\_XS）](<https://oplearnx.com/resources/pk_7c11004bf865>)（帖子 · 深入）：这是 r/LocalLLaMA 的社区帖子，作者在 Asus ROG Flow Z13（128 GB、70 W）上对比 UkisAI 的 Qwen3.8-Flash-Next 微调版 Swift 1.5 与自己原有方案，涉及 Halogen、gufo、llama.cpp 三种引擎和多种量化格式，均启用 MTP。帖中记录了服务启动时间、32k prompt 下的 TTFT、预填充与解码速度、MTP 接受率、KLD，以及数学、LCB 和 11 项 Pi 代码任务的得分、耗时与 token 消耗，并说明结果仅来自单次运行。适合关注本地大模型推理性能、量化方案与编码智能体实测的人阅读。
48. [MacBook Pro M5 Max 上运行 Nanbeige4.3-33B Q4：mlx-lm、llama.cpp 与 Kapitsa 的对比，512 到 32K 上下文范围](<https://oplearnx.com/resources/pk_4415e9065f31>)（帖子 · 深入）：这是一篇社区基准测试帖，在 MacBook Pro M5 Max（128GB）上对 Nanbeige4.3-33B 4-bit 量化模型比较 mlx-lm、llama.cpp 与 Kapitsa 三个引擎的 prefill、decode、首 token 时间、后续延迟和显存占用，覆盖 512 至 32K 提示长度；作者自述是 Kapitsa 引擎的开发者，并公开了原始输出与脚本。帖中称该模型速度慢、KV 缓存占用高（128K 上下文约 26GB），编码能力尚可。适合在 Apple 芯片上做本地推理性能对比的人阅读。
49. [两天调优单块 Tesla P40：35B MoE、完整 262k 上下文，短上下文约 60 t/s、深至 100k 时约 30 t/s，且不使用低于 Q4 的量化](<https://oplearnx.com/resources/pk_b80eaba8c303>)（帖子 · 深入）：这是一篇 Reddit r/LocalLLaMA 社区帖子，作者记录在单块 24GB Tesla P40（PCIe x1、Windows、自改 llama.cpp）上运行 Ornith 1.5 35B-A3B 模型、保持 Q4\_0 权重与 q8\_0 KV 的调优过程。文中列出带来提升的做法（关闭 ECC、KV 用 q8\_0 而非 q4\_0、检查 MTP 头是否训练、为 flash-attention 的 KQ 部分使用 int8 dp4a、限制 MTP 预填充窗口）以及未奏效的尝试（f16 KV、核内反量化 V、官方 Q4\_K\_M），并给出 llama-bench 测试数据。适合在本机用单卡或旧款显卡跑大模型推理、关注量化与 llama.cpp 调优的人阅读。
50. [mw00/project-maya](<https://oplearnx.com/resources/pk_99adf6f25898>)（项目 · 深入）：Project Maya 是用于在自有 GPU 上私有运行 GLM-5.3-Flash（321B MoE）和 DeepSeek-V4.1-Flash-1017（748B MoE）的项目，支持单卡至 16 卡、NVIDIA 与 AMD、Linux 与 Windows（实验性）。包含推理引擎、服务器、仪表盘、OpenAI 与 Anthropic 兼容 API 以及量化工具，可处理并发请求并支持图片。
51. [用 LiteRT Tensor API 在边缘端进行原生模型编写](<https://oplearnx.com/resources/pk_45e70d15d3a6>)（博客 · 深入）：Google 开发者博客 2026 年 10 月 19 日的文章，作者为 Ping Yu、Quentin Khan、Chintan Parikh、Lu Wang。文章介绍 LiteRT Tensor API，让开发者以原生 C\+\+ 控制模型图，在异构边缘硬件上统一端到端机器学习计算；同时说明最常见的部署路径是把训练好的模型（如用 LiteRT Torch 转换 PyTorch 模型）交给 LiteRT 运行时执行，而在需要完全控制网络表示与优化、支持新架构或试验新的 lowering 逻辑时可采用原生编写方式，并提到 MLX 和 llama.cpp 的相关先例。适合关注端侧 AI 部署、延迟与内存预算受限场景的开发者阅读。
52. [用冻结模型的多 token 预测加速 Pixel 上的 Gemini Nano 模型](<https://oplearnx.com/resources/pk_faa9eb01549b>)（博客 · 深入）：Google 研究人员介绍一种把多 token 预测改造到已冻结的生产模型上的方法，用于加速端侧推理，规避单独草稿模型带来的低效。文章背景是手机端的能耗预算和内存限制，以及标准语言模型逐 token 自回归生成造成的瓶颈，目标是在不离设备的前提下更快实现通知摘要、文本校对等功能。
53. [自主边缘——嵌入工业应用中的智能](<https://oplearnx.com/resources/pk_cdf40c9311fb>)（书籍 · 深入）：这是一本由 Taylor & Francis 出版的开放获取图书，作者为 Vermesan, Ovidiu 与 Pijlman, Fetze，出版信息只给到 2026 年。书中汇集多学科研究者与实践者的文章，讨论人工智能、边缘计算、自主系统与工业应用交汇处的技术变化，包括智能从云端向车辆、机器人、制造系统、智慧城市与嵌入式设备迁移，以及在延迟、能耗、隐私、安全与实时性约束下的边缘 AI 设计，主题词涉及软件定义汽车与联邦学习。

---
中文标题与摘要由模型根据原文生成，以原文为准。
来源：LearnMap · 学径（https://oplearnx.com）
