算力热钱撞上不良率:中小银行AI采购开始精打细算
这篇文章想说的是:一场围绕AI的采购逻辑正在中小银行体系内翻转,从“囤算力”转向“买应用”,这不是IT部门的预算调整,而是银行经营逻辑在不良率压力下的被迫理性化。过去两年我被问到最多的问题是“我们该上多少张卡”,现在这个问题变成了“什么应用能直接帮我压降不良”。这种转变是好事,但过程恐怕会碾碎不少伪需求。
说实话,去年年初还有北方某城商行朋友跟我聊,说市里给了政策,要建一个区域算力中心,规划了上百P的算力,准备采购华为昇腾和寒武纪的卡,算力规模对标省级节点。我当时问了句“你们的模型业务能消耗多少算力”,对方沉默了半分钟。后来发现这不是个案,2023年到2024年上半年,不少中小银行把AI预算的70%以上砸向了基础设施——服务器、GPU集群、机房改造。
但金融监管总局的统计数据摆在那里:2024年商业银行净息差已经压到1.52%,城商行只有1.40%。息差在缩
我的一位在苏南某上市农商行做科技部负责人的朋友,去年做了个项目复盘,情况相当尴尬。他说自己行里没有大型模型的训练需求,真正跑起来的是合同要素抽取、OCR识别、反欺诈规则引擎这些小模型推理任务。结果呢?100多台GPU服务器,实际使用率不到15%。后来发现,核心瓶颈压根不在算力,而在数据质量——柜面系统、信贷系统、风险系统之间的数据隔离是历史遗留问题,API接口的权限管控都有争议,跑大模型需要的用户行为日志和交易链路数据,80%都还躺在各业务部门自己的数据库里。
的数据隔离是历史遗留问题,API接口的权限管控都有争议,跑大模型需要的用户行为日志和交易链路数据,80%都还躺在各业务部门自己的数据库里。这批设备的投资回报率,行里讨论了几轮也没有定论。年初审计部门来查,问了一个让科技部头疼的问题:这些设备到底创造了多少可量化的业务价值?整个部门支支吾吾说不清楚。我想任何一个在银行干过的人都能体会这种处境。其实这也不全是科技部门的锅,银行采购决策天然偏向“硬资产”——因为可以折旧、可以入固定资产,说明白墙上有个机房比在服务器里跑个模型更容易过审。
应用采购潮的两个信号
但这个局面在2024年下半年开始松动。两个信号特别明显。第一个信号来自监管:国家金融监督管理总局去年发布了关于银行保险业数字化转型的年度通报,专门点名了“重建设、轻应用”的问题,要求金融机构在考核中增加核心业务场景的应用成效权重。说白了就是要看AI到底有没有帮上信贷审批和风险监测的业务价值。
第二个信号来自市场端:中小银行的AI采购开始从“百模大战”转向“拿来主义”。一个很直观的观察是,2024年各大行的年报里,“大模型”词频开始下降,取而代之的是“数字员工”“智能贷后”“知识助手”这类落到具体场景的说法。招行年报里明确指出其大模型应用聚焦于零售客户服务与风控场景,并没有刻意强调算力底座;而一些头部股份行的反应更快,兴业银行在年报中直接披露了其AI在反欺诈和贷后管理场景中的效率提升数据。大的金融机构都在调整方向,中小银行自然有样学样。
中小银行的转机:采购决策链条正在变化
更关键的变化是采购决策权在悄悄转移。以前AI立项基本都是科技部说了算,业务部门只是提个模糊需求,比如“做个智能客服”或者“搞个OCR识别”。现在不一样了。某股份制银行去年一场关于贷后管理AI应用的项目评审会上,风险管理部直接对着厂商报价单开火,问的不是能跑多大的模型参数量,而是“你这个贷后预警模型的误报率有多高”“能不能接入我们的催收工作流”“接口文档什么时候能交付”。这种场景在过去的采购流程中根本看不到。
我在调研中了解到一家中部地区的城商行,批了800万预算做“AI+贷后催收”,先理了理他们大约30%的不良贷款是有抵押物的,只是因为处置周期长、法律流程复杂,账面上看起来压力山大。他们的想法是先用AI模型自动生成标准化的催收策略、提醒函和证据链清单,把基层客户经理从繁杂的手工台账和文字工作中解放出来。这800万跟动辄上亿的算力采购比起来是小数目,但每一分钱都嵌在业务链条里,是能直接对应到成本收入比改善上面的。
从“军备竞赛”到“对症下药”的真实账本
为什么过去那套“囤算力”的打法走不通了?算一笔细账就清楚了。假设一家资产规模在3000亿左右的城商行,去年采购了十几台八卡服务器,外加网络、存储和机房改造,硬件投入大概在25
我心想,更麻烦的是算力的快速贬值。现在去二手市场看看,前两年还是香饽饽的A100服务器,转售价格已经打到了四到五折。硬件技术迭代快,一旦算力没法被有效消耗,就成了银行资产负债表上最尴尬的一块资产。我熟悉的某西部城商行,2023年购置了大量国产算力服务器用于大模型训练,结果去年发现真实业务根本消耗不了这么多算力。最后只能通过云服务商对外提供算力租赁,但银行做算力出租业务,既不符合监管导向,合规风险还高,这笔投资基本宣告失败。反正现在行里一听到“算力扩容”四个字,预算评审会先打三个问号。
的某西部城商行,2023年购置了大量国产算力服务器用于大模型训练,结果去年发现真实业务根本消耗不了这么多算力。最后只能通过云服务商对外提供算力租赁,但银行做算力出租业务,既不符合监管导向,合规风险还高,这笔投资基本宣告失败。反正现在行里一听到“算力扩容”四个字,预算评审会先打三个问号。真正的转折点来自存量不良的压力。金融资产管理公司去年发布的行业分析报告显示,中小银行2024年新增不良资产的生成速度明显快于预期,尤其在批发零售业和制造业领域。零售端虽然信用卡和消费贷额度收敛,但抵押经营贷的风险滞后效应正在逐步显现。核销力度加大,但增量风险还在冒头。这种局面下,支行行长和风险管理部最需要的是能帮他们提前识别风险、自动生成贷后检查报告、动态评估抵押物价值的工具,而不是一个不知道跑什么模型才好的算力机房。
从政策端看,央行《金融科技发展规划(2022—2025年)》里,重点任务是“数字驱动”和“智慧为民”,强调的是技术与业务的融合深度,而非硬件指标。2024年发布的《关于加强银行业保险业移动互联网应用程序管理的通知》也体现出监管对技术应用效能的关注导向。沿着这些政策信号往下走,我的判断是未来的采购清单里,算力基建的占比会持续收缩,数据治理服务、模型微调工具、业务场景落地方案才是真正的重头戏。拿贷后管理场景来说,批量处理裁判文书、自动提取抵押物司法查封信息、预警关联企业异常变更,这些能力比单纯堆算力更有现实价值。
转向之后,该迈过几道坎
但“买应用”这条路也不好走。我了解到的一个现实问题是,市面上大部分AI应用厂商对银行核心业务的理解还停留在表面——做出来的产品在演示环境里跑得顺风顺水,一旦接上真实的生产环境和业务流程就开始各种“水土不服”。核心的信贷系统改造迟迟推不动,外围应用做得再好也只是空中楼阁。
另一个实际挑战是定制化开发与标准产品之间天然的矛盾。中小银行不像大行有那么庞大的科技团队,可以自己改代码做二次开发,但每家银行的贷后流程、审批权限、合规要求又有各自的特点。只做标准化的SaaS产品,对接起来可能还是会对不上关键流程;如果每个客户都要做深度定制,厂商的交付成本不可控,最终还是要落到银行自己来买单。最终能跑通的路子,大概率会收敛到几个特定赛道,比如贷后管理、智能合规、文档自动化,厂商在这些领域沉淀出相对标准化的行业配置,再借助大模型自然语言交互来做轻量化的定制实现。
所以我的建议是,中小银行下一步搞AI,采购预算的指挥棒得交给业务风险条线来扛。凡是提报AI项目,先回答三个问题:优化了哪个KPI?涉及多少业务量?能容忍多长的试错周期?如果答不上来,这个项目就没必要立。对于买算力的需求,我的判断是更可以谨慎一些——除非你的数据规模和在线交易并发量真的到了那个体量,否则按需租用云算力就够了,自建算力中心的决策门槛在当下的经营环境下应该提高。所谓“从囤算力到买应用”,本质上是从技术迷信回归到业务实效,从考核“运行效率”转向考核“业务结果”。
这是一次姗姗来迟的理性回归。钱跟业务走,而不是钱跟技术走,才是中小银行AI采购该有的正经逻辑。
本文由「银行人实用工具箱」(deepwater84.cn)出品,专注银行从业者的效率工具与专业内容。
