采纳答案成功!
向帮助你的同学说点啥吧!感谢那些助人为乐的人
老师,在我的实际开发中使用 base64编码后传递给 kimi-k2.5 模型后,我们的服务器会提示 413请求体过大,这种情况应该怎么优化上下文管理呢?
413这个错误是你的服务器报的错么?可以看下你服务器的反向代理配置,看下是不是对请求体内容做了相应的限制;如果413是kimi的服务器返回的错误,就说明传递的内容超过kimi的限制,这个能优化的空间就比较少了(减少上传内容的数量等)。
是我们的 Python 后端接口报的 413 错误,但是他们不调配置,只能在我们的 java 后端调用他们的接口前去优化上下文,目前我是遍历 messages 数据,如果发现超过 limit 了就从第一条消息开始移除。。。老师那里有什么更好的方法来管理这个上下文吗?
413这个和便利messages数据长度关系影响不大,最主要的原因是在发起post请求的时候,你们将图片/文件的base64附加到message中了,导致请求体超过了反向代理能配置的大小,所以报错了; 还有另外一种策略,使用kimi的图片/文件上传功能,单独上传好文件之后,会得到文件id,然后在/chat/completions接口中直接使用文件id,这样就可以避开你们服务器的限制。 参考文档:https://platform.moonshot.cn/docs/api/files#%E4%B8%8A%E4%BC%A0%E6%96%87%E4%BB%B6
回复 泽辉呀:老师,对于多模态的模型,比如支持上传视频,图片的模型,不应该把 base64 格式的数据放到 message 里吗?
登录后可查看更多问答,登录/注册
MCP+A2A 从0到1构建商业级多Agent全栈应用
66 7
223 5
152 5
69 4
261 4
购课补贴联系客服咨询优惠详情
慕课网APP您的移动学习伙伴
扫描二维码关注慕课网微信公众号