① 量化现状
采集 CPU、内存、磁盘队列、阵列状态与网络质量，先确认瓶颈在哪，不凭感觉归因。
工程案例
五类典型场景的配置思路与交付记录：行业、规模、配置、效果逐项列出，不含客户名称与合同信息。
关于本页内容：案例按业务场景整理，已做脱敏处理——不标注客户名称、联系人与合同金额，配置与效果数据来自我方交付记录的范围归纳。我们不在官网上使用未经客户授权的企业名称与 Logo。
Case Studies
五类场景，五种配置取向
每个案例都能独立看：先讲清客户被什么卡住，再给出配置与理由，最后是实测效果和复盘结论。
AI 算力
4 卡推理服务器：单机承载 32 路视频结构化分析
客户原本按调用量租用云端 GPU 做视频结构化推理，月账单随路数线性上涨。我们按 32 路 1080P、每路 8-10 FPS 抽帧的实际算力需求，配了一台 4 卡 4U 推理服务器，把推理任务整体迁回本地机房，同时保留云端作为突发流量的溢出通道。
- 月度算力支出
- 一次性投入后转为固定折旧，32 路规模下 11-14 个月回本
- 单机承载路数
- 稳定运行 32 路 1080P，抽帧 8-10 FPS；扩到 40 路时显存占用约 86%
7 台老旧物理机整合到 3 节点 ESXi 集群
客户的 ERP、OA、文件共享、监控回放、域控等 7 个业务跑在 7 台服役 6-9 年的物理机上，分散在车间配电房和办公楼两个位置。我们按实际资源占用重新核算，用 3 个节点组成 ESXi 集群承载全部业务，同时把车间机房撤掉，运维从「7 台各管各的」变成「1 个控制台」。
- 机房数量
- 1 个（办公楼机房），车间机房撤除
- 单点故障影响
- 任一节点故障，虚拟机自动重启，中断以分钟计
监控路数翻倍后，存储按 90 天留存重算：96TB 起步
客户把园区监控从 120 路扩到 260 路，原有存储的实际留存天数从 60 天掉到 22 天，不满足园区管理规定。我们从码率与留存天数反推容量，选 24 盘位机型配 RAID 6，按 90 天留存一次规划到位，并保留 4 个空盘位用于后续扩容。
- 实际留存天数
- 约 96 天，满足 90 天规定并留有余量
- 容错能力
- RAID 6，容 2 块盘同时故障
ERP 数据库服务器：内存优先，而不是 CPU 优先
客户反映 ERP 每月月底结账要跑 6 小时，白天多人同时查询时页面要转圈十几秒。原服务器是 8 核 32GB 的入门机型，客户准备换一台「CPU 更强」的机器。我们做了 3 天性能采样，发现 CPU 平均利用率仅 19%，但内存长期占用 96%、磁盘队列长度持续偏高，真正的瓶颈是内存不足导致的换页。最终以内存翻 4 倍、换 SSD 阵列的方式解决，结账时间降到 40 分钟。
- 月底结账耗时
- 约 40 分钟
- 白天查询响应
- 2 秒以内
8 台设计工作站：渲染提速靠显卡，稳定性靠电源与散热
客户有 8 个设计工位，日常跑 SolidWorks 大装配（单文件 8000+ 零件）和 KeyShot 渲染。原设备是普通商用台式机加游戏显卡，打开大装配要等 5 分钟，渲染一张图要 40 分钟。我们按「建模吃单核与显存、渲染吃显卡算力」的差异分工，配了统一平台的工作站，建模打开时间降到 40 秒，单图渲染降到 6 分钟。
- 大装配打开时间
- 约 40 秒
- 单图渲染耗时
- 约 6 分钟
How We Deliver
每个案例背后的同一套流程
场景不同，流程一致：先量化问题，再定配置，最后用实测数据验收。
② 出两套方案
同一需求至少给两种配置取向，逐项列出差异与取舍，由客户按业务重要性决定。
③ 整机压测
交付前完成 72 小时稳定性测试与真实负载验证，把问题留在我们这边而不是客户现场。
④ 分批割接
核心业务单独窗口，旧设备保留可回退期，确认稳定后再下架。