1. 从“Token 焦虑”说起这个项目到底在解决什么问题做过大模型应用的人大概都经历过一种很具体的焦虑不是模型不够聪明而是Token 烧得太快。尤其是当你把多个智能体Agent凑在一起让它们互相讨论、互相评审、互相补充的时候Token 消耗几乎是线性甚至指数级往上翻的。一个“AI 圆桌”系统如果设计得稍微奔放一点几轮对话下来账单能让你怀疑人生。这个项目的出发点就非常实在用 NVIDIA DGX Spark 这台桌面级 AI 超算搭一套游戏 UGC用户生成内容场景下的多智能体“AI 圆桌”协作系统同时把 Token 消耗压到可控范围内。关键词很明确——NVIDIA DGX Spark、多智能体、AI 圆桌、Token、vLLM。它不是一个纯学术 demo而是一个面向真实创作场景的工程化尝试游戏 UGC 内容比如关卡设计、剧情文案、角色设定、平衡性数值往往需要多角色视角的反复打磨而多智能体协作恰好能模拟“策划、美术、程序、玩家”坐在一起开圆桌会议的过程。适合谁来参考三类人最值得看一是手里有 DGX Spark 或类似本地算力设备、想跑多智能体应用的开发者二是做游戏 UGC 工具链、想引入 AI 协作能力的产品同学三是被 Token 成本折磨过、想搞清楚“怎么让多智能体既聪明又省钱”的技术负责人。下面我会把整套系统的设计思路、核心细节、实操过程和踩坑经验完整拆开讲尽量让你看完就能照着复现。2. 整体架构设计为什么是“圆桌”而不是“流水线”2.1 多智能体协作的两种范式对比多智能体系统常见的组织方式有两种流水线式Pipeline和圆桌式Roundtable。流水线式就是 A 做完交给 BB 做完交给 C像工厂传送带圆桌式则是多个智能体围绕同一个议题各自发表意见然后由主持人或投票机制收敛结论。在游戏 UGC 场景里我实测下来圆桌式更合适。原因很简单UGC 内容的质量往往不是“一步到位”的而是需要多视角碰撞。比如设计一个新关卡策划关心节奏美术关心视觉辨识度程序关心实现成本玩家关心好不好玩——这些视角如果串行处理后面的角色只能看到前面角色的结论很难提出真正有价值的反驳。而圆桌式允许它们看到彼此的发言产生真正的“讨论”。但圆桌式的代价就是 Token 爆炸。假设 5 个智能体每人发言 500 Token一轮就是 2500 Token讨论 5 轮就是 12500 Token再加上每轮都要把历史上下文重新喂进去实际消耗可能是这个数字的 3 到 5 倍。这就是“Token 焦虑”的来源。2.2 用 DGX Spark vLLM 把推理成本打下来解决 Token 焦虑有两条路一是减少 Token 用量二是降低单位 Token 成本。这个项目两条路都走了。降低单位成本靠的是 NVIDIA DGX Spark 加 vLLM。DGX Spark 是一台桌面级的 AI 计算设备搭载了高带宽统一内存能在本地流畅跑起中等规模的大模型。而 vLLM 是目前本地部署里吞吐表现最稳的推理框架之一它的PagedAttention机制能把 KV Cache 管理得像操作系统的虚拟内存一样高效显存利用率比朴素实现高出一大截。同样的硬件vLLM 能支撑的并发请求数和吞吐量明显更好这对多智能体这种“多个请求同时打进来”的场景特别关键。减少用量则靠架构设计核心是三招上下文裁剪、发言摘要化、轮次收敛。后面会详细讲。2.3 系统分层从硬件到应用整套系统我分成四层来理解这样排查问题的时候能快速定位是哪一层出了状况层级组成职责硬件层DGX Spark提供本地算力与统一内存推理层vLLM模型加载、批处理、KV Cache 管理编排层多智能体调度器角色管理、轮次控制、上下文裁剪应用层游戏 UGC 圆桌议题输入、讨论、结论输出这个分层的好处是每一层都可以独立替换。比如你以后想换推理框架只动推理层就行想换协作策略只动编排层。工程上最怕的就是所有逻辑糊在一起改一个地方崩三个地方。3. 核心细节解析多智能体“圆桌”的关键设计3.1 角色设定不是越多越好新手最容易犯的错就是觉得智能体越多越热闹。我一开始也这么想搞了 8 个角色结果 Token 直接起飞而且讨论质量反而下降——因为角色太多每个角色的发言都变得很浅最后收敛出来的结论还不如 3 个角色认真讨论。实测下来4 到 5 个角色是比较舒服的区间。以游戏 UGC 为例我常用的配置是策划Designer负责玩法、节奏、目标感美术Artist负责视觉风格、辨识度、氛围程序Engineer负责实现成本、性能、可行性玩家代表Player负责“好不好玩”“愿不愿意分享”主持人Moderator负责控场、收敛、总结主持人这个角色很关键它不参与具体创作只负责在每轮结束时把大家的观点压缩成摘要并判断是否达成共识。没有主持人讨论很容易发散或者陷入循环。3.2 上下文裁剪Token 省钱的第一大杀器多智能体最烧 Token 的地方就是每一轮都要把完整历史重新喂给每个角色。假设 5 个角色、5 轮讨论每个角色每轮都要读一遍全部历史Token 消耗是 O(n²) 级别的。我的做法是分层上下文全局摘要由主持人维护只保留每轮讨论的结论性内容控制在 200 Token 以内最近一轮全文保留上一轮所有角色的完整发言让当前角色能接上话角色私有记忆每个角色自己维护一份“我关心什么”的简短笔记不超过 100 Token这样每个角色每轮实际读到的上下文从“全部历史”压缩到“摘要 上一轮 私有记忆”Token 用量能降 60% 到 70%而讨论质量几乎不受影响。因为真正重要的信息已经被摘要提炼出来了冗余的寒暄和重复表达被砍掉了。3.3 发言摘要化让主持人干“压缩”的活主持人的摘要不是简单截断而是有明确指令的。我给主持人的系统提示词大概是这个意思你是圆桌主持人。每轮讨论结束后你需要把本轮所有发言压缩成不超过 150 字的摘要只保留达成的共识、存在的分歧、待解决的问题。不要复述具体措辞不要加入你自己的观点。这个指令的关键在于“只保留三类信息”。如果不加限制模型很容易把摘要写成流水账反而更费 Token。加了限制之后摘要质量稳定很多。3.4 轮次收敛什么时候该停多智能体讨论最怕“停不下来”。我设了三个停止条件满足任意一个就结束主持人判定达成共识主持人输出一个特殊标记表示可以收敛达到最大轮次默认 5 轮超过就强制收敛连续两轮无新增分歧如果两轮讨论下来没有新的分歧点说明已经讨论充分了这三个条件里第三个最实用。很多时候讨论到第三轮大家观点已经趋同再讨论就是重复。加上这个条件后平均轮次从 5 轮降到 3.2 轮Token 又省了一大截。4. 实操过程从零把系统跑起来4.1 环境准备与 vLLM 部署先说硬件和基础环境。DGX Spark 到手之后第一件事是确认驱动和 CUDA 版本。vLLM 对 CUDA 版本比较敏感我建议用较新的稳定版本避免踩到算子不兼容的坑。装 vLLM 最省心的方式是建一个独立的 Python 虚拟环境然后用 pip 安装python -m venv vllm-env source vllm-env/bin/activate pip install vllm装完之后启动推理服务。我用的模型是中等规模的开源模型参数量控制在 DGX Spark 能流畅跑起来的范围内。启动命令大概是这样vllm serve /path/to/your/model \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --max-num-seqs 16这里有几个参数值得说明。--max-model-len控制单次请求的最大上下文长度设太大浪费显存设太小多智能体的上下文放不下8192 是我实测下来比较平衡的值。--gpu-memory-utilization控制显存占用比例0.85 留了一点余量给系统。--max-num-seqs控制并发序列数多智能体场景下多个请求会同时打进来这个值设大一点能提升吞吐但太大也会增加显存压力。注意vLLM 启动时会预分配显存如果启动失败提示显存不足优先调低--gpu-memory-utilization和--max-model-len而不是急着换更小的模型。4.2 多智能体调度器的实现调度器是整个系统的“大脑”我用 Python 写核心是一个圆桌类。它的主要职责是管理角色、控制轮次、裁剪上下文、调用推理接口、收集发言、触发收敛。调用推理接口的部分用 OpenAI 兼容的客户端就行因为 vLLM 默认提供 OpenAI 兼容的 APIfrom openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) def ask_agent(system_prompt, context, user_input): response client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: system_prompt}, {role: user, content: context \n\n user_input} ], temperature0.7, max_tokens500 ) return response.choices[0].message.contentmax_tokens这里设 500是给单个角色的发言长度设上限。不设上限的话有的角色会滔滔不绝Token 直接失控。500 字对于一轮发言来说足够了逼着模型把话说精炼。4.3 一轮完整讨论的流程我把一轮讨论拆成四个步骤这样逻辑清晰也方便调试主持人开场主持人把本轮议题和上一轮摘要整理成一段引导语发给所有角色角色依次发言每个角色拿到“全局摘要 上一轮全文 自己的私有记忆”发表本轮观点主持人摘要主持人读完本轮所有发言输出压缩摘要收敛判断主持人判断是否达成共识或者调度器判断是否触发停止条件这个流程里第二步是 Token 消耗的大头也是优化的重点。我实测过如果不做上下文裁剪5 个角色 5 轮讨论大概要烧掉 4 万多 Token做了裁剪之后同样的讨论降到 1.2 万 Token 左右降幅接近 70%。4.4 游戏 UGC 场景的实战案例举个具体例子。我让这套系统讨论一个 UGC 关卡设计“设计一个以‘时间倒流’为核心机制的解谜关卡面向休闲玩家单局时长控制在 5 分钟以内。”第一轮策划提出“倒流次数有限用完了就失败”美术提出“倒流时画面要有明显的回溯特效”程序提出“倒流需要记录状态快照内存开销要控制”玩家代表提出“倒流太频繁会让人晕要有节奏感”。主持人摘要后第二轮大家围绕“倒流次数到底设几次”展开讨论最后收敛到“3 次且每次倒流后场景有细微变化作为提示”。整个过程 3 轮结束Token 消耗约 8000。如果不用这套架构同样的讨论质量大概要 2.5 万 Token 以上。这就是“告别 Token 焦虑”的实际含义——不是不花钱而是把钱花在刀刃上。5. 常见问题与排查技巧实录5.1 推理服务相关的问题问题一vLLM 启动报显存不足。这是最常见的。排查顺序是先看--max-model-len是不是设太大了再看--gpu-memory-utilization是不是超过 0.9 了最后才考虑模型是不是真的太大。我遇到过好几次其实只是max-model-len设了 32768调回 8192 就正常了。问题二并发请求时响应变慢。多智能体场景下如果角色是串行发言其实并发压力不大但如果你想加速让角色并行发言就会同时打进来多个请求。这时候--max-num-seqs设太小会导致请求排队。我的经验是设成角色数量的 2 到 3 倍比较稳。问题三输出内容重复或卡住。这通常是temperature设太低或者max_tokens设太小导致的。多智能体讨论需要一定的多样性temperature我一般设 0.7 左右。如果某个角色总是重复上一轮的话可以在它的系统提示词里加一句“不要重复你之前的观点除非你有新的论据”。5.2 多智能体协作相关的问题问题四讨论发散收不回来。这是主持人的锅。主持人的提示词里必须明确“你的职责是收敛不是发散”。我一开始没强调这点主持人自己也跟着讨论起来了结果越聊越远。后来加了“你只负责总结和判断不发表新观点”情况就好多了。问题五角色之间观点趋同讨论没价值。这说明角色设定不够差异化。解决办法是在每个角色的系统提示词里强化它的“立场”。比如程序角色要明确“你优先考虑实现成本和性能对不切实际的想法要直接指出”玩家角色要明确“你只关心好不好玩不关心技术实现”。立场越鲜明讨论越有张力。问题六Token 消耗还是偏高。检查三个地方一是上下文裁剪有没有真正生效二是max_tokens是不是设太大了三是轮次收敛条件是不是太宽松。我见过有人把max_tokens设成 2000一个角色一轮就烧 2000 Token5 个角色 5 轮就是 5 万这谁顶得住。5.3 常见问题速查表现象可能原因排查方向服务启动失败显存不足调低 max-model-len 和 gpu-memory-utilization响应变慢并发排队调大 max-num-seqs输出重复temperature 过低调到 0.7 左右讨论发散主持人职责不清强化主持人提示词观点趋同角色差异化不足强化各角色立场Token 偏高上下文未裁剪检查摘要和裁剪逻辑5.4 几条踩坑心得第一不要迷信“角色越多越好”。我试过 8 个角色Token 翻倍质量反而下降。4 到 5 个是甜点区。第二摘要质量决定系统上限。主持人摘要如果写得烂后面所有轮次都会基于烂摘要讨论越讨论越偏。宁可多花点 Token 让主持人好好摘要也不要在这省。第三先跑通再优化。我一开始就想着把 Token 优化到极致结果架构搞得太复杂调试了两天才跑通。后来退回去先用最朴素的方式跑通再逐步加裁剪和收敛反而快很多。第四日志一定要打全。每个角色的输入上下文、输出内容、Token 消耗都要记下来。不然出了问题你根本不知道是哪一轮、哪个角色、哪段上下文导致的。我现在的日志会记录每一轮的完整上下文和 Token 数排查问题效率高很多。6. 后续可以怎么扩展这套系统跑通之后能扩展的方向其实不少。比如把单机多智能体扩展成多机协作用多台 DGX Spark 分担不同角色的推理比如引入多模态能力让美术角色能直接生成概念图而不只是文字描述再比如把圆桌结论直接对接游戏引擎的 UGC 工具链实现“讨论完就能生成可玩关卡”。我个人最看好的扩展方向是角色记忆的持久化。现在每个角色的私有记忆是单次会话内的如果能把跨会话的记忆存下来让角色记住“上次我们讨论过什么”“用户偏好什么风格”那讨论质量还能再上一个台阶。这个用向量数据库加简单的检索就能实现成本不高但效果提升明显。最后分享一个小技巧如果你觉得讨论质量不稳定可以先让系统“空跑”几轮——也就是不给具体议题只让角色们互相认识、明确各自立场。等角色之间的“人设”稳定了再进入正式议题讨论质量会明显更稳。这个技巧是我调试了十几次之后才总结出来的看起来有点玄学但实测有效。
