小睿聊AI 07｜两台 Spark 跑本地 Agent，长上下文到底能不能用？

图 1｜本地 Agent 与双机计算的概念封面。

我是小睿。

这套部署用的是两台技嘉 GIGABYTE AI TOP ATOM，采用 NVIDIA GB10，属于 DGX Spark 同平台整机。实测给出了一个明确的起点：128K 长输入已经能在本地运行，首次读入与预热后的响应相差很大。

让 Agent 帮忙改一段代码，第一轮通常不复杂：给出报错，读几个文件，提出修改。再往后，它要看项目约定、查调用关系、运行测试、读失败日志，最后回头调整。问答还在继续，带进去的材料已经越来越多。

整理报告也是如此。开始只有几份文件，接着补会议记录、历史版本、表格和计算结果；现场排查则可能从一张照片开始，逐步加上设备手册、参数和测量数据。

对围绕同一批代码、资料持续工作的 Agent，这类设备值得考虑。部署的关键，是给模型和缓存留足资源，把执行工具与任务文件安排在合适的位置；交给团队使用时，再把这些资源组织成员工能直接使用的助手。是否划算，要看它持续做成了多少合格任务。

一、两台小主机，首先带来的是容量选择

图 2｜GIGABYTE AI TOP ATOM 官方外观与接口图。图片来源：GIGABYTE。

每台 ATOM 配有 128GB 统一内存，CPU 和 GPU 共同使用。运行时，模型权重、系统、推理框架、推理临时缓冲区和上下文缓存都要从这里分配空间。上下文缓存常写作 KV 缓存，用来保存已处理内容的中间计算状态。

“128GB”容易让人直接联想到能装多大的模型，但 Agent 还会不断留下新内容：工具调用参数、搜索结果、测试日志、上一轮生成的代码。这些内容一旦随下一轮请求送回模型，也会占用上下文和缓存空间。输入更长、同时处理的请求更多，留给缓存的余量就会改变。

双机有两种值得分开的用法。

一种是让两台共同运行一个较大的模型。框架把计算或模型状态分到不同节点，节点之间持续交换数据。这里关心的是权重怎样分片、通信能否跟上，以及长输入时还有多少余量。共同运行一个模型时，一台故障可能影响整个模型服务，恢复方式也需要一起设计。

另一种是各自运行能单机容纳的模型，再按任务分工。例如交互与后台批处理分别安排资源，或把不同类型的模型放在不同节点。这样做是否划算，仍取决于实际模型能否装下、请求分布和任务时限。

两种部署解决的问题不同。单机里的 CPU/GPU 互联，与两台机器之间的网络也不同。双 ATOM 可以通过 ConnectX-7 配合分布式推理；NVIDIA 文档给出的每个 QSFP 端口上限是 200Gb/s，以太网互联需要软件正确使用。两台各有 128GB，并不会仅凭一根线就变成一张可随意使用的 256GB 显卡。

官方接口图也能帮助辨清连接：USB-C 供电口与三个 USB-C 数据口分开，RJ45 10GbE 用于日常网络连接，ConnectX-7 承担节点间高速互联。部署时应核对实际接线与框架配置，不能把办公网络连通当成双机推理已经配置完成。

图 3｜双 ATOM 的节点边界与连接示意，非现场接线复现。业务 LAN 与节点间高速互联分开理解。

若单台装不下，优先研究双机协同；若是同一时间的请求多，则同时比较分开服务。先确定瓶颈，再决定怎样连接。

二、先把“等多久”拆开，实测才有用

上下文，就是模型这一次需要读的材料，包括问题、资料和前面的对话。长度用 token 计，token 是模型处理文本的单位，并不等于一个汉字。

看速度时先分两件事：发出请求后多久收到第一个输出 token，叫首包时间（TTFT）；开始输出后每秒生成多少 token，叫输出速度（decode）。首个 token 可能还不是有用答案；完整任务还要经过多轮处理、工具执行、检索、重试和人的检查。多人或多任务一起用时，还要看并发，也就是同一时间正在处理的请求数。

本文把首次处理记为冷请求，预热后再次处理记为热请求；长输入测试的热值取第二次热请求。这是测试请求口径，与机器温度无关，也不是直接把上一轮答案再发一遍。

下面是这套双 ATOM 使用背景下，同一套代码题的实际部署记录，分短请求、32K、128K 三档。32K 与 128K 先测一次冷请求，再测两次热请求，热值取第二次。Qwen 为当前配置，DeepSeek 为此前保留的配置；两组运行配置不同，用来观察实际部署体验。本表没有单机对照，不能据此判断双机相对单机的加速收益。

表 1｜三档实际部署记录

作者实测；同一套代码题、2048 token 输出口径；两组运行配置不同。32K与128K一冷两热，热值取第二次热请求。

指标	Qwen3.8 Flash	DeepSeek V4 Flash 0731
短请求首包	0.13–0.17 秒	0.25 秒
短请求输出	42–58 tok/s / 同题中位 42.1	45–56 tok/s / 未给中位数
26–32K 冷首包	10.26 秒 / 33031 token	14.7–16.6 秒
26–32K 热首包	0.58 秒	0.37–0.45 秒 / 池受压曾到 1.5 秒
26–32K 热输出	63.8 tok/s	66–73 tok/s
32K 热命中	95.7%	干净 99% / 池受压 91%
128K 冷首包	42.87 秒 / 132427 token	69–73 秒
128K 热首包	0.69 秒	0.63 秒
128K 热输出	61.8 tok/s	60 tok/s
配置窗口	262K	384K

表中模型名称沿用测试记录：Qwen3.8 Flash、DeepSeek V4 Flash 0731。Qwen 两档长输入分别为 33031、132427 token；“32K”“128K”作为档位名称。

图 4｜三档请求的首包时间。各面板横轴独立，不能跨面板比较线长；区间沿用记录，热值取第二次热请求。

短请求要保留。确认一个条件、追问一个参数、修改一小段代码，本来就不需要长上下文。这里 Qwen 首包为 0.13–0.17 秒，DeepSeek 为 0.25 秒；后续输出分别为 42–58 与 45–56 tok/s，区间有重叠。

32K 这一档，两套配置各有快的环节：首次读入时 Qwen 等待较短；预热后，DeepSeek 的首包时间更短、输出速度更高。冷读等待与热请求表现，要分别衡量。

128K 更能说明为什么要拆开看。Qwen 首次首包 42.87 秒，热请求为 0.69 秒；DeepSeek 分别为 69–73 秒和 0.63 秒。热输出则为 61.8 与 60 tok/s，两组数值接近。初次读入长资料与后续复用资料，已经是两种很不同的等待体验。

图 5｜短、中、长输入的输出速度。点值与区间分别保留；两组运行配置不同。

在这套本地配置中，我最终选了Qwen，也考虑了直接输入现场照片的需求。本篇先讨论请求和资源安排，识图与工具正确性仍需相应任务验证。

这组差别会改变任务安排。第一次分析整个项目或一批长资料，可以先完成必要的文件筛选，再交给模型读入；交互界面应显示正在处理，避免用户因暂时没有输出而反复提交。进入后续修改时，再观察前面的材料有没有被复用。若每一轮都像首次读入那样等待，就要查输入组织、缓存保留和队列，而不是只看输出速度。

三、任务继续，上下文为什么越来越长

想象一个代码任务的输入顺序：项目约定、相关代码、当前问题。第一次读完以后，Agent 运行测试，下一轮再附上测试结果和新的要求。

前面的材料如果保持稳定，服务就有机会复用已经算过的部分，只处理新增内容。常用的前缀缓存保存的是处理历史输入时产生的中间状态；具体能复用到哪里，取决于引擎和缓存策略。前缀缓存主要减少重复处理输入的计算，并不直接缩短后续生成每个 token 的时间。

组织输入时，可以把稳定的项目约定和资料放在前面，把当前问题、新文件与工具结果追加在后面。测试工具先返回关键错误和相关片段，完整日志留在工作区，需要时再读。这样既减少无关材料，也便于回查。每轮重新排列全部资料、把大段动态内容插到最前面，会减少前缀复用的机会。

图 6 前缀复用的一般机制示意。图中百分比另列为原记录观察值，分母未明确，不代表通用机制的因果比例。新增内容仍需处理，资源竞争可能影响缓存保留。

不过，热请求测试与持续工作的 Agent 仍需分开。当前“一冷两热”的结果给出了预热后的基线；真实工作会不断追加内容，也可能有别的任务占用缓存。新增后缀依然要算，缓存被淘汰后，旧材料也可能重新处理。

记录里就有一个值得注意的观察：DeepSeek 的 32K 热首包在干净条件下为 0.37–0.45 秒，缓存池受压时曾到 1.5 秒；相应记录中的“热命中”从 99% 变为 91%。这不能画成一条完整的性能曲线，却足以提醒部署者：独自跑一次顺畅，和夹在多个任务之间继续工作，是两种环境。

因此，落地测试最好用一项有连续性的工作：读代码、改代码、运行测试、读日志、再修改。每轮留下输入量、命中信息、输出量、首包与最终结果，同时记录工具用了多久。这样才能知道时间花在了模型、重读资料，还是某个工具上。

长任务还需要区分两件事：缓存保留了多少计算，任务保留了多少事实。缓存可能被淘汰，已确认的目标、采用的文件版本、最后一次测试结果却应能从任务记录里找回来。阶段摘要可以帮助继续工作，关键数值和结论仍要能回到原文件。

四、把本地 Agent 搭完整：模型、工作区、资料各有位置

一个常见误区，是把所有服务都塞进推理机器。其实本地部署可以是一套在自己掌握的网络里协作的服务，按职责安排位置。

在电脑上提出修改要求后，Agent 先把问题发给模型，再到指定目录读代码、改文件和运行测试。模型服务保存上下文缓存；代码、测试日志和修改差异留在工作区。资料检索和业务系统也通过各自接口接入。

对于个人或小团队，可以先从代码工作区加本地模型开始：任务只访问指定目录，修改保留差异，运行测试后提交结果。做资料整理时，再接入自己的文档目录和检索服务；做定期报告时，把一次任务的输入、脚本、产物放在同一个可追溯的位置。

如果要交给同事使用，企业还应提前准备好助手能用的模型、资料和工具，按岗位与任务配置范围。员工打开工作入口，就能获得已经组合好的支持，不必各自重装模型、重配一遍工具。

任务并发与推理并发也应分开看。一个 Agent 正在等脚本或文件传输时，不一定持续占用模型计算；另一项请求可以在服务允许时使用这段时间。但前一项任务的缓存是否保留、返回后是否重新排队，仍由运行策略决定。部署时应分别看工具等待、模型队列和缓存占用，不能把“同时开着几个任务”直接当成几路推理吞吐。

GB10 的 CPU 是 Arm 架构，这会影响容器与二进制选择。比如一个执行环境要求 Linux/amd64 和 KVM，就应放到满足条件的工作节点，再通过接口连接推理服务。把“模型能在 GB10 上运行”推成“所有配套软件都应在 GB10 上运行”，会给部署增加不必要的麻烦。

接入 Agent 时，API 地址能连通只是第一步。应走完一次真实的工具循环：模型提出调用，工具收到合法参数，执行结果返回，模型根据结果继续。流式输出、工具参数、错误返回和长上下文都在这条路径上。量化用较低精度表示模型权重，以减少内存占用，效果取决于具体方案。升级前，保存一份能跑通的模型、量化文件、引擎版本与启动配置，再用原来的代码题、长资料和工具任务检查新版本。若参数格式、工具调用或输出质量出现变化，可以回到原版本逐项比较。

如果目标是断网工作，还要把链路查完整。语音、图片解析、搜索、登录、备份、更新等服务各有自己的地址；模型改到本地，不会自动替其他功能改变去向。需要的依赖提前准备，不需要的外部功能关闭，再以实际断网任务验证。

五、把同一套本地能力，交到现场员工手里

两台机器放在办公室，现场员工怎样用上？以测量服务团队为例：企业先准备一位“测量结果复核助手”，把已核实的检查步骤、对应版本的资料、允许读取的数据和可运行的计算工具组织好，再按岗位与任务分发给工程师。这是 MEASIX 企业自托管套件的一种应用设计，下面用它说明本地算力怎样进入日常工作。

企业统一供给模型服务和工具，员工得到的是面向任务的助手。比如现场工程师可以读取获准的测量结果、运行检查脚本；调整业务配置需要相应审批。客户资料与个人任务文件仍按访问范围管理，不能因为大家使用同一个模型，就让不同项目的材料彼此可见。

员工在设备旁打开领航 Pilot，选择这位助手，提出：“这次结果为什么与上次不一致？”已有方法帮助他先确认工件、测量时间、单位、配置和是否重新装夹，再通过衡准 Metrivon 取得对应结果。需要比较两组曲线时，脚本在工舱 Runcove 的工作空间里处理数据副本，原始输入、脚本版本与输出保留在同一任务中。手机端负责组织这些步骤与工具调用；模型推理由本地服务承接，脚本在相应工作节点执行。

这样安排，现场先能做完常规检查。若仍解释不了差异，工程师把已确认条件、做过的尝试和待判断的问题交给专家，减少从头找文件、重新转述现场的往返。设备的实时控制与安全保护继续由设备侧负责。

新检查方法先在当前任务中修正，再用已知答案的样本、不同工况与失败样例验证。专业人员确认适用范围后，才整理进新版助手发布；客户样本和专用阈值仍留在获准的项目范围。

缓存让下一轮少做重复计算，持久保存的样本、脚本和验证记录，才让下一位同事有依据地接着用。原始对话、工具日志和一次成功结果是整理依据，不能自动成为可信的共同经验。枢策 Orchelm 在套件中的位置，是组织企业共同供给的模型和受管助手；上述业务审核由企业负责，不依赖模型自行宣布方法有效。

图 7｜企业准备并按任务下发能力，员工带入现场事实；候选改法经专业验证后再发布。模型与执行节点分别承载工作，图中闭环为应用设计。

这条应用链也解释了为什么企业会关心本地算力：同一份能力交给更多员工后，多个助手会共同使用推理资源。现场问答与后台整理应分别安排优先级、排队和可用额度；后台持续任务可以按松子 Tuck 的方案组织，避免批量长资料挤占正在交互的任务。当前单任务的 128K 实测不能换算成可服务人数，仍要用实际混合负载检验。

六、验收本地部署，用三类任务就能开始

不妨从自己每周都要做的工作中各取一项，保留原始输入和合格结果。题目不必多，但要能暴露问题。

第一类是代码任务。给定一个小问题，让 Agent 找到位置、修改、运行测试并解释差异。验收看修改是否正确、测试是否真的执行、失败后能否继续；首包只反映其中一小段体验。

第二类是资料与报告。给定不同版本的资料，让它整理结论、标明依据、完成计算并导出产物。验收看版本是否用对、关键项是否遗漏、数字能否复算，以及人工最终改了多少。

第三类是交给员工的业务工具任务。请一位未参与部署、具备相应岗位基础的同事，从下发的助手开始，读取获准配置或结果，运行检查并交回产物。验收看资料和工具是否拿得到、参数是否合法、结果能否追溯；超出权限时能否停下。这样检验的才是员工真正用到的能力。

三类任务都要覆盖初次进入、围绕既有资料继续工作，以及中断后恢复。然后把一次现场短问答与一个长资料后台任务同时放进去，观察短问答是否开始排队、原任务是否需要重新读资料、失败后能否继续。问题出现在哪一段，资源就优先调整到哪一段。

当前实测覆盖短请求、32K、128K。200K、多人容量和长期稳定性需要相应任务的记录，不从现有表格往外延长一条线。

配置窗口也要这样理解：记录里的 Qwen 为 262K，DeepSeek 为 384K，说明可配置容量有差别；输入接近上限时等多久、完成得对不对，仍需要该长度的实际任务来回答。

七、双机约八万元，每月还要花多少钱

先看购机投入。本次查到的京东公开商品页中，128GB、4TB Gen4 的技嘉 ATOM 单台展示价为 39,499–39,999 元；型号明确为 ATAGB10-9001 的页面显示 39,999 元，两台按此计算是 79,998 元。4TB Gen5 的 ATAGB10-9000 样本为 43,999 元，两台为 87,998 元，不能混成同一配置的价格。

表 2｜国内公开商品页展示价（人民币）

配置样本	单台展示价	两台硬件金额
128GB / 4TB Gen4 / ATAGB10-9001	39,999 元	79,998 元
128GB / 4TB Gen5 / ATAGB10-9000	43,999 元	87,998 元

这里用 79,998 元作为双 Gen4 的硬件预算基准。商品页仍提示登录查看到手价，实际优惠、发票、运费、库存和是否附互联线，要在采购时确认。它是公开展示价测算，不是我的购入价，也不是已经取得的最终采购报价。

再看每月承担多少成本。按零残值、不计融资的简单分摊，三年使用期对应每月约 2,222 元，五年约 1,333 元。这是经营测算假设，不能据此保证机器寿命。

电费则另算。假设两台合计的平均功率取 200W、320W、480W 三档，连续开机 30 天、电价每度 0.8 元，月电费分别约为 115、184、276 元。三档都只是预算情景，实际功耗应由墙上电表读取；480W 也不是整套系统的实测功率上限。

表 3｜双机电费情景：30天×24小时，0.8元/度

双机合计平均功率	月电量	月电费
200W	144 度	约115 元
320W	230.4 度	约184 元
480W	345.6 度	约276 元

如果按双机合计 320W 的中间情景，再为维护留出每月 4 小时、每小时 200 元的人工预算，三年分摊下约 3,200 元/月；五年约 2,300 元/月。人工单价与工时都可替换成自己的数据。一次模型升级和排错若多用几小时，就可能超过整月电费，所以运维不宜默认为零。

图 8｜以双机公开展示价79,998元为基准的月成本算例。电费与人工均为明示假设，不是作者实测账单。

初次安装人工也应另填：若用 8 小时、内部人工成本按每小时 200 元估算，就是一次性 1,600 元。这只是可替换的预算假设，不是市场必需收费；互联线、备份、UPS 或许可按实际需要另列。是否要交换机取决于连接方式，双机直连不应机械加一台。已有设备则应把“继续使用的新增费用”和“重新购买的全部投入”分开。

再用同名的 Qwen3.8 Flash 官方 API 做一组费用参照。阿里云北京地域当前公开标准价为：每百万输入 token 0.8 元、输出 2.7 元，隐式缓存命中的输入 0.1 元；下文采用的输入长度处于这一计费档。云端同名服务与本地量化配置仍需另做任务质量验收。

取接近本文长输入的一次调用：计费输入 132,427 token，计费输出 2,048 token，输出包含被计费的思考与回答。无缓存时约 0.111 元；若 80%的输入 token 命中隐式缓存，约 0.037 元。这里的 80%是费用假设，与前文未明确分母的本地“热命中”不是同一个指标。

表 4｜Qwen3.8 Flash API 长输入费用情景（人民币）

月调用次数（假设）	输入无缓存命中	80%输入命中隐式缓存
1,000 次	约111 元	约37 元
10,000 次	约1,115 元	约373 元

这些是调用次数，不是整项 Agent 任务数，更不是双机吞吐承诺。一项任务若包含 10 次这样的调用，就应累计 10 次输入输出；1000 项任务便对应表中的 1 万次。实际长度会变化，应按每轮记录加总。这里仅算文本模型 token 费，检索、外部工具、存储与必要重试另计，也没有采用需另付创建费的显式缓存。

只看这组预算，低调用量时 API 费用明显低于新购双机的固定投入。若只是偶尔写代码、整理报告，又允许使用云端服务，可以先用实际账单验证需求，不急着为“每个 token 更便宜”购买设备。

如果工作需要在受控内网中持续进行，要求固定模型版本，或必须把资料和执行环境掌握在自己手里，本地设备还承担了这些要求的成本。此时应先确认哪些环节确实必须本地运行，再核算日常任务量。允许外发的工作也可以单独使用 API，但不能把敏感任务的云端回退设成未经确认的默认路径。

已有设备的继续使用，则重点看新增电费、维护工时和占用资源的机会成本；新购设备必须把完整投入算进去。两边都用同一任务检查完成质量、工具执行和人工返修，再计算合格任务成本，才有共同的比较依据。

结语：先跑完自己每天要做的工作

目前能确认的是，128K请求已在这两套配置中跑通：首次等待为数十秒，预热后的首包约一秒以内。能否稳定完成多轮Agent任务，还要让它围绕同一批代码或资料连续推进，记录工具执行、恢复与最终交付，再决定双机怎样分工。

有了真实任务的输入规模、等待时间和完成成本，才有依据决定保留多少缓存、怎样安排队列，以及是否增加设备。先把这一类任务稳定做完，再扩大使用范围。

简要说明

性能数据来自作者实测，模型名称沿用测试记录；两组为不同运行配置。使用同一套代码题、2048 token 输出口径，32K 与 128K 一冷两热，热值取第二次热请求。“热命中”沿用原记录名称，不据此推算全天表现或并发人数。

硬件规格参考 GIGABYTE 与 NVIDIA 官方资料，缓存机制参考 vLLM 文档。MEASIX 案例与架构图为应用设计。产品图片来源：GIGABYTE 官方发布资料，用于介绍设备外观与接口。

价格为 2026 年 10 月 6 日查到的公开页面展示，可能非实时；采购前请复核。京东 Gen4 商品页 · 京东 Gen5 商品页 · Qwen3.8 Flash 官方计费。

资料来源（核对日期：2026年10月6日）：

• NVIDIA：DGX Spark 节点互联
• vLLM：自动前缀缓存