制造业：边缘与断网
产线侧要求毫秒级响应且不能依赖公网，推理必须下沉到边缘设备或厂区机房。为什么难？因为工控网络隔离、设备型号杂、现场运维能力有限。可行做法是选用轻量模型与离线可运行方案，并保留人工确认与物理联锁。
金融业：双活与审计
金融系统要求高可用与灾备，算力资源需双活部署，所有调用要留痕可审计。这类场景不适合只用按需弹性资源，因为峰值时的配额无法保证。落地时应把算力纳入既有的灾备与变更管理体系，而不是另建一套，边界在灾备与审计要求。
建筑业：项目制现场
建筑项目周期短、地点分散，现场网络不稳定，大型图纸与模型文件传输成本高。算力应靠近项目部署或采用离线处理，成果再回传。边界是涉及执业签章的成果，必须由持证人员在可控环境中复核，不能依赖远端自动出结果。
互联网：弹性与成本
互联网业务峰值明显、迭代快，适合按需弹性与竞价资源，但要把冷启动、限流与降级设计好。成本敏感意味着需要持续优化批量与缓存，否则规模越大亏损越多。这一模式的优势是弹性，劣势是长期单位成本不一定最低，边界是长期单位成本。
政务国企：本地与等保
这类客户通常要求资源本地化、通过等保测评、走集中采购流程。项目周期长，但一旦建成使用稳定。准备方案时要把部署架构、数据分级与运维责任写清，并预留测评整改时间，否则容易在验收前卡住，这也是为什么要预留整改期。
适用与不适用
适合谁
- 为多行业客户交付算力方案的集成商
- 集团内负责跨行业复制的平台团队
- 需要评估自身算力需求形态的企业
不适合谁
- 认为算力方案可以完全标准化复制的团队
- 只做单点试用、不考虑运维的读者
典型场景
一家算法公司把互联网场景的弹性方案原样卖给制造客户，试点时发现厂区网络不稳定、边缘设备算力不足，推理经常超时。复盘后改为在厂区部署小模型做实时判断，复杂分析回传机房批量处理，才满足产线节拍。
可执行步骤
- 按延迟、驻留、峰值与预算四个维度逐项刻画行业需求，再选择方案
- 确认现场的网络、供电与设备条件，不能只参考中心机房的配置标准
- 把实时判断与批量分析两类负载分开设计，避免在高峰期互相挤占资源
- 把测评、灾备与签章要求提前纳入方案设计与预算，并预留整改时间
- 用同行业场景验证方案效果，并且不把跨行业的案例当作书面交付承诺
常见坑
- 把互联网弹性方案直接用于产线，网络抖动导致推理超时，直接影响产线节拍与订单交付。
- 忽略等保与本地化要求，方案在合规评审阶段被退回重做，整体工期几乎翻倍，预算超支。
- 用云端自动结果替代现场执业复核，最终成果无法签认，执业责任也无法落实，只能返工。
自检与验收清单
- 是否已逐项刻画了延迟与数据驻留的双重要求
- 现场的网络、供电与设备条件是否都已逐项核实
- 实时判断与批量分析的负载是否已经分开设计
- 合规测评与签章边界是否已在方案中逐条写明
常见问题
为什么不能做一个通用算力方案？
因为约束条件不同：产线要断网可用，金融要双活审计，项目现场网络差，政务要本地化测评。可以统一的是运维规范与成本口径，不能统一的是部署位置与资源形态。
边缘算力性能不够怎么办？
优先做模型压缩与任务拆分，把实时判断留在边缘、复杂分析回传。若仍不满足，再评估边缘设备升级。直接上大模型往往成本高，散热与供电也都成问题，运维也难。
行业差异会影响合同吗？
会。交付地点、可用性指标、数据删除方式与验收标准都应按行业调整。把互联网场景的服务等级条款直接套到产线或政务项目上，通常无法执行，验收也会卡住。