本地化 AI Agent 的兴起与背景
演讲者胡嘉璽（嘉崎人智技术长）指出，自今年1月起，多家前沿模型厂商开始封禁账号，这促使团队探索替代方案。与此同时，本地端模型的快速发展让在 Agent 中使用地端模型成为可能。经过半年的观察，他认为本地端模型的进步“有点可怕”、“有点夸张”。因此，本次分享的主题聚焦于使用 DGX Spark 硬件运行一个基于本地模型和开源 Harness 的 Agent。
胡嘉璽拥有自2014年以来的AI行业经验，从早期的YOLO、LSTM到后来的GPU应用。他强调加入其Facebook粉丝专页及“Vibe Coding Taiwan”社群以获取最新硅谷同步资讯。本次分享分为八个部分，涵盖Agent定义、模型解析（包括DeepSeek-V4等）、本地端模型的必要性、Hugging Face模型识别、推理引擎选择以及Harness的安全边界作用，最后通过不同组合进行实机演示。
“那今天呢，我的主今的这个分享的主题就是在谈我们用一台 DGX Spark 来跑一个 agent。”
Agent 的核心架构：Model 与 Harness
Agent被定义为“帮你做事的东西”，它能控制电脑执行任务，因此存在安全风险。胡嘉璽将Agent拆解为两个核心部分：LLM（大语言模型）和Harness。他使用NBA球员作为类比：身高、体重、百米速度等先天条件是Model，而运球、三分投射、团队配合等技术则是Harness。Agent的强大程度取决于这两者的结合。
“agent 它主要分成两部分，第一部分叫做 llm LLM 啊，那第二部分呢，就是除了 LLM 之外 agent 其他东西都叫做 harness。”
Agent必须部署在本地电脑或浏览器中。若仅在浏览器运行，它无法控制操作系统（如读写Excel、PDF或使用Computer Use截屏）。只有本地部署的Agent才能通过控制电脑来完成复杂任务。因此，理解Model和Harness的区别是构建安全且强大Agent的基础。
模型原理与前沿闭源模型的困境
Model本质上是全球数据（如Common Crawl的数万亿Token）经过Transformer算法压缩后的文件，大小在几百GB到几TB之间。2024年引入Reasoning（推理）功能，模型在回答前会自问自答；2025年出现Toolformer机制，允许生成带有代码或函数名的Token。通过外部监控器捕获这些代码并在沙箱中执行，再将结果反馈给LLM，从而赋予其工具使用能力。此外，模型需具备视觉理解能力（如通过Patch处理图像），以便进行Computer Use操作。
目前前沿闭源模型包括OpenAI的GPT系列、Anthropic的Claude（Haiku/Sonnet/Opus/Fable）、Google Gemini及xAI Grok。胡嘉璽指出，这些模型定价高昂，普通用户每月订阅费轻松超过200美元。其高成本源于美国昂贵的电费、百万级薪资的科学家团队以及GPU/TPU硬件投入。
“当你随便写一个专案时，你都会发现你下面的那个那个用的多少钱，那一个月早就超过 200 美金了。”
开放权重模型与中国厂商的崛起
进入大模型市场的门槛极高，小米天才少女罗福莉曾指出入场券需达1TB参数规模。然而，随着Kimi K3（2.8T）和Qwen 3（2.4T）的出现，这一门槛已升至2TB以上。闭源模型因参数巨大、成本高昂且仅少数公司（约20家，多在中国）能进行Retrain/SFT而难以持续经营。
相比之下，开放权重模型（Open Weights）虽非完全开源代码，但提供可下载的权重文件。Nemotron 3采用Mamba架构独立开发；Google有Gemma，OpenAI曾有GPT-OS。目前90%的开放权重模型来自中国厂商，包括GLM、DeepSeek（Pro/Flash版本）、Qwen系列以及MiniMax等上百家厂商。
“开放权重模型，它目前已经不再是玩玩玩耍而已了，它已经是正式进入使用阶段了啊。”
胡嘉璽引用arena.ai的盲测数据，显示这些中国开放权重模型在性能上已具备实战能力，标志着本地端AI应用正式进入实用阶段。
开放权重模型在Agent与Coding基准测试中的强势崛起
近期AI领域的Leaderboard发生了显著变化，特别是在新增的Agent执行（Agent Execution）项目中，开放权重模型已经占据了前10名中的多个席位。值得注意的是，Kimi K3作为拥有开放权重的模型（尽管遵循特定License），在Hugging Face上公开了权重，并长期占据榜首位置。这一现象打破了以往由闭源模型垄断高端能力的局面。Anthropic CEO Dario Amodei曾于今年3月预言，开放权重模型需要6到18个月才能追上前端闭源模型的水平。
然而，现实进展远超预期。以2024年8月的数据来看，开放权重模型的表现已经相当于今年2月时闭源模型的水平（如Opus 4.6）。在Coding能力，特别是WebDev（JavaScript/HTML）及Python、Rust等通用编程能力的评测中，前12名中有半数以上是开放权重模型，前三名更是有两席被其占据。这表明开放模型不仅在理论上可行，在实际工程应用中已具备替代部分云端闭源服务的能力。除了本地部署，AWS、Azure、Google Cloud以及NVIDIA NIM和OpenRouter等云端服务商也广泛提供这些开放模型的API，用户可根据需求选择公有云、私有云或局域网部署。
"开放权重模型要追上前端模型要6到18个月"——Anthropic CEO Dario Amodei
MoE与Dense架构的机制差异及KV Cache优化策略
在模型架构层面，本次演示重点对比了MoE（混合专家）与Dense（稠密）两种模式。作者用开车做比喻：在复杂路况下，大脑只激活处理紧急状况的神经元（MoE），而在欣赏音乐时则调用更广泛的神经资源（Dense）。DeepSeek采用的MoE架构允许模型在推理时仅激活部分参数，从而大幅降低计算负载。相比之下，Dense模型如Qwen（千问）则需要处理全部参数。
Transformer架构的核心在于Self-Attention机制，其本质是通过QKV（Query, Key, Value）进行模糊数据库查询。由于Token间相关性计算需要大量的矩阵乘法，导致KV Cache（键值缓存）体积庞大且计算密集。为了解决这一问题，中国模型厂商在架构上进行了极致优化：
- CSA (Chunked Sparse Attention) & HCA (Hybrid Cache Architecture)：通过稀疏化或分组策略减少KV计算量。
- MLA (Multi-Head Latent Attention)：对KV进行降维处理，压缩存储需求。
- MTP (Multi-Token Prediction)：在训练和推理阶段，让模型一次性预测后续多个Token（如3-4个），若命中则成倍提升生成速度。
"为了不让KV cache的压力变大，所有的优化如CSA、HCA都是为了让KV值的运算变小"。
中美算力成本差异与模型性价比分析
中国AI模型的快速崛起背后，是极致的成本控制能力。美国头部模型依赖高昂的NBA级别工程师薪资、昂贵的GPU集群（如H100/H200）及高昂的电费。而中国模型厂商则利用以下优势实现了“降维打击”：
- 人力成本：许多具备国际视野的工程师回流中国，薪资约为美国同行的1/10。
- 能源成本：中国拥有巨大的发电总量（超过美印之和），且核电等基础设施审批相对宽松，电费极低。
- 硬件适配：在H100/H800甚至华为昇腾910C等受限硬件上，通过上述架构优化（MoE、MTP、量化）实现了与顶级闭源模型相当的性能。
这种成本结构意味着，当中国模型的Token携带信息量与美国顶级模型相当时，其实际生产成本仅为后者的1/50甚至更低。这种巨大的成本优势必然导致市场重新定价，使得开放权重模型在商业部署中具备极高的性价比。
实测演示：Qwen与DeepSeek的性能表现对比
为了直观展示架构差异，作者进行了实机演示。使用开源工具对比了Qwen 2.5-7B（Dense）与早期MoE引擎OLMoE的运行状态。结果显示，在生成相同Token时，Dense模型需扫描全部参数，而MoE模型仅激活约1/4的参数（具体比例视路由机制而定），直观体现了MoE的效率优势。
在基准测试方面，DeepSeek在Terminal Bench（终端任务完成度）等Agent评测中得分高达42.7-60区间，已接近此前被神化的闭源模型水平。Qwen作为Dense小参数模型（Hidden Size 5120），通过量化和MTP技术，在保持较小体积的同时实现了高速推理。这些实测数据证明，开放权重模型已在Agent执行和代码生成等关键领域达到可用甚至领先状态。
Qwen 3.8 27B模型架构与开源特性
Qwen 3.8 27B是一款完全开源的视觉语言模型，其Tokenizer支持约24万token的上下文窗口，这一规模与GPT等主流模型（通常在20-30万之间）相当。该架构设计旨在通过优化KV Cache来显著提升推理速度，同时具备处理文字与图片的多模态能力。值得注意的是，该模型不仅支持商用和微调，更被定义为“完全开源”，而非仅开放权重的半开源自研模型。虽然原计划推出35B MoE版本，但因曝光原因已取消发布。
“它已经不是开放权重了，它是一个开源模型。”
在上下文窗口方面，尽管Qwen支持26万token的长文本处理，但演讲者指出并非所有场景都需要极长的上下文。过长的窗口可能导致模型在中间段落出现注意力分散或“遗忘”现象，因此在实际应用中需根据任务需求合理设置。此外，该模型支持开启不同强度的“思考模式”，以适应从简单问答到复杂逻辑推理的不同需求。
硬件部署可行性与性能表现
对于本地部署，Qwen 3.8 27B对硬件的要求相对亲民。在配备5090显卡（32GB显存）的设备上，可以轻松运行FP8版本的模型；而4090显卡（24GB显存）虽然略显吃力，但通过采用NVFP4量化精度，也能完全容纳该模型。值得注意的是，从FP8降至NVFP4仅导致约2个百分点的性能精度损失，性价比极高。若拥有128GB统一内存的设备（如Mac Studio或DGX Spark），运行体验则更为轻松，甚至可同时挂载其他模型进行并行处理。
| 硬件配置 | 显存/内存大小 | 支持模型精度 | 运行状态评估 |
|---|---|---|---|
| NVIDIA RTX 5090 | 32GB VRAM | FP8 | 轻松运行，无压力 |
| NVIDIA RTX 4090 | 24GB VRAM | NVFP4 (量化) | 完全容纳，精度损失约2% |
| Mac Studio / DGX Spark | 128GB Unified Memory | FP8/NVFP4 | 极其轻松，可多模型并行 |
在DGX Spark上，Qwen 3.8 27B的推理速度约为每秒30 token。若采用并发或并行处理，吞吐量可提升至80-90 token/秒。对于更小的模型或优化后的工作流，这一速度甚至可能更高。这种性能表现使得DGX Spark成为进行概念验证（POC）的理想工具，用户可先以较低成本测试可行性，再决定是否部署至更昂贵的GB300集群或私有云环境。
地端模型的安全优势与适用场景
演讲者强烈反驳了“地端模型仅是玩具”的旧观念，强调其在企业级应用中的核心价值：安全性与可控性。对于拥有几十至几百人团队的机构，地端模型无需将数据发送至云端闭源服务商，从而彻底杜绝了数据泄露风险。特别是在搭配安全的Agent Harness（如沙箱环境）时，模型执行过程被严格限制在本地或私有网络中。
“地端模型只要跑一小群人的目标... 根本不会出到你公司以外的地方，非常安全。”
以Claude Cowork为例，其执行环境位于云端VM中，而本地部署的Claude Code则运行于本机。演讲者通过实验证明：在Mac上使用VirtualBox创建虚拟机后，无法在该VM内再嵌套运行Claude Code的沙箱环境，这证明了其底层执行依赖于宿主机的本地资源。因此，对于注重资安的金融、证券及保险行业，地端模型配合私有云和沙箱Harness的架构，是保障数据隐私的最优解。目前演讲者已将日常任务（如翻译、摘要、去标识化）迁移至地端模型，主要使用Nemotron及最新的Qwen 3.8 27B。
Hugging Face模型命名规范与量化技术解析
在Hugging Face等平台上，理解模型名称背后的技术参数至关重要。以NVIDIA-Nemotron-3-Ultra-550B-A55B-NVFP4为例：
1. 参数规模：550B表示总参数量。若名称后无后缀，通常为Dense模型（全参数推理）；若有A55B等标记，则表示MoE架构，每次推理仅激活55B参数，但加载时需占用全部550GB内存。
2. 量化格式：NVFP4代表NVIDIA的浮点4位量化。量化旨在减少存储和计算需求，例如将64位整数或16位浮点数压缩。常见的QAT（量化感知训练）指在训练中即引入量化约束，而大多数模型为后处理量化。
3. 其他后缀：IT表示经过指令微调（Instruction Tuning），使模型能遵循人类指令而非单纯文本接龙；MTP（Multi-Token Prediction）允许一次预测多个token，需训练时支持。
“大部分你先看到模型是模型先训练出来... 这叫做量化。”
此外，需警惕uncensored（未审查）或abliterated模型可能输出非法内容。演讲者曾测试此类模型，发现其具备协助破解网站的能力，因此强烈建议用户在使用开源模型时保持警惕，避免法律风险。对于追求极致性能的用户，Eagle和dspark等格式因支持MTP而备受青睐。
模型显存需求估算：量化精度与KV Cache的关键影响
在评估如 RTX 4090 (24GB) 或未来 RTX 5090 是否能容纳 Qwen 3.8 27B 模型时，核心在于理解参数大小与量化精度的关系。通常以 FP8（8位元）量化作为基准，此时模型参数量与所需显存呈近似 1:1 关系。例如 Qwen 27B 模型在 FP8 量化下仅需约 27GB 显存，这解释了为何许多开发者青睐该模型——它在拥有 32GB 显存的设备上能运行良好，且留有充足的 KV Cache（键值缓存）空间以支持较大的上下文窗口。
"FP8剛好就等於我的記憶體的數量跟模型的參數數量就是 GB 與 B 的差別啊"
然而，若使用 BF16（半精度浮点）格式，显存需求将翻倍。对于更激进的 NVFP4 量化（4位元），虽然理论显存占用减半，但实际并非精确的数学除法。以 Qwen 27B 为例，NVFP4 量化后显存占用约为 10-12GB。但必须注意，不能仅凭参数量计算显存，还需预留 KV Cache 空间。KV Cache 的占用取决于模型的 Attention 层数、并发用户数量以及并行输入序列的长度。因此，显存规划必须包含模型权重、KV Cache 及系统开销的总和。对于使用统一内存架构（UMA）的设备如 DGX Spark，虽然其显存带宽远低于 RTX 4090/5090，但其优势在于大容量内存（如 DGX Spark 的大显存配置），适合对延迟不敏感但需处理长上下文或高并发的场景。
模型格式演进：从分散文件到 GGUF 一体化包
在部署过程中，除了权重文件（Weights），用户还需下载 tokenizer、config.json 以及 toolparser 规则定义等辅助文件。若遗漏或配置错误任一组件，模型将无法正常运行。为简化部署流程，GGUF 格式应运而生。GGUF（GPT-Generated Unified Format）将上述所有必要文件打包为单一格式，成为 Ollama、llama.cpp 等推理引擎的标准支持格式。
"GGUF就是我們常常看到的 Ollama、llama.cpp 他們就是用 GGUF 把剛剛我講這些檔案全部變成一個"
使用 GGUF 格式的最大优势在于部署的便捷性。用户只需下载一个文件，配合轻量级的推理前端（如 Ollama），即可快速启动模型服务。然而，这种便利性也伴随着局限性：GGUF 格式对特定量化标准的支持较为专一。例如，如果某个模型未提供 GGUF 格式的 NVFP4 版本，用户便无法通过 llama.cpp/Ollama 直接运行该量化模型。此外，GGUF 格式的推理性能通常不如针对特定硬件优化的原生引擎（如 TensorRT-LLM）高效，因此它更适合作为快速测试、原型验证或本地轻量级部署的首选方案，而非大规模生产环境的主力引擎。
推理引擎选型：vLLM、SGLang 与专用引擎的对比
面对众多推理引擎（Inference Engines），选择需基于硬件架构、性能需求及易用性。以下是主要引擎的特性对比：
| 推理引擎 | 核心特点 | 适用场景/优势 | 局限性 |
|---|---|---|---|
| llama.cpp / Ollama | C++ 编写，支持 GGUF 格式，轻量级 | 本地快速部署、测试实验；Ollama 提供极简 CLI | |
| LM Studio / Unsloth Desktop | GUI 界面，支持参数调整（MTP, Twisting） | 桌面端用户友好；适合非服务器环境 | |
| TensorRT-LLM (TRT-LLM) | NVIDIA 官方出品，CUDA 兼容性极佳 | NVIDIA GPU 上的极致性能；支持 NVFP4 | |
| vLLM | 参数配置精细，支持 OpenAI API 兼容端点 | 生产环境首选；高并发、多用户共享服务 | |
| SGLang | 支持复杂推理逻辑，xAI Colossal 使用此引擎 | 特定模型优化；部分模型仅支持 SGLang | |
| D-Flash / DwarfStar | 专用引擎，针对特定模型优化速度 | 追求极致 Token 生成速度；支持多 token 预测 |
"我最推薦就是 vLLM...而且它可以變成一個 OpenAI 的相容端點"
vLLM 被强烈推荐用于生产环境。它不仅参数设置极其细致，还能轻松暴露为 OpenAI API 兼容端点，方便局域网内多台设备调用。对于追求极致速度的场景，可考虑 D-Flash 等专用引擎，它们可能支持每次预测多个 Token（如 3-5 个），从而提升吞吐量。然而，SGLang 也是重要选项，因为某些模型（如部分最新架构）仅支持 SGLang。值得注意的是，在 ARM 架构设备（如 DGX Spark）上运行 vLLM/SGLang Docker 镜像时，可能面临缺乏预构建镜像的问题，此时需回退到手动配置参数。
高效部署策略：利用 Claude Code 与 Docker 自动化运维
手动记忆和调整各推理引擎的复杂参数是一项繁琐工作。本分享提出了一种“偷懒”但高效的自动化部署策略：结合 Claude Code 与 Docker。具体流程如下：
- 获取模型文档：复制 Hugging Face 上的 Model Card 页面内容或 GitHub README。
- 指令 AI 助手：将文档粘贴给 Claude Code，并指定使用 Docker 部署。
- 自动化配置：Claude Code 根据文档自动生成 Dockerfile 或 docker-compose.yml，并处理依赖安装。
- 网络暴露：通过指令告知 Claude Code 需要开放的端口，使其自动配置防火墙或 Docker 网络映射。
"我的 CLAUDE.md 有規定得非常清楚...如果是這種一次性的服務啊，你不准安裝任何東西，比如說我不准你安裝，你只能你用 Docker"
此策略的核心优势在于可重复性与快速切换。通过 Docker，用户可以随时 docker stop 和 docker start 服务，实现模型的快速切换（相比 Ollama 加载大模型需等待数分钟）。同时，强制使用 Docker 隔离环境避免了系统污染。对于需要 Tool Use（工具调用）的场景，可在 Claude Code 指令中指定特定的 parser（如 Qwen Tool Parser 或 Hermes），由 AI 自动完成配置。这种方法极大地降低了推理引擎的入门门槛，使开发者能专注于业务逻辑而非底层运维细节。最终原则是：启动便捷、API 兼容、工具解析明确，而 vLLM + Docker + Claude Code 的组合完美契合这些需求。
部署环境管理：Docker 的必要性
在本地进行 AI Agent 开发时，依赖 Docker 容器是管理环境脏乱的关键策略。虽然用户可能担心找不到合适的镜像，但借助 Claude Code 等工具协助查找几乎能解决所有问题。若不使用容器化部署，随着 Ollama、LM Studio 等工具及各类模型的不断下载，4TB 的存储空间会迅速被占用至不足 1TB。Docker 的优势在于其隔离性，一旦环境出现问题或需要清理，直接删除容器即可彻底清除残留文件，避免本地文件系统变得杂乱无章。相比之下，非容器的部署方式会导致环境难以维护，且容易因文件堆积而影响系统性能。
安全边界模型：Harness 比 Model 更危险
在 Agent 架构中，安全风险的核心并非在于模型本身，而在于 Harness（执行环境）。模型本质上是“文字接龙”，仅在 GPU 中运行，离开硬件即失效；而 Harness 负责处理模型输出的函数调用、文件写入及网络通信，占据了 Agent 90% 的操作逻辑。因此，Harness 是数据泄露和系统被恶意操控的主要入口。安全边界可分为两个维度：一是模型存放位置，从最危险的公有云到相对安全的厂商背书云端，再到完全隔离的私有云或本地部署；二是 Harness 的执行环境。若模型处于云端而 Harness 在本机且无防护，爆炸半径将覆盖整台电脑。因此，选择可审查源代码的开源 Harness（如 PiAgent、Gemini CLI）比闭源工具更具可控性，用户可自主评估其安全性。
Harness 分类与选型趋势：开源 vs. 闭源
目前的 Agent Harness 主要分为通用型和编码型，并分为开源与闭源两大阵营。闭源工具如 Claude Code、ChatGPT Codex 和 Cursor，因其功能集成度高且具备远程通信（如 Telegram、Discord）能力，逐渐取代了早期的通用 Agent 工具。尽管 Anthropic 和 OpenAI 成立时间较短，但微软生态（如 VS Code + Copilot）因企业信任度高而广泛普及。开源工具方面，LlamaIndex 和 Hermes Agent 曾一度流行，但随着编码 Agent 能力的增强，其通用性优势减弱。近期热门的开源工具包括 OpenCodeInterpreter（功能全面）和 PiAgent。PiAgent 采用极简设计，仅提供四个核心工具并通过扩展机制增强功能。虽然它不提供开箱即用的复杂架构，但让用户清晰了解 Agent 的每一步搭建逻辑，便于深度定制和安全审查。相比之下，闭源工具虽易用但黑盒化严重，用户无法知晓其内部运作细节。
安全执行环境：从本机到沙箱的演进
为了限制 Agent 操作的“爆炸半径”，必须将 Harness 部署在安全环境中。仅限制工作目录已不足以防止模型绕过，因此容器化技术成为主流方案。Docker 和虚拟机（VM）可将 Harness 隔离，即使发生崩溃或恶意操作，也仅影响容器内部而不波及宿主机。NVIDIA 推出的 OpenShell（用于封装 OpenClaw）以及 Docker 新发布的 Docker SBX (Sandbox)，均提供了更严格的沙箱隔离能力。根据安全等级划分：
| 安全层级 | 模型位置 | Harness 位置/状态 | 风险描述 |
|---|---|---|---|
| L1 (最危险) | 云端 | 本机，无防护 | 整台电脑面临被恶意代码 wiped 的风险 |
| L2 | 云端 | Docker/VM (沙箱) | 爆炸半径限制在容器内，宿主机安全 |
| L3 | 云端 (可控) | 开源 Harness | 代码可审查，但执行环境仍需谨慎 |
| L4/L5 | 私有云/本地 | 沙箱内执行 | 数据不出公司范围，Harness 隔离运行 |
| L6/L7 | 私有云/本地 | OpenShell/NemoClaw | 网络受限或完全隔离，最高安全性 |
在实际演示中，通过 DGX Spark 设备模拟了从 L1（无防护）到沙箱环境的不同场景，验证了在银行稽核等敏感场景中，利用 Agent 进行去个资化（脱敏）处理时，沙箱隔离对保护客户隐私数据至关重要。
云端模型去识别化的风险与成本警示
演示首先展示了使用云端大模型进行数据脱敏（De-ID）的过程。操作者通过 Agent Harness 调用云端 Qwen 3.8 27B 模型，对包含个人信息的 Excel 文件进行去标识化处理。该过程涉及读取 Office 文档、理解中文姓名脱敏规则（如二字名变“王”，四字名中间两字打码等），并自动生成 Python 代码执行任务。整个流程耗时约 10分钟，虽然模型表现智能且彻底地完成了地址移除和姓名打码，但演示者强调这是极不安全的方式。因为数据上传至云端可能导致隐私泄露，且产生额外费用。演示者指出其账户在7天内仅消耗 8% 的用量，耗时5小时即花费数美元。更严重的风险在于企业合规性：曾有客户因将含个资数据上传云端，导致3分钟后被资安部门处罚并要求撰写报告。因此，直接连接云端模型处理敏感数据是绝对禁止的高风险行为**。
PDF解析的陷阱与中国软件生态
在处理PDF文档时，文字提取与图像识别存在巨大差异。纯文本转换的PDF通常问题较小，但若为扫描件或图片型PDF，解析难度极大。针对此类需求，演讲者建议采用特定的工具链，并特别指出某些国产软件在OCR和位置抓取方面表现极强。尽管存在对使用中国软件的顾虑，但鉴于其在公家单位中的广泛渗透及当前技术优势（如精准抓取位置信息），在实际操作中往往难以避免。这反映了在特定垂直领域，技术实力可能超越地缘政治偏好。对于开发者而言，若需处理复杂PDF，必须评估这些工具的兼容性与伦理风险。
“如果你對中國東西有就是不想用就不要用啊，那但是目前我知道就是很多公家單位都在用... 這個可是大陸軟體哦。”
Agent安全：Harness而非模型的责任
关于开放权重模型是否会被植入恶意提示词（如窃取机密数据），核心观点在于安全风险主要源于Harness而非模型本身。大语言模型（LLM）本质上是文字接龙，其安全性依赖于SFT（监督微调）和RLHF（人类反馈强化学习）阶段的对齐训练，旨在回避危险问答。然而，恶意Prompt Injection往往发生在Harness层的数据注入环节。若Harness未做好隔离与过滤，Agent仍可能被攻破。因此，保护Agent的关键在于部署Governance机制。即使如Claude 4.8等闭源模型也曾被破解，这证明了Agent的安全性上限取决于Harness的健壮性。建议通过安装Governance组件来防护，而非单纯依赖模型本身的“智能”。
DGX Spark性能调优与并发能力
在硬件层面，DGX Spark的时脉设定直接影响推理速度。通过systemctl或直接询问AI助手进行超频，演讲者发现将时脉从2000MHz提升至3003MHz（最高支持值）可显著改善性能。初期设定2100MHz时温度约为40多度，后续可逐步测试至更高频率以寻找稳定性边界。针对多机串联性能提升有限但并发量增加的现象，两台GB10串联可将模型层分布处理，速度略快但非倍增。对于Qwen 27B模型，在8个并行数下可达约100 tokens/秒。基于此数据，单台设备在8个并行环境下可支持5-8人同时使用进行编码或Agent任务，若涉及Computer Use等重负载操作则需减少并发数。
| 配置/场景 | 关键参数/表现 |
|---|---|
| DGX Spark最高时脉 | 3003 MHz (建议逐步超频测试稳定性) |
| Qwen 27B @ 8并行 | ~100 tokens/秒 |
| 单台设备建议并发人数 | 5-8人 (编码场景) / 更少 (Computer Use场景) |
| 多机串联效果 | 速度略快，非线性倍增；适合更大模型与更高并发 |
Agent上限在于Harness：CPU vs GPU逻辑
演讲者强调Agent的上限由Harness决定，而非LM本身。一个核心原则是：能用CPU解决的任务绝不使用GPU/LLM，因为GPU推理具有非确定性（Non-deterministic），而CPU执行确定性的系统指令（如yt-dlp下载视频、ffmpeg处理字幕）是100%准确的。当Harness提供丰富的CPU工具集时，LLM只需生成正确的指令序列即可完成任务，无需“猜测”结果。这种模块化、可定制的Harness（如Pi或OpenClaw）能显著提升Agent的可靠性与效率。相比之下，LangChain等框架更适合从头开发定制Agent。对于大规模部署（如百位工程师），建议先通过DGX Spark小范围测试，再根据规模扩展至DeepSeek Pro等云端方案。本地模型与前沿模型的差距可通过优秀的Harness设计来弥补，关键在于工具链的完备性与确定性执行能力。
“能用 CPU 解決的事情就不要用 GPU 解決... GPU 是 non-deterministic，就它是一個不確定性的東西。”
实机部署体验：Qwen在DGX Spark上的量化选择
在本次关于从模型部署到Agent Harness的分享中，演讲者重点探讨了Qwen 3.8 27B模型在NVIDIA DGX Spark硬件上的实际运行表现。经过多轮测试与对比，演讲者指出Qwen系列模型在资源受限的边缘设备上具有极高的适配性。特别是在量化版本的选择上，演讲者通过亲身实践得出了明确的结论：Q4是DGX Spark上的“甜蜜点”，即在保证模型智能水平的同时，能够维持流畅的运行速度。相比之下，更激进的量化版本如Q2虽然能进一步降低显存占用，但在DGX Spark上完全无法使用。为了佐证这一观点，演讲者回忆了之前尝试运行GLM模型的经历：当强制将量化级别降至Q1时，设备根本无法正常响应或推理完全失效。这一案例清晰地展示了硬件瓶颈对模型量化下限的硬性约束，也反向证明了Qwen在同等条件下仍能保持可用性的优势。
模型横向对比：DeepSeek的多模态与直觉优势
在确立了Qwen的部署可行性后，演讲者将视角转向了与其他主流模型的横向对比。他特别提到了DeepSeek模型的表现，并给出了高度评价。演讲者认为DeepSeek在多个维度上优于当前方案，具体体现在其模型体积更小、推理速度更快。除了基础的性能指标外，演讲者还强调了DeepSeek在直觉多模态能力上的突出表现。这意味着模型在处理复杂指令或多类型输入时，能更自然地理解用户意图，而非仅仅依赖机械的规则匹配。此外，长期运行稳定性也是DeepSeek的一大亮点，这在需要持续交互的Agent场景中尤为关键。尽管Qwen在部署兼容性上表现优异，但DeepSeek凭借其在速度和智能直觉上的双重优势，成为了演讲者心中另一个极具竞争力的选择。这种对比并非简单的优劣之分，而是展示了不同模型在特定场景下的差异化优势。
资源限制与购书建议：从技术到生活的延伸
在分享的最后部分，演讲者回归到硬件限制的客观现实。他再次强调DGX Spark的算力边界，指出对于Q2这样高压缩比的模型，该硬件平台确实存在无法逾越的性能障碍。这一结论不仅是对技术细节的总结，也为后续的资源规划提供了重要参考：在边缘设备上进行模型部署时，必须严格评估量化级别与硬件性能的匹配度。随后，演讲者自然地过渡到个人生活分享环节。他推荐了一本相关的技术书籍，并提供了具体的购买渠道建议。演讲者指出通过天瓏网络书店购买可享受约79折的优惠，而博客来等其他平台价格相对较高。他幽默地表示“想买就买，不想买也没关系”，这种轻松的结尾方式拉近了与观众的距离。最后，演讲者将时间交还给主持人保哥，现场观众报以热烈的掌声，标志着这场关于Qwen与DGX Spark实机演示的分享圆满结束。
结论
本地化 AI Agent 的可行性已由 Qwen 3.8 27B 与 DGX Spark 实机验证确立。Qwen 凭借对 NVFP4/Q4 量化的良好支持，在 RTX 5090/4090 及 DGX Spark 等硬件上实现低成本、高并发的本地部署，且精度损失仅约2%。其核心优势在于极致的成本控制与数据隐私安全，通过本地部署彻底规避云端泄露风险。
然而，Agent 的最终效能上限取决于 Harness 而非模型本身。安全隔离（如 Docker/Sandbox）是必要前提，且应优先使用 CPU 处理确定性任务以弥补 GPU 的非确定性缺陷。尽管 DeepSeek 在直觉与速度上具优势，但 Qwen 凭借开源特性、丰富的工具链适配及成熟的量化方案，已成为企业级私有化部署的高性价比首选。