去年有个开发者想解决一个排班问题,点进行业标杆的官网,定价页上只有一个按钮:「联系销售」。没有价格。没有套餐。什么都没有。

这种体验你熟悉吗?

打开网易新闻 查看精彩图片

他最后发现,这个叫Gurobi的工具年费1万到5万美金,而且许可证绑定特定机器——想在容器里自动扩容?门儿没有。于是他花了几个月,搭了一个9美元月费的API替代方案。

这件事的核心矛盾很有意思:一个几十年前就成熟的技术,为什么用起来像在购买企业级ERP?

线性规划到底是什么?

先快速过一下概念。线性规划(Linear Programming,线性规划)听起来很学术,其实很直白:在给定限制条件下,找出最优解。

你想最大化某个东西——利润、效率、产出——同时受制于预算、时间、人力、原材料。求解器算出数学上的最优答案。

混合整数规划(Mixed-Integer Programming,混合整数规划)是升级版:部分变量必须是整数。你不能生产3.7把椅子,只能是3把或4把。

这些问题的应用场景遍地都是:

• 制造业:工厂本周该生产哪些产品,才能在人力物料有限时利润最大?
• 物流:50辆卡车跑200个站点,最省钱的路线怎么排?
• 排班:30个护士分配到3个班次、7天,既要合规又要照顾个人偏好,怎么安排?
• 金融:20种资产怎么配置,收益最大同时风险可控?

数学理论早就成熟。但商业求解器的定价模式,似乎还停留在大型机时代。

那1万美金到底买了什么?

Gurobi是行业金标准,速度确实快。但问题在于购买体验。

一位用户在论坛吐槽:「最好的混合整数规划求解器(CPLEX、GUROBI、FICO)都贵得离谱,除非你是学术机构。」

另一位说:「Gurobi确实快,但许可证根本搞不定。」

还有人说得更直接:「我就烦那种定价页上什么都没有的。」

挖到的具体数字:Gurobi年费1万到5万美元,看配置;IBM CPLEX单用户起步价3420美元/年。

这些工具的设计对象是财富500强的物流部门,不是给SaaS应用开发排班功能的程序员。

许可证模式雪上加霜。Gurobi的许可绑定特定机器。一位Hacker News用户描述,他们公司「在eBay买了4台旧的24核至强」,就为了避开额外的许可证席位费用。

另一位点出了与现代基础设施的根本冲突:「没法让Gurobi在自动扩容的容器里跑,这最终让我们放弃了。」

云原生时代,你的基础设施可以秒级伸缩,但核心工具却要求你数物理CPU核心、填采购申请、等销售回邮件。

开源求解器 vs 商业包装

开发者没有从零写求解器——那确实不明智。他选了HiGHS,一个已在生产环境验证的开源LP/MIP求解器,包装成托管API。

调用方式:一个HTTP请求。没有许可证文件。没有销售电话。不用数座位。

月费9美元。

这个对比很刺眼。不是9美元 vs 1万美元的技术差距,是商业模式的差距。

商业求解器卖的是「企业级支持」+「性能保证」+「合规背书」。但对于一个需要嵌入产品功能的开发者来说,这些重资产反而是负担。

开源求解器的性能差距在缩小。HiGHS在标准测试集上的表现已经相当能打。对于大多数SaaS场景——排班、路径优化、资源分配——它够用了。

真正的创新在于交付形态:把求解器变成基础设施,而不是资产采购。

谁在重新定义这个品类?

这件事的趋势很明显:基础设施的「民主化」正在吃掉企业软件的溢价。

数据库领域发生过同样的故事。Oracle和SQL Server曾经是企业标配,现在PostgreSQL和云托管服务(RDS、Cloud SQL)承担了90%的场景。剩下的10%才需要专门采购。

机器学习也在走这条路。训练GPT-4级别的模型需要千万级投入,但调用API只需要几美分。

优化求解器可能是下一个。当开源方案的性能达到「足够好」,而云原生交付大幅降低使用门槛,传统厂商的定价权就会被侵蚀。

但这里有个开放问题:性能敏感的场景怎么办?

航空公司的航班调度、芯片厂的排产优化、高频交易的实时风控——这些场景下,求解速度快10%可能意味着数百万美元的差异。Gurobi和CPLEX的技术积累和工程优化,短期内难以被开源方案替代。

市场可能会分层:高端客户继续为极致性能付费,中长尾场景被云原生API收割。

这对传统厂商是威胁,也是机会。如果他们能推出灵活的、按量计费的云版本,而不是坚持机器绑定+年度合同,或许能守住更多阵地。

为什么这件事值得跟踪?

这个案例的价值不在技术本身,而在产品形态的洞察。

开发者识别了一个被忽视的细分市场:需要嵌入优化功能、但付不起企业级定价、也不想管理基础设施的SaaS团队。然后用最小可行产品(Minimum Viable Product,最小可行产品)验证需求。

9美元的定价是信号,不是终点。它测试的是「有没有人为这种便利性付费」,而不是「求解器值多少钱」。

如果验证成功,路径很清晰:按调用量阶梯定价、增加企业级SLA、扩展求解器类型(二次规划、随机规划)。本质上是在重建一个云原生的优化求解器品类。

更大的图景是:企业软件的「消费化」趋势在加速。买家从CIO变成个体开发者,决策周期从季度变成分钟,交付形态从安装包变成API端点。

每个传统品类都在被重新做一遍。这次是运筹优化,下次可能是仿真建模、有限元分析、或者别的什么「只有大企业才用得起」的工具。

如果你在做B2B产品,这个案例值得放进你的参考库:怎么找到被高价方案忽视的细分场景,怎么用现代基础设施重构交付体验,怎么用激进定价验证需求。

最后一个问题留给你:你所在的行业里,有没有那种「联系销售才能看价格」的工具?如果有,9美元的替代方案会是什么形态?