实战 AI Max 395 智能体部署：1M上下文 平替在线大模型实现Token自由！

实战 AI Max 395 智能体部署：1M上下文 平替在线大模型实现Token自由！

这个话题在我草稿箱里躺了挺久，主要是内容比较散：硬件、系统、推理框架、智能体配置、出图出视频，想到哪写到哪，一直串不成一条线。最近不少朋友问我同一个问题：本地模型跑编码智能体，到底顶不顶用？我这套方案在自己机器上跑了两个多月，今天一次说清楚——机器怎么搭、框架怎么选、坑怎么踩、最后算下来到底省了多少。

文中的数字都是本机实测，日志都还在，想抄作业的朋友可以逐步核对。

1. 先说环境：AI Max 395 和我的双系统方案

1.1 那颗 128G 统一内存

手里已经有这类小主机的可以跳过这节。还没上车的，记住几个关键点就够了：

组成规格说明
CPU16 核 32 线程 Zen 5，最高 5.1 GHz编代码、跑编译都够用，但它不是主角
GPURadeon 8060S，40 CU（RDNA 3.5），最高 2.9 GHz推理真正干活的部分
内存128 GB LPDDR5x-8000，256-bit，理论带宽 256 GB/s买这台机器就是为了它
显存划分可变显存（VGM）可调，但实测 Windows 侧设自动（约 64G）最稳，Linux 侧留 512M 就够别照搬「划 96G」的攻略，后面细说
功耗默认 55W，可配到 120W整机功耗相当于一台游戏本

为什么本地跑大模型要选它？说白了就是容量。一张 32G 显存的卡连权重都装不下，更别提长上下文的 KV 缓存。qwen3.8-flash-next 六十多 G 的权重常驻之后，还剩一大把内存给 KV 池，这就是后面 1M 上下文的本钱。

带宽 256 GB/s 跟 HBM 没法比，本来不指望它有 4090 那种速度——过去拿它跑大模型，基本是"能跑，但慢得没法干活"。转折点是社区新出的推理框架 halogen：解码速度不再随上下文长度崩塌，Prefill 快出数倍，再加上磁盘 KV 缓存把重启税直接抹平，AI Max 395/400 这代机器硬是逆风翻盘，重新拥有了生产力。它是怎么做到的，第 2 节用实测数据说话。

1.2 Ventoy + VHD 双系统：整个系统就是一个文件

这部分是我自己的玩法，说出来可能有人觉得怪：Windows 11 和 Ubuntu Server 24.04 都装在 vhd 虚拟硬盘里，用 Ventoy 双系统启动。

好处要折腾起来才体会得到：

  • 两个系统各自就是一个 .vhd 文件，想挪到哪块盘就复制过去，不用重装；
  • Windows 侧在 vhd 之上再套一层差分磁盘，折腾坏了删掉差分盘，秒级回到干净状态；
  • Linux 侧不支持 vhd 差分，但无所谓——vhd 文件本身复制一份就是整机备份，恢复就是复制回来。

为什么这么折腾？因为智能体会替我改系统。opencode 用顺手之后，你很难忍住不让它动系统配置，那就得给自己备足后悔药。升级推理框架翻车了？还原。系统搞崩了？还原。后悔药的成本就是几份文件拷贝。

Ventoy U盘/分区（本机直接硬盘启动）
 ├── Win11.vhd ── Win11-差分.vhd   ← 差分盘秒级还原
 └── Ubuntu2404.vhd                ← 复制文件 = 整机备份

2. 推理框架：同一个模型，两种命

模型统一用 qwen3.8-flash-next 一个模型文件，通过参数设置为2个不同上下文的模型（512k 和 1M ，官方表示上下文最多为256k，但通过我们调整配置，让上下文达到最大的1M），看起来2个模型，其实就一个权重文件。

下图中，qwen3.8-flash-next （512k上下文）和 qwen3.8-flash-next -1m（1M上下文）被设置为2个模型，但其实是一个模型文件
同理，qwen3.8-flash-next-unc（512k上下文）和 qwen3.8-flash-next-unc-1m（1M上下文）也是一个模型文件，两个入口。每次只能启动一个模型，128G内存也只能容纳一个模型，一个模型拉起时另一个模型被自动卸载。本人业务多以512k上下文模型为主（机子内存剩余约21G），1M上下文为辅（机子内存剩余约13G，由于启动后kv缓存已被系统锁定大小，所以无需担心爆显存）。

下图：当前本机所有llama-swap托管模型：
在这里插入图片描述

2.1 Windows 11 + llama.cpp：能用，但勉强

llama.cpp 在 Windows 上装起来不难，Vulkan 后端开箱即用，速度就有点难看了：

上下文长度解码速度
20k约 30 t/s
50k约 20 t/s
100k约 15 t/s

说句公道话，超长会话的稳定性倒是不错：从 32K 一路聊到 100K，生成速度只是从 22–23 t/s 缓慢降到 21–22 t/s，没有崩。真正的问题在首字符：20k 上下文的 Prefill（18.9K tokens）实测只有 441 t/s，长上下文下光等首字就要 1–5 分钟，甚至更久。

聊天、办公咨询，等几分钟无所谓；智能体不一样，一个任务几十轮请求，每轮都等几分钟首字，这谁受得了。所以 Windows 下的 llama.cpp 我现在的定位就是聊天和办公咨询的备用机。

2.2 Ubuntu 24.04 + halogen：真正的主角

Linux 这边我把几款主流开源推理框架都试了一遍，速度都不尽如人意，最后只能接受闭源的 halogen（halogen-flash-server，可免费使用）。部署方式是 podman quadlet 起服务，前面挂 llama-swap 做统一入口，同一份权重起 1M 和 512K 两个上下文配置（1M 靠 YaRN 扩展），按需路由。还有个 Linux 侧特有的福利：BIOS 里 VGM 只需给核显留 512M，推理引擎会把剩下的约 124G 全部识别成显存——权重、KV 池、缓存全在「显存」里进出，不用纠结哪块内存归谁。

装完实测，我觉得这个选择是值的。三点：

第一，解码速度基本不随上下文长度掉。 10k 到 1M，平均解码都在 60 t/s 上下。贴几个实测数字：

上下文halogen 实测解码
8k52–65 t/s
131k48–65 t/s
225k46–55 t/s
127K 长会话（151 次请求）中位 63 t/s
900k 满上下文约 55 t/s

对比 llama.cpp 在 100k 的 15 t/s，差距自己看。从 8k 到 225k 只掉几个 t/s，900k 满上下文还有 55 t/s，这已经摸到在线大模型的尾巴了。

下图是真实的解码速度：
解码速度实测

第二，Prefill 同样不随上下文掉速，稳定在 1600 t/s 左右。 8k 冷启动 1852 t/s，225k 冷启动还有 1487 t/s。对比 Windows 下 llama.cpp 的 441 t/s，首字等待直接砍到四分之一。

第三，磁盘 KV 缓存，这条是我最想说的。 halogen 能把每次会话的上下文 KV 缓存落盘，下次会话直接从磁盘载入，不用重新推理。跨重启实测：

上下文冷 prefill 要等磁盘缓存恢复
152K95 s2.3 s
500K约 5 min约 3 s
901K702 s7.4 s

按 1600 t/s 算，500K 上下文冷 prefill 要干等 5 分钟；有磁盘缓存，3 秒开聊。引擎升级、系统重启、换会话续聊，从此没有"重启税"这回事。

再补一条整体数据：那条 151 次请求的长会话里，RAM 层 prompt cache 命中率 98.1%，折算下来相当于省了约 91 分钟的 GPU 重算——这笔时间不加缓存的话，每次重启都要重新交。

halogen 更新很勤，隔三差五出新版，升级这事我也没留给自己手动。我给引擎侧配了一套自动升级程序，具体功能：新版升级提醒，一键自动升级！。

升级提醒，opencode中提醒升级：
升级提醒，opencode中提醒升级

打开升级软件，一键升级。自动升级演示，升级耗时约1-2分钟时间：
在这里插入图片描述

3. opencode：智能体本身很简单，六个插件才是正戏

opencode 的部署很简单，线上教程一大把，不赘述。真正让这套本地方案从"能用"变成"敢用"的，是我加的六个插件。

3.1 代码审核插件：用少量 token 买智力

本地模型和在线旗舰的差距，说到底还是智力差距。我的办法是让在线模型当审校、本地模型当打工人：opencode 每次 write/edit 提交代码，插件自动把改动送给在线模型审核（DeepSeek 网页版或 API，配了多模型回退链），审核意见在下一步动作之前回灌给本地模型，有 bug 当场修，审到 PASS 才放行。

几个我在意的设计细节：

  • 审核通过不注入对话，只记日志，不往上下文里灌噪音；
  • 多个文件自动合并送审，有界等待，不会把流程卡死；
  • 配置文件（json/yaml/env 这类）硬性禁止送审——配置里常有密钥，送审等于外泄；隐私项目一键把审核整个关掉。

效果能量化：本地模型的产出质量能到在线模型的九成左右，而送审只传增量 diff，token 消费比全程用在线模型低 95%。

下图为自动提交代码审核，审核结果提醒：
在这里插入图片描述
下图：对审核结果进行整改：
在这里插入图片描述

3.2 记忆插件：不再失忆，但有个大坑

opencode 默认每个会话都是新脑子。opencode-mem 提供跨会话全局记忆，项目约定、踩坑记录、我的偏好，重启开机它都记得。

但这个插件跟 halogen 的 KV 磁盘缓存八字不合，这个坑我踩了两天。插件把记忆块注入在系统提示词尾部（约 8k token 处），而记忆块的内容每轮都在变。KV 缓存是按 token 前缀命中的，前缀在第 8k 个 token 处被打破，8k 之后的全部历史 KV 就都作废了。症状很具体：258k 上下文的会话，缓存只保得住 8k，剩下 250k 每轮重新 prefill，每次白等 2–5 分钟。

定位方法倒是干净：查 opencode.db 里每个 step 的 cache_read，如果永远卡在 8000 附近，就是它。

修复只需要一行 patch，把注入块从系统提示词挪到 messages 末尾。内容再变也只作废尾部几百 token，历史前缀永久稳定：

- event.system.push({ type: "text", text: injected });
+ event.messages.push({ role: "user", content: [{ type: "text", text: injected }] });

修复前后对比（重启后首条消息）：

指标修复前修复后
首 step cache_read7,936（断在 8k）222,712（≈全量）
首 step 新 prefill63,449 tokens1,069 tokens
首 step 耗时58 s7.8 s

提醒一句：这个 patch 打在 npm 缓存目录里，升级 opencode-mem 会被覆盖，升级后要重新打一遍。

3.3 循环守护 + 语音提醒：犯浑时有人拽一把，停下时有人喊你

本地模型跑智能体，最怕两件事：陷入循环反复做同一个操作，或者中途异常断掉、假装任务完成了。循环守护插件全程盯着 opencode 控制台，检测到循环模式或异常中断就主动介入——提醒、打断、追问，直到任务真正做完。挂机跑长任务的心安，全靠它。

语音提醒是后来加上的，结果就回不去了。控制台每次停下来等你的时候都会出声：任务完成播一段约 3 秒的完成旋律；弹出选项等你拍板（提问、权限确认）则是「滴滴滴滴」四连短音。提示音是脚本实时合成的 WAV，不依赖任何音频素材。别小看这两声——智能体挂机时你根本不知道它什么时候停，听到声音再过来，一眼就知道是该继续干活还是该拍板了。

下图是循环介入：
在这里插入图片描述

3.4 自动技能生成器：越用越聪明

每次任务结束，系统自动复盘这次的做法值不值得沉淀，值得就生成一份技能文档。下次遇到同类任务直接按沉淀好的流程走，不再从头摸索。这不是口号，两个多月下来它给我沉淀的几十条技能，执行类似任务顺畅多了。
在这里插入图片描述

3.5 时间戳插件：给每轮任务装上行车记录仪

task-timing 给会话里每条消息盖时间戳：你发的消息标发送时刻，智能体的最终回复标「开始时间 --> 结束时间（耗时 X分Y秒）」，中间多轮工具调用合并计一次。排查问题的时候特别有用——智能体说「刚才那步失败了」，你能对上是几点几分哪一轮，跟引擎日志、插件日志一一对上；平时扫一眼，任务跑到哪了、一轮花了多久，一目了然。
在这里插入图片描述

3.6 halogen 升级提醒插件：引擎升级不缺席

前面说引擎侧会自动分阶段升级、失败自动回滚，客户端这边再挂一个升级提醒插件：每 5 分钟轮询一次引擎的升级动态，有新版本、升级完成、或者失败回滚了，提醒直接注入 opencode 会话，去重落盘，重启也不重复轰炸。这个是我全套配置里最「省心」的一个——引擎在机器那头悄悄升级，我在这头写代码，版本变了自动知道，全程不用盯。

4. ComfyUI：出图出视频，128G 内存的另一半价值

光跑语言模型，这台机器其实只发挥了一半。128G 统一内存真正的奢侈之处，是能把一张卡想都不敢想的图像、视频模型直接塞进"显存"。ComfyUI 我现在两边都装了：Windows 侧用 AMD 便携包，Ubuntu 侧跑在 Docker 容器里，模型库放共享盘，两边共用一份。

4.1 部署：比想象中简单

我用的是社区 AMD 便携包 ComfyUI_windows_portable_amd（v0.33.1），解压即用，自带 pytorch 2.9.1+rocm7.2.1。ROCm 生态最难的那段日子已经过去了，gfx1151 现在原生识别，启动日志直接是这样：

pytorch version: 2.9.1+rocm7.2.1
AMD arch: gfx1151
Device: cuda:0 AMD Radeon(TM) 8060S Graphics : native

不需要像早期那样设 HSA_OVERRIDE_GFX_VERSION 骗过框架。显存划分这块我踩过一次坑：网上攻略都说把 VGM 划到 96G，我实测下来 Windows 侧反而不正常；设成自动（约 64G），LLM 推理和 ComfyUI 都能顺利跑——42GB 的视频模型照样塞得进去。

Ubuntu 侧走的是 Docker：一个 comfyui 容器，模型、工作流、输入输出全部挂载在宿主机磁盘上。好处是容器本身无状态，镜像随便换、容器随便重建，数据一动不动；局域网里其他设备开个浏览器就能用，不用蹲在那台小主机前操作。两边版本各自独立升级，互不干扰。

自定义节点装了一百来个（Manager、KJNodes、WanVideoWrapper、LTXVideo、SeedVR2、reactor、controlnet_aux……），真正天天用的也就那十几个。

4.2 跑什么模型，跑多快

模型库里放的都是大家伙，单位以 GB 计：

用途模型大小
图像Z-Image-Turbo / moody 系列 mix12 GB
图像Qwen-Image / Qwen-Edit（GGUF Q6_K）17 GB
图像Flux2-dev（GGUF Q6_K）/ Flux2-Klein 9B27 GB / 8 GB
视频LTX-2.3 22B（bf16 / fp8 / distilled）42 GB / 29 GB / 23 GB
视频Wan2.2-I2V-A14B（High/Low，Q6_K）12 GB × 2
修复SeedVR2 视频超分 / 高清放大 + 面部修复工作流—

42GB 的视频模型直接进显存，这在 32G 卡上是想都别想的事。耗时都是日志里的实测：

任务实测耗时
单张出图（Z-Image-Turbo / Krea2-turbo 级）20–30 秒
高清放大 + 面部修复工作流5–6 分钟
LTX-2 文生视频 / 图生视频约 11 分钟一条
LTX-2.3 22B 图生视频23–24 分钟一条

一条 23 分钟听着吓人，但这是 22B 视频模型在本地跑的价。我的玩法是睡前排几个任务，早上起来 output 目录里躺着一堆成品。工作流也玩得挺花：首尾帧生成、四图参考、视频加音效（V2V Foley）、带语音的数字人，都能跑。

4.3 几个实用的习惯

  • 模型库放共享盘：ComfyUI 程序在系统盘，模型和输出在共享盘，两个系统用同一份，备份到 8T 盘时一并带走；
  • 写脚本核对模型：网上下的工作流经常引用一堆本地没有的模型，我写了个小脚本扫描所有工作流的模型引用，对照本地模型库自动生成缺失清单，不用等报错了再猜缺哪个；
  • 大图像模型用 GGUF：flux2-dev 用 Q6_K 量化后 27GB，省内存、载入快，肉眼差别不大；
  • 工作流出问题丢给智能体：Docker 侧的工作流文件就躺在宿主机磁盘上，这给了智能体插手的机会。我围绕这个沉淀了一套技能：静态体检（连线完整性、模型引用、参数数量）、API 格式转工作流格式、命令行批量改提示词和换模型，最后用无头浏览器真的打开前端加载一遍，断链 0 才算修好。网上下的工作流打不开、画布空白、一根线都没有，多半是 API 格式和连线格式的坑，丢给 opencode 比在 WebUI 里手点快得多。

5. 收尾：算一笔账

维度在线大模型本机方案
费用token 计费，重度使用月均数百电费，月均几十
上下文200K–1M，常要排队或加价1M，随便用
解码速度50–80 t/s45–63 t/s，基本不随上下文变
长会话首字看排队磁盘缓存命中后秒级
代码隐私全部出网全本地（审核可关）
限流高峰期常见无
智力基准九成左右（本地 + 在线审核）

不足也说清楚：halogen 是闭源的（好在免费）；首次部署调优确实要花时间；Windows 侧的 llama.cpp 目前只适合聊天场景。但对我来说，这套方案带来的变化很实在——我不再纠结"本地模型能不能打"，开始琢磨"在线模型还剩什么优势"。

6. 要抄作业的话

  1. 硬件：AI Max 395 / 128G，BIOS 显存划分 Windows 侧设自动（约 64G）即可，Linux 侧 VGM 留 512M，引擎自动把剩余约 124G 识别为显存；
  2. 系统：Ventoy + vhd 双系统（Win11 上差分盘，Ubuntu 整机文件备份）；
  3. 推理：Ubuntu 下 podman 部署 halogen，llama-swap 做统一入口，同一权重起 512K 和 1M 两个配置，开启磁盘 KV 缓存（我给了 200G 预算），再配升级看护插件自动盯版本；
  4. 模型：qwen3.8-flash-next；
  5. 智能体：opencode + 代码审核 / opencode-mem（记得打尾部注入补丁）/ 循环守护（含语音提醒）/ 自动技能生成器 / 时间戳 / halogen 升级提醒；
  6. 出图出视频：Windows 侧 ComfyUI AMD 便携包（ROCm 7.2，gfx1151 原生支持），Ubuntu 侧 Docker 容器（端口 8188，数据目录挂宿主机磁盘），模型库放共享盘两边共用；
  7. 验收：跑一条长会话，看 cache_read 是否接近全量上下文、解码是否稳在 60 t/s 上下、重启续聊是否秒级。

哪一步卡住了，或者踩到了我这篇没写到的坑，欢迎评论区留言、站内私信，配置、脚本、补丁我都整理好了，聊得来的直接发你，如果评论够多，也可以发一篇详细的部署教程。欢迎一起来折腾——你即将踩的坑，我大概率刚踩过。

本文实测数据来自：AMD AI Max 395 / 128G 统一内存 / Ubuntu Server 24.04 / halogen-flash-server / qwen3.8-flash-next。

# 人工智能 # 经验分享 # vscode
Logo
北京朝阳AI社区

更多推荐

cover

从零开始训练语言大模型5——全唐诗5.2万首step=10000训练

avatar 北京朝阳AI社区
cover

官方博客里智能体授权一秒可收，算力分区同步落地｜2026年11月08日

avatar 北京朝阳AI社区
cover

404 vs 100% 精准：3 层 AI 架构，如何让信创国产库 API 文档告别死链？

avatar 北京朝阳AI社区