Marker项目中的Google LLM传输问题分析与解决方案

问题背景

在Marker项目（一个文档处理工具）中，开发团队遇到了一个与Google生成式AI模型交互相关的问题。当项目尝试使用Google的生成式AI服务时，在某些Windows 10系统环境下会出现进程卡死的现象。这个问题特别出现在调用Google的LLM（大型语言模型）服务时。

问题分析

经过技术团队的排查，发现问题根源在于Google生成式AI库的默认传输协议选择上。Google的genai库默认使用某种传输协议，但在特定系统环境下（特别是Windows 10），这种默认协议可能会导致连接不稳定或进程阻塞。

解决方案

技术团队发现了一个有效的临时解决方案：在配置Google AI服务时，显式指定使用REST传输协议。具体实现方式是在调用genai.configure()方法时添加transport='rest'参数。

# 修改前的代码
genai.configure(api_key=self.api_key)

# 修改后的代码
genai.configure(api_key=self.api_key, transport='rest')

这个修改强制Google AI库使用基于REST的HTTP协议进行通信，而不是默认的传输方式，从而避免了进程卡死的问题。

长期解决方案

虽然上述临时方案有效，但Marker团队正在实施更长期的解决方案：

1. 升级到Google-genai库的最新版本，该版本可能已经修复了底层传输问题
2. 考虑默认使用flash-2.0模型，该模型在测试中表现更稳定
3. 在项目配置中增加传输协议的可配置选项，提高灵活性

技术启示

这个案例展示了在使用第三方AI服务时可能遇到的底层通信问题。开发者在集成外部AI服务时应当：

1. 注意不同系统环境下的兼容性问题
2. 了解服务提供商提供的各种连接选项
3. 在配置中保留足够的灵活性以应对不同环境需求
4. 及时跟进服务提供商的SDK更新

Marker团队的处理方式体现了良好的问题解决思路：先找到临时解决方案保证功能可用，同时规划长期的技术升级路线。这种分层解决问题的方法值得其他开发团队借鉴。