“软件开发的原则之一——每引入一个模块风险就增大两分”
大家都知道作者现在做的是基于大模型的上层应用开发，之前主要做的工作流和自己部署大模型；虽然操作起来很复杂也很困难，但从功能开发的角度来说定制化比较强，开发也比较简单。
之前在搞工作流的时候感觉好复杂，主要时间都花在了运维上面，真正的功能开发时间并不长。
这次有个功能需要用到第三方接口，本来以为不需要自己维护大模型能够减轻很多压力，只需要关注于功能开发，应该会比较简单，但等到真正去做的时候才发现想多了。
调用第三方模型服务
之前自己部署模型的时候，一周需要花三天时间搞运维，一天时间搞开发，一天时间搞测试；现在调用第三方模型服务，本来以为会轻松一点，结果是花四天时间开发，一天时间测试，把之前运维的时间全都用在开发上了。
本以为自己脱离了苦海，结果却发现自己又进入了另一个苦海。
为什么调用第三方服务会这么困难？
当然调用三方服务比较困难并不只是大模型开发中所面临的，所有需要调用第三方接口的应用都挺困难的，需要面对各种各样的问题。
比如，第一点文档不全；很多三方接口的文档写的那叫一个乱七八糟，甚至有些根本没有文档，只有一些简单的代码示例；而作为调用者来说，我们首先要测试接口通不通，而这只是最基础的一步。
在接口通了的前提下，我们需要去测试接口不同的响应状态，比如正常响应有哪些；不正常的响应有哪些，有哪些需要注意的错误码，然后不同的错误码响应数据格式是否一致等等。
然后根据不同的响应数据，还需要与自己的业务逻辑做兼容，不同的响应可能会对业务逻辑产生什么影响。
其次，由于大模型的功能问题，导致其响应一般会比较慢，因此大部分都是采用异步或回调的方式，也就是说别人一个接口就可以搞定一个功能；而调用大模型功能至少需要两个甚至两个以上的接口才有可能完成一个功能。
这就在无形中增加了很多工作量，而这些接口又直接或间接影响到业务逻辑；这就导致开发难度增大，各种意外情况也会增多。
那为什么自己部署模型就不会有这些问题呢？
事实上自己部署模型也会有这些问题，只要涉及到多个功能模块之间的调用都会面临这些问题；但不同的一点是，如果全都是自己的系统，那么自己就可以想办法保证其中某些功能的稳定性，这样在处理一些业务逻辑时就不需要考虑一些异常问题和极端情况。
但由于调用的是第三方接口，而我们无法保证第三方接口的稳定性，因此我们就必须去兼容在第三方接口不稳定的情况下所产生的一些极端问题。
而且更重要的一点就是，自己维护的系统可以用更加合适的架构和方式去处理可能出现的异常情况，而使用第三方接口只能是我们去兼容别人，而不能让别人兼容我们。
这就直接导致需要大量与业务无关的代码来兼容这些问题。
其次还有一个问题是什么？
如果是自己的接口，接口有哪些响应你一清二楚，你就知道该怎么处理；而调用第三方接口，即使别人给了你文档，为了安全性，你还是需要把每种可能都测试一遍；而这就需要浪费大量的时间和精力。
还有一点就是，别人的接口是按照别人的业务逻辑和思路进行处理的；虽然别人给了你接口文档，并且都有说明，但某些参数的作用你可能并不是很了解，但是它可能很重要。
这时就会让你间接给你的代码埋下隐患，可能在某些情况下就会出现一些意想不到的意外情况。
总之，自己部署模型自己维护，运维压力比较大，开发压力比较小；而使用第三方模型服务，没有运维压力，但开发压力比较大。
因为一个完全自主可控，一个完全不可控。
原文链接：