Liquid Glass（液态玻
Mar
11
为什么要这么做
2026年的开年，生龙活虎的AI生态依然泾渭分明。一边是云端算力持续通胀，API调用需要排队、限流，热门模型动不动显示“繁忙”；另一边，开源社区的进展悄然越过了某个临界点——那些一年前还需要大型工作站才能运行的实用型模型，如今已经可以完整地运行在家庭级别的硬件上。这种变化带来一个朴素的问题：当你的每一次对话、每一张生成图片、每一段视频创作，都必须经过云端服务器时，我们到底在使用AI，还是在被AI背后的服务商定义？
正巧qwen3.5模型在春节推出，qwen3.5 35B模型的混合专家模型的知识广度已经不输deepseek在线服务，而qwen3.5 27B稠密模型的IQ已经超过deepseek3.2满血版。以数十B的家庭部署容量挑战百B级别在线服务，离线部署的意义正在于此。
- 首先是隐私。 所有对话历史、上传的图片、生成的视频，都停留在你控制的硬盘里，不必担心哪一天它们成为某个大公司微调模型的数据养料。你的家庭相册、工作文档、个人创作，不需要为了一次智能分析而被扫描上传。
- 其次是资源的可控性。 不再需要盯着“当前请求过多”的提示，不需要为了某个功能反复切换网络环境，更不需要等待大公司的审核队列。本地部署意味着无论外部网络环境如何变化，你的AI中枢始终在线，响应速度只取决于硬件性能。
- 然后是技术的可控性。 云端模型是一个黑箱——你不知道它训练过什么，不知道它为什么这样回答，更无法让它按照你的特定需求进行调整。而本地部署的模型，你可以微调、剪枝、量化，让它真正适应你的数据、你的术语、你的偏好。它不是某个大公司喂出来的通用品，而是你可以亲手调教的专属助手。
- 最后是长期的成本考量。 云端API按次收费的模式，在重度使用下很快就会超过一台高性能硬件的购置成本。而开源模型的迭代速度，正在让“买硬件而非买算力”变得越来越划算——你投入的是一次性设备，换回的是无限次、无限制的调用权。
更重要的是，我们正处在这样一个技术节点：一年前还需要仰望的闭源模型能力，今天已经被开源模型中复现、优化，并压缩到了可以家庭部署的尺寸。这意味着，离线不再是妥协，而是一种能力对等的选择。
基于这样的判断，我在春节购置了新的家庭mini AI设备，搭建了这座“末日堡垒”——一个完全离线、能跑文本、图像、音频、视频全模态模型的家庭AI中枢。本文便是对着这个过程进行的分享。
部署模型与选择
AI全模态生态下，AI主要有两大核心：大语言模型和扩散模型，它们各司其职。
- 大语言模型（LLM）：负责处理“符号的世界”，即文本内容，比如对话、代码、推理等。它采用自回归方式，逐个预测并生成词语。目前可本地部署的主流模型参数多在100B以内，像Qwen3.5的35B版本很合适，122B在主流mini AI主机上也能运行。
- 扩散模型：负责处理“感知的世界”，生成图像、视频、音频等内容。它从随机噪点开始，逐步去噪直至形成清晰图像。这个过程涉及大量矩阵运算，生成高分辨率内容时计算量会指数级增长。
一般来说LLM参数更大（如100B+常见），因为语言需要巨量神经元存储知识；扩散模型参数虽小，但更依赖“强算力”来渲染世界。因此，相同参数量下，扩散模型对算力的要求远高于LLM。它需要在高维空间反复迭代去噪，每一步都涉及复杂变换；而LLM只是逐个生成token，计算密度相对可控。这也是为什么跑扩散模型图像生成比文本对话更“烧显卡”。
硬件选择
以上特点自然会关系到我们的私有硬件选择：
- 对于扩散模型，我原本的家用PC实际上已经在运行目前主流的轻量级扩散模型，但是由于显存只有12G，LLM运行起来相当吃力。同时由于扩散模型对算力的需求与对于量化的保守，绝大部分开源扩散模型的高速运行强以来cuda生态，因此一张N卡对于扩散模型的运行是刚需。
- 对于LLM，主流模型进行极端的gguf量化或者FP4对运行结果影响并不大，因此无论是N卡还是mac的M芯片还是A卡，LLM的运行均还不错。
同时我们要注意的是显存的强需求：同时运行多个数十B参数量的模型，24G 32G这样的显存自然够呛，如果是专业工作站，自然是多卡串联或者超大杯RTX 5000 PRO这样的高成本玩法，而作为家用AI硬件，除开传统PC，统一内存的设备自然是最佳选择。
目前业界统一内存设备有如下3个性能相近的家用AI mini主机的选择：
- Apple M芯片Mac Mini/Studio，128G内存轻而易举，最大512G统一内存。
- NVIDIA DGX Spark平台，GB10平台的N卡芯片，默认128G统一内存原生支持2设备串接。
- AMD AI Max 395平台，同样大部分都是128G统一内存，同时还是x86设备可以windows。
从性价比的角度，AMD ~= Apple >> NVIDIA，老黄是非常坑人的。
从兼容性的角度，NVIDIA >> Apple > AMD，老黄的坑人建立在垄断式的技术碾压，不过这个判断仅仅在目前26年2月。（更新，2月末DGX Spark涨价了，性价比更低了）
因此推荐的决策树是：
- if 强需求扩散模型: return GB10平台设备 like NVIDIA DGX Spark
- else: return Apple M芯片Mac Mini/Studio
此处，从个人角度考虑，因为个人玩AIGC扩散模型，因此强需求N卡cuda生态，同时希望完全本地部署全套的话需要极大显存，因此昂贵的NVIDIA DGX Spark基本上是唯一解（性价比极低，但是是最廉价的大显存N卡方案）。如果不追求AIGC或者不追求同时在显存中加载LLM和扩散模型，更推荐M芯片Mac，并且现在这个时间推荐等等高端M5芯片。
LLM（大语言模型）
模型选择
当然，从前文大家可以知道整个事儿就是为了qwen3.5这盘醋包的饺子。可以从rank中看到qwen3.5我们可能采用的系列的对比。
]
可以注意到在以IQ为主的榜单上甚至27B模型是最优秀的。我在本地也对可能在本地部署的3款模型进行了对比：
- qwen3.5 27B：以长思考链为亮点的稠密模型，27B参数量即27B激活参数量，因此智商非常高，适合逻辑推演等IQ优先的场景。本地输出速率在10-15t/s左右，确实很慢了。
- qwen3.5 35BA3B，看起来参数量大但是由于是专家模型，因此本质上是知识范围相对更大但是激活参数量极少，因此响应速度快50-60t/s左右的速度已经和上一代普通非flash模型的线上速度无异，但是开启思考可以明显感知到思考思路不够精炼，偶尔存在重复输出。总的来说是性价比极高的模型。并且非常适合在Mac上部署。
- qwen3.5 122BA10B，它明确是一个更大的专家模型，虽然智商排名仍然在27B之下，但是其知识面广仍然抬高了整体可用性，也显然比35B强不少。可惜即使加载mxfp4模型，运行起来也是80G显存，再运行一些其他东西128G显存就开始吃不消了，同时20-30t/s的输出速度也不太可用。
网络上的测评已经看得够多了，因此实际上用1月时火热的“50米洗车”问题考验了一下3个模型在thinking和非thinking模式下的结果：
- Thinking：
OK
OK
OK
- No Thinking：
Not OK
Not OK
OK
结论上，Thinking模式下全对没问题，而非Thinking模式下只有122B是正确的，符合预期。
- 当然，最终考虑到122B的部署内存与本地追求“快”的输出速度，实际部署还是选择了35B的unsloth版Q8量化模型（实际运行内存在40G+，部署Q4/FP4模型内存还能减半，适合在工作mac上运行） https://huggingface.co/unsloth/Qwen3.5-35B-A3B-GGUF/tree/main 国内下载推荐镜像站https://hf-mirror.com/
至于35B的模型可用性到底怎么样，最近有一个龙虾任务测评工具：https://pinchbench.com
- 虽然都是轻量级/flash模型在对比，qwen3.5 35B的75%结果在一众闭源/百B级模型之间已经足够可用了。
部署方案
在个人本地电脑上部署和运行大模型时，目前主流的几大方案各有侧重，适合不同硬件条件、使用场景和用户偏好。
- Ollama 是最容易上手的选择，几乎一键安装、一行命令就能拉取并运行模型（支持 GGUF 格式），内置模型管理、本地优先、注重隐私，对 CPU 和 GPU 都有良好兼容性，尤其适合 Mac 或配置一般的 Windows PC，用于快速测试、个人聊天或小项目。它的缺点是并发能力较弱，高负载下响应明显变慢，扩展性有限，不太适合生产级或多人使用场景。
- llama.cpp 则强调极致兼容性和资源效率，几乎能在任何硬件上跑起来（包括纯 CPU、老旧笔记本或边缘设备），支持多种量化级别、启动极快、依赖很少、跨平台性最强，是资源受限环境或需要最大便携性的首选。它在单用户推理性能上表现优秀，但并发请求处理较弱，GPU 加速虽有支持却不如 NVIDIA 专用工具极致。
- vLLM 针对高吞吐量和低延迟做了深度优化，凭借连续批处理（continuous batching）和 PagedAttention 机制，在中高端 NVIDIA GPU 上能高效处理并发请求，提供 OpenAI 兼容 API，便于集成各种前端工具。它设置相对简单、模型兼容性好，适合开发者本地跑 API 服务、多任务负载或模拟生产环境，但在极低配置硬件或纯 CPU 场景下优势不明显，单次提示响应有时不如 llama.cpp 快。
- TensorRT-LLM 是 NVIDIA GPU 上追求极致性能的方案，通过自定义内核融合、FP8/INT4 等高级量化、in-flight batching 等技术，能在 RTX 40/50 系列或更高端卡上实现显著更低的延迟和更高的 token 生成速度（相比 llama.cpp 可能快 30-70%）。
总的来说各有千秋各有优劣。同时对于mac场景，LM Studio 在macOS上也有很好的原生支持，提供完整图形界面、模型下载/管理、聊天UI、OpenAI API endpoint一键开启，对新手极其友好。它底层也大量使用Metal加速，启动模型和响应速度在M系列上普遍优于Windows版本，是“不想写代码但想要好体验”的Mac用户常用选择。
- 最终，针对我这台ubuntu系统的NVIDIA DGX Spark，我选择了 llama.cpp 作为个人本地大模型部署方案，主要因为它在 GGUF 兼容性、资源效率和 server 搭建友好度上最均衡。GGUF 格式生态最成熟，几乎所有热门模型都有现成高质量版本，切换模型非常方便。最实用的是它的 llama-server：一行命令就能启动一个兼容 OpenAI API 与 Claude 风格 的本地服务器，直接对接 Open WebUI、Claude Code、VS Code 等各种前端，几乎零配置就能用起来。相比其他工具：Ollama 更简单但并发弱；vLLM 和 TensorRT-LLM 性能强但设置复杂、模型兼容性不如 GGUF 丰富；llama.cpp 则在“广兼容、跑得稳、开 server 简单”这几点上最适合个人日常使用。
整体follow unsloth团队的指南即可： https://unsloth.ai/docs/models/qwen3.5#qwen3.5-35b-a3b
扩散模型
模型选择
扩散模型我们来到了AIGC领域，这里就不是一个大模型通吃的时代，而是一堆中小规模的模型百花齐放。同时有一个需要关注的点，这个领域目前的开源生态远打不过闭源（比如最强的开源视频模型和seedance2.0比，完全不是一个时代的技术），可能的原因是AIGC更贴近生产力和商业模型。
在这个基础上，作为老AIGC玩家的我选择了几个关键领域业界比较认可的几个模型：
1. 文生图（text to image）领域：Z-Image-Turbo
- 阿里通义多模态团队（不是qwen团队，而是和qwen打架的那个团队）开源的 Z-Image-Turbo 是6B参数的超高速文生图模型，通过解耦蒸馏技术仅需8步推理即可实现亚秒级出图，画质逼近闭源SOTA，支持中英文双语文本渲染，16GB消费级显卡友好，前一阵子是开源图像模型Elo榜首，同时兼顾速度快和够优秀确实没话说。目前的rank如下，虽然看起来比qwen与flux低，但是他们的水平已经和上一代图片生成闭源模型（gpt一代，接近banana一代）等同，完全可用。（另外这里阿里的qwen团队的qwen图像模型和和通义多模态团队z-image图像模型在国内用起来都是顶流，可以认为不分伯仲，至于为什么通义实验室下两个团队在干这个，又是一个故事）
- 地址：https://huggingface.co/Tongyi-MAI/Z-Image-Turbo
2. 图片编辑（image edit）领域，常见的是为一张图片添加一个人，把两张图片的人合在一起，修改姿势，修改画风，超分等：Qwen Image Edit 2511
- Qwen-Image-Edit-2511是通义千问团队于2025年12月发布的图像编辑模型（基于前版2509大升级），专攻指令驱动的精准改图，最大亮点是人物一致性大幅提升、多人合照更稳、内置热门LoRA（打光/镜头/风格无需外挂）、工业设计质感与几何推理能力显著增强，目前开源社区公认最强开源图像编辑模型，目前基本上是明确的top1（除了腾讯开源了一个70B的大型模型）。
- 地址：https://huggingface.co/Qwen/Qwen-Image-Edit-2511
3. 视频生成：Wan2.2
- 仍然是阿里开源的模型，多模态团队的阿里通义万相Wan2.2是2025年7月开源的视频生成模型系列，全球首个采用MoE混合专家架构的开源视频扩散大模型（总参27B，推理激活14B），包含文生视频T2V-14B、图生视频I2V-14B和轻量混合TI2V-5B三种主力版本，支持电影级光影/构图/微表情控制，复杂动作与人物交互显著领先，能在消费级显卡高效运行。要注意的是由于视频长度与分辨率，视频模型显存占用极高，推理5s720p视频加上模型加载占用也是40G开外了，因此此模型相对于中等规模LLM意外的是一个性能大户。
- 由于开源视频模型在总榜上已经老后面了，因此就不再贴rank了，模型地址：https://huggingface.co/Wan-AI/Wan2.2-T2V-A14B
有意思的是，加上LLM，我们一共选择了4款模型，均是阿里开源的。两款qwen团队的两款多模态团队的。阿里不愧是开源大户。
部署方案
多模态模型部署的方案几乎没有讨论的余地，AIGC玩家唯一选择——即ComfyUI：ComfyUI是一个开源的节点式AI绘画界面。它将图像生成流程拆解为一个个功能模块，通过拖拽和连线的方式，让用户像搭建乐高一样自由定制工作流。这种方式不仅显存占用更小、运行效率更高，还能将工作流保存为文件精准复现，非常适合追求细节控制和复杂流程的专业用户。
在ubuntu并且N卡上，ComfyUI的部署如丝般顺滑，完全没有阻碍：
实际运行一次文生图（Z-Image-Turbo）的界面如下。它的GUI的截图想必大家多少都见过的：
友好的前端访问
上文我们为LLM和扩散模型部署了server，当然ComfyUI带工作流界面。但是对于日常使用，我们习惯于在类似于千问豆包这类的聊天窗口完成任务，因此部署一个好用的前端界面便是接下来的一环。
离线豆包一样的OpenWebUI
在linux服务器上部署的开源的Chat类方案，目前最优解自然是OpenWebUI（https://github.com/open-webui/open-webui）。可以把 OpenWebUI 想象成一个 “完全私有的、你自己服务器上的ChatGPT”，同时它不仅是一个统一的聊天界面，也是一个私人的知识库：你可以上传自己的文档构建一个完全本地、不上传云端的安全知识库，然后向AI提问文档里的内容，并且用RAG检索；当然也支持自定义Agent，Skill等。
- 它部署它非常简单，运行起来后，只需要简单的将openAI server指向本地的llama-server，我们的qwen就可以运行起来了。向qwen提问题或者多模态理解都轻而易举。
配置
qwen普通问答
]
qwen多模态输入
- ComfyUI也可以使用标准的工作流进行桥接，我们的Chat也能利用扩散模型生成图片与编辑图片。
配置
Text to Image
Image Edit
现在，我们得到了一个完全在本地部署离线运行的小豆包，或者说是小千问（毕竟部署的模型全是阿里家的）。
内网穿透
我们的OpenWebUI可以在我们的局域网里访问了，但是作为生产力，自然希望自己人在外也能访问家庭的模型与数据，自然就涉及内网穿透了。真巧我本地可以实践以下3个常见家用内网穿透方案：
1. NAS自带穿透服务
家里正好有一台功能完善的NAS自带了内网穿透服务。用NAS优势在于真正的零配置与傻瓜式操作，无需任何网络知识，注册账号即可在任何网络环境下访问；劣势则是速度受限于厂商的免费中转服务器，带宽极窄，仅能勉强用于浏览文档或照片，同时访问的Web容器和权限受NAS的应用管理，并不太自由。
2. 花生壳这样的商业穿透服务
花生壳我也用过，优势在于它结合了低门槛与高性能，只需安装客户端并付费，即可获得稳定且有保障的商用带宽；当然问题注意还是在穿透暴露http服务需要ICP备案，我们还是暴露的AI类服务，确实大可不必直接放弃。
3. 自建FRP服务
还是正好，我在大陆和境外都有闲置云服务器和闲置域名。直接在新加坡阿里云上部署FRP服务听起来很不错，优势在于极高的自由度与可控性，深度定制转发规则，数据掌握在自己手中，长期成本可能低于商业服务，当然，也不需要备案。
最终，NAS方案与FRP服务方案我都用起来了。利用NAS建设了简单的服务器管理API，穿透访问安全。而OpenWebUI本身也frp挂在了阿里云上，便于在浏览器直接访问。
目前家庭网络看起来如下：
现状（安全性差）
理想态（安全，web服务docker化，堡垒机）
接下来 / Todo
OpenWebUI只能说是用户友好的离线豆包，但是豆包不是生产力工具，OpenWebUI的功能甚至还无法覆盖我部署的全部模型。
作为程序员，Claude Code、龙虾、大量的Skill打通我们本地部署的模型与能力，才能构成真正的本地离线AI生产力堡垒。So，这些内容正在编写分享文档Part 2。
2026年的开年，生龙活虎的AI生态依然泾渭分明。一边是云端算力持续通胀，API调用需要排队、限流，热门模型动不动显示“繁忙”；另一边，开源社区的进展悄然越过了某个临界点——那些一年前还需要大型工作站才能运行的实用型模型，如今已经可以完整地运行在家庭级别的硬件上。这种变化带来一个朴素的问题：当你的每一次对话、每一张生成图片、每一段视频创作，都必须经过云端服务器时，我们到底在使用AI，还是在被AI背后的服务商定义？
正巧qwen3.5模型在春节推出，qwen3.5 35B模型的混合专家模型的知识广度已经不输deepseek在线服务，而qwen3.5 27B稠密模型的IQ已经超过deepseek3.2满血版。以数十B的家庭部署容量挑战百B级别在线服务，离线部署的意义正在于此。
- 首先是隐私。 所有对话历史、上传的图片、生成的视频，都停留在你控制的硬盘里，不必担心哪一天它们成为某个大公司微调模型的数据养料。你的家庭相册、工作文档、个人创作，不需要为了一次智能分析而被扫描上传。
- 其次是资源的可控性。 不再需要盯着“当前请求过多”的提示，不需要为了某个功能反复切换网络环境，更不需要等待大公司的审核队列。本地部署意味着无论外部网络环境如何变化，你的AI中枢始终在线，响应速度只取决于硬件性能。
- 然后是技术的可控性。 云端模型是一个黑箱——你不知道它训练过什么，不知道它为什么这样回答，更无法让它按照你的特定需求进行调整。而本地部署的模型，你可以微调、剪枝、量化，让它真正适应你的数据、你的术语、你的偏好。它不是某个大公司喂出来的通用品，而是你可以亲手调教的专属助手。
- 最后是长期的成本考量。 云端API按次收费的模式，在重度使用下很快就会超过一台高性能硬件的购置成本。而开源模型的迭代速度，正在让“买硬件而非买算力”变得越来越划算——你投入的是一次性设备，换回的是无限次、无限制的调用权。
更重要的是，我们正处在这样一个技术节点：一年前还需要仰望的闭源模型能力，今天已经被开源模型中复现、优化，并压缩到了可以家庭部署的尺寸。这意味着，离线不再是妥协，而是一种能力对等的选择。
基于这样的判断，我在春节购置了新的家庭mini AI设备，搭建了这座“末日堡垒”——一个完全离线、能跑文本、图像、音频、视频全模态模型的家庭AI中枢。本文便是对着这个过程进行的分享。
部署模型与选择
AI全模态生态下，AI主要有两大核心：大语言模型和扩散模型，它们各司其职。
- 大语言模型（LLM）：负责处理“符号的世界”，即文本内容，比如对话、代码、推理等。它采用自回归方式，逐个预测并生成词语。目前可本地部署的主流模型参数多在100B以内，像Qwen3.5的35B版本很合适，122B在主流mini AI主机上也能运行。
- 扩散模型：负责处理“感知的世界”，生成图像、视频、音频等内容。它从随机噪点开始，逐步去噪直至形成清晰图像。这个过程涉及大量矩阵运算，生成高分辨率内容时计算量会指数级增长。
一般来说LLM参数更大（如100B+常见），因为语言需要巨量神经元存储知识；扩散模型参数虽小，但更依赖“强算力”来渲染世界。因此，相同参数量下，扩散模型对算力的要求远高于LLM。它需要在高维空间反复迭代去噪，每一步都涉及复杂变换；而LLM只是逐个生成token，计算密度相对可控。这也是为什么跑扩散模型图像生成比文本对话更“烧显卡”。
硬件选择
以上特点自然会关系到我们的私有硬件选择：
- 对于扩散模型，我原本的家用PC实际上已经在运行目前主流的轻量级扩散模型，但是由于显存只有12G，LLM运行起来相当吃力。同时由于扩散模型对算力的需求与对于量化的保守，绝大部分开源扩散模型的高速运行强以来cuda生态，因此一张N卡对于扩散模型的运行是刚需。
- 对于LLM，主流模型进行极端的gguf量化或者FP4对运行结果影响并不大，因此无论是N卡还是mac的M芯片还是A卡，LLM的运行均还不错。
同时我们要注意的是显存的强需求：同时运行多个数十B参数量的模型，24G 32G这样的显存自然够呛，如果是专业工作站，自然是多卡串联或者超大杯RTX 5000 PRO这样的高成本玩法，而作为家用AI硬件，除开传统PC，统一内存的设备自然是最佳选择。
目前业界统一内存设备有如下3个性能相近的家用AI mini主机的选择：
- Apple M芯片Mac Mini/Studio，128G内存轻而易举，最大512G统一内存。
- NVIDIA DGX Spark平台，GB10平台的N卡芯片，默认128G统一内存原生支持2设备串接。
- AMD AI Max 395平台，同样大部分都是128G统一内存，同时还是x86设备可以windows。
从性价比的角度，AMD ~= Apple >> NVIDIA，老黄是非常坑人的。
从兼容性的角度，NVIDIA >> Apple > AMD，老黄的坑人建立在垄断式的技术碾压，不过这个判断仅仅在目前26年2月。（更新，2月末DGX Spark涨价了，性价比更低了）
因此推荐的决策树是：
- if 强需求扩散模型: return GB10平台设备 like NVIDIA DGX Spark
- else: return Apple M芯片Mac Mini/Studio
此处，从个人角度考虑，因为个人玩AIGC扩散模型，因此强需求N卡cuda生态，同时希望完全本地部署全套的话需要极大显存，因此昂贵的NVIDIA DGX Spark基本上是唯一解（性价比极低，但是是最廉价的大显存N卡方案）。如果不追求AIGC或者不追求同时在显存中加载LLM和扩散模型，更推荐M芯片Mac，并且现在这个时间推荐等等高端M5芯片。
LLM（大语言模型）
模型选择
当然，从前文大家可以知道整个事儿就是为了qwen3.5这盘醋包的饺子。可以从rank中看到qwen3.5我们可能采用的系列的对比。
可以注意到在以IQ为主的榜单上甚至27B模型是最优秀的。我在本地也对可能在本地部署的3款模型进行了对比：
- qwen3.5 27B：以长思考链为亮点的稠密模型，27B参数量即27B激活参数量，因此智商非常高，适合逻辑推演等IQ优先的场景。本地输出速率在10-15t/s左右，确实很慢了。
- qwen3.5 35BA3B，看起来参数量大但是由于是专家模型，因此本质上是知识范围相对更大但是激活参数量极少，因此响应速度快50-60t/s左右的速度已经和上一代普通非flash模型的线上速度无异，但是开启思考可以明显感知到思考思路不够精炼，偶尔存在重复输出。总的来说是性价比极高的模型。并且非常适合在Mac上部署。
- qwen3.5 122BA10B，它明确是一个更大的专家模型，虽然智商排名仍然在27B之下，但是其知识面广仍然抬高了整体可用性，也显然比35B强不少。可惜即使加载mxfp4模型，运行起来也是80G显存，再运行一些其他东西128G显存就开始吃不消了，同时20-30t/s的输出速度也不太可用。
网络上的测评已经看得够多了，因此实际上用1月时火热的“50米洗车”问题考验了一下3个模型在thinking和非thinking模式下的结果：
- Thinking：
OK
OK
OK
- No Thinking：
Not OK
Not OK
OK
结论上，Thinking模式下全对没问题，而非Thinking模式下只有122B是正确的，符合预期。
- 当然，最终考虑到122B的部署内存与本地追求“快”的输出速度，实际部署还是选择了35B的unsloth版Q8量化模型（实际运行内存在40G+，部署Q4/FP4模型内存还能减半，适合在工作mac上运行） https://huggingface.co/unsloth/Qwen3.5-35B-A3B-GGUF/tree/main 国内下载推荐镜像站https://hf-mirror.com/
至于35B的模型可用性到底怎么样，最近有一个龙虾任务测评工具：https://pinchbench.com
- 虽然都是轻量级/flash模型在对比，qwen3.5 35B的75%结果在一众闭源/百B级模型之间已经足够可用了。
部署方案
在个人本地电脑上部署和运行大模型时，目前主流的几大方案各有侧重，适合不同硬件条件、使用场景和用户偏好。
- Ollama 是最容易上手的选择，几乎一键安装、一行命令就能拉取并运行模型（支持 GGUF 格式），内置模型管理、本地优先、注重隐私，对 CPU 和 GPU 都有良好兼容性，尤其适合 Mac 或配置一般的 Windows PC，用于快速测试、个人聊天或小项目。它的缺点是并发能力较弱，高负载下响应明显变慢，扩展性有限，不太适合生产级或多人使用场景。
- llama.cpp 则强调极致兼容性和资源效率，几乎能在任何硬件上跑起来（包括纯 CPU、老旧笔记本或边缘设备），支持多种量化级别、启动极快、依赖很少、跨平台性最强，是资源受限环境或需要最大便携性的首选。它在单用户推理性能上表现优秀，但并发请求处理较弱，GPU 加速虽有支持却不如 NVIDIA 专用工具极致。
- vLLM 针对高吞吐量和低延迟做了深度优化，凭借连续批处理（continuous batching）和 PagedAttention 机制，在中高端 NVIDIA GPU 上能高效处理并发请求，提供 OpenAI 兼容 API，便于集成各种前端工具。它设置相对简单、模型兼容性好，适合开发者本地跑 API 服务、多任务负载或模拟生产环境，但在极低配置硬件或纯 CPU 场景下优势不明显，单次提示响应有时不如 llama.cpp 快。
- TensorRT-LLM 是 NVIDIA GPU 上追求极致性能的方案，通过自定义内核融合、FP8/INT4 等高级量化、in-flight batching 等技术，能在 RTX 40/50 系列或更高端卡上实现显著更低的延迟和更高的 token 生成速度（相比 llama.cpp 可能快 30-70%）。
总的来说各有千秋各有优劣。同时对于mac场景，LM Studio 在macOS上也有很好的原生支持，提供完整图形界面、模型下载/管理、聊天UI、OpenAI API endpoint一键开启，对新手极其友好。它底层也大量使用Metal加速，启动模型和响应速度在M系列上普遍优于Windows版本，是“不想写代码但想要好体验”的Mac用户常用选择。
- 最终，针对我这台ubuntu系统的NVIDIA DGX Spark，我选择了 llama.cpp 作为个人本地大模型部署方案，主要因为它在 GGUF 兼容性、资源效率和 server 搭建友好度上最均衡。GGUF 格式生态最成熟，几乎所有热门模型都有现成高质量版本，切换模型非常方便。最实用的是它的 llama-server：一行命令就能启动一个兼容 OpenAI API 与 Claude 风格 的本地服务器，直接对接 Open WebUI、Claude Code、VS Code 等各种前端，几乎零配置就能用起来。相比其他工具：Ollama 更简单但并发弱；vLLM 和 TensorRT-LLM 性能强但设置复杂、模型兼容性不如 GGUF 丰富；llama.cpp 则在“广兼容、跑得稳、开 server 简单”这几点上最适合个人日常使用。
整体follow unsloth团队的指南即可： https://unsloth.ai/docs/models/qwen3.5#qwen3.5-35b-a3b
// 安装llama.cpp
git clone https://github.com/ggml-org/llama.cpp
cmake llama.cpp -B llama.cpp/build \
-DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON
cmake --build llama.cpp/build --config Release -j --clean-first --target llama-cli llama-mtmd-cli llama-server llama-gguf-split
cp llama.cpp/build/bin/llama-* llama.cpp
// 运行模型
llama-server \
--model models/qwen35_35BA3B/Qwen3.5-35B-A3B-Q8_0.gguf \
--mmproj models/qwen35_35BA3B/mmproj-F16.gguf \
--chat-template-kwargs "{\"enable_thinking\": false}" \
--ctx-size 262144 \
--temp 0.6 \
--top-p 0.95 \
--top-k 20 \
--min-p 0.00 \
--alias qwen35-35b \
--port 8001扩散模型
模型选择
扩散模型我们来到了AIGC领域，这里就不是一个大模型通吃的时代，而是一堆中小规模的模型百花齐放。同时有一个需要关注的点，这个领域目前的开源生态远打不过闭源（比如最强的开源视频模型和seedance2.0比，完全不是一个时代的技术），可能的原因是AIGC更贴近生产力和商业模型。
在这个基础上，作为老AIGC玩家的我选择了几个关键领域业界比较认可的几个模型：
1. 文生图（text to image）领域：Z-Image-Turbo
- 阿里通义多模态团队（不是qwen团队，而是和qwen打架的那个团队）开源的 Z-Image-Turbo 是6B参数的超高速文生图模型，通过解耦蒸馏技术仅需8步推理即可实现亚秒级出图，画质逼近闭源SOTA，支持中英文双语文本渲染，16GB消费级显卡友好，前一阵子是开源图像模型Elo榜首，同时兼顾速度快和够优秀确实没话说。目前的rank如下，虽然看起来比qwen与flux低，但是他们的水平已经和上一代图片生成闭源模型（gpt一代，接近banana一代）等同，完全可用。（另外这里阿里的qwen团队的qwen图像模型和和通义多模态团队z-image图像模型在国内用起来都是顶流，可以认为不分伯仲，至于为什么通义实验室下两个团队在干这个，又是一个故事）
- 地址：https://huggingface.co/Tongyi-MAI/Z-Image-Turbo
2. 图片编辑（image edit）领域，常见的是为一张图片添加一个人，把两张图片的人合在一起，修改姿势，修改画风，超分等：Qwen Image Edit 2511
- Qwen-Image-Edit-2511是通义千问团队于2025年12月发布的图像编辑模型（基于前版2509大升级），专攻指令驱动的精准改图，最大亮点是人物一致性大幅提升、多人合照更稳、内置热门LoRA（打光/镜头/风格无需外挂）、工业设计质感与几何推理能力显著增强，目前开源社区公认最强开源图像编辑模型，目前基本上是明确的top1（除了腾讯开源了一个70B的大型模型）。
- 地址：https://huggingface.co/Qwen/Qwen-Image-Edit-2511
3. 视频生成：Wan2.2
- 仍然是阿里开源的模型，多模态团队的阿里通义万相Wan2.2是2025年7月开源的视频生成模型系列，全球首个采用MoE混合专家架构的开源视频扩散大模型（总参27B，推理激活14B），包含文生视频T2V-14B、图生视频I2V-14B和轻量混合TI2V-5B三种主力版本，支持电影级光影/构图/微表情控制，复杂动作与人物交互显著领先，能在消费级显卡高效运行。要注意的是由于视频长度与分辨率，视频模型显存占用极高，推理5s720p视频加上模型加载占用也是40G开外了，因此此模型相对于中等规模LLM意外的是一个性能大户。
- 由于开源视频模型在总榜上已经老后面了，因此就不再贴rank了，模型地址：https://huggingface.co/Wan-AI/Wan2.2-T2V-A14B
有意思的是，加上LLM，我们一共选择了4款模型，均是阿里开源的。两款qwen团队的两款多模态团队的。阿里不愧是开源大户。
部署方案
多模态模型部署的方案几乎没有讨论的余地，AIGC玩家唯一选择——即ComfyUI：ComfyUI是一个开源的节点式AI绘画界面。它将图像生成流程拆解为一个个功能模块，通过拖拽和连线的方式，让用户像搭建乐高一样自由定制工作流。这种方式不仅显存占用更小、运行效率更高，还能将工作流保存为文件精准复现，非常适合追求细节控制和复杂流程的专业用户。
在ubuntu并且N卡上，ComfyUI的部署如丝般顺滑，完全没有阻碍：
#安装
pip install comfy-cli
comfy --install-completion
#根据显卡相关指引安装cuda生态或其他
...
#然后就可用了
comfy --skip-prompt launch --background -- --listen 0.0.0.0 --port 8080 --preview-method auto实际运行一次文生图（Z-Image-Turbo）的界面如下。它的GUI的截图想必大家多少都见过的：
友好的前端访问
上文我们为LLM和扩散模型部署了server，当然ComfyUI带工作流界面。但是对于日常使用，我们习惯于在类似于千问豆包这类的聊天窗口完成任务，因此部署一个好用的前端界面便是接下来的一环。
离线豆包一样的OpenWebUI
在linux服务器上部署的开源的Chat类方案，目前最优解自然是OpenWebUI（https://github.com/open-webui/open-webui）。可以把 OpenWebUI 想象成一个 “完全私有的、你自己服务器上的ChatGPT”，同时它不仅是一个统一的聊天界面，也是一个私人的知识库：你可以上传自己的文档构建一个完全本地、不上传云端的安全知识库，然后向AI提问文档里的内容，并且用RAG检索；当然也支持自定义Agent，Skill等。
- 它部署它非常简单，运行起来后，只需要简单的将openAI server指向本地的llama-server，我们的qwen就可以运行起来了。向qwen提问题或者多模态理解都轻而易举。
配置
qwen普通问答
qwen多模态输入
- ComfyUI也可以使用标准的工作流进行桥接，我们的Chat也能利用扩散模型生成图片与编辑图片。
配置
Text to Image
Image Edit
现在，我们得到了一个完全在本地部署离线运行的小豆包，或者说是小千问（毕竟部署的模型全是阿里家的）。
内网穿透
我们的OpenWebUI可以在我们的局域网里访问了，但是作为生产力，自然希望自己人在外也能访问家庭的模型与数据，自然就涉及内网穿透了。真巧我本地可以实践以下3个常见家用内网穿透方案：
1. NAS自带穿透服务
家里正好有一台功能完善的NAS自带了内网穿透服务。用NAS优势在于真正的零配置与傻瓜式操作，无需任何网络知识，注册账号即可在任何网络环境下访问；劣势则是速度受限于厂商的免费中转服务器，带宽极窄，仅能勉强用于浏览文档或照片，同时访问的Web容器和权限受NAS的应用管理，并不太自由。
2. 花生壳这样的商业穿透服务
花生壳我也用过，优势在于它结合了低门槛与高性能，只需安装客户端并付费，即可获得稳定且有保障的商用带宽；当然问题注意还是在穿透暴露http服务需要ICP备案，我们还是暴露的AI类服务，确实大可不必直接放弃。
3. 自建FRP服务
还是正好，我在大陆和境外都有闲置云服务器和闲置域名。直接在新加坡阿里云上部署FRP服务听起来很不错，优势在于极高的自由度与可控性，深度定制转发规则，数据掌握在自己手中，长期成本可能低于商业服务，当然，也不需要备案。
#client（内网机器）
serverAddr = "161.117.83...."
serverPort = 7777
[[proxies]]
name = "web"
type = "http"
localPort = 8989
customDomains = ["ai.lrd.tw"]
#server（阿里云）
bindPort = 7777
vhostHTTPPort = 8989最终，NAS方案与FRP服务方案我都用起来了。利用NAS建设了简单的服务器管理API，穿透访问安全。而OpenWebUI本身也frp挂在了阿里云上，便于在浏览器直接访问。
目前家庭网络看起来如下：
现状（安全性差）
理想态（安全，web服务docker化，堡垒机）
接下来 / Todo
OpenWebUI只能说是用户友好的离线豆包，但是豆包不是生产力工具，OpenWebUI的功能甚至还无法覆盖我部署的全部模型。
作为程序员，Claude Code、龙虾、大量的Skill打通我们本地部署的模型与能力，才能构成真正的本地离线AI生产力堡垒。So，这些内容正在编写分享文档Part 2。
渝公网安备 