在AWS Lambda调用OpenAI Whisper API遇「无效文件格式」错误

核心问题 #

本地可正常处理Opus编码的WebM音频转写，但部署到AWS Lambda后，OpenAI Whisper API返回格式错误，FFmpeg解析时提示EBML header parsing failed。已确认Lambda临时目录可用、改用内存字节流仍无效，仅Lambda环境下出现数据损坏。

排查思路与修复方案 #

1. 修正API Gateway二进制传输配置

   • API Gateway默认会对非配置的二进制媒体类型做Base64编解码，若未添加audio/webm或audio/webm;codecs=opus到二进制媒体类型列表，会导致音频数据被篡改。
   • 开启API Gateway集成请求/响应的"Passthrough"模式，避免网关自动修改请求体。

2. 校验请求体完整性

   • 在Lambda中打印接收的音频字节长度，和客户端发送的原始字节数对比，确认是否存在数据截断：

     audio_data = audio_file.read()
     print(f"Received bytes: {len(audio_data)}")
     

   • 若长度不一致，检查API Gateway的payload大小限制（默认10MB，超大音频需调整）。

3. 适配Lambda Proxy事件格式

   • 若使用LAMBDA_PROXY集成，Lambda接收的二进制数据会被Base64编码在body字段，需手动解码：

     import base64
     from io import BytesIO
     
     def lambda_handler(event, context):
         if not event.get('isBase64Encoded') or not event.get('body'):
             return {"statusCode": 400, "body": "No audio file found"}
         
         audio_data = base64.b64decode(event['body'])
         buffer = BytesIO(audio_data)
         buffer.name = "recording.webm"
         
         transcript = client.audio.transcriptions.create(
             model="whisper-1",
             file=buffer
         ).text
         
         return {"statusCode": 200, "body": {"transcription": transcript}}
     

   • 若用Flask部署（如Zappa），需调整框架请求解析逻辑，确保二进制数据不被错误处理。

4. 验证客户端发送格式

   • 确认客户端请求Content-Type为multipart/form-data，音频字段的Content-Type准确设置为audio/webm;codecs=opus。
   • 禁止客户端对音频数据做额外Base64编码，直接发送原始二进制流。

额外验证步骤 #

• 在Lambda中将接收的音频数据上传到S3，下载后用本地FFmpeg解析，确认是传输问题还是Lambda处理问题。
• 通过CloudWatch日志查看完整请求体结构，验证数据格式是否符合预期。

内容的提问来源于stack exchange，提问作者sc0urge