做語音轉錄的開發者，過去總被一道割裂感困擾:聊天走OpenRouter，轉寫卻要再搭一個Whisper服務器，或者額外接一家專門做語音轉文本的第三方SDK。7月22日，OpenRouter把這道裂痕抹平了——它在自家平臺上線了POST /api/v1/audio/transcriptions端點，用戶用與Chat Completions完全相同的Bearer密鑰，把base64編碼的音頻發過去，就能拿回一份含轉錄文本和用量對象的JSON。聊天和轉寫，從此共用一張門票。

這份便利的核心是複用。你不需要新的SDK，也不需要單獨的服務，因爲轉錄功能和聊天流量跑在同一個平臺上，由多個提供商託管的模型會自動在彼此之間做負載均衡，而不是被焊死在某一家供應商身上。對已經把OpenRouter當主力的團隊，這套集成意味着少維護一條鏈路、少記一把密鑰。

image.png

模型層面，OpenRouter擺出了兩條路線。一類是openai/whisper-1這樣的Whisper類模型，按音頻時長也就是每秒計費;另一類是更新的語音轉文本（STT）模型，按token計費。需要留意的是，STT模型的ID不會出現在默認的/api/v1/models目錄裏，因爲它屬於需要主動篩選的輸出模態——通過?output_modalities=transcription參數，就能把這批模型及其當前定價篩出來。想在接入前先試手，OpenRouter Playground裏也能直接在瀏覽器內上傳文件轉錄。

調用方式簡單到一次請求就閉環。把文件base64編碼，和模型、格式一起POST過去，再從響應裏讀text和usage兩個字段即可。data字段吃的是原始base64字節，不是data: URI，所以別給它加data:audio/mp3;base64，前綴;format字段必填，告訴上游模型怎麼解碼這些字節。如果你早就有面向OpenAI的/v1/audio/transcriptions寫的客戶端，只需把base URL指向https://openrouter.ai/api/v1就能直接用，零改動遷移。端點也接受OpenAI風格的multipart/form-data上傳，文件加模型，大小上限25MB。

字段規範上，model和input_audio.data、input_audio.format是必填項，格式可選wav、mp3、flac、m4a、ogg、webm、aac之一;language是ISO-639-1語言代碼，省略則由模型自動檢測;temperature控制採樣，取值0到1;response_format默認json，設成verbose_json就能額外拿到任務、語言、時長和片段時間戳，配合timestamp_granularities選word還能拿到詞級時間戳，不過這兩項只在兼容OpenAI的提供商如OpenAI、Groq、Together上有效，其餘提供商會直接返回400。provider塊則用來透傳各家的私有參數，比如Groq可以通過provider.options.groq.prompt傳入預期詞彙，幫模型正確處理專有名詞，免得把術語唸錯。

響應是一份JSON，text字符串裝着轉錄結果，usage對象則讓費用可以按請求計量而非靠估算。一個示例裏，9.2秒的音頻產生了113個token、83個輸入與30個輸出，標註成本0.000508美元——這個數字來自文檔示例並非實際報價，真實花費取決於所選模型和音頻時長。響應頭裏還帶一個X-Generation-Id，方便你記錄追蹤或調試某次具體請求。

路由邏輯沿用聊天的同一套。當一個轉錄模型由多個提供商託管，OpenRouter會按價格做負載均衡，把請求分發到各家之間，避免被單一供應商綁定。不過目前轉錄端點還沒開放按請求的路由控制，聊天調用裏熟悉的order、only、allow_fallbacks、data_collection、sort這些字段，在這裏都不生效，provider塊只攜帶提供商特定選項。OpenRouter明確不對提供商定價加價，目錄價就是你的實付價，而零補全保險意味着失敗的轉寫不會被計費;如果你手裏有自己的提供商協議，BYOK功能允許用自有密鑰路由，只付平臺費、免掉按量模型成本，且按量付費模式下每月前100萬次請求的平臺費直接免除。

真正動手搭建前，有四個約束必須算進架構。其一是60秒上游超時——它卡的是處理時間而非音頻長度，體積大或未壓縮的錄音容易超時，長音頻得分段轉寫再拼文本;其二是音頻URL不支持，端點只認base64JSON或不超過25MB的OpenAI風格多部分文件;其三是SRT/VTT格式輸出不支持，srt、vtt、text會被拒並返回400，時間戳只能靠verbose_json拿，字幕文件得自己按時間戳拼;其四是格式支持因提供商而異，wav是兼容性最廣的安全默認，mp3等壓縮格式則能生成更小更快的負載。一段通宵遊戲會話那樣持續數小時的錄音，單次調用根本覆蓋不了，必須分塊處理。

最後是把轉錄擺對位置。當你只需要把音頻變成文字，用/audio/transcriptions;當你想讓模型對音頻內容做推理，比如客服通話的情感分析、對音頻問答、或把音頻與其他模態混進同一個提示詞，就該用/chat/completions裏的input_audio內容類型。文本轉語音則是第三個獨立端點。OpenRouter給的對照很直白:要轉錄稿，走轉錄端點拿JSON文本加用量;要一個能理解音頻的模型，走聊天補全拿一次對話結果。當一份密鑰同時兜住對話與聲音，語音能力在應用裏落地的門檻，又被悄悄削平了一截。