深入探討如何在 AWS 上打造成本優化的自建 AI 轉錄管線——運用 Spot 執行個體、基於 SQS 佇列的自動擴展，以及 Whisper Large-v3 Turbo——在價格上擊敗 OpenAI Whisper API。
大多數建構語音轉文字的團隊都默默接受 API 帳單。我沒有。當一個副業專案開始讓我每月花費 $180 的轉錄 API 費用時，我在 AWS 上重建了整個管線，並將處理成本降到 每小時不到 $0.10——比 OpenAI Whisper API 本身還便宜。
這篇文章將逐步介紹架構、權衡，以及讓它運作的具體決策。這裡的一切都驅動著我以獨立創辦人身分打造的 AI 轉錄平台 StrikeScribe，因此這些數字來自真實的生產工作負載，而非基準測試玩具。
如果你正在建構任何基於 Whisper、Deepgram、AssemblyAI 或 OpenAI 音訊 API 的東西，這就是大多數人錯過的套利機會。
問題：託管轉錄 API 在成本上無法規模化
託管 API 非常適合入門。你傳送音訊，就能取得文字。但定價模式會懲罰用量：
- OpenAI Whisper API：約每小時 $0.36（按 $0.006/分鐘計算）
- Otter、Fireflies 等：訂閱等級會限制你的小時數，並收取高額超額費用
- AssemblyAI / Deepgram：具競爭力，但仍是隨使用量線性成長的按分鐘計費
當你每月處理數百小時——會議、播客、研究通話、IoT 音訊串流——那條線性成本曲線就會成為主要支出項目。你正在為本可直接租用的 GPU 運算支付利潤。
洞察：Whisper 的基礎模型是開源的。你支付的是他人的便利層。如果你能有效率地自行執行推論，經濟效益就會逆轉。
架構
以下是高階管線：
Upload → S3 → SQS Queue → Autoscaling Worker Group (GPU Spot Instances)
→ Whisper Large-v3 Turbo → Pyannote (diarization) → Postgres → Client
Enter fullscreen mode Exit fullscreen mode
讓我拆解實際影響成本的各個部分。
1. Whisper Large-v3 Turbo 達到品質／速度的甜蜜點
Whisper Large-v3 Turbo 能以接近 Large-v3 的準確度，大幅縮短推論時間。對於成本敏感的管線來說，推論速度就是成本，因為你是以 GPU 秒數計費。Turbo 能大幅降低每音訊小時所需的秒數。
為了更快處理，我透過 faster-whisper（CTranslate2 後端）執行，它比參考實作更省記憶體與運算資源：
from faster_whisper import WhisperModel
# int8_float16 keeps VRAM low while preserving accuracy
model = WhisperModel(
"large-v3",
device="cuda",
compute_type="int8_float16",
)
segments, info = model.transcribe(
"audio.wav",
beam_size=5,
vad_filter=True, # skip silence, save compute
vad_parameters={"min_silence_duration_ms": 500},
)
for segment in segments:
print(f"[{segment.start:.2f} -> {segment.end:.2f}] {segment.text}")
Enter fullscreen mode Exit fullscreen mode
這裡有兩個低成本的優化：
-
vad_filter=True— 語音活動偵測會完全跳過靜音區段。真實世界的錄音（會議、通話）充滿死音。這項功能本身就大幅降低了運算量。 -
int8_float16量化 — 讓你在較便宜、VRAM 較少的 GPU 上執行 Large-v3，而大多數音訊不會有明顯的準確度損失。
2. SQS + 佇列深度自動擴展
最簡單的方法是讓一台 GPU 執行個體永遠開啟。這也是最昂貴的方法——你為閒置時間付費。
相反地，我用 SQS 佇列將上傳與處理分離。一個輕量 Node.js 控制器會輪詢佇列深度，並根據積壓工作量擴展工作節點群：
import { SQSClient, GetQueueAttributesCommand } from "@aws-sdk/client-sqs";
import { AutoScalingClient, SetDesiredCapacityCommand } from "@aws-sdk/client-auto-scaling";
const sqs = new SQSClient({ region: "us-east-1" });
const asg = new AutoScalingClient({ region: "us-east-1" });
async function scaleWorkers() {
const { Attributes } = await sqs.send(
new GetQueueAttributesCommand({
QueueUrl: process.env.QUEUE_URL,
AttributeNames: ["ApproximateNumberOfMessages"],
})
);
const backlog = parseInt(Attributes.ApproximateNumberOfMessages, 10);
// one worker per N queued jobs, capped to control spend const desired = Math.min(Math.ceil(backlog / 5), MAX_WORKERS);
await asg.send(
new SetDesiredCapacityCommand({
AutoScalingGroupName: process.env.ASG_NAME,
DesiredCapacity: desired,
})
);
}
Enter fullscreen mode Exit fullscreen mode
當佇列為空時，節點群會縮減到零個 GPU 工作者。你只在有音訊需要處理時才支付 GPU 時間。這是最大的一項結構性成本槓桿。
3. Spot 執行個體（以及如何應對中斷）
GPU Spot 執行個體比隨需執行個體便宜 60–90%。缺點是 AWS 可能在 2 分鐘警告後回收它們。對於轉錄這種無狀態批次工作負載來說，這是完美的搭配——前提是你能優雅地處理中斷。
工作者會監聽 Spot 中斷通知，並將進行中的工作重新排入佇列，確保不會遺失任何工作：
// Poll the instance metadata endpoint for the interruption signal
async function checkForInterruption() {
try {
const res = await fetch(
"http://169.254.169.254/latest/meta-data/spot/instance-action",
{ signal: AbortSignal.timeout(1000) }
);
if (res.status === 200) {
// Reclaim imminent — put the current job back on the queue
await requeueCurrentJob();
await gracefulShutdown();
}
} catch {
// 404 = not interrupted, carry on
}
}
setInterval(checkForInterruption, 5000);
Enter fullscreen mode Exit fullscreen mode
因為工作是冪等的且有佇列支援，中斷的工作會被其他工作者接手。不會遺失任何工作，也不需要手動復原。這種韌性讓 Spot 能用於生產環境，而不僅僅是業餘批次工作。
4. 使用 Pyannote 進行說話者分離
原始轉錄稿只是價值的一半——知道「誰說了什麼」才能把一整面文字轉成可用的會議記錄。Pyannote 負責說話者分離：
from pyannote.audio import Pipeline
pipeline = Pipeline.from_pretrained(
"pyannote/speaker-diarization-3.1",
use_auth_token=HF_TOKEN,
)
diarization = pipeline("audio.wav")
for turn, _, speaker in diarization.itertracks(yield_label=True):
print(f"{speaker}: {turn.start:.1f}s - {turn.end:.1f}s")
Enter fullscreen mode Exit fullscreen mode
接著將分離片段與 Whisper 的時間戳對齊，就能為每行文字標註說話者。雖然會增加運算量，但這是從「一份轉錄稿」變成「會議智慧」的關鍵。
成果
在生產環境中執行此管線：
- 處理成本：每小時音訊低於 $0.10——擊敗 OpenAI Whisper API
- 一次壓力測試：來自 9 台 Raspberry Pi 24/7 錄音的 216 小時音訊，總成本 低於 $3
- 整體基礎架構成本較「永遠開啟／託管 API」的基準降低約 60%
四項槓桿——Turbo 模型、VAD 靜音跳過、縮減至零的自動擴展，以及 Spot 定價——的複合效果是乘法而非加法。每項單獨都有幫助；疊加後，它們徹底改變了單位經濟效益。
什麼時候不該自建
公平來說，這不是免費午餐。我選擇自建的原因是：
- 用量高到 API 費用遠大於工程時間
- 工作負載是 批次而非即時（Spot + 佇列延遲可以接受）
- 我願意管理 AWS 基礎架構、GPU 驅動程式與模型更新
如果你用量低、需要低於一秒的即時字幕，或不想維護基礎架構，託管 API 才是正確選擇。損益平衡點通常落在每月低百位數小時左右。
結論
套利模式——找出競爭對手定價過高的項目，然後用你可控的基礎元件以更低成本建構——在目前的 AI 基礎架構中非常真實。大量的「AI 產品」定價只是 GPU 運算與開源模型上的利潤。
如果你處理大量的音訊資料，我這套管線的組合是：
-
faster-whisper+ Large-v3 Turbo，使用int8_float16與 VAD - 能縮減至零的 SQS 佇列深度自動擴展
- 具中斷安全與冪等工作的 GPU Spot 執行個體
- 使用 Pyannote 進行說話者分離，增加真實產品價值
我已將所有這些功能整合到 StrikeScribe——上傳音訊或影片，即可取得可搜尋的轉錄稿加上結構化的 AI 洞察，無需註冊，也不需要會議機器人。如果你想看看這條管線的輸出端實際運作，這是最簡單的方法。
歡迎在留言區提出架構問題——特別是 Spot 中斷處理與分離對齊，這兩件事通常是大家卡住的地方。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.