1. 从 Token 焦虑到 AI 圆桌这个项目到底在解决什么问题做过游戏 UGC 内容审核或者社区运营的人大概率都经历过一种窒息感玩家上传的攻略、同人设定、剧情讨论帖每天几千上万条人工审核根本看不过来。用大模型去跑吧API 按 Token 计费一条长帖动辄几千 Token一天下来账单能让人心跳骤停。更别提有些场景需要多个模型从不同角度反复讨论、交叉验证Token 消耗直接翻倍再翻倍。我们这个项目就是在 NVIDIA DGX Spark 黑客松上做出来的东西队名“NVIDIA Developer社区说的都队”项目核心是一套跑在 DGX Spark 上的游戏 UGC 多智能体“AI 圆桌”协作系统。说白了就是把原本需要调用云端 API 才能完成的多角色内容评审流程完整地搬到本地 DGX Spark 上用 vLLM 做推理引擎让多个不同人格设定的智能体围成一桌对同一条 UGC 内容进行多角度评审、讨论、投票最终输出一个综合判定结果。这套系统适合谁参考如果你正在做社区内容治理、游戏 UGC 审核、多智能体协作流程设计或者单纯想了解怎么在 DGX Spark 这种桌面级 AI 工作站上把 vLLM 和多智能体跑通那这篇内容应该能给你不少可以直接抄的细节。我下面会把整个系统的设计思路、vLLM 部署的坑、多智能体协作的调度逻辑、以及实际跑下来遇到的问题和排查方法全部摊开讲。2. 整体架构设计为什么选 DGX Spark vLLM 多智能体2.1 核心需求拆解与方案选型逻辑先把这个项目的需求拆干净。游戏 UGC 场景下一条内容可能同时涉及违规判定、质量评估、社区氛围匹配度、创意价值这几个维度。如果用一个模型一次性输出所有维度的判断效果往往很糊——模型会顾此失彼而且你很难知道它到底在哪个维度上出了偏差。多智能体“圆桌”的思路就是把这几个维度拆开每个智能体只负责一个视角各自独立给出意见然后通过一轮或多轮讨论达成共识。这样做的好处很直接每个智能体的 prompt 可以高度聚焦输出质量更稳定讨论过程本身也是可追溯的出了问题能定位到具体哪个环节。那为什么非得用 DGX Spark 本地跑两个原因。第一是数据隐私游戏 UGC 里经常包含玩家个人信息、未公开的游戏内容走云端 API 有合规风险。第二是成本多智能体意味着同一个内容要被推理多次Token 消耗是单模型的几倍本地推理把这部分成本压到了电费级别。推理引擎选 vLLM是因为它在并发吞吐上的优势太明显了。多智能体圆桌本质上是多个请求并发跑vLLM 的 PagedAttention 和连续批处理能把 GPU 利用率拉满同样的硬件下吞吐比朴素推理高出一个量级。这一点在圆桌场景里是决定性的——如果推理引擎吞吐不够多个智能体排队等 GPU整个圆桌的响应时间会崩掉。2.2 系统分层与数据流转整个系统我分成四层来理解从下往上依次是推理层DGX Spark 上的 vLLM 服务加载主模型和 embedding 模型对外暴露 OpenAI 兼容接口。智能体层每个智能体是一个独立的角色定义 系统提示词 调用封装负责单一评审维度。协作层圆桌调度器负责把 UGC 内容分发给各智能体、收集意见、组织讨论轮次、触发投票。应用层对外提供审核结果、讨论记录、置信度评分供社区运营后台消费。数据流转是这样的一条 UGC 内容进来先经过预处理清洗、截断、关键信息提取然后由调度器同时发给圆桌上的所有智能体。每个智能体独立推理输出自己的评审意见和理由。第一轮结束后调度器把所有人的意见汇总再发给每个智能体进行第二轮“看到别人意见后的修正”。通常两轮就够了轮次太多收益递减还费 Token。最后进入投票环节按预设权重汇总输出最终判定。提示圆桌轮次不是越多越好。我们实测下来两轮讨论的判定准确率比单轮提升明显但到第三轮提升就很小了反而响应时间线性增长。建议从两轮起步根据实际效果再调。2.3 为什么不用现成的多智能体框架市面上有 AutoGen、CrewAI 这类多智能体框架我们一开始也评估过。但实际用下来发现两个问题一是这些框架的抽象层太厚调试的时候很难看清底层到底发了什么请求、Token 怎么消耗的二是它们默认的通信模式偏“对话式”而我们的圆桌场景更需要“并行独立评审 汇总讨论”的结构硬套框架反而别扭。所以最后我们选择了自己写调度逻辑只依赖 vLLM 的 OpenAI 兼容接口。这样做的好处是完全可控每个请求的 prompt、参数、返回都能打日志排查问题非常直接。代价是要自己处理并发、超时、重试这些工程细节但对于一个黑客松项目来说这部分工作量完全可接受而且换来了最大的灵活性。3. vLLM 部署实操从镜像拉取到服务稳定运行3.1 环境准备与镜像选择DGX Spark 到手之后第一件事是把基础环境理清楚。DGX Spark 用的是 ARM 架构的 Grace CPU 加 Blackwell GPU这个组合意味着很多 x86 上的现成镜像不能直接用必须选支持 ARM64 的版本。这一点在拉镜像之前一定要确认否则拉下来跑不起来白白浪费时间。vLLM 的官方镜像我们用的是vllm/vllm-openai这个 tag它自带 OpenAI 兼容的 API server启动即用。版本上建议选较新的稳定版新版本对 Blackwell 架构的支持更好PagedAttention 的显存效率也有优化。拉镜像的命令很直接docker pull vllm/vllm-openai:latest如果你需要跑 embedding 模型做 UGC 内容的语义去重或相似度检索可以额外部署一个 embedding 服务。我们用的是 Qwen3-Embedding 系列的轻量版本0.6B 参数规模在 DGX Spark 上跑起来毫无压力和主模型共享 GPU 也完全撑得住。注意ARM 架构下一定要确认镜像的 manifest 里包含 arm64。可以用docker manifest inspect先看一眼别等拉完几个 G 才发现架构不对。3.2 启动参数与显存分配计算vLLM 启动参数里最关键的几个是--model、--tensor-parallel-size、--gpu-memory-utilization、--max-model-len。这几个参数直接决定了服务能不能起来、能跑多快。先算显存。DGX Spark 的 GPU 显存是统一内存架构可用显存比较充裕但也不能无脑全占。假设我们加载一个 7B 到 14B 级别的模型FP16 精度下模型权重本身大概占 14GB 到 28GB。KV Cache 的大小取决于并发数和上下文长度公式大致是KV Cache 显存 ≈ 2 × 层数 × 注意力头数 × head_dim × 序列长度 × 并发数 × 精度字节数这个公式不用手算到精确值vLLM 启动时会自己根据--gpu-memory-utilization去分配。我们的经验是如果只跑推理服务--gpu-memory-utilization设到 0.85 到 0.9 比较稳妥留一点余量给系统和其他进程。如果还要同时跑 embedding 服务主模型这边降到 0.7 左右给 embedding 留出空间。--max-model-len要根据你的 UGC 内容长度来定。游戏 UGC 的长帖可能到几千 Token加上多智能体的系统提示词和讨论历史上下文很容易冲到 8K 以上。我们设的是 16384够用且不会因为上下文太长导致 KV Cache 爆掉。一个典型的启动命令长这样docker run --gpus all \ -v /path/to/models:/models \ -p 8000:8000 \ --ipchost \ vllm/vllm-openai:latest \ --model /models/your-model \ --served-model-name roundtable-main \ --gpu-memory-utilization 0.85 \ --max-model-len 16384 \ --tensor-parallel-size 1 \ --enable-prefix-caching--enable-prefix-caching这个参数在多智能体场景下特别有用。因为所有智能体的系统提示词是固定的prefix caching 能把这部分 KV Cache 复用起来多个智能体并发请求时能省下可观的显存和计算。实测下来开启后首 Token 延迟有明显下降。3.3 服务健康检查与接口验证服务起来之后别急着接业务先用 curl 打一下健康检查和推理接口确认服务真的可用curl http://localhost:8000/health返回 200 就说明服务活着。然后测一下推理curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: roundtable-main, messages: [{role: user, content: 你好}], max_tokens: 64 }这一步能返回正常内容说明模型加载、推理链路都没问题。如果卡住或者报错大概率是显存不够或者模型路径不对去看容器日志vLLM 的日志会明确告诉你哪一步失败了。实操心得vLLM 首次启动加载模型可能要几分钟别以为卡死了就重启。看日志里有没有出现加载进度耐心等。另外--ipchost这个参数别省多进程共享内存需要它省了容易出莫名其妙的通信错误。4. 多智能体圆桌的协作逻辑与调度实现4.1 智能体角色设计与提示词工程圆桌上放几个智能体、每个智能体是什么角色这是整个系统效果好坏的核心。我们的设计是四个固定角色加一个主持角色合规审查员只关注内容是否违反社区规则输出违规类型和严重程度。质量评估员评估内容的原创性、信息密度、表达清晰度。氛围匹配员判断内容是否符合社区调性是否有引战、阴阳怪气倾向。创意发现员识别内容中的亮点创意给出推荐权重。主持人不参与评审负责汇总意见、组织讨论、统计投票。每个角色的系统提示词要写得非常聚焦。比如合规审查员的提示词里我会明确列出违规类型清单要求它只输出 JSON 格式的判定结果不要发散。提示词越聚焦模型的输出越稳定后续解析也越省事。这里有个容易踩的坑不要让智能体在提示词里“扮演”过于复杂的角色。比如你写“你是一个有十年经验的资深社区运营专家精通心理学、社会学、法律……”模型反而会抓不住重点。我们的经验是角色描述控制在两三句话把评审维度和输出格式说清楚效果比长篇大论的人设好得多。4.2 圆桌讨论轮次的调度实现调度器的核心逻辑是一个状态机。第一轮是独立评审所有智能体并行收到 UGC 内容各自输出意见。这里用 Python 的asyncio配合aiohttp并发发请求能充分利用 vLLM 的批处理能力。import asyncio import aiohttp async def agent_review(session, agent, content): payload { model: roundtable-main, messages: [ {role: system, content: agent.system_prompt}, {role: user, content: content} ], temperature: 0.3, max_tokens: 512 } async with session.post( http://localhost:8000/v1/chat/completions, jsonpayload ) as resp: return await resp.json() async def round_one(agents, content): async with aiohttp.ClientSession() as session: tasks [agent_review(session, a, content) for a in agents] return await asyncio.gather(*tasks)第二轮是讨论修正。调度器把第一轮所有智能体的意见拼成一段“会议纪要”再发给每个智能体让它们看到别人的观点后修正自己的判断。这一轮的 prompt 里要明确要求“以下是其他评审员的意见请结合这些意见重新审视你的判断如果你改变了看法说明理由如果坚持原判也说明理由。”温度参数这里有个细节。第一轮独立评审时温度设低一点0.2 到 0.3保证判定稳定第二轮讨论时可以稍微调高到 0.5 左右让模型更愿意表达不同意见避免所有人无脑附和。这个技巧实测下来对讨论质量提升明显。4.3 投票汇总与置信度计算两轮讨论结束后进入投票。每个智能体输出一个结构化结果包含判定标签和置信度分数。汇总时不是简单多数决而是加权投票合规审查员的违规判定权重最高因为这是硬性红线质量、氛围、创意三个维度的权重相对均衡。置信度的计算我们用了两层一层是模型自己输出的置信度另一层是智能体之间的一致性。如果四个智能体里三个都说“通过”一个说“存疑”那整体置信度就比全票通过要低。最终输出的置信度是这两层的加权组合运营后台可以根据置信度高低决定是自动处理还是转人工。def aggregate_votes(agent_results, weights): score 0 total_weight 0 for result, weight in zip(agent_results, weights): score result[confidence] * weight total_weight weight base_confidence score / total_weight # 一致性系数 labels [r[label] for r in agent_results] agreement labels.count(max(set(labels), keylabels.count)) / len(labels) return base_confidence * 0.6 agreement * 0.4这个公式不是拍脑袋来的。我们试过纯加权平均发现当智能体意见分歧大时加权平均会掩盖分歧给出一个虚高的置信度。加入一致性系数后分歧大的情况置信度会被拉低更符合实际。5. 实际跑下来的问题与排查记录5.1 推理服务层面的典型故障问题一并发请求一多部分请求超时。这个在圆桌场景里很常见因为第一轮四个智能体同时发请求。排查下来是 vLLM 的--max-num-seqs默认值偏小并发一上来就排队。解决办法是适当调大这个参数同时确认--gpu-memory-utilization留够了 KV Cache 空间。如果显存紧张就调小--max-model-len给并发腾地方。问题二输出 JSON 解析失败。模型有时候会在 JSON 外面包一层 markdown 代码块或者多输出几句解释。这个不能怪模型是提示词没约束好。我们在提示词里加了“只输出 JSON不要任何其他文字”并且在解析端做了容错先用正则提取 JSON 部分再解析双保险。问题三第二轮讨论时上下文超长。四个智能体的第一轮意见拼起来可能很长加上原始 UGC 内容很容易超过--max-model-len。我们的处理是对第一轮意见做摘要压缩只保留判定结果和核心理由把冗长的论证过程砍掉。这样既省 Token 又不影响讨论质量。5.2 多智能体协作层面的坑坑一智能体互相“带偏”。第二轮讨论时如果某个智能体的意见写得特别有说服力其他智能体会集体倒向它哪怕它其实是错的。这个现象在模型规模不够大时尤其明显。缓解办法是给每个智能体的讨论 prompt 里加一句“请独立判断不要仅仅因为其他评审员意见一致就改变自己的判断”。坑二主持人汇总时丢失细节。一开始我们让主持人智能体自己去看所有意见然后汇总结果它经常漏掉某个智能体的关键理由。后来改成程序化汇总主持人只负责生成一段总结性文字真正的判定和置信度计算由代码完成。这样既保留了可读性又保证了准确性。坑三Token 消耗比预期高。虽然本地推理不花钱但 Token 消耗直接影响响应时间。我们统计下来一条中等长度的 UGC 内容跑完整圆桌流程总 Token 消耗在 8000 到 15000 之间。优化手段包括prefix caching 复用系统提示词、第一轮意见摘要压缩、限制每个智能体的输出长度。5.3 常见问题速查表现象可能原因排查方向解决手段服务启动卡住模型路径错误或显存不足看容器日志加载进度检查路径调低 gpu-memory-utilization并发请求超时max-num-seqs 太小观察请求排队情况调大并发数或降低 max-model-lenJSON 解析失败提示词约束不够检查模型原始输出强化格式约束解析端加容错讨论轮次上下文超长意见未压缩统计 Token 数对第一轮意见做摘要智能体意见趋同讨论 prompt 引导不足检查第二轮 prompt加入独立判断的明确要求响应时间波动大GPU 被其他进程占用查看 GPU 利用率隔离推理服务避免混跑实操心得多智能体系统调试时一定要把每个智能体的原始输入输出完整打日志。我们一开始图省事只打最终结果出了问题根本不知道是哪个环节歪的。后来加了全链路日志排查效率提升了一个档次。6. 这套系统还能怎么扩展跑通基础版本之后我们试了几个扩展方向有些效果不错有些还在摸索。扩展一动态圆桌规模。不是所有 UGC 都需要四个智能体全上。简单的内容可以只跑合规审查员加质量评估员两个角色复杂内容再拉满。这样能根据内容复杂度动态分配算力整体吞吐能提升不少。扩展二embedding 做历史一致性检查。用 Qwen3-Embedding 把历史审核过的内容向量化存起来新内容进来先做相似度检索如果和历史某条高度相似直接把历史判定结果作为参考喂给智能体。这个对重复内容、洗稿内容的识别特别有效。扩展三智能体记忆。让每个智能体维护一个短期记忆记住最近处理过的几条内容及其判定这样在讨论时能引用“类似内容之前是怎么判的”提升判定的一致性。这个方向我们还在实验主要难点是记忆的存储和检索效率。扩展四接入更多模型。vLLM 支持同时 serve 多个模型理论上可以让不同智能体用不同模型比如合规审查用更严谨的模型创意发现用更发散的模型。这个对显存要求更高DGX Spark 上需要仔细规划资源分配。我个人在实际操作中的体会是多智能体系统的价值不在于智能体数量多而在于每个智能体的职责是否清晰、协作机制是否合理。四个职责明确的智能体效果远好于八个职责模糊的智能体。另外本地推理虽然省了 API 费用但调试和优化的时间成本不低如果只是小规模试用云端 API 可能更省事但一旦规模上来或者有数据隐私要求DGX Spark 加 vLLM 这套组合的性价比就体现出来了。最后分享一个小技巧圆桌讨论的轮次和智能体数量建议做成配置项而不是写死在代码里。我们在黑客松现场就靠这个快速调整参数根据评委的反馈实时切换不同的圆桌配置演示效果灵活很多。