这两年跟企业客户聊AI落地绕不开的一个词从“GPU”变成了“Token”。以前大家开口就是“我们有多少张卡”现在开口变成了“我们每个月的Token消耗量是多少、推理延迟能不能压到500毫秒以内”。这个变化看着小背后是整个AI算力需求的拐点——企业真正在意的不是硬件峰值有多猛而是每一分算力能换成多少可用的Token、能跑通多少真实业务。再加上ODCC近期关于超节点的一系列讨论把“超节点”这个概念推到台前国产算力方案一下子成了许多技术决策者桌上最热的话题之一。这篇内容我想用这些年做企业级AI基础设施积累的经验把“国产超节点”和“企业级Token需求”这两件事彻底拆开讲透。先说清楚Token到底怎么决定算力需求再讲超节点是什么、国产方案的核心构成和组网细节然后给出一套可以直接套用的Token消耗估算方法和算力配置公式最后把私有化部署和日常运维里容易踩的坑列出来。适合正在做AI基础设施选型的技术负责人、算法工程团队以及所有被“算力焦虑”困扰又不想盲目堆卡的朋友。1. 从“拼卡数”到“算Token”企业级AI需求的真实拐点1.1 先搞清楚Token到底是什么很多人第一次接触Token是在调大模型API的时候看到账单上写着“消耗xx tokens”下意识以为这是字数统计。其实Token是模型处理文本的最小单元可以简单理解成“词的碎片”。英文通常一个单词拆成1到2个Token中文则通常一个字或一个词对应1到2个Token。你输入一段话模型把它切成Token序列再进行计算输出的时候也是一个Token一个Token往外蹦的。这就带来一个关键认知Token不只是计费单位它同时是算力消耗的基本刻度。模型每生成一个Token背后都是一次完整的前向推理计算每处理一段输入也要为这些Token做一次预填充计算。所以“Token用量”本质上就是“算力使用量”的代理指标。企业谈Token需求其实就是在谈算力需求只是比以前更接近业务本身了。我在实际项目里经常碰到这种情况客户说“我要部署一个70B的模型”但他真的需要的只是“每天处理2万次客服对话”。这两件事中间隔着很大的换算误差。搞清楚Token的概念以后你会发现算力规划完全可以变成一个精确的计算题而不是拍脑袋堆卡。1.2 企业级Token需求集中爆发的三类场景从我这几年接触的企业项目看Token需求最大、最真实的主要是三类场景第一类是智能客服与知识库问答。这类场景的特点是输入长、输出短。用户可能传一整份产品手册进来然后连续追问。这里的Token消耗大头是输入文本的预填充。单次会话动辄消耗几千Token如果企业有几千个客服坐席一天的Token消耗量轻松过千万。第二类是代码辅助生成。程序员每天调用补全和对话式编程工具每次请求的输入包含当前文件上下文、光标位置、历史对话一次请求就是几千Token。一个中型研发团队几百个工程师每天的高频使用会让Token消耗以指数级增长。热搜词里那个“cursor ai编程”就是这个方向大家感受应该都很深。第三类是营销内容和音视频脚本生成。这类场景的特点是批量调用、上下文反复拼接经常要基于同一个品牌资料库生成几十个版本的文案或分镜脚本。每个版本都要把资料库重新输入一遍Token消耗非常吓人而且这类业务往往有明显的波峰波谷对算力的弹性要求很高。1.3 算力规划从“峰值性能优先”转向“单位成本产量优先”过去企业采购算力最关注的是“这卡多少TFLOPs”“显存多少G”。现在这些参数依然重要但大家的口径变了更多会问“这张卡每秒能吐多少Token”“跑一个7B模型并发能到多少路”甚至直接问“我每月要消耗1亿Token到底要买几台服务器”。这个转变的本质是从“拼马力”变成了“算油耗”。就像买家用车峰值马力决定你偶尔飙一下能多快但日常开销真正相关的是百公里油耗。大模型推理也一样理论算力决定了峰值上限但企业每天面对的是持续、波动的Token产出需求单位算力能稳定输出多少Token才是真正影响成本和体验的指标。这种变化也解释了为什么“超节点”这种新形态开始被重视——单卡性能再强如果集群规模大了以后网络成为瓶颈、显存互相割裂单位Token成本依然降不下来。超节点的核心思路恰恰就是让大量算力单元像一个整体一样协同从而把单位Token的生产成本压低。2. 国产超节点是什么它到底“超级”在哪里2.1 超节点的本质一台逻辑上的“巨型AI计算机”先给个直白定义超节点就是把几十张、上百张乃至更多AI加速卡通过超高速互联网络组合成一个逻辑上的超级计算单元。表面看它是一个集群但在模型训练和推理的视角里它更像“一台拥有巨大显存和超高并行度的巨型AI计算机”。你可能会有疑问这不就是集群吗传统数据中心不也能搞几百张卡互联区别在于传统集群的节点之间通过网络交换机连接通信延迟高、带宽受限而超节点强调“无收敛”的高速互联卡与卡之间的通信延迟低到微秒级带宽高到可以支撑全量参数同步。用生活中的例子类比传统集群像是几间独立办公室人员跨部门沟通要经过走廊超节点则是一个大开间所有人一个转身就能直接对话。这段时间ODCC关于超节点的讨论很多行业里对超节点的标准定义还在演进中但核心方向是一致的把计算、存储、网络放到一个连续的高带宽域里减少“远程通信”带来的效率损失。这个方向对训练大模型尤其重要因为梯度同步、张量并行这些操作都极度依赖卡间通信。2.2 国产超节点的硬件底座到底长什么样国产超节点和英伟达方案的核心区别有两个一是加速卡换了二是配套的组网生态变了。先看加速卡。目前国内能规模化商用的AI加速卡主要集中在昇腾、寒武纪、海光这几家还有一些创业公司如壁仞、摩尔线程也在持续迭代。参数上大家常看的是FP8算力、显存容量和互联带宽。比如某些国产卡在FP8精度下的算力已经能做到跟主流国际产品掰手腕的水平显存也从过去的32G逐步走向64G以上。再看网络。超节点的互联不再依赖传统的以太网加交换机模式而是引入了类似NVLink的私有高速互联协议部分方案也支持RoCE或IB网络。组网时通常会采用无阻塞胖树结构或者全互联结构确保任意两张卡之间的通信带宽不打折。这里有个容易被忽略的点网络不是买几台交换机就行而是要跟加速卡的互联引擎深度适配国产方案在这方面目前更多走“全栈自研”路线把网卡、交换机、协议栈整体打包。最后是整机柜形态。超节点一般的交付形态是整柜交付包含计算节点、高速交换设备、液冷散热系统和集中管理模块。整柜交付的好处是部署速度快、功耗和散热经过整体优化。机柜功率基本在30kW以上个别高配方案能到60kW以上普通风冷机房根本压不住必须上液冷。2.3 算力组网中真正决定成败的细节很多人盯着加速卡的算力参数看却忽视了组网里三个决定实际性能的细节数据进得来吗、数据转得动吗、任务调度得了吗。先说数据进得来。企业级业务的数据来源非常杂热搜词里有“无人机无线图传的数据怎么传到算力平台上”也有“雷视融合的算力需求”这些都是端侧到中心侧的典型场景。无人机传回的图像数据要实时送入算力中心做目标检测路边雷视融合设备采集的交通数据要汇聚到中心做分析。这要求超节点方案不只是算得快还要能跟边缘数据链路打通包括流式数据接入、视频解码、数据清洗这些前置处理环节。否则算力再强数据喂不进来也是空转。再说数据转得动。进入超节点以后数据要频繁在卡与卡之间搬运。比如张量并行推理时模型的中间结果需要在多张卡之间做AllReduce上下文很长时KV Cache需要在多卡间均衡存放。如果网络有拥塞或者协议栈开销大算力再高也会被通信拖住。实测中这一步最容易出现“纸面算力很高实际吞吐只有六成”的情况。最后是任务调度。超节点不是把所有任务都塞进去跑就一定快调度器要根据模型并行策略、显存余量、卡间拓扑来排布任务。一个好的调度策略能把资源利用率拉高20%到30%这就涉及到后面要讲的软件栈了。3. 企业Token消耗怎么算一份可以直接套用的估算方法3.1 Token消耗量的基础估算公式我先给一个企业项目里最常用的估算公式月Token总量 日活跃用户数 × 人均日交互轮次 × 每轮平均Token数 × 30天。看起来简单但三个变量都要谨慎取值差一个数量级都很正常。先说人均日交互轮次。客服类场景可以按每个坐席每天处理50到100次对话来估代码场景可以按开发者每天调用100到200次补全来估内容生成场景则要按实际任务量来估。取小了后面扩容很被动取大了前期采购预算会虚高。再说每轮平均Token数。输入和输出要分开算而且要把系统提示词、历史上下文、工具调用记录都算进去。我做过一个知识库问答项目用户只输入了十几个字但请求里带的知识库检索结果加上历史对话一轮就吃掉3000多Token比想象的高出十几倍。所以估算时千万别只看用户输入的字数要看完整请求体的Token量。最后加上安全余量。我一般会在估算结果上再乘1.5倍用于容纳版本迭代、新功能上线带来的用量增长以及高峰期并发。按这个口径一个500坐席的客服团队假设每坐席每天处理80次会话、每次平均消耗4000 Token一个月就是500×80×4000×30算出来是48亿Token这个数字在大模型时代真的不夸张。3.2 从Token预算反推硬件配置估算出Token总量以后下一步是把业务需求翻译成硬件需求。核心指标是“每秒Token吞吐量”简称TPS。公式是所需TPS 月Token总量 ÷ 月有效运行秒数。一个月按30天算假设业务每天跑12小时有效秒数是30×12×3600约129万秒。上面48亿Token的场景所需TPS就是48亿÷129万约3700 Token/s。这个3700 Token/s是平均值实际还要考虑峰值系数。我一般按平均值的3倍预留峰值能力也就是需要约11000 Token/s的稳定输出能力。接下来看单卡能提供多少。以中等规模的国产加速卡跑7B模型为例实测单卡输出速度大约在1000到2000 Token/s之间如果用上FP8量化还能再高一些。11000 Token/s的峰值需求大概需要6到8张卡就能覆盖。但如果换70B模型单卡输出可能只有200到400 Token/s同样需求就要准备30张以上的卡。这就是为什么我一直强调先定Token需求再选模型规模否则很容易被模型参数带着跑偏。3.3 成本账与部署形态选型成本这一块公有云API、私有化部署、混合架构三条路各有各的账本。走公有云API最省心按Token付费一亿Token大概几千元起具体看模型档次和厂商定价优势是零运维、上线快劣势是数据要出去、长期单价高私有化部署则是一笔重资产投入一个中等规模集群硬件成本就要几百万算力中心还要算上机房、电力、制冷和运维人力热搜词里“搭建算力中心需要多少钱”这个问题我给的基准数是满足10亿级月Token的私有机房含硬件、机柜、液冷、网络和一年的运维成本保守预算在200万到500万之间。如果是混合架构核心敏感数据用私有化非敏感和弹性需求走API成本可以更灵活。我的建议是月Token消耗低于1亿直接买API最划算月Token消耗超过5亿且数据敏感私有化部署的账就算得过来了处于中间地带就用混合架构过渡。4. 国产超节点部署的实操要点与避坑指南4.1 私有化部署的六步典型流程第一步是需求确认核心是明确业务类型、模型规模、并发量和Token消耗目标。第二步是硬件选型结合预算确定加速卡数量、CPU服务器配置、交换机和存储方案。第三步是组网实施把计算节点和高速网络设备上架、布线、配置IP和路由这一步最好让有经验的网络工程师来做超节点组网和普通机房差别很大。第四步是部署推理引擎现在主流方案是vLLM、SGLang或者厂商自带的推理框架需要跟加速卡的驱动版本严格匹配。第五步是模型加载与测试用业务数据做小规模压测观察TPS、显存占用和延迟。第六步上线和监控接入监控面板记录Token吞吐、错误率和延迟指标。整个过程看起来不复杂但每一步都有细节。特别是第四步国产加速卡的软件生态还在快速迭代驱动和推理引擎的版本组合非常敏感。我之前遇到过驱动小版本升级后推理引擎直接起不来的情况只能回滚。经验是部署前先在测试环境锁定一套组合版本上线后非必要不升级。4.2 四个高频性能瓶颈与解决办法第一个瓶颈是KV Cache显存不够。并发一高KV Cache会把显存瞬间吃满导致请求报错或排队。解决办法是启用PagedAttention这类显存管理机制同时控制最大并发数和上下文长度。第二个瓶颈是算子缺失导致回退CPU。国产卡在部分复杂算子上覆盖不全某些模型结构会触发不支持的算子推理引擎回退到CPU执行速度会慢几十倍。遇到这种情况要么改模型结构里对应的算子要么升级驱动和推理引擎的算子库千万别硬抗。第三个瓶颈是并发调度策略不合理。默认配置下推理引擎的调度策略是FCFS先来先服务一个长请求会把后面所有短请求堵住。解决办法是启用Continuous Batching让引擎在token级别动态调度请求。第四个瓶颈是数据传输开销过大。输入数据如果走HTTP传输大文本或图片预处理时间可能比推理时间还长。解决办法是把数据预处理放到算力平台内部或者用二进制协议替代JSON。4.3 一个小型验证环境的搭建记录我最近在一个项目里搭了一个8卡国产加速卡的验证环境跟大家一起看看真实数据。硬件是2台4卡服务器加1台高速交换机单机配置是2颗CPU、512G内存、4张加速卡。推理引擎用的vLLM的国产芯片适配版本模型先跑了一个7B的对话模型FP8量化最大上下文长度8192。部署完成后做了三轮压测。第一轮单请求测试输出速度大约1700 Token/s这个数据对于7B模型来说是正常水平。第二轮20路并发测试整体吞吐大约8500 Token/s单路延迟升到3秒左右显存占用80%。第三轮加入长上下文请求6000 Token输入KV Cache压力明显上升最大并发只能压到12路再高就会触发显存交换。后来通过限制单请求的最大生成长度和开启PagedAttention把稳定并发拉回18路整体吞吐提升了35%。这个配置的硬件成本大约60万左右对于技术验证来说性价比很高值得作为起步参考。5. 企业Token系统与算力运维常见问题速查5.1 鉴权体系里那些“Token”问题网上搜Token一半以上结果其实是关于登录鉴权的。企业做AI平台时经常被这类问题折磨用户登录状态突然失效前端调API报“token exchange failed”后台日志显示401或403。这些报错里的Token是JWT或OAuth令牌跟大模型的Token完全两码事但运维的人如果没分清排查起来非常痛苦。最常见的三个坑一是Access Token过期时间太短用户正操作到一半就被踢下线解决思路是把过期时间调到合理范围同时加上Refresh Token自动续签机制。二是JWT签名算法或密钥不匹配前后端各用各的密钥结果签名验证永远过不了解决思路是统一密钥管理和算法配置。三是时钟偏差问题服务器时间不一致会导致Token的iat和exp判断失效解决思路是同步NTP时间服务。还有一个容易被忽略的点API网关层如果配置了国家或地区限制策略海外用户访问时可能返回“region not supported”之类的错误。这不是Token本身坏了而是网关策略拦截。排查时先看网关日志别一上来就查代码。5.2 算力资源与推理质量类问题速查表现象可能原因排查思路GPU利用率很高但输出很慢通信开销过大或数据预处理瓶颈观察卡间通信流量检查输入数据链路GPU利用率很低但请求排队KV Cache显存不足查看显存占用调整并发上限同一模型同一次请求结果不稳定采样参数或量化误差固定temperature和top_p检查量化方式长上下文场景后半段质量下降位置编码外推问题换用支持长上下文的模型或RoPE扩展推理延迟突然升高数倍算子回退CPU或触发垃圾回收查看引擎日志确认算子执行设备这张表是几个项目里反复出现的问题汇总。我的经验是遇到性能问题先分层排查从上到下依次看网络延迟、引擎配置、算子设备、显存状态不要一上来就怀疑硬件坏了很多时候都是软件配置的问题。5.3 运维避坑清单长期稳定运行的经验对于超节点这类复杂系统我总结了四条长期运维经验。第一条是监控一定要细化到算子级别只盯GPU利用率远远不够要能看到每个算子的耗时分布才能快速定位是通信瓶颈还是计算瓶颈。第二条是模型和引擎版本升级前务必做A/B对比测试直接在生产环境升级风险太大先用流量回放或者影子模式验证。第三条是备份和容灾要提前规划模型的权重文件、推理引擎配置文件、调度策略都要有版本管理一键恢复能力比事后补救重要得多。第四条是Token消耗的账单系统要自己搭一套不管用公有云API还是私有化部署都要有按部门、按项目、按场景粒度的Token计量否则成本失控的时候根本说不清钱花哪了。写到这里我把国产超节点从概念到落地这几个层面能讲的实操细节基本都过了一遍。最后说一个我自己的习惯碰到企业客户问“这个方案稳不稳”我不会上来就看跑分而是先看他们的Token账单和线上日志。跑分是给报表看的Token吞吐才是给业务看的。如果你也在调研国产超节点或者正在做企业级的算力规划建议先拿一个小型业务场景跑一个月真实负载再决定要不要上大集群。毕竟算力这个东西只有跑在自己业务上的数据才算数。