長脈絡工作流最貴的地方，往往不是模型答得多好，而是每一輪都要把同一份 repository 說明、工具定義或參考文件重新送進去。2026 年 9 月 18 日，AWS Machine Learning Blog 說明 Kimi K3 已在 Amazon Bedrock 上架，並指出它是 Bedrock 上第一個支援明確 prompt caching 的開放權重模型。對正在把 coding agent 或知識工作流程推上 production 的團隊來說，這個組合值得拆開來看。
規格數字背後的實際形狀
根據 Moonshot AI 的說法，Kimi K3 是該公司目前最強的模型，也是第一個達到 2.8 兆參數的開放模型；它同時具備原生視覺能力與 100 萬 token 的 context window，並在擴展效率上比 Kimi K2 有大約 2.5 倍改善。AWS 把這些特性對應到需要長時間維持脈絡的 coding 與知識工作，例如橫跨大型 repository、文件與圖片的流程。
這裡的關鍵不是參數量本身，而是「長時間」與「多模態」同時成立時，重送的 context 會變成主要成本來源。
明確 prompt caching 改變了什麼
Bedrock 的明確快取讓你在可重用的 prompt 前綴結尾加上 prompt_cache_breakpoint，前綴至少要 1,024 tokens。寫入快取的 token 以較高費率計價，但至少保留 30 分鐘；後續命中快取的請求，輸入 token 以折扣價計費，而且不計入每分鐘輸入 token 配額。
對照本部落格先前談過的 Amazon Bedrock prompt caching 成本壓縮做法，這次的差別在於 Kimi K3 是開放權重模型，而快取是平台層能力。也就是說，之後新上架的開放權重模型有機會直接沿用同一套機制，而不必每個模型各自整合。
用 OpenAI Python SDK 呼叫時，可以在 extra_body 開啟明確模式，並在 system prompt 與 user 訊息上分別標記斷點，做出分層快取。
resp = oai_client.responses.create(
model="global.moonshotai.kimi-k3",
extra_body={"prompt_cache_options": {"mode": "explicit"}},
input=[
{
"type": "message",
"role": "system",
"content": [
{
"type": "input_text",
"text": SYSTEM_PROMPT,
"prompt_cache_breakpoint": {"mode": "explicit"},
},
],
},
],
)要注意的是，快取只對「穩定前綴」有效。如果你的 system prompt 每次都被動態組裝，或工具定義順序會變，命中率就會掉下來。
資料邊界與推論路徑的選擇
AWS 表示，Kimi K3 與 Bedrock 上其他開放權重模型一樣，資料在 AWS 資料邊界內處理、不會分享給模型供應商，也不會用來訓練底層模型；推論請求一律啟用 zero data retention，zero operator access 則讓 AWS 營運人員也無法存取推論期間的 prompt 與 completion。
推論路徑有兩種：沒有區域限制的工作負載可用全球 profile global.moonshotai.kimi-k3，AWS 說全球跨區域推論比地理 profile 便宜約 10%；有資料落地要求的話，則用美國地理 profile us.moonshotai.kimi-k3。這個 10% 的差距，對高流量團隊是實質的架構決策點，而不是單純的設定選項。
工具鏈怎麼接
Bedrock 支援 OpenAI 相容的 Responses 與 Chat Completions API，也支援 Invoke 與 Converse API。AWS 舉了兩個接入例子：開源的 OpenCode 有原生 amazon-bedrock provider，走 Converse API，設定好之後可用 /models 切換到 global.moonshotai.kimi-k3；Hermes Agent 則原生支援 Bedrock 上的模型，可透過 hermes model 選擇。
AWS 也提到一個當下的限制：如果你用 named profiles 管理多組 AWS 憑證，Hermes 目前需要設定 AWS_PROFILE 環境變數或使用預設 profile，相關支援仍待後續處理。這種細節通常不會出現在發表公告的規格表裡，但會直接影響你怎麼安排團隊的憑證策略。
先量測，再決定要不要換
Kimi K3 在 Bedrock 上最實際的價值，是把「長脈絡重複送 context」這件事從無法優化，變成可以標記、可以量測、可以計價的工程問題。下一步不需要一次換掉整個 stack：挑一條重複 context 佔比高的流程，先量快取命中率與實際帳單變化，再決定全球或美國地理 profile。至於 2.8 兆參數與 100 萬 token 在你們的任務上是否真的轉換成更好的輸出，仍要靠自己的評估集回答。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。