wen aidev
Published on

深入解析 Amazon Bedrock：底層運作原理與 SDK 實戰指南

Table of Contents

上千行程式碼的底層，其實只是在做一件事：把你的字傳給 AI，再把 AI 的字拿回來。

但如果你以為串接 Amazon Bedrock 只是打一個 REST API 這麼簡單，那你可能很快就會遇到 Timeout 或是花費爆表的問題。在進入更複雜的 RAG (檢索增強生成) 架構前，我們必須先搞懂 Bedrock 的底層運作原理，以及如何正確使用 SDK。

Bedrock 的 Serverless 架構原理

跟傳統你需要開一台 EC2 伺服器、把模型裝進去、自己處理負載平衡的做法不同，Bedrock 是一個純粹的 Serverless (無伺服器) 服務。

也就是說，當你呼叫 Bedrock API 時：

  1. 認證過關：AWS IAM (Identity and Access Management) 會先檢查你的權限。
  2. 分配資源：Bedrock 後台會自動把你導向一台準備好該模型 (例如 Nova 2 Lite) 的機器。
  3. 按量計費：它不跟你算這台機器開了幾個小時，而是算你傳了幾個「Token」。

為了讓大家更好理解這個過程，特別是「串流 (Streaming)」回應是怎麼運作的，我畫了下面這張流程圖：

Amazon Bedrock API Streaming 流程圖

圖說：Bedrock Streaming API 底層資料流解析

最致命的陷阱：為什麼你要用 Streaming API？

很多人剛開始寫程式串 LLM 時，會用最直覺的作法：發送 Request →\rightarrow 等模型想完 →\rightarrow 收回一段完整的文字。這種方式我們叫 Synchronous (同步) 呼叫。

但問題來了，如果你要模型幫你寫一篇 1000 字的文章，模型可能要花上 15 秒才能吐出完整的字。這 15 秒內，你的網頁或 App 看起來就像當機了一樣。如果在 AWS Lambda 裡面跑，甚至可能會觸發 Timeout 中斷執行。

這就是我們必須使用 Streaming API 的原因。它會讓模型「想出一個字，就馬上丟一個字給你」，讓你的前端能像 ChatGPT 一樣，一個字一個字地顯示出來。用戶看到有字在動，就不會覺得系統壞掉。

實戰：使用 Boto3 (Python) 串接 Bedrock 串流

在 2025/2026 年，AWS 針對開發者體驗做了非常多優化，尤其是推出了專屬的 Bedrock API Keys（有別於傳統的 IAM User Key，這讓臨時授權變得更簡單）。

這裡我們看一段用 Python boto3 實作 Streaming 的標準寫法：

import boto3
import json

# 1. 建立 Bedrock Runtime 客戶端
client = boto3.client('bedrock-runtime', region_name='us-east-1')

# 2. 設定你的請求內容 (以 Amazon Nova 2 Lite 為例)
model_id = 'amazon.nova-2-lite-v1:0'
payload = {
    "inputText": "請用繁體中文，簡單解釋量子運算的原理。",
    "textGenerationConfig": {
        "maxTokenCount": 512,
        "temperature": 0.5,
        "topP": 0.9
    }
}

# 3. 呼叫 invoke_model_with_response_stream
response = client.invoke_model_with_response_stream(
    modelId=model_id,
    contentType='application/json',
    accept='application/json',
    body=json.dumps(payload)
)

# 4. 處理回傳的 Event Stream
stream = response.get('body')
if stream:
    for event in stream:
        chunk = event.get('chunk')
        if chunk:
            chunk_obj = json.loads(chunk.get('bytes').decode())
            # 把片段的文字印出來，end="" 讓字連在一起印
            print(chunk_obj.get('outputText', ''), end="", flush=True)
print("\n--- 回應結束 ---")

程式碼拆解與注意事項

  • Client 選擇：注意我們宣告的是 bedrock-runtime 而不是 bedrock。bedrock 是用來管模型設定的，bedrock-runtime 才是用來跟他講話的。
  • Payload 格式差異：這是一個隱藏大坑！不同的模型廠商（Amazon, Anthropic, Meta）要求的 Payload 屬性名稱完全不一樣！上面的寫法適用於 Amazon 自家模型，如果是 Claude，欄位名稱會變成 messages，這在寫抽象層程式碼時要特別注意處理。
  • Token 控管：maxTokenCount 千萬不能省。這是保護你皮包的最後一道防線，萬一模型突然壞掉開始瘋狂亂講話，這個數值可以強制切斷它。

⚡️ 進階技巧：如何算出花了多少錢？

在 Streaming 的最後一個 Chunk 裡面，Bedrock 會附上 amazon-bedrock-invocationMetrics（包含 inputTokenCount 和 outputTokenCount ）。記得一定要把這兩個值抓出來紀錄進資料庫，你才知道每個用戶到底燒了你多少錢！

小結

把 SDK 搞定、跑出流暢的文字輸出，這只是「讓大腦能動」的第一步。

真實的企業級應用中，光靠大腦憑空想像是不夠的。我們必須把公司的私有文件餵給大腦，這就是近年來最火熱的 RAG (檢索增強生成) 架構。

到了 2026 年，AWS 上的 RAG 架構已經演化出了非常多進階的變形。下一篇，我們將全面展開 AWS 企業級 RAG 系統架構，帶你看看現代系統是怎麼設計的！

留言討論