上周有个做工业设计的朋友问我他们团队想把三维设计工作搬上云让我给个能落地的方案。我没急着回先反问了一句你们现在最难受的是算力不够还是协作太慢他愣了几秒说两个都难受。但真要说痛点是周五下午客户临时要改一个装配体的配色全组只有一台机器打得开那个文件而那台机器的主人那天正好请假了。这个场景太典型了。三维设计上云这件事被讨论得很多但大部分讨论都停在“把工作站搬到云端”这个层面好像只要有一块远程显卡、一个远程桌面问题就解决了。真做过项目的人会知道GPU算力池解决的是“算力怎么分”的问题云端协作解决的是“人和资产怎么对得上”的问题这两件事的技术栈、推进节奏、踩坑点完全不一样。把它们揉成一个项目推进通常会死在中途。这篇文章我想把这两条线拆开讲清楚算力池怎么建、池化粒度怎么选、三维设计软件搬上云有哪几条路线、像素流的画质和延迟怎么调、协作层的版本与权限怎么设计、最后是从小试点推到全员时真实的成本和坑。面向的是正在做技术选型的团队负责人、IT 支撑人员以及想搞清楚原理的一线设计师。不需要你是运维专家但看完之后你应该能自己画出一张适合自己团队的架构草图。1. 本地工作站模式卡在哪三个地方在谈怎么上云之前得先把“不上云为什么难受”讲透。很多人一上来就比硬件参数、比云主机价格其实方向偏了。本地工作站的问题从来不是“性能不行”而是性能和需求之间的匹配方式太粗糙。1.1 按峰值采购按平均值闲置做过硬件采购的都懂这个逻辑你买工作站不是按日常使用强度买是按“最坏情况”买。一个做内外饰设计的团队平时大多数时间在改单个零件、做曲面细节八核处理器、中端专业图形卡、16GB 显存完全够用。但一年里有那么几次要打开一个上万零件级别的整车装配体做干涉检查这时候 32GB 内存都不一定够显存分分钟爆掉加载时间从三十秒变成八分钟。采购决策一旦按这 5% 的峰值场景做剩下 95% 的时间就是闲置。更麻烦的是这种闲置没法转移——A 同事的机器空着B 同事打开大装配体还是会卡因为闲置的是别人的机器。硬件是绑在工位上的算力也是。我们粗算过一笔账一台配置中等偏上的图形工作站采购价四万五左右按五年折旧每年九千加上电费整机功耗按 500W 算每天开机八小时、一年 250 个工作日就是 1000 度电八百块上下再加上机房或工位的空调分摊、五年内的硬件维护和一次显卡升级摊到每年大约一万二。这还只是一台。二十人的团队就是二十四万一年而这二十四万里可能有七成的时间在跑轻负载。云上的账不是这么算的。云端按时计费理论上你只为实际使用的那部分付费。但这里有个反直觉的结论我后面第 6 章会详细算如果团队里的人都是满负荷八小时在线云端反而更贵真正省钱的是利用率低、波动大的团队。所以“上云一定省钱”这个判断是错的得看你的使用曲线。1.2 资产散在个人硬盘里版本靠文件名维系第二个问题更隐蔽也更致命。三维设计的资产不是单个文件是一个引用网络装配体引用零件零件引用草图草图挂着外部参照材质球指向贴图目录工程图关联模型。这一整套东西天然要求路径稳定。本地模式下的现实是什么模型放在个人机器的 D 盘某个文件夹里改完压缩成 zip 发到群里另一头解压出来打开贴图丢了外部参照找不到提示“无法解析文件路径”。于是开始互相传贴图、传字体、传材质库传到最后谁也不知道手上这一版是不是最新的。命名方式也很朴素外壳_v3_final_final_改.fbx。这不是谁不专业是二进制模型文件根本没法做文本 diff。你没法像看代码一样看两个版本差在哪只能靠“谁改的、什么时候改的、改了什么”这种口头或聊天记录里的信息。人一多这套体系立刻崩。1.3 评审回环太长从“改一版”到“看到改后效果”隔了一整个下午第三个问题出在协作节奏上。设计师改完一版要给别人看通常的流程是截图或者导出一段环绕动画或者干脆渲染几张效果图发到群里等反馈。客户或结构工程师提出意见再改再截图。这个回环里最耗时的不是改是“等看到”。渲染一张高质量效果图中等场景几分钟到几十分钟不等导出一段十秒的环绕动画可能就是一小时。如果评审方想看的是“把这个外壳换成哑光深灰、把这个倒角改小两毫米”他其实只需要看到实时预览但为了拿到这个实时预览整个管线要跑一遍离线渲染。这就引出一个很重要的判断三维设计上云最大的价值不在于把显卡搬到远端而在于把“看”这件事的成本降到接近零。当任何人打开浏览器就能用完整算力实时转模型、实时换材质、实时标批注的时候评审回环从“半天”压缩到“几分钟”这才是工作流真正被重构的地方。2. GPU 算力池不是“一堆显卡插在机架上”那么简单搞清楚痛点就可以谈算力池了。我见过不少方案把“算力池”理解成买一批带显卡的服务器装个虚拟化平台完事。这么做的结果通常是资源是集中了但分配不出去或者分配出去之后性能表现和本地差一大截。2.1 三种池化粒度决定了你能服务多少种人从资源分配的角度GPU 池化大致分三个层次它们的取舍完全不同池化方式典型实现思路图形兼容性隔离性适合的负载整卡直通一台虚拟机独占一张物理卡完整驱动原生行为强大装配、仿真、离线渲染硬件切分单卡切成若干固定实例各自持有独立显存需要专业图形卡支持图形实例强显存独立不互相挤占中小模型建模、轻量预览时间片复用多台虚拟机共享一张卡轮流使用依赖虚拟化层能力重图形负载容易降级弱会互相影响办公、二维制图、轻量查看这张表最需要盯的是“图形兼容性”这一列。三维设计软件重度依赖图形接口而且要的不是“能跑”是“跑得对”——抗锯齿正常、线框显示正常、实时预览不掉帧、某些高级着色效果可用。时间片复用在通用计算场景下很成熟但放到重图形负载上经常出现一种情况单看跑分正常一打开复杂场景就掉到十几帧而且找不到原因。所以我的建议很直接面向设计师的算力优先整卡直通或硬件切分时间片复用只放在非关键岗位。硬件切分还有个细节值得说。切分出来的实例显存是独立的这意味着一个实例显存用爆了不会把同卡的其他实例拖垮这个隔离性对多人共用场景非常关键。但代价是灵活性差——切分比例是固定的你切了四个 1/4 实例就没法临时合并成两个 1/2 给大装配使用。除非你的虚拟化层支持动态重组否则规划切分比例的时候要按“长期平均需求”来别按峰值。2.2 先搞清楚你的三维负载到底吃什么选规格之前必须做负载画像。三维设计是个笼统说法里面差别巨大负载类型GPU 瓶颈点显存需求CPU 偏好交互性要求零件与曲面建模中低主要看图形驱动质量4-8GB单核主频敏感很高大装配加载与干涉检查高几何计算叠加显存带宽16-24GB 起多核并行明显中实时渲染与材质预览很高12-24GB中等很高离线渲染与光线追踪很高且持续满载依场景可超 24GB高无仿真与拓扑优化高且持续中等但吃带宽很高低注意第一行和第三行的区别。零件建模对单核主频极其敏感——很多建模软件的核心几何内核是单线程的你给它 64 核也没用它就在那儿用一核跑。这时候配一台核多但主频低的机器交互手感反而比本地老旧工作站差。这个坑我在第 6 章会展开是试点阶段最容易翻车的地方。而离线渲染是另一个极端它对交互完全没要求可以排队、可以抢占、可以用便宜得多的算力。这两类负载放在同一个池子里用同一套调度策略就是浪费。合理的做法是交互型节点和批处理型节点分开建池批处理池允许抢占、允许跨地域、允许用低优先级实例成本能压下来一大截。2.3 一份可以直接照着配的分层方案基于上面两张表我给出一个中等规模团队20-40 人可以参考的分层规格。参数是我实际项目里比较常见的配比具体数值要按你们的场景实测调整节点类型GPU 规格档位显存CPU内存单人会话数数量占比轻量查看节点入门专业图形卡8GB4-8 核16GB2-420%标准建模节点中端专业图形卡16GB8 核高主频32GB1-245%大装配节点高端专业图形卡24-48GB16 核64-128GB120%渲染批处理节点高端或消费级高显存卡24GB16-32 核64GB独占排队调度10%仿真节点高带宽计算卡按需32 核以上128GB独占5%这里有个经验比例标准建模节点的数量按“同时在线的设计师人数 × 0.6”估算不要按人头 1:1 配。因为设计师不是全程都在高强度建模有大量时间在开会、看资料、等反馈。早期我按 1:1 配结果监控显示峰值并发从来上不去 70%白白浪费。反过来大装配节点按 0.15 到 0.2 配就够了因为这类重负载访问是脉冲式的且可以排队。另外提醒一句虚拟化软件本身有开销。整机直通的开销可以忽略但切分实例和虚拟网络会吃掉一部分性能实测下来图形负载的衰减在 3% 到 8% 之间这个要在容量规划里预留出来别把资源算得太满。3. 把三维软件搬上云的三条技术路线算力池是地基但用户摸到的是“怎么用”。把三维设计软件搬到云上业内主要有三条路线它们解决的不是同一个问题很多团队一开始就选错了。3.1 像素流路线本质是把显示器拉长这条路线的原理很好理解应用还是原封不动地跑在云端那台带显卡的机器上本地什么都不需要装云端把渲染完成的画面编码成视频流推下来客户端的鼠标键盘操作实时回传上去。用户看到的是一个“超长显示器”——显示器在云端屏幕和鼠标在你手上。它的最大优势是零改造。所有插件、所有本地脚本、所有自定义工具栏全都能用因为是同一个软件、同一个环境。设计师的肌肉记忆也不用重建。对已经有一套成熟工作流的团队来说这是迁移成本最低的方式。代价有三个方面。第一是延迟所有交互都要绕一圈网络这个后面第 4 章细讲。第二是并发成本每多一个活跃会话就要多一份编码资源编码器是有并发会话上限的这个上限经常成为瓶颈。第三是体验一致性网络抖一下画面就糊一下这种体验劣化很难通过参数完全消除。3.2 应用容器化路线交付的是“环境”不是“画面”这条路线的思路是把三维软件和它的依赖运行时库、插件、授权配置、首选项打包成一个可复现的镜像按需拉起。用户接进去的还是应用本身但后端不再是一台长期开着的虚拟机而是一个随用随起、用完销毁的实例。它解决的是“环境漂移”问题。本地模式下每个人的机器装的东西都不一样同一个模型在两个人机器上打开效果不同排查起来极其痛苦。容器化之后环境是声明式的出问题可以重建也可以回滚到上一个镜像版本。对需要严格质量控制的团队这个价值比省算力更大。难点在于图形支持和授权管理。图形接口在容器里跑需要虚拟化层或设备插件做透传有些软件会检测运行环境行为不稳定浮动授权在实例频繁启停的场景下容易出现授权没正常释放、名额被占的情况。这些问题都有解法但需要提前验证不能等到上线才发现。3.3 Web 原生引擎路线不是搬过去是重新做一遍第三条路线跟前两条完全不同不是把桌面软件搬到云上而是在浏览器里跑一套 Web 原生的三维引擎把模型和数据加载进去重新实现查看、标注、审阅这些能力。这条路线的性能天花板最高因为可以针对场景做极致优化——只加载需要的 LOD 层级、用渐进式传输、用实例化渲染批量画重复零件。它也可以做到真正的多人实时同步因为渲染和数据在一套体系里。但它有个硬约束它只能覆盖“看”和“评”覆盖不了“改”。真正的建模、曲面设计、参数化修改还是得回到专业软件。所以我的看法是这条路线不该被当成桌面软件的替代品它是协作层的基础设施。用它来做评审、做方案汇报、做跨部门看图、做客户确认效果远好于截图。第 5 章会展开讲。3.4 混合编排把不同诉求的人分到不同路线真做项目几乎没人只用一条路线。我们一般这样组合角色主要诉求推荐路线理由核心建模设计师完整功能、手感、插件像素流整卡零改造手感最接近本地结构/工艺工程师看图、测量、加批注Web 原生无需安装打开即用外部供应商阶段性查看、按需提意见Web 原生 权限隔离不给他们客户端风险可控渲染与效果图大批量出图批处理池排队成本最低可抢占管理层与客户方案确认Web 原生全景移动端也能看这套组合的原则很清晰高频、深度、需要完整功能的操作放像素流低频、浅层、只需要看的操作放 Web 端。按这个原则分你会发现需要高配算力的人其实没那么多算力池的规模能压下来不少。4. 画质、延迟、带宽像素流调优的实操细节三条路线里最容易出问题、也最考验功力的是像素流。它的调优不是玄学把每个环节的耗时拆开看就知道该往哪儿使劲。4.1 编码参数怎么定先定场景再定码率参数没有万能值得按场景分档。下面这张表是我在项目里用下来比较稳的一组起点值可以直接抄再按实测微调使用场景分辨率帧率编码格式目标码率色度采样精细建模操作1920×108060低延迟 H.26412-18 Mbps4:2:0大装配审阅2560×144030-60H.26525-40 Mbps优先 4:2:2色彩与材质评审1920×108030H.265 或新一代编码30 Mbps 以上4:4:4移动端或弱网1280×72030低延迟 H.2644-6 Mbps4:2:0几个关键选择的理由帧率优先于分辨率。三维操作的手感对帧率极其敏感30 帧和 60 帧的主观差异远大于 1080p 和 1440p。弱网环境下我的第一反应永远是降分辨率保帧率而不是反过来。编码格式选低延迟模式别开会话级优化。直播场景里常用的那些提升压缩率的技巧比如多帧参考、B 帧在交互场景里是灾难因为它们引入了额外的缓冲。交互编码必须关掉 B 帧、缩短 GOP、开启低延迟模式压缩率会损失 15% 到 25%这个是必须付的代价。编码器并发上限是个硬墙。消费级和专业级显卡的硬件编码器同时支持的编码会话数是有限的超出之后要么排队要么回落到软件编码后者会直接把 CPU 打满。我们踩过一次二十个人同时在线第十一个人开始画面明显卡顿查了很久才定位到这里。规划并发数的时候一定要把这个上限写进容量表。4.2 延迟拆解手感变差到底是哪一段的锅用户抱怨“卡”这个“卡”可能是六个环节里任何一个造成的。我习惯把它拆成一张表来定位环节典型耗时优化手段应用渲染一帧8-16 ms关闭垂直同步、适当降采样、减少实时阴影帧缓冲捕获2-5 ms用显卡内零拷贝捕获别走内存回读硬件编码3-8 ms低延迟预设、关 B 帧、固定量化参数网络传输5-60 ms就近接入、专线或优质公网链路客户端解码显示2-6 ms客户端硬解、关闭后处理输入端采集与回传5-40 ms提高输入采样频率、开启预测把这张表连起来看同城网络下总延迟能压到 25-40 毫秒这个区间设计师基本感知不到用起来和本地差不太多。跨地域的话光传输本身的物理延迟就摆在那儿一千里以上单程就是十几毫秒起总延迟很难低于 60 毫秒超过 80 毫秒拖拽模型的时候会有明显的“粘手”感。这里有个容易被忽略的细节输入回传延迟往往比画面延迟更影响手感。因为人眼对画面延迟有一定容忍度但对“鼠标动了画面没动”极其敏感。优化输入端收益比优化渲染端大。具体做法包括提高客户端的鼠标采样上报频率、在协议层开启输入预测、避免输入事件走低优先级队列。这几条改动加起来实测能把手感打分提高一档。4.3 设计场景特有的画质坑细线、色阶和材质通用视频流的画质优化经验直接搬到三维设计上会出问题因为设计场景的视觉特征和影视内容完全不同。第一是细线。三维设计里到处都是 1 像素宽的边线、轮廓线、尺寸标注。这些高频细节在 4:2:0 色度采样下会被严重破坏线框模式下尤其明显细线会闪烁、断裂、发虚。解决方案是尽量提高编码质量降低量化参数或者在评审场景切到 4:2:2 甚至 4:4:4。代价是码率上升 30% 到 50%但这钱该花。第二是渐变色阶。曲面模型上大面积的柔和渐变在压缩后容易出现色带。这个在材质评审里会误导判断——明明是平滑过渡的曲面看着像有台阶。缓解办法是开启编码器的去色带滤波或者接受稍高码率。第三是抗锯齿与压缩的叠加失真。应用端做的抗锯齿边缘本来就很细腻编码一压边缘会出现蠕动。我们的做法是在云端把抗锯齿质量调高一档宁可多花一点渲染时间让编码前的画面更干净压缩后反而更稳。还有一个必须提醒的点色彩管理要端到端打通。设计师的显示器做过校准加载了色彩配置文件这个配置文件在云端实例里必须同样存在并生效客户端显示器也要正确识别。我们遇到过一次“模型在云端看着偏绿导出的图是正常的”排查了半天最后发现是客户端没加载显示器的色彩配置只影响观感不影响数据。这种问题不影响交付物但会让人对系统失去信任很难解释清楚一定要在上线前统一校准。5. 协作层版本、权限、评审比算力更难算力池建好技术上跑通了接下来才是真正的硬骨头。我个人的判断是一个三维设计上云项目技术部分的难度占三成协作流程和习惯改造占七成。因为技术问题是确定的协作问题是博弈的。5.1 二进制资产的版本策略锁、分支、快照各有代价三维模型是二进制这一点决定了它没法沿用代码那套“分支 合并”的思路。你不能把两个版本的模型自动合并中间那些几何拓扑的冲突是没法自动解决的。所以行业里通行的做法是独占锁谁要改先签出签出期间别人只能只读。这个方案简单但会制造等待。所以我们做了两点改造一是把锁的粒度做细。不锁整个项目只锁具体的零件或子装配。一个整车的装配体不同人改不同的子系统互不干扰。实现上靠资产目录的层级划分配合锁服务锁的键用资产唯一标识而不是文件路径这样重命名和移动不会导致锁失效。二是给“看”开绿灯。只读访问永远不需要锁允许任何人随时打开最新版本查看。配合 Web 端的轻量查看器可以让评审方在设计师改的同时就看到进展不用等签入完成。另外还有一层快照机制不能省每次签入自动打一个不可变快照保留完整引用关系包括当时用的贴图、材质、外部参照打上时间戳和操作人。这样任何时候都能回到某一天的状态也不会因为贴图被覆盖而还原不出来。快照存储用冷存储就行访问频率低成本可以压得很低。5.2 权限要按“零件”而不是按“人”设计早期我们的做法是按人分组设计组、工艺组、供应商。很快就不够用了。因为同一个项目里有的零件对供应商公开有的绝对不行同一个供应商这个项目能看那个项目不能看。后来改成按资产标签授权。每个资产在入库时打标签项目、密级、可外发范围。权限规则挂在标签上人在哪个组只决定他能看到哪些标签。这套做法的好处是可扩展——新来一个供应商给他打上“项目 A 可外发”的标签组合就行不用改任何规则。还有两个细节值得注意。一是下发的数据要脱敏对外发的模型能在下发前自动剥掉内部的结构树命名、去掉未发布的变体、简化内部细节这些都可以在导出管线里自动化。二是水印与追溯Web 端查看时叠加不可见的用户标识水印一旦出现外流能定位到人。这一条与其说是技术措施不如说是心理约束实际效果比想象中好。5.3 把批注钉在三维坐标上而不是截图上评审闭环这件事我觉得是被低估最严重的环节。传统的做法是截图 红圈 文字描述“这里倒角改大一点”。问题是“这里”到底是哪儿模型一转视角谁也说不清。可行的做法是在 Web 查看器里做三维锚点批注点击模型表面的某个位置记录下这个点的世界坐标、所在的面 ID、当时的相机视角然后挂一条评论。别人打开的时候点击这条评论视角自动飞到那个位置锚点高亮显示。这解决了“沟通指代”的问题把一轮评审里来回确认的时间省掉一大半。再往前推一步把批注和任务系统连起来每条批注可以指派给人、设定截止时间、标记状态待处理、已修改、已确认。设计师在云端改完直接在同一个批注下回复并附上新版本的对比视图评审方点开就能看到前后差异。这条链路打通之后一个设计变更的完整轨迹是可查的事后追责或者复盘都有据可依。6. 从一个小试点走到全员上云理念讲完讲落地的部分。这一章我尽量把真实的排期、成本和踩过的坑写清楚因为大部分人卡在这里。6.1 试点选人比选型更重要很多团队试点阶段喜欢找“最能折腾的人”觉得技术强的人能帮你把问题都试出来。我的经验正相反试点阶段应该选“最愿意反馈、脾气最好、且工作内容有代表性”的人。技术强的人往往有一套自己的优化习惯遇到问题会自己绕过去你就收不到真实反馈脾气急的人遇到延迟波动两天就撂挑子项目直接失去内部支持。理想的第一批试点是三到五个人一个做标准建模的、一个做大装配的、一个做渲染的、再加一个跨地域协作的对接人。跑两周收集的问题清单基本就覆盖了八成。试点期一定要设一个明确的“成功判据”别用“大家觉得还行”这种模糊标准。我们的判据是三条日常建模操作的主观流畅度评分不低于本地的 80%大装配打开时间不超过本地的 1.5 倍每周因为环境问题导致的工作中断不超过一次。三条都过才进入扩大范围。6.2 踩坑实录几个印象最深的排查链路坑一配置拉满的云主机打开模型反而比本地慢三倍。现象很反直觉云上那台机器核心数是本地的四倍显卡也更新但打开同一个装配体就是慢。排查链路是这样的先看加载过程的资源曲线发现 CPU 总体利用率只有 8%其中一核跑满其余全在睡觉——这直接指向单线程瓶颈说明几何内核在单核上跑。再看单核主频云上那台是低频多核的型号单核睿频比本地那台老工作站还低。结论是规格选错了加钱堆核心反而更慢。修复方案是把标准建模节点换成高主频、核心数适中的规格核心数从 32 降到 8单核性能提升 30% 以上加载时间立刻回到本地水平成本还降了。这个坑的教训是三维设计选型的第一指标是单核性能不是总核数采购清单上那一栏“vCPU 总数”会骗人。坑二第十一个人上线之后所有人都开始卡。现象是前十个会话一切正常第十一个开始全员掉帧。排查思路是先排除网络和存储这两项监控都平稳然后看 GPU 的编码器占用发现到一个点之后直接跳满同时 CPU 上出现了软件编码进程。定位到硬件编码器有并发会话数上限超限之后系统自动回落到软件编码把 CPU 打满进而影响所有会话的渲染。解法有两个层面短期是在调度层加并发上限超过上限的请求排队并提示长期是增加编码节点把并发分散到多台机器上。这也说明一件事容量规划不能只看 GPU 计算资源编码资源要单独算一遍。坑三模型颜色看着不对导出却没问题。这个前面提过排查过程很有意思先怀疑编码色度采样改成 4:4:4 之后有改善但没根治再查客户端的显示配置发现客户端系统没有加载显示器的色彩配置文件导致所有内容都偏色只是别的软件不明显三维模型的大面积纯色把它放大了。修复是把客户端的显示配置文件统一纳管登录时自动下发并校验。这类问题不上报错误、不产生日志全靠人眼发现最容易被拖成“大家都说不清楚但就是感觉不对”的长期怨气。坑四贴图集体丢失而且只在新机器上丢。现象是新拉起的实例打开老项目贴图全部显示为默认材质。查引用路径发现模型里记的是绝对路径指向原来那台工作站的盘符。这是历史遗留问题——早期建模时直接拖拽贴图进场景软件记的就是绝对路径。修复要分两步短期写一个批处理脚本扫描所有资产把绝对路径重写为相对路径并统一工程目录结构长期是在入库环节做校验绝对路径直接拒绝入库。这个改造花了我们不少时间但做完之后跨环境打开模型的成功率从六成提到接近百分之百。坑五浮动授权莫名被占满。容器化实例频繁启停之后浮动授权池经常显示“已用满但没人在用”。原因是实例被强制回收时客户端没来得及向授权服务发起释放请求服务端要等超时才回收这个超时通常十几分钟。高峰期这个时间差会让新会话拿不到授权。解法是在实例生命周期钩子里加一步优雅关闭先通知应用退出等授权释放确认再销毁实例同时把授权服务的超时时间调短。另外在调度层加一个“授权可用数”作为调度约束没有可用授权就不分配实例避免用户连上去之后卡在授权等待界面。6.3 成本账什么情况下上云真的省钱最后算钱。这块最容易被供应商的 PPT 带偏我用一组具体的数来推。本地模式前面算过一台中等偏上的工作站摊到每年约一万二含折旧、电费、维护。这是“不管用不用钱都花了”。云端模式一台同等规格的实例按时计费大概每小时六到十元取中间值八元。存储另算热数据用块存储1TB 每月一两百元冷数据用对象存储1TB 每月几十元。现在分两种团队看满负荷型设计师每天在线八小时、每月二十二天那就是 176 小时每月一千四百元每年一万七。加上存储比本地贵四成左右。波动型设计师实际高强度使用每天四小时其余时间在开会、看资料、沟通每月 88 小时每月七百元每年八千四。加存储一万出头和本地持平甚至略低。但真正的差距不在单价在闲置转移。本地模式下二十个人配二十台机器峰值也就三五个人同时在跑重负载剩下十五台的算力浪费掉。云端模式下二十个人配八台标准节点加两台大装配节点资源可以在人之间流动总容量需求直接降到一半。这一项算下来整体成本能降三到四成这才是上云省钱的真正来源。反过来如果你的团队是清一色的满负荷、全天候高强度使用而且都在同一个地点、网络条件很好那本地模式依然是更经济的选择。这种情况下上云的价值主要在协作和弹性不在省钱——这一点最好提前跟管理层说清楚别用“省钱”做立项理由后面账对不上会很被动。还有一个隐藏成本要提迁移期是双份开销。本地机器不能立刻退役云端同时在付费这个重叠期通常两到三个月。预算里必须留出这块否则中途会因为“怎么比原来还贵”而被叫停。7. 我个人的几条经验判断做了几个这类项目之后有几条判断我越来越确信写出来供参考。不要追求“全量上云”。最稳的形态永远是混合核心重负载上云享受弹性日常轻量操作留本地避免网络依赖协作层用 Web 端拉平所有人的访问门槛。追求 100% 上云的方案最后往往因为某个必须联网才能干的活卡住整个团队。先把资产管线理顺再谈算力。我见过太多团队算力池建得漂漂亮亮结果一上线发现模型引用全是绝对路径、材质库版本混乱用户打开就报错最后归因于“云不行”。实际上这些问题在本地也存在只是被“每个人机器上恰好都有那份文件”掩盖了。上云是一次强制性的资产治理趁这个机会把目录规范、命名规范、引用规范一次做干净收益比算力本身大得多。给设计师留一条“逃生通道”。不管系统多稳总会有网络抽风或者调度出问题的时候。留一台本地机器或者留一个能快速切回本地的模式让设计师在最坏情况下还能干活。这不只是技术冗余更是心理安全感——知道有退路的人才愿意认真用新系统。监控要盯“体验指标”不是“资源指标”。GPU 利用率、内存占用这些是给运维看的对判断系统好不好用没帮助。真正该盯的是每个会话的端到端延迟、帧率分布、编码回落次数、会话建立耗时。这几个指标一恶化用户马上就会有感知比任何资源告警都灵敏。最后一个观察三维设计上云这件事技术方案在同质化真正拉开差距的是对设计流程的理解。你得知道设计师什么时候在等、等的是什么、哪些等待是可以被消除的、哪些等待其实是思考时间不该被打断。把这些搞清楚了再回头看算力池和协作工具取舍就变得很自然——哪些该花钱、哪些可以省、哪些必须自己写一目了然。