“软件开发的准则之一——每引入一个模块危险就增大两分”
大家都知道作者如今做的是基于大模型的下层运行开发，之前关键做的上班流和自己部署大模型；只管操作起来很复杂也很艰巨，但从配置开发的角度来说定制化比拟强，开发也比拟便捷。
之前在搞上班流的时刻觉得好复杂，关键期间都花在了运维下面，真正的配置开发期间并不长。
这次有个配置须要用到第三方接口，原本以为不须要自己保养大模型能够减轻很多压力，只须要关注于配置开发，应该会比拟便捷，但等到真正去做的时刻才发现想多了。
调用第三方模型服务
之前自己部署模型的时刻，一周须要花三天时间搞运维，一天时间搞开发，一天时间搞测试；如今调用第三方模型服务，原本以为会轻松一点，结果是花四天时间开发，一天时间测试，把之前运维的期间全都用在开发上了。
本以为自己脱离了苦海，结果却发现自己又进入了另一个苦海。
为什么调用第三方服务会这么艰巨？
当然调用三方服务比拟艰巨并不仅是大模型开发中所面临的，一切须要调用第三方接口的运行都挺艰巨的，须要面对各种各样的疑问。
比如，第一点文档不全；很多三方接口的文档写的那叫一个乌七八糟，甚至有些基本没有文档，只要一些便捷的代码示例；而作为调用者来说，咱们首先要测试接口通不通，而这只是最基础的一步。
在接口通了的前提下，咱们须要去测试接口不同的照应形态，比如反常照应有哪些；不反常的照应有哪些，有哪些须要留意的失误码，而后不同的失误码照应数据格局能否分歧等等。
而后依据不同的照应数据，还须要与自己的业务逻辑做兼容，不同的照应或者会对业务逻辑发生什么影响。
其次，由于大模型的配置疑问，造成其照应普通会比拟慢，因此大局部都是驳回异步或回调的模式，也就是说他人一个接口就可以搞定一个配置；而调用大模型配置至少须要两个甚至两个以上的接口才有或者实现一个配置。
这就在有形中参与了很多上班量，而这些接口又直接或直接影响到业务逻辑；这就造成开发难度增大，各种异常状况也会增多。
那为什么自己部署模型就不会有这些疑问呢？
理想上自己部署模型也会有这些疑问，只需触及到多个配置模块之间的调用都会面临这些疑问；但不同的一点是，假设全都是自己的系统，那么自己就可以想方法保障其中某些配置的稳固性，这样在解决一些业务逻辑时就不须要思考一些异常疑问和极其状况。
但由于调用的是第三方接口，而咱们无法保障第三方接口的稳固性，因此咱们就必定去兼容在第三方接口不稳固的状况下所发生的一些极其疑问。
而且更关键的一点就是，自己保养的系统可以用愈加适合的架构和模式去解决或者发生的异常状况，而经常使用第三方接口只能是咱们去兼容他人，而不能让他人兼容咱们。
这就直接造成须要少量与业务有关的代码来兼容这些疑问。
其次还有一个疑问是什么？
假设是自己的接口，接口有哪些照应你一清二楚，你就知道该怎样解决；而调用第三方接口，即使他人给了你文档，为了安保性，你还是须要把每种或者都测试一遍；而这就须要糜费少量的期间和精神。
还有一点就是，他人的接口是依照他人的业务逻辑和思绪启动解决的；只管他人给了你接口文档，并且都有说明，但某些参数的作用你或者并不是很了解，然而它或者很关键。
这时就会让你直接给你的代码埋下隐患，或者在某些状况下就会发生一些意想不到的异常状况。
总之，自己部署模型自己保养，运维压力比拟大，开发压力比拟小；而经常使用第三方模型服务，没有运维压力，但开发压力比拟大。
由于一个齐全自主可控，一个齐全无法控。
原文链接：