从「能跑」到「好用」，本地 AI 还差什么？

在个人电脑上跑大模型，早就不是什么新鲜事了。7B、14B、32B，只要硬件撑得住，都有人跑过。让我最近又认真看这件事的，不是「某个 27B 模型终于装进个人电脑了」，而是另一个变化——本地模型正在从「能跑起来」，往「能拿来干活」走。

最近我在自己 Mac 上跑了 Qwen3.8-27B，速度和能力都挺出乎我意料。但这里得先把一件事说清楚：27B 对今天大多数个人电脑来说，依然不算轻。你得有足够大的统一内存或显存，内存带宽得够，还要折腾量化、推理框架、上下文长度，甚至要不要上 MTP、DFlash 2 这类推理加速。

说白了，今天的变化不是「电脑突然变成了数据中心」，而是模型、硬件、推理框架、整个本地 AI 的软件栈，几样东西在同时往前挪。这才是我觉得本地 AI 真正值得看的地方。

Scaling Law 之外的另一条路线

过去几年，大模型基本沿着 Scaling Law 在走：更多数据、更大模型、更多算力，换更强的能力。从 GPT、Gemini、Claude 到 Qwen、DeepSeek，云端模型的天花板还在往上顶，两三年前觉得遥远的能力，现在已经成了日常工具。Scaling Law 没有失效，云端模型以后大概率还会更大更强。

但另一面也越来越明显：GPU 集群、数据中心、电力、散热、网络，加上每一次调用的 Token 成本，都在跟着涨。云端 AI 不可能无限制地把所有计算都揽过去。

所以我最近一直在看另一条路：能不能用更小的模型，去做过去需要更大模型才能做的事。

前阵子，清华大学和 OpenBMB 提出过一个概念，叫 Densing Law，密度法则。它不关心模型能做多大，只关心单位参数里装了多少能力，指标叫 Capability Density，能力密度。他们分析了一批开源模型，结论是：2023 到 2025 这三年，大模型的最大能力密度大概每 3.5 个月翻一倍。

如果这条曲线继续走，达到同样能力需要的参数量就会越来越小。今天要几十 B 才做好的事，未来十几 B、甚至几 B 也许就够了。

这句话听着像预言，其实我手边就有一个现成的例子。上期写本地数字人的时候，那套系统——语音识别、对话、声音、形象、记忆、实时打断——加起来，大脑只是一个 4B 模型，再配两个 0.6B 的小模型，一个做语音识别、一个做语音合成。总参数不到 6B，就撑起了一个能实时对话、能被打断、有记忆、有形象的陪伴。上一期里我实测过，4B 从说完到开口只要 100 毫秒出头，生成速度 160 token/s。

放在两三年前，实时语音对话基本是云端专属，更别说再挂一个数字人和一套记忆。现在它能整个跑在一台 MacBook 里。这不是因为某一个模型突然变聪明了，而是能力密度这条曲线在起作用：同样的事，需要的参数量一直在缩。

它和摩尔定律有点像，但推的不是同一件事：摩尔定律推的是硬件密度，密度法则说的是模型能力密度。两件事叠在一起——终端和边缘设备的算力一直在涨，模型本身又在越做越「小而强」——过去只能待在数据中心里的那部分 AI，自然就开始往用户身边挪。

我最近跑 Qwen3.8-27B 的一些感受

我不拿 Qwen3.8-27B 来证明「大模型终于能本地跑了」，这事早就发生了。让我觉得有意思的是，这个模型出来没多久，社区就冒出一堆针对不同硬件、不同需求的优化版本。

雪瑜在 X 上整理过几个，我照抄在这里：

• mlx-community/Qwen3.8-27B-4bit + incoai/Qwen3.8-27B-DFlash2：Apple Silicon 的 MLX 路线，他自己测下来，加 DFlash 2 之后 TPS 大概翻倍；
• Qwen3.8-27B-MTPLX-Optimized-Speed：原生 MTP，模型约 20.4GB，在速度、质量和内存之间取平衡；
• Qwen3.8-27B-MTPLX-Optimized-Quality：8bit 为主，峰值内存约 32.7GB，偏质量；
• Qwen3.8-27B-GGUF 的若干版本：主要解决 llama.cpp、MTP、多模态和跨平台兼容。

那个「TPS 翻倍」是作者在自己设备上的结果，不能当成所有硬件都会有的提升。但这个例子本身很有代表性——大家讨论的重点已经变了。以前是「这模型能不能跑」，现在问的是：Mac 上用 MLX 还是 GGUF？4bit 还是 8bit？内存够不够？要质量还是要速度？用原生 MTP 还是外挂 DFlash 2？上下文开多大？怎么接到 OpenCode、Agent 或者自己的服务里？

这已经是另一个阶段了：模型只是底座，部署、量化、推理、加速和应用生态的分量越来越重。

当然这不等于门槛没了，恰恰相反。27B 这种 Dense 模型，4bit 量化后的权重就要十几到二十 GB，再算上 KV Cache、上下文、计算 Buffer、视觉模块，还有推测解码要的 Draft Model，实际内存会更高。所以一台 16GB 的普通笔记本，和一台 64GB、128GB 统一内存的 Apple Silicon，体验完全是两回事。本地 AI 在变好用，但离「随便一台电脑都能跑 27B」，还有距离。

模型之外，还有很多东西

以前看本地模型，大家只问两件事：多少 B？吃多少内存？

真正做产品以后我才发现，光看参数量远远不够。同一个 27B，换硬件、换推理框架、换量化，体验能差出一大截。Apple Silicon 有 MLX、Core ML、Metal，Intel 有 OpenVINO，NVIDIA 有 CUDA 和 TensorRT-LLM，此外还有 llama.cpp、ONNX Runtime、vLLM、SGLang 这些路线；量化有 4bit、5bit、8bit；再往下是算子融合、Attention 优化、KV Cache 管理、内存布局，还有针对 CPU、GPU、NPU 的分别优化。

这些东西不决定模型能不能启动，决定的是用户愿不愿意一直用。首 Token 等多久？每秒出多少 Token？上下文拉长以后速度掉多少？内存会不会突然爆？机器上同时开着别的软件，AI 还能不能保持流畅？这些问题，比宣传页上一个「XX TOPS」实在得多。

所以本地 AI 做产品，是个系统工程：

模型 × 推理框架 × 算子 × 硬件

哪一层没对上，最终体验都会打折扣。

本地一定更快吗？

很多人讲端侧 AI，把低延迟抬得很高。这话对，但只说了一半。

本地确实省掉了数据上传、网络传输、服务器排队、结果返回这些时间，网络延迟和抖动少很多。可这不代表本地推理一定更快。云端可能是整个 GPU 集群，本地可能就是一台几十 TOPS 的 PC。模型一大，或者框架和硬件没调好，很可能网络省下来的时间，被本地更慢的推理吃回去了，总时间反而更长。

所以我现在更愿意把本地 AI 这个优势，说成「延迟更可控」。实时语音、设备控制、本地搜索、摄像头分析这些场景，稳定、可预测的延迟，常常比峰值速度更值钱。

再说成本

云端模型基本按量收费：输入多少 Token、输出多少 Token，背后 GPU 都在干活，所以必然有持续成本，用得越多越贵。

本地是另一套账。硬件买断之后，模型部署在设备里，多跑一次不会多出一笔 API 费。电费、折旧当然还在，严格说边际成本不是零，但对个人和很多中小企业，已经低到可以忽略。

这会直接改掉很多 AI 产品的成本模型。知识库、语音助手、图片理解、本地检索，这些每天要调很多次的服务，全走云端的话，长期 Token 成本很可观。如果高频、简单的任务都在本地解决，只把真正复杂的丢给云端，整个系统的成本会完全不一样。所以我一直觉得，本地 AI 一个很实在的价值，不是把云替掉，是给云分流。

隐私这件事也没那么简单

这是我最近一直在想的一块。

很多人一提隐私，就说敏感数据不能上云，所以必须用本地模型。逻辑没错，但现实还有个问题：本地模型的能力现在还有上限，复杂推理、专业知识、长上下文这些，云端最强模型仍然明显更强。

所以产品设计里经常卡在一个平衡上：只追最强能力，就得让更多数据上云；数据全留本地，又得牺牲一部分能力。

我最近看到两个比较典型的做法，一个法律领域、一个医疗领域。都不是简单的「全本地」或「全上云」，而是让本地模型先把敏感信息处理掉——姓名、身份证号、电话、地址、病例号，在本地识别、脱敏，再把脱敏后的数据发给云端大模型做复杂分析。云端返回后，本地模型把必要的真实数据回填，最后交给用户审核。流程很直观：

原始数据 → 本地脱敏 → 云端推理 → 本地回填 → 用户审核

这种架构挺有代表性。端侧 AI 不一定要跟云端对着干，它完全可以做云端前面那一层本地处理。真正要解决的不是「数据能不能上云」，而是哪些数据能上云、以什么形式上云。医疗、法律、金融、企业知识库这些高敏感场景里，这种端云协同会越来越常见。

DFlash 2 和推理加速

以前一说端侧性能，就两件事：换更快的芯片，或者把模型做小。但最近 DFlash、DFlash 2 这类工作让我看到第三条路：不改硬件也不改模型，直接改推理方式。

传统 LLM 生成文字是串行的：先生成第一个 Token，再第二个、第三个，一个接一个。Speculative Decoding（推测解码）的思路，是让一个小 Draft Model 先猜后面的 Token，主模型再验证。猜得准，一次就能收下多个 Token，主模型完整推理的次数就少了。DFlash 往前走了一步，用 Block Diffusion 让 Draft Model 一次并行预测一整块候选 Token；DFlash 2 接着优化候选路径选择和块内预测。针对 Qwen3.8-27B，现在已经有专门的 DFlash 2 Draft Model，也出了 GGUF 版本，能和 llama.cpp 一起用。

有意思的不是某个 Benchmark 快了多少，而是它说明本地 AI 的性能提升，至少会从三条线同时来：硬件更强、模型更高效、推理方法更聪明。而且这三件事还会互相牵扯——比如 DFlash 2 自己也要吃内存，某些机器上速度快了，能留给上下文的内存反而少了。所以本地推理越来越像一个工程权衡，不是把某个数字拉到最大就完事。

Agent Harness 这一层

除了推理性能，还有个变化我觉得一样重要。

最近一年 Agent 很火，但我关注的不是某一个 Agent 产品，是它背后的 Harness Engineering。我现在更愿意把模型看成「大脑」，Harness 是外面那套真正让它持续完成任务的东西：工具调用、文件系统、搜索、记忆、上下文管理、权限控制、任务拆分、失败重试、结果验证，都在这一层。

Hermes Agent、Pi 这类框架越来越明确地在走这个方向：模型可以换，但外面的 Tools、Skills、Memory、Context、Agent Loop 留着。

这对本地模型尤其关键。本地模型受硬件限制，不可能永远用最强的模型。但只要外面套一套设计得不错的 Harness——不会的可以搜，要实时信息的可以调工具，复杂任务可以拆步，失败可以重试，结果还能复查——一个中等模型最后完成任务的能力，可能比它单次推理高出一大截。

所以以后评价一个本地 AI，光问「你用的什么模型」不够了，还得看它外面挂着什么。

本地和云端其实不是二选一

聊到这，我的态度也就清楚了：这轮本地 AI 的机会，不在「端侧模型马上超过云端模型」。这个问题本身就太简单。

更可能是一个分层架构。最靠用户的端侧，做实时交互、设备感知、简单推理、隐私数据处理；往上，边缘设备扛本地知识库、文件理解、多模态搜索、长期记忆、企业私有数据，还能跑更大的本地模型；云端继续干最复杂的推理、超大模型、多模型协作，和吃大规模算力的活。

Agent 和 Harness 把这几个层串起来。一个任务进来，系统要判断它在哪一层跑合适：本地能不能做，要不要上更大的模型，哪些数据不能出本地，哪些脱敏后可以上云，最后调哪个模型、哪个工具、哪个 Agent。

再往后，可能不只是「端 + 云」，而是「端 + 边 + 云 + 多模型 + 多 Agent」。AI 会越来越像一整套计算系统，而不是一个模型。

我理解的「拐点」

如果现在让我重新总结，本地 AI 的拐点，恐怕不是某一天突然蹦出一个「够小又够强」的模型，而是很多因素一起越过可用线。

能力密度在涨，芯片算力和内存带宽在涨，MLX、OpenVINO、llama.cpp、TensorRT 这些框架在成熟，4bit/8bit 量化越来越好，MTP、DFlash 2 这类推测解码还在往下压生成延迟，Harness 又让中小模型靠工具、搜索、记忆、验证去完成更复杂的任务。这些东西叠到一起，本地 AI 才真正从「技术演示」变成「产品能力」。这也是我现在看端侧、边缘 AI，不再只盯某颗芯片或某个模型的原因——决定体验的是整个系统。

对做 AI 产品的人意味着什么

以前做 AI 应用，懂 Prompt、会调几个 API，就能做出不少东西。但真进了本地、边缘、云协同的地界，知识跨度一下就拉开了：得懂点硬件，知道 CPU、GPU、NPU、显存、内存带宽影响什么；得懂模型，知道不同模型的能力和资源需求；还得懂推理框架、性能优化、Agent、Tool、Memory、Context、Harness，以及数据放哪、什么时候用本地、什么时候上云。再往后还有多模型协作、多 Agent 调度和整套 AI Infra。

这让我想到最近常被提起的 FDE，Forward Deployed Engineer。这类人和传统软件工程师不太一样，不能只钉在某一个技术点上，得进真实场景，把模型、工程、数据、硬件、业务拼起来，解决一个具体问题。我觉得端边云 AI 以后会越来越需要这种人——不必最懂模型训练，也不必最懂芯片，但得知道怎么把这些东西攒成一个真能用的系统。

最后

过去几年，AI 行业最关心的是「模型还能有多强」。接下来几年，我觉得另一个问题会更重要：这么强的 AI，该在哪跑？

答案大概率不是云，也不是端，而是看成本、隐私、延迟、能力和场景，让计算落在最合适的位置。

Scaling Law 还会继续，云端模型还会更大更强。但与此同时，能力密度在涨，本地硬件在变强，推理框架在成熟，量化和解码技术在变，Agent Harness 也在抬高中小模型完成实际任务的成功率。所以我现在的判断是：本地 AI 真正值得关注的，不是「某个 27B 终于能在电脑上跑」，而是我们正从「模型塞不塞得进去」的阶段，走进「怎么把它跑得更快、更稳、更便宜，而且真能干活」的阶段。

从「能跑」到「好用」，中间隔的不是一颗更强的芯片，是一整套正在快速成熟的本地 AI 技术栈。

最后提一句题外话。创刊词里我写过，钛贵在提纯——钛矿石遍地都是，但把钛从矿石里提出来，工序极长。密度法则说的其实也是这件事：把更多能力，提进更少的参数里。这个时代稀缺的从来不是更大的模型，而是把能力提纯到用户手边的东西。

参考资料

文中提到的概念、模型和框架，来源都在这里：

1. 清华大学 / OpenBMB：Densing Law（密度法则）

   • 清华大学：《计算机系孙茂松团队提出"密度法则"揭示大模型高效化发展内在趋势》
   • https://www.tsinghua.edu.cn/info/1175/122675.htm
   • 文中"能力密度"和"约每 3.5 个月翻一倍"的说法，主要参考这份资料。

2. Densing Law 论文

   • Han Xu 等，Densing law of LLMs，Nature Machine Intelligence，2025
   • https://www.nature.com/articles/s42256-025-01137-0
   • DOI：https://doi.org/10.1038/s42256-025-01137-0

3. Qwen3.8 / Qwen3.8-27B

   • Qwen 官方 GitHub
   • https://github.com/QwenLM/Qwen3.8
   • 本地跑 Qwen3.8-27B 的部分，结合了我自己的实际体验。

4. 雪瑜：Qwen3.8-27B 社区优化版本整理

   • https://x.com/xueyu1125/status/2091493180730687807?s=46
   • 文中 MLX 4bit + DFlash 2、MTP 优化版本、约 20.4GB / 32.7GB 内存占用，以及作者自测 TPS 提升，来自这条帖子。具体速度表现和设备、上下文、量化方式有关，不能当成统一 Benchmark。

5. DFlash：Block Diffusion for Flash Speculative Decoding

   • Jian Chen、Yesheng Liang、Zhijian Liu，ICML 2026
   • https://arxiv.org/abs/2602.06036
   • 用于理解 DFlash 用 Block Diffusion 并行 Draft、加速 Speculative Decoding 的思路。

6. DFlash 2

   • Inco AI：DFlash 2: Keep Drafting Parallel
   • https://inco.ai/blog/dflash2/
   • Qwen3.8-27B DFlash 2 GGUF：https://huggingface.co/incoai/Qwen3.8-27B-DFlash2-GGUF
   • DFlash 2 在 DFlash 并行 Draft 的基础上，继续优化候选路径选择和块内预测，已有针对 Qwen3.8-27B 的专用 Draft Model。

7. Qwen3.8-27B 本地部署与量化示例

   • https://huggingface.co/Blackfrost-AI/Qwen3.8-27B-ABLITERATED-GGUF
   • 该页面列出了从 Q2_K 到 Q8_0 的不同量化大小，也说明实际运行内存还要算上上下文状态、计算 Buffer、视觉模块和 Draft Model 等额外占用。

8. Hermes Agent

   • Nous Research 官方 GitHub
   • https://github.com/NousResearch/hermes-agent
   • 关于 Agent Harness、Skills、Memory、MCP、Agent Loop 的讨论，部分参考 Hermes Agent 的公开架构和文档。

9. Pi Coding Agent

   • https://pi.dev/
   • Pi 自称 "minimal agent harness"，支持通过 Extensions、Skills、Prompt Templates 扩展 Agent 能力。

10. 视频：AI 端侧拐点，离我们还有多远？

    • https://www.youtube.com/watch?v=MMy7RJtDxoI&t=66s
    • 一段与本文主题同向的视频讨论：AI 从云端走向端侧的产业拐点，手机、汽车、个人设备如何演变为「私人智能体」，以及端侧模型在算力、能耗、推理能力和商业化上还需要突破哪些瓶颈。