Tokens、上下文視窗與推論參數

token（詞元）、context window（上下文視窗）與 temperature（溫度參數）是每位 AWS Certified AI Practitioner（AIF-C01）考生都必須熟練掌握的三個核心槓桿。當 Amazon Bedrock 上的基礎模型讀取提示詞並產生回覆時，它讀的不是「文字」，而是 token——每一個關於 token、context window 與 temperature 的設定，都直接影響費用、延遲、創意程度與事實可靠性。AIF-C01 Task Statement 2.1 明確要求考生理解 token、context window 與 temperature，而社群考試心得也反映：temperature 參數是整份考卷中最容易失分的題目之一。本篇將為你建立一套在真實場景與 AWS 考題中都能成立的思維模型。

本學習指南從基礎出發，帶你逐步理解 token 在 byte-pair 層級的本質、context window 如何同時涵蓋輸入與輸出的 token 預算、temperature 如何重塑機率分佈，以及何時應將 temperature 設為 0、何時應設在 0.5 以上。此外也涵蓋考試情境中常與 token、context window、temperature 一起出現的相鄰推論參數：top_p（nucleus sampling）、top_k、max_tokens、stop sequences、frequency penalty、presence penalty，以及用於可重現性的 seed。讀完之後，你將能夠毫不猶豫地為 Amazon Bedrock 上的資料抽取、程式碼生成、創意寫作、腦力激盪和 RAG（retrieval-augmented generation，檢索增強生成）選出正確的 token、context window 與 temperature 設定。

什麼是 Token、Context Window 與 Temperature？

token、context window 與 temperature 是三個相互關聯的概念，共同定義了大型語言模型（LLM）如何消費文字、產生文字。token 是模型輸入與輸出的最小單位——不是字元，不是單詞，而是由模型的 tokenizer 切分出來的子詞片段。context window 是單次模型呼叫能夠處理的 token 總預算，同時計算輸入提示的 token 數與輸出回覆的 token 數。temperature 是推論時用來重塑「下一個 token 機率分佈」的參數，temperature 為 0 時模型趨向確定性輸出，temperature 越高則輸出越隨機。

在 Amazon Bedrock 上，每一個基礎模型——Anthropic Claude、Amazon Titan、Meta Llama、Mistral、Cohere Command、AI21 Jurassic——都有自己的 tokenizer 和自己的 context window 上限，並且每一個都將 temperature、top_p、top_k 和 max_tokens 作為推論參數對外開放。計費依據是每 1,000 個輸入 token 加上每 1,000 個輸出 token，這正是 token、context window 與 temperature 不只是理論概念的原因——它們也是影響你 AWS 帳單的旋鈕。

為什麼 Token、Context Window 與 Temperature 對 AIF-C01 如此重要

AIF-C01 Domain 2（生成式 AI 基礎）佔整份考試的 24%。Task Statement 2.1 明確要求考生能說明 token、context window 及推論參數，包括 temperature、top_p 和 max_tokens。社群考試回饋顯示，temperature 是 AIF-C01 最常失分的題目之一，因為考生直覺地認為「temperature 越高 = 回答越聰明」——但事實恰恰相反，temperature 越高只是讓輸出更隨機。預計考試中會有兩到四道題目涉及 token、context window 與 temperature，且至少有一道陷阱題的正確答案不是 temperature。

白話文解釋 Token、Context Window 與 Temperature

token、context window 與 temperature 聽起來很技術性。以下三個生活類比能幫你把這三個概念一次搞懂。

類比一 — 傳統市場的豬肉攤（切肉師傅）

想像你走進傳統市場，看著豬肉攤師傅備料。

• Token 就是師傅已經切好的肉塊。師傅不會把整條豬腿直接丟進鍋裡；他會依照料理需求，把豬肉切成一塊一塊的子詞碎片，每一塊就是一個 token。英文文字大約每四個字元切出一個 token；中文、日文、韓文（CJK）每個字大約就是一個 token。標點符號、空格、換行符也各自成為一個 token。模型讀的就是這些切好的 token，不是原始的完整文字。師傅刀工不同（不同的 tokenizer），同樣一段文字切出來的塊數就不一樣多，最終計費也就不同。
• Context window 就是砧板的面積。砧板有限，所有備好的食材（輸入的 prompt token）加上留給料理成品的空間（輸出的 completion token）都必須同時放在砧板上。若試圖堆超過砧板能容納的量，最先切好的食材就會掉落——模型截斷內容，品質隨之崩潰。
• Temperature 就是師傅的即興發揮旋鈕。Temperature = 0 代表師傅嚴格按照食譜，每次都做出一模一樣的菜。Temperature = 0.7 代表師傅略施創意，今天多加一匙辣椒、明天換個擺盤。Temperature = 1.0 代表師傅完全即興發揮，成品可能令人驚艷，也可能讓人難以下嚥。

考題說「每次呼叫都需要相同結構的 JSON」，就把即興旋鈕轉到零。考題說「我們想要新鮮的行銷標語」，就把旋鈕轉高。

類比二 — 便利商店筆記本（桌上能放多少張紙）

想像你坐在便利商店的桌前讀書備考。

• Token 是你在答題紙上寫下的每一個字和每一個標點。老師不是用句子計分，而是用 token 計算。一篇 750 個英文單字的文章大約有 1,000 個 token；一篇 1,000 個中文字的文章同樣大約是 1,000 個 token。
• Context window 是你桌面的大小。桌上能放幾張紙是有限的，問題題本（輸入的 prompt）加上答題本（輸出的 completion）都必須同時放在桌上。如果題本本身就佔了桌面的九成，答題本只剩一成的空間。在 RAG（retrieval-augmented generation，檢索增強生成）的情境中，檢索回來的文件段落就是題本；模型的回覆就是答題本。context window 規劃不當，是 RAG 流水線靜默失敗的最常見原因。
• Temperature 是你答題時能發揮的創意自由度。Temperature = 0 就像數學考試——只有一個正確答案，你必須精準寫出。Temperature = 0.7 就像哲學申論題——有許多合理的回答，你選一個最有把握的。Temperature = 1.0 就像即興口語測驗——風格與驚喜比正確性更重要。

這個類比帶出的考試陷阱洞見是：提高 temperature 不會增加知識量，也不會強化推理能力。它只會增加輸出的變異性。temperature 越高，幻覺（hallucination）只會更嚴重，不會改善。

類比三 — 電費帳單（用電量計費）

現在想像你在查每個月的電費帳單。

• Token 是度數（kWh）。你依照用了多少度數付費。Amazon Bedrock 依每 1,000 個輸入 token（模型讀取你的 prompt 所用的度數）加上每 1,000 個輸出 token（模型生成回覆所用的度數）分開計費。輸入與輸出的電費費率不同——輸出幾乎永遠比輸入貴，因為生成文字比讀取文字更耗費運算資源。
• Context window 是你家電路的總容量（安培數）。一個 200,000-token 的 context window 就像一個 200 安培的電路。你可以自由分配輸入負載和輸出負載，但兩者相加不能超過電路容量，否則斷路器跳閘（截斷或 API 錯誤）。
• Temperature 是燈光的調光旋鈕。Temperature = 0 把燈鎖定在同樣亮度，每次一模一樣。Temperature = 1.0 讓燈光在整個亮度範圍內隨機閃爍。閃爍看起來很有生命力——但它絕對不比鎖定亮度更準確。

記住電費的畫面：token = 用電量、context window = 電路容量、temperature = 調光旋鈕。每一道關於 token、context window 與 temperature 的 Amazon Bedrock 考題，都可以快速轉換成用電量預算問題。

Token 是什麼？——子詞編碼（Subword Encoding）解析

token 是基礎模型讀取或產生的最小文字片段。從原始文字轉換為 token 的過程由模型的 tokenizer 執行，而 Amazon Bedrock 上每個模型家族——Anthropic Claude、Amazon Titan、Meta Llama、Mistral、Cohere、AI21——都搭載自己專屬的 tokenizer。這意味著完全相同的句子，在不同 Bedrock 模型上會產生不同的 token 數量。

子詞編碼——為什麼 1 個單字不等於 1 個 token

現代 LLM 使用子詞分詞演算法（最常見的是 Byte Pair Encoding，簡稱 BPE，以及 SentencePiece、WordPiece 等變體）。子詞分詞將文字切分成兼顧兩個目標的片段：

1. 常見的完整單字獲得單一 token（例如 the、and、cloud）。
2. 罕見的單字被拆分成多個子詞 token（例如 tokenization → token + ization）。

這就是為什麼一個常見的 5 個字母單字可能只是 1 個 token，而一個相同長度的罕見技術術語可能需要 3 個 token。在大多數 tokenizer 中，標點符號、空白字元和換行字元也各自算作獨立的 token。

AIF-C01 考生必背的 token 數量粗估規則

• 英文文字：大約每 4 個字元 1 個 token，或大約每 0.75 個單字 1 個 token。1,000 個英文單字 ≈ 1,333 個 token。
• CJK 文字（中文、日文、韓文）：大約每個字元 1 個 token。1,000 個中文字 ≈ 1,000 個 token。
• 程式碼：差異極大——識別符在不同模型中的分詞方式不同。一行 Python 程式碼可能是 5 到 20 個 token。
• JSON：每個大括號、中括號、冒號、逗號和引號都是獨立的 token，因此 JSON 負載比純文字消耗更多 token。

以上都是估算值——唯一權威的計數來自模型自身的 tokenizer。Amazon Bedrock 在每次呼叫的回應 usage 欄位中會返回 inputTokens 和 outputTokens 計數器。

輸入 token vs 輸出 token——計費不對稱

Amazon Bedrock 的定價將輸入 token 和輸出 token 視為兩個獨立計費器。對幾乎每個模型而言，輸出 token 的單價都高於輸入 token，通常是 3 到 5 倍，因為自迴歸生成比讀取更耗費運算資源。這帶來三個你在 AIF-C01 應立即記下的設計原則：

1. 精簡的 prompt 省錢 — 刪除樣板文字、移除多餘的範例、在 RAG 中壓縮檢索到的上下文。
2. 設定 max_tokens 上限是成本控制手段 — 沒有上限的話，失控的生成可能產生你根本不需要的數千個輸出 token。
3. 摘要便宜、擴展昂貴 — 將一份 10,000-token 文件摘要成 500 個輸出 token，遠比將 500-token 大綱擴展成 10,000-token 完整報告便宜得多。

什麼是 Context Window？

context window 是模型在單次呼叫中能夠處理的最大 token 數量——同時計算輸入 token（system prompt + 使用者 prompt + 檢索到的上下文 + 對話歷史）與輸出 token（生成的 completion）的總和。若總和超過 context window 上限，模型將無法處理該請求，並依 Bedrock 模型家族的不同，返回錯誤或靜默截斷。

為什麼 Context Window 是輸入加輸出的共用預算

一個常見的誤解是 context window 只限制輸入。事實並非如此。例如 Bedrock 上的 Anthropic Claude，prompt 和 completion 共用同一個 token 池。如果 Claude 3 Sonnet 的 context window 是 200,000 個 token，而你送入 199,500 個 token 的 prompt，模型的回覆就只剩 500 個 token 的空間。這通常不是你想要的結果。實際設計時應為模型輸出預留一個生成緩衝區——通常是 1,000 到 4,000 個 token。

Amazon Bedrock 各模型家族的 Context Window 大小（近似值）

確切限制因模型版本而異，且可能隨時更新——請務必查閱 Amazon Bedrock User Guide——但截至 2024–2025 年的大致數量級如下：

• Anthropic Claude 3 / 3.5 家族（Haiku、Sonnet、Opus）：最高 200,000 個 token。
• Amazon Titan Text：依版本不同，4,000 到 32,000 個 token。
• Meta Llama 3.x 家族：依版本不同，8,000 到 128,000 個 token。
• Mistral / Mixtral 家族：32,000 個 token（Mistral 7B / 8x7B）。
• Cohere Command R+：最高 128,000 個 token。
• AI21 Jamba：特定版本最高可達 256,000 個 token。

對 AIF-C01 而言，你需要記住：context window 的範圍從低端的約 4K 個 token 到高端的 200K+ 個 token，且這個數字在 2023 到 2025 年間大幅成長。考試不測具體數字，而是測考生能否理解：更大的 context window 讓你在不用切塊技巧的情況下做更多 RAG。

Context Window 與 RAG 設計——最常被測試的設計概念

RAG（retrieval-augmented generation，檢索增強生成）將檢索到的文件段落注入 prompt，讓模型能夠以來源資料為基礎作答。context window 直接限制了你能注入多少檢索內容，進而驅動具體的設計決策：

1. 切塊大小（Chunk size） — 檢索到的文件被切成 200 到 1,000 個 token 的段落。較小的切塊能在 prompt 中放入更多片段；較大的切塊能保留更完整的局部上下文。
2. Top-K 檢索 — 每次查詢檢索幾個切塊（通常是 5 到 20 個）。檢索的切塊越多 = 消耗的 token 越多 = context window 越快耗盡。
3. 上下文填充 — 所有檢索到的 token 加上 system prompt 加上使用者問題加上預留的輸出緩衝，必須合計在模型的 context window 之內。

當一個團隊從 4K-token 模型升級到 200K-token 模型時，切塊策略往往大幅簡化——有時甚至完全不需要切塊，因為整個知識庫都能放入 context。這正是考試情境所探討的核心取捨。

Context Window 超限時會發生什麼事

超限後的行為依 Bedrock 模型不同而異：

• 部分模型在推論開始前返回驗證錯誤（Amazon Bedrock 在請求 token 數超過模型上限時返回 ValidationException）。
• 部分模型會靜默截斷最早的 token，悄悄丟棄早期歷史或檢索到的上下文。這是最糟糕的失敗模式，因為症狀表現為「模型好像忘記了事情」。
• 對話式應用必須實作 context window 管理——對舊對話輪次進行摘要、丟棄相關性低的訊息，或在長對話中採用滑動視窗策略。

推論參數（Inference Parameters）總覽

每次在 Amazon Bedrock 上呼叫基礎模型時，你都會傳入一組 inference parameters（推論參數）來塑造取樣過程。此時 tokenizer 已將你的文字轉換為 token，模型也已對詞彙表中的下一個 token 生成了機率分佈。Inference parameters 決定的是從該分佈中選取哪個 token，以及何時停止生成。

AIF-C01 考生必須認識的核心 inference parameters 如下：

1. Temperature — 重塑整個機率分佈。
2. top_p（nucleus sampling，核心取樣）— 以累積機率質量為門檻截斷分佈尾端。
3. top_k — 截斷至機率最高的 K 個 token。
4. max_tokens（依模型不同，也稱 maxTokenCount、max_new_tokens、max_gen_len）— 對輸出 token 數量設置硬性上限。
5. stop sequences — 一旦生成到指定字串，立即停止繼續生成。
6. frequency_penalty 和 presence_penalty — 抑制重複（部分模型支援）。
7. seed — 固定亂數種子以實現可重現輸出（部分模型支援）。

不同 Bedrock 模型家族開放的參數子集各有不同。Bedrock 上的 Anthropic Claude 使用 temperature、top_p、top_k、max_tokens 和 stop_sequences。Amazon Titan Text 使用 temperature、topP、maxTokenCount 和 stopSequences。Meta Llama 使用 temperature、top_p 和 max_gen_len。名稱不同，但語意在各家族之間幾乎相同。

Temperature — 創意與確定性的調節旋鈕

Temperature 是 AIF-C01 測試最頻繁的 inference parameter，社群反映的痛點在於考生直覺地將 temperature 與準確度混為一談。Temperature 不會改變模型所知道的事物，也不會增加推理能力。Temperature 只是重塑下一個 token 的機率分佈。

Temperature 如何在數學上重塑分佈

模型生成原始 logit 值後，temperature 在這些 logit 值通過 softmax 之前對其進行除法運算。數學上：

• Temperature = 0 使分佈完全崩潰——機率最高的那個 token 每次都獲勝。輸出完全確定（忽略微小的數值不確定性）。相同的 prompt 在 temperature 0 下，重複呼叫會產生本質上相同的 completion。
• Temperature = 1.0 保持分佈不變，等同於模型的原始輸出。下一個 token 從模型的自然機率估計中取樣。
• Temperature > 1.0 壓平分佈——低機率的 token 獲得提升，使罕見和令人驚訝的選擇更容易出現。輸出變得越來越混亂。

大多數 Bedrock 模型接受 0 到 1 之間的 temperature 值（Claude：0–1；Titan：0–1；部分模型可延伸到 2）。典型的生產環境使用範圍是 0 到 0.9。

何時應將 Temperature 設為 0

當任務有唯一正確答案或需要確定性結構時，將 temperature 設為 0（或非常接近 0，例如 0.1）：

• 資料抽取 — 從文件中擷取特定欄位（發票金額、合約日期、人名）。你希望每次得到相同的輸出。
• 分類 — 將文字指派給某個類別。變異性會導致標籤漂移。
• 生產環境的程式碼生成 — 語法正確性比風格多樣性更重要。
• 結構化輸出 — 生成下游系統需要解析的 JSON、XML 或 YAML。
• 工具／函式呼叫（Tool/Function Calling） — 模型必須選擇正確的函式並精確格式化參數。
• 基於檢索上下文的事實問答（RAG） — 模型應忠實回報檢索段落的內容，而不是自己發明。
• 回歸測試與評估 — 任何可重現性需求都要求 temperature = 0。

何時應將 Temperature 設為 0.5 以上

當多樣性、創意和驚喜是理想結果時，將 temperature 設在 0.5 到 1.0 的範圍：

• 創意寫作 — 小說、行銷文案、標語生成、故事構思。
• 腦力激盪 — 從一個 prompt 生成許多候選想法。
• 改寫 — 產生同一句話的多種不同措辭。
• 合成資料生成 — 產生多樣化的訓練樣本。
• 對話式 UX — 不應因為重複相同開場白而顯得機械化的聊天機器人。
• 內容擴充 — 將大綱擴展為多樣化輸出以進行 A/B 測試。

對大多數真實世界的商業聊天機器人來說，temperature 0.3 到 0.7 是最佳甜蜜點——足夠多樣化以聽起來自然，又夠低以保持基本事實依據。

Temperature 與幻覺（Hallucination）

基礎模型在任何 temperature 下都可能產生幻覺，但幻覺的機率和形式會隨 temperature 而改變：

• 低 temperature 的幻覺傾向於自信、似是而非、且是單一答案——模型堅守最可能（但有時是錯誤的）的 token 序列。
• 高 temperature 的幻覺傾向於更多樣、更令人驚訝、也更容易被察覺——但發生頻率也更高。

解決幻覺的方法不只是調整 temperature。正確的做法是透過 RAG、Amazon Bedrock Knowledge Bases、引用來源，以及 Bedrock Guardrails 的 grounding check 來錨定事實。Temperature 是風格旋鈕，不是真相旋鈕。

Top-P（Nucleus Sampling，核心取樣）

top_p，也稱為 nucleus sampling（核心取樣），是在取樣前截斷機率分佈尾端的另一種方式。與固定 temperature 不同，top_p 選出累積機率超過門檻值 p 的最小 token 集合，並只從該集合中取樣。

• top_p = 1.0 — 不截斷，詞彙表中的每個 token 都有資格（僅受 temperature 約束）。
• top_p = 0.9 — 只從累積佔 90% 機率質量的 token 中取樣。低機率的異常值被排除。
• top_p = 0.1 — 只有最頂端的少數 token 有資格；輸出接近確定性。

top_p 與 temperature 相互作用。大多數從業者要麼調整 temperature，要麼調整 top_p，而不是同時大幅調整兩者。常見的生產配方是對話式輸出採用 temperature = 0.7, top_p = 0.9，或確定性資料抽取採用 temperature = 0, top_p = 1（等同於近似貪婪取樣）。

Top-K 取樣

top_k 在每個步驟將取樣池限制在 K 個機率最高的 token，無論其機率質量如何。

• top_k = 1 — 等同於貪婪取樣；永遠選擇機率最高的單一 token。完全確定性。
• top_k = 50 — 從前 50 個候選中取樣；是一個中間地帶。
• top_k = 0（或未設置）— 無限制；等同於考慮所有 token（受 temperature 和 top_p 約束）。

top_k 受 Bedrock 上的 Anthropic Claude 支援；Amazon Titan Text 不開放 top_k。Bedrock 上的 Meta Llama 開放 top_p 和 temperature，但不直接開放 top_k。

Max Tokens — 輸出長度上限

max_tokens（Amazon Titan 上稱為 maxTokenCount，部分模型稱為 max_new_tokens，Meta Llama 上稱為 max_gen_len）對模型在單次回應中能生成的 token 數量設置硬性上限。它同時是品質控制和成本控制工具。

為什麼 Max Tokens 很重要

• 成本控制 — 沒有上限的話，失控的生成可能消耗你不打算付費的數百甚至數千個額外輸出 token。
• 延遲控制 — 生成時間與輸出 token 數量線性增長。設置 max_tokens 上限能控制尾端延遲。
• Context window 保護 — 在輸入和輸出共用 context window 的模型上，過大的 max_tokens 會侵佔你本來打算用於長 prompt 的空間。
• UX 控制 — 聊天介面的簡短回覆感覺更靈敏；報告生成需要更高的上限。

常見的 Max Tokens 設定值

• 短聊天回覆：256–512 個 token。
• 摘要：500–2,000 個 token。
• 文件生成：2,000–8,000 個 token（依模型上限而定）。
• 單字分類：通常 16–64 個 token 就足夠了。

max_tokens 不會強迫模型填滿到該長度。它只設置天花板。當模型自然結束時（例如命中 stop sequence、發出序列結束 token，或完成了一個完整的回答），它會提早停止。

Stop Sequences（停止序列）

stop sequences 是當模型生成到這些字串時，立即停止繼續生成的字串。Bedrock 模型 API 接受包含最多幾個 stop sequences 的陣列。

Stop Sequences 的使用情境

• 結構化輸出控制 — 在 "</response>" 或 "\n\n---" 標記處停止。
• 對話輪次邊界 — 在 "Human:" 或 "User:" 處停止，以防止模型幻覺出下一輪使用者發言。
• 成本控制 — 一旦答案完成就立即停止，而不讓模型繼續喋喋不休。
• 安全邊界 — 在已知的 prompt injection 標記處停止。

Stop sequences 按字面逐字比對；必須完全匹配（大多數模型區分大小寫）。

Frequency 與 Presence Penalties（頻率與出現懲罰）

部分 Bedrock 模型家族（主要是 AI21 Jurassic、Cohere Command 及其他某些模型——Anthropic Claude 預設不開放這些參數）支援 frequency_penalty 和 presence_penalty 以抑制重複。

• frequency_penalty 根據 token 在輸出中已出現的次數按比例懲罰。較高的值能減少詞彙層級的重複。
• presence_penalty 對任何已出現過的 token 進行懲罰（無論出現次數多少）。較高的值鼓勵模型引入新詞彙。

對 AIF-C01 而言，記住這些是重複控制參數，而非準確度或創意參數。它們解決的是「模型一直重複相同短語」的問題。

Seed — 推論可重現性

seed 是固定取樣過程中亂數產生器的 inference parameter。在特定 Bedrock 模型上支援此功能，設定固定的 seed——結合相同的 prompt、temperature 和其他參數——可在同一模型版本和 Region 的呼叫之間產生（大致）可重現的輸出。適用情境包括：

• 自動化測試 — 期望穩定輸出的回歸測試。
• 稽核軌跡 — 為合規審查重現特定模型回應。
• 除錯 — 將 prompt 修改與取樣變異性隔離開來。

Seed 不保證在不同模型版本、不同 Region 或不同 Bedrock 部署之間逐位元完全相同的可重現性。它只在給定的推論設定內穩定隨機取樣步驟。

Amazon Bedrock 定價 — 每 1,000 個輸入 Token 加每 1,000 個輸出 Token

Amazon Bedrock 採用按 token 計費模式，有兩個計費器：輸入 token 和輸出 token。價格以每 1,000 個 token 為單位報價，並依模型而異。輸出 token 幾乎總是比輸入 token 更貴。

AIF-C01 考生應知道的計費規則

1. 雙計費器 — 輸入 token 和輸出 token 分開定價。費用 = (input_tokens / 1000) × 輸入單價 + (output_tokens / 1000) × 輸出單價。
2. 輸出更貴 — 因為自迴歸生成每個輸出 token 都需要一次前向傳播，同一模型的輸出單價通常是輸入的 3 到 5 倍。
3. 更大／更有能力的模型費用更高 — 按每千 token 計費，Claude Opus > Claude Sonnet > Claude Haiku，反映出能力層級。
4. On-Demand vs Provisioned Throughput — On-Demand 是按 token 付費。Provisioned Throughput 是針對特定模型的按小時承諾，適合在數字上合算的穩定高流量工作負載。
5. 嵌入與圖像模型定價方式不同 — 文字嵌入模型（Titan Embeddings、Cohere Embed）只對輸入 token 收費。圖像模型（Stable Diffusion、Titan Image Generator）按生成的圖像數量收費。

成本優化模式

• Prompt 壓縮 — 去除填充字、樣板文字和多餘的範例。
• 收緊 max_tokens — 根據 UX 需求上限輸出長度。
• 使用更便宜的模型 — 將簡單請求（分類、實體抽取）路由到 Claude Haiku 或 Amazon Titan Text Lite；將 Claude Sonnet / Opus 保留給需要複雜推理的任務。
• 快取 — 在應用層快取確定性（temperature=0）的答案。
• Provisioned Throughput — 對於單一模型的持續高流量，承諾按小時 provisioned throughput 而非 on-demand。
• 批次推論 — Amazon Bedrock 批次推論作業可以為非互動式工作負載提供更低的單位價格。

為真實場景選擇 Temperature

AIF-C01 最常見的題型是「在這個業務情境下，團隊應該設置哪個 temperature？」使用下表，幾秒內就能作答。

注意規律：**結構化、事實性、可重現 = 低 temperature。創意、探索性、多樣化 = 高 temperature。**如果考試情境說「相同的輸入應該每次產生相同的輸出」，答案永遠是 temperature = 0（若支援，通常搭配 top_p = 1 和固定 seed）。

不同 Bedrock 模型家族上的 Token、Context Window 與 Temperature

雖然 token、context window 與 temperature 的概念是通用的，但在 Amazon Bedrock 上不同模型供應商的參數名稱和範圍有所不同。了解這些差異本身就是考試要測的技能。

Bedrock 上的 Anthropic Claude

• Inference parameters：temperature（0–1）、top_p（0–1）、top_k（整數）、max_tokens（整數）、stop_sequences（陣列）。
• Context window：最高 200,000 個 token（Claude 3 / 3.5 家族）。
• 不開放 frequency_penalty 或 presence_penalty。

Bedrock 上的 Amazon Titan Text

• Inference parameters：temperature（0–1）、topP（0–1）、maxTokenCount、stopSequences（陣列）。
• Context window：依版本不同，4K–32K 個 token。
• 不開放 top_k。

Bedrock 上的 Meta Llama

• Inference parameters：temperature（0–1）、top_p（0–1）、max_gen_len。
• Context window：依版本不同，8K–128K 個 token。

Bedrock 上的 Mistral / Mixtral

• Inference parameters：temperature（0–1）、top_p（0–1）、top_k、max_tokens、stop（陣列）。
• Context window：32K 個 token（Mistral 7B、Mixtral 8x7B 版本）。

Bedrock 上的 Cohere Command

• Inference parameters：temperature、p（top_p）、k（top_k）、max_tokens、stop_sequences、frequency_penalty、presence_penalty。
• Context window：最高 128K 個 token（Command R+）。

對 AIF-C01 而言，你不需要逐一記憶每個模型的確切參數名稱。你需要知道的是：每個 Bedrock 文字模型都開放 temperature、某種形式的 top_p、某種形式的 max_tokens，以及 stop sequences，且即使欄位名稱不同，這些概念在各家族之間是相互對應的。

常見考試陷阱 — Token、Context Window 與 Temperature

token、context window 與 temperature 是一個容易被過度簡化的領域。留意以下 AIF-C01 陷阱。

• Temperature ≠ 準確度 — 最大的陷阱。提高 temperature 不會讓模型更聰明；只會讓輸出更隨機。「我們需要事實性、一致的輸出」的正確答案是 temperature = 0。
• Context window 是輸入加輸出的總和 — 不只是輸入。永遠為 completion 預留生成預算。
• 1 個單字 ≠ 1 個 token — 英文平均每個單字約 1.33 個 token。CJK 每個字元約 1 個 token。考試有時要求你估算 token 數量以計算定價。
• 輸出 token 比輸入 token 更貴 — 不是同一個費率。同一模型的輸出單價通常是輸入的好幾倍。成本優化應優先從收緊 max_tokens 著手。
• max_tokens 不會強迫模型填滿輸出 — 它只設置天花板。模型可以且會提早停止。
• Stop sequences 逐字比對 — "END" 的 stop sequence 不會在 "end" 處停止（大多數模型區分大小寫）。
• top_p 與 temperature 是替代方案 — 在大多數實際調整中，你調整其中一個，而不是同時積極調整兩者。固定一個，調整另一個。
• Seed 不保證跨 Region 或跨版本的可重現性 — seed 只在其他設定完全相同的推論環境內穩定取樣隨機性。
• 超過 context window 不一定有明確的錯誤提示 — 部分模型靜默截斷。呼叫前務必驗證 token 數量。
• Tokenizer 因模型而異 — 相同的句子在 Claude、Titan、Llama 和 Mistral 上有不同的 token 數量。定價計算是依模型而定的。

Token、Context Window 與 Temperature vs 相關概念

Token vs 單字 vs 字元

Token 是模型實際消費的單位。單字是人類視角的概念。字元是儲存層面的概念。在計費和 context window 計算中，只有 token 才重要。永遠不要用單字估算 Bedrock 費用。

Context Window vs 模型記憶 vs RAG

更大的 context window 讓你能在單次呼叫中放入更多檢索文件或更長的對話歷史。它與模型「記住事情」不同——基礎模型在不同呼叫之間沒有持久記憶。聊天應用透過在 prompt 中攜帶對話歷史來實作記憶，而該歷史在每次呼叫時都會計入 context window。RAG 是可擴展的替代方案：每次查詢只檢索相關的段落，而不是攜帶完整的歷史記錄。

Temperature vs 微調（Fine-Tuning）vs 提示工程（Prompt Engineering）

Temperature 在推論時調整取樣。每次呼叫都可以免費更改。Fine-tuning 調整模型的權重，成本高昂且持久，直到下一次微調作業才會改變。Prompt engineering 在不改變模型的情況下修改輸入文字。對大多數 AIF-C01 情境而言：先從 prompt engineering 開始，若模型缺乏資訊則加入 RAG，只有在兩者都不足時才進行 fine-tuning，並將 temperature 作為最後一哩的品質調節旋鈕獨立調整。

AIF-C01 必背數字與重點事實

• 1 個 token ≈ 4 個英文字元 ≈ 0.75 個英文單字。
• 1 個 CJK 字元 ≈ 1 個 token（粗估規則）。
• Context window = 輸入 token + 輸出 token，共用預算。
• Amazon Bedrock 定價 = 每 1,000 個輸入 token + 每 1,000 個輸出 token，兩個獨立計費器。
• 輸出 token 的費用通常是輸入 token 的 3 到 5 倍（同一模型）。
• Temperature = 0 — 確定性，最適合資料抽取、分類、程式碼、結構化輸出、工具呼叫。
• Temperature > 0.5 — 創意，最適合行銷文案、小說、腦力激盪。
• top_p 預設值 ≈ 0.9 是典型的生產環境起點。
• top_k = 1 等同於貪婪取樣（完全確定性）。
• max_tokens 是天花板，不是目標值。
• Stop sequences 逐字比對，大多數模型區分大小寫。
• Seed 能穩定取樣，但不保證跨 Region 的可重現性。
• Bedrock 上的 Anthropic Claude 3 / 3.5 context window 最高達 200,000 個 token。
• Amazon Bedrock 在每次回應的 usage 區塊中返回 inputTokens 和 outputTokens 計數器。

練習情境演練 — Token、Context Window 與 Temperature

情境一：一家銀行希望使用 Amazon Bedrock 上的 LLM，從掃描的申請書中抽取特定欄位（貸款 ID、申請人姓名、申請金額）。應使用哪個 temperature 設定？答案：temperature = 0（確定性，資料抽取）。

情境二：行銷團隊希望基礎模型為同一個產品生成 10 個不同的標語。應使用哪個 temperature 設定？答案：temperature 0.7–1.0（創意，多樣性）。

情境三：一個 RAG 流水線檢索了 20 個各 1,000 個 token 的段落，使用者問題增加了 200 個 token。選定的 Bedrock 模型有 32,000 個 token 的 context window。模型回覆還剩多少 token？答案：32,000 − 20,000 − 200 = 11,800 個 token——但實際上應預留安全緩衝區，目標是為 completion 保留 4,000–8,000 個 token。

情境四：團隊希望相同的 prompt 在重複呼叫時得到完全相同的答案。應使用哪種組合？答案：temperature = 0（若支援則加上固定 seed）。

情境五：開發者發現 Amazon Bedrock 帳單偏高。Prompt 已經很短，但每次回應都跑到 4,000 個 token。應優先調整什麼？答案：降低 max_tokens — 在輸入短、輸出長的工作負載中，輸出 token 主導費用。

情境六：一個應用程式向 Bedrock 模型傳送了一個 8,000 個 token 的 prompt，但該模型的 context window 只有 4,000 個 token。會發生什麼事？答案：請求以驗證例外失敗或被截斷。團隊必須切換到 context window 更大的模型，或縮減 prompt。

情境七：一個聊天機器人產生了事實錯誤但語氣自信的回答。正確的緩解措施是什麼？答案：透過 Amazon Bedrock Knowledge Bases 以 RAG 錨定模型，並啟用 Bedrock Guardrails grounding check — 單獨調整 temperature 無法修復幻覺。

情境八：團隊希望將英文使用者評論翻譯成西班牙文。應使用哪個 temperature？答案：temperature 0 到 0.3 — 翻譯是忠實度任務，而非創意任務。

情境九：產品團隊推出創意寫作助理。他們想要多樣且有趣的輸出。應使用哪個 temperature 和 top_p？答案：temperature 0.7–0.9，top_p ≈ 0.9。

情境十：合規團隊需要為稽核目的重現上週的特定模型回應。需要哪些參數？答案：相同的 prompt + 相同的 temperature + 相同的 top_p + 相同的 seed + 相同的模型版本 — 這五個條件都必須符合才能重現取樣結果。

常見問題（FAQ） — Token、Context Window 與 Temperature 熱門問題

1. 在 Amazon Bedrock 基礎模型的情境下，token（詞元）是什麼？

token 是基礎模型消費和產生的最小文字單位。Tokenizer 使用 Byte Pair Encoding（BPE）或 SentencePiece 等演算法將輸入文字切分成子詞片段。在 Amazon Bedrock 上，每個模型家族（Anthropic Claude、Amazon Titan、Meta Llama、Mistral、Cohere、AI21）都有自己的 tokenizer，相同的文字在不同模型上會產生不同的 token 數量。粗估規則：1 個英文 token 約等於 4 個字元或 0.75 個單字；1 個 CJK 字元約等於 1 個 token。Amazon Bedrock 分別對每 1,000 個輸入 token 和每 1,000 個輸出 token 計費。

2. Context window 究竟限制什麼？

context window（上下文視窗）是模型在單次呼叫中能處理的最大 token 總數，同時計算輸入 token（system prompt、使用者 prompt、檢索上下文、對話歷史）和輸出 token（生成的 completion）。如果總和超過上限，大多數 Bedrock 模型返回驗證錯誤；部分模型靜默截斷最早的 token。實際設計應永遠為 completion 預留生成緩衝區（通常 1,000–4,000 個 token）。Bedrock 上的 Anthropic Claude 3 / 3.5 最高提供 200,000 個 token 的 context window；Amazon Titan Text 依版本不同，範圍從 4K 到 32K。

3. Temperature 實際上控制什麼？為什麼它不會提升準確度？

temperature 在推論時重塑下一個 token 的機率分佈。Temperature 0 在每個步驟選擇機率最高的單一 token（確定性）。Temperature 1.0 從模型的原始機率估計中取樣。Temperature 超過 1.0 壓平分佈，使低機率的 token 更常被選中（更有創意，也更隨機）。Temperature 不增加推理能力、知識或事實依據——它只控制變異性。更高的 temperature 傾向於增加幻覺而非減少。對於事實性或結構化任務，設置 temperature = 0。

4. top_p 和 top_k 有什麼區別？

top_p 和 top_k 都在每個 token 步驟限制取樣池，但使用不同的截斷方式。top_k 選取 K 個機率最高的 token（例如前 50 個），無論其機率質量如何。top_p（nucleus sampling）選取累積機率超過門檻值 p（例如合計佔 0.9）的最小 token 集合。top_p 會根據分佈形狀自適應調整；top_k 是固定數量。在生產環境中，調整 temperature 或 top_p 其中一個即可，不要同時積極調整兩者。Bedrock 上的 Anthropic Claude 同時支援 top_p 和 top_k；Amazon Titan Text 只支援 top_p。

5. Amazon Bedrock 推論的定價如何與 token 相關？

Amazon Bedrock 採用雙計費器的按 token 計費模式。費用 = (input_tokens / 1000) × 每千輸入單價 + (output_tokens / 1000) × 每千輸出單價。價格依模型和 Region 而異，輸出 token 的費用通常是同一模型輸入 token 的 3 到 5 倍。用緊湊的 max_tokens 減少輸出通常是投資報酬率最高的成本優化。On-Demand 是按 token 付費；Provisioned Throughput 是按小時承諾，適合特定模型的持續高流量工作負載。

6. 何時應將 temperature 設為 0，何時應設在 0.5 以上？

當任務有唯一正確答案或需要確定性結構時，設置 temperature = 0：資料抽取、分類、程式碼生成、結構化 JSON 輸出、工具／函式呼叫、基於 RAG 上下文的事實問答，以及回歸測試。當多樣性和創意是理想結果時，設置 temperature 在 0.5 以上（通常是 0.5–0.9）：創意寫作、行銷文案、腦力激盪、改寫、合成資料生成，以及自然聽起來的聊天機器人回覆。商業聊天機器人通常落在 0.3–0.7 作為中間地帶。

7. max_tokens 和 context window 有什麼區別？

max_tokens（依 Bedrock 模型不同，也稱 maxTokenCount、max_new_tokens 或 max_gen_len）是每次請求模型能生成的輸出 token 數量上限，由使用者控制。context window 是模型架構施加的輸入加輸出 token 總預算上限。max_tokens 是每次呼叫的使用者設定天花板；context window 是模型的硬性限制。在擁有 200,000 個 token context window 的模型上設置 max_tokens = 500，只是將輸出限制在 500，讓 context window 的其餘部分用於輸入。max_tokens 不會強迫模型生成到該數量；模型可以（且通常會）提早停止。

8. Stop sequences 在所有 Bedrock 模型家族中的行為一致嗎？

所有主要 Bedrock 文字模型家族（Claude、Titan、Llama、Mistral、Cohere）都支援 stop sequences，但參數名稱不同（stop_sequences、stopSequences、stop）。所有模型都對 stop sequence 進行逐字比對——"END" 不會在 "end" 處停止。Stop sequences 在生成的文字上進行評估，匹配時立即停止回應。大多數模型每次呼叫接受 1 到 4 個 stop sequences 的陣列。

9. seed 參數是什麼，何時應該使用它？

seed 固定取樣過程中使用的亂數產生器。與相同的 prompt、temperature、top_p 和其他參數結合使用時，固定的 seed 讓輸出在同一模型版本和 Region 的呼叫之間（大致）可重現。適合用於自動化測試、稽核可重現性和除錯。請注意，seed 不保證在不同模型版本、不同 Region 或不同 Bedrock 部署之間逐位元完全相同——模型更新或基礎設施變更仍可能改變輸出。seed 受特定 Bedrock 模型支援；請查閱各模型的參數文件。

10. Context window 如何影響 Amazon Bedrock 上的 RAG 設計？

RAG 將檢索到的段落注入 prompt，讓模型能夠以來源文件為基礎作答。context window 直接限制了你能注入多少檢索 token。設計選擇——切塊大小（每個切塊通常 200–1,000 個 token）、top-K 檢索（每次查詢通常 5–20 個切塊），以及預留的生成緩衝區（completion 通常需要 1K–4K 個 token）——必須全部放入模型的 context window 之內。從 4K-token 模型升級到 200K-token 模型通常會大幅簡化切塊策略。Amazon Bedrock Knowledge Bases 會自動化切塊、嵌入、檢索和上下文注入，將大部分複雜性隱藏在受管理的 RAG 流水線背後。

延伸閱讀

• Amazon Bedrock User Guide — Inference Parameters. https://docs.aws.amazon.com/bedrock/latest/userguide/inference-parameters.html
• Amazon Bedrock Model Parameters Reference. https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters.html
• Anthropic Claude Messages API Parameters on Amazon Bedrock. https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters-anthropic-claude-messages.html
• Amazon Titan Text Model Parameters on Amazon Bedrock. https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters-titan-text.html
• Meta Llama Model Parameters on Amazon Bedrock. https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters-meta.html
• Amazon Bedrock Pricing. https://aws.amazon.com/bedrock/pricing/
• Amazon Bedrock Knowledge Bases (RAG). https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html
• Amazon Bedrock Provisioned Throughput. https://docs.aws.amazon.com/bedrock/latest/userguide/provisioned-throughput.html
• AWS Certified AI Practitioner AIF-C01 Exam Guide. https://d1.awsstatic.com/training-and-certification/docs-ai-practitioner/AWS-Certified-AI-Practitioner_Exam-Guide.pdf

摘要

token（詞元）、context window（上下文視窗）與 temperature 是共同控制 Amazon Bedrock 基礎模型成本、延遲、創意程度與一致性的三個核心槓桿。Token 是由各模型專屬 tokenizer 生成的子詞片段，英文平均每個 token 約 4 個字元，CJK 每個字元約 1 個 token。Context window 限制了輸入加輸出的 token 總預算——應預留生成緩衝區，並圍繞它規劃切塊大小、top-K 檢索數量和 prompt 長度。Temperature 重塑取樣分佈：temperature = 0 是確定性的，最適合資料抽取、分類、程式碼生成、結構化輸出、工具呼叫和忠實的 RAG 回答；temperature > 0.5 最適合創意寫作、行銷文案和腦力激盪。相關的 inference parameters 包括：top_p（nucleus sampling）、top_k、max_tokens（輸出上限，也是成本控制工具）、stop sequences（逐字停止符）、frequency 和 presence penalties（部分模型上的重複控制），以及 seed（在固定設定內的可重現性）。Amazon Bedrock 定價採用雙計費器模式——每 1,000 個輸入 token 加每 1,000 個輸出 token——同一模型的輸出 token 通常比輸入 token 貴好幾倍。

對 AIF-C01 而言，記住最大的陷阱：temperature 不會提升準確度，也無法修復幻覺。事實準確性要靠 RAG、資料錨定和 Bedrock Guardrails；temperature 是風格旋鈕，不是真相旋鈕。掌握 token、context window 與 temperature，在 AIF-C01 上直接價值兩到四道題，並能讓你在提示工程、模型選擇、成本優化和 RAG 設計等題型上清晰推理。