Kimi K3 完整指南：2.8 兆參數開源模型的規格解讀、計費結構與台灣採用策略

Kimi K3 是月之暗面（Moonshot AI）在 2026 年 7 月推出的基礎模型，總參數量 2.8 兆，是Kimi K3 官方指南登記的全球第一個達到 3 兆量級的開源模型，原生支援影像理解，並提供百萬 token 級的脈絡視窗，鎖定跨小時的工程工作、知識處理與深度推理這類高門檻任務。到 2026 年 10 月的現在，它已經被更新的 K3.1 Pro 取代旗艦位置，但「前代旗艦」四個字反而讓它更值得台灣團隊認真評估：權重完整開放、API 計費結構單純、長任務定位沒有變，這三件事加起來，讓 K3 在「成本敏感但需要大上下文」的應用裡，成為一個務實的選項。

這篇指南跳過功能導覽，直接站在採用決策的視角把 K3 拆開：供應商與產品線的層級關係、兆級參數規模背後的架構含義、百萬脈絡與計費結構怎麼互相影響、快速接通 API 的實際步驟、家族內四條產品線、六個模型 ID 的選型方式，以及把工作放上這家中國業者之前該做的盡職調查。所有規格與價格結構都對齊 2026 年 10 月的官方文件，連結放在文中各處，數字會過時的地方我會直接告訴你該去哪裡查最新值。

先分清楚：Moonshot、Kimi 與 K3 各代表什麼

談這家公司的產品，第一件事是把三個名字分層。公司層是北京月之暗面科技有限公司，維基百科的Moonshot AI公司條目記載它 2023 年 3 月由楊植麟、周昕宇、吳育昕三位清華同窗創立，其中楊植麟曾先後任職於 Google Brain 與 Meta 的研究團隊，現任執行長，總部位於北京市海淀區。品牌層是 Kimi，一個同時掛在消費端服務、模型家族兩個層面的名字。模型層才是 kimi-k3 這個具體的模型 ID，也是你在 API 呼叫裡實際填的字串。三層混著談，討論資料治理時會搞錯對象，討論計費時會算錯帳。

產品線在 2026 年 10 月的分工是這樣：消費端的 kimi.com 已經升級到 K3.1 Pro，介面提供定時任務、靈感庫、簡報製作、深度研究與 3D 生成等功能，介面文字為簡體中文；開發端的 Kimi API 平台（platform.kimi.ai）走計量付費，Kimi API 計費說明明載 API 平台沒有訂閱制，與消費端的會員方案、Kimi Code 產品是兩套帳務體系，這一點在評估成本時經常被混淆；模型層目前上架四條產品線：kimi-k3.1-pro、kimi-k3、kimi-k2.7-code 與 kimi-k2.6，其中 K3 已完整釋出權重。同一個「Kimi」字樣出現在不同入口時，指的是不同的東西，各產品的計費、合約與資料政策要分別查閱，這種多層結構的檢查方法，可以對照我們拆解對岸模型商的三層身分的框架來看。

平台內建工具的生態也影響採用判斷。官方工具透過 Formula 框架整合：先從工具端點取得定義、掛進請求的工具欄位，模型回傳呼叫意圖後，把函式名稱與參數送到執行端點，再把結果接回對話。留意這套流程講的是官方工具；你自己定義的客製工具，官方文件示範的走法是在應用端執行函式、把結果回傳給模型，兩條路不要混為一談。現階段有一個重要的使用限制：網路搜尋功能官方明確聲明正在更新，近期不建議放進生產環境，需要檢索能力的應用要另外規劃資料來源，這條限制在後面的反指標清單會再出現一次。

2.8 兆規模背後的架構：KDA、LatentMoE 與 Attention Residuals 在省什麼

K3 的規格表上有三個技術名詞值得花三分鐘弄懂，因為它們直接決定了「2.8 兆參數」對你帳單的意義。第一個是 Kimi Delta Attention（KDA），一種混合線性注意力機制；第二個是 Attention Residuals，設計目的都是讓資訊在更長的序列與更深的模型裡流動得更順；第三個是 Stable LatentMoE 框架下的稀疏混合專家架構，896 個專家裡每個 token 只啟動 16 個。官方文件對這組架構的總結是：整體縮放效率約為前代 K2 的 2.5 倍。

「896 選 16」是理解 K3 成本結構的鑰匙。總參數量決定了模型的知識容量，但每次推論實際動用的參數只佔一小部分，這代表 2.8 兆的模型不必然對應 2.8 兆等級的推論成本，模型規模與單次呼叫成本在某種程度上脫鉤了。這也是為什麼 K3 能同時給出百萬級的脈絡容量與相對務實的計量價格結構。對採購方來說，參數總量看過就忘沒關係，這個架構取向才值得記住：用稀疏化換取「大而不貴」，代價是架構複雜度，而架構複雜度對實際採用者的影響，主要體現在自架部署的硬體門檻上。

「開源」在 K3 的脈絡裡是具體承諾而非行銷詞：K3 快速上手指南載明完整模型權重已經釋出，更詳細的架構、訓練與評測內容承諾隨技術報告發布，K3 技術部落格則收錄了完整的跑分與案例。官方也給了一個有意思的座標：從 2025 年 7 月到 2026 年 7 月的 12 個月裡，Kimi 的模型有 9 個月維持開源模型規模的前沿位置。開放權重對台灣團隊的實際意義是退場保險：供應商政策改變、價格結構調整或服務中斷時，你還有一條自建推論的路，這個選項在後面盡職調查那節會再回來。對語言模型運作原理不熟悉的讀者，可以先讀我們對LLM 運作原理的拆解再回來看這節。

百萬脈絡的實務換算：你的文件放得進去嗎

K3 系列的脈絡視窗是 1,048,576 個 token，這個數字出自Kimi API 定價說明，對 K3 與 K3.1 Pro 一體適用。換算成實際文件量需要小心：官方文件以英文舉例，1 個 token 大約等於 3 到 4 個英文字元，中文的壓縮比依各家分詞器而異，沒有放諸四海皆準的係數，實務上建議直接用平台提供的 token 計算工具先估算，再把結論寫進成本模型。粗略的量級感受可以先建立：整份上市公司年報、一套內規彙編或中型專案的核心模組，都有機會放進這個視窗；實際塞不塞得下，先用平台的 token 估算工具量過，並預留輸出空間。

輸出端的額度是另一個常被忽略的數字：max_completion_tokens 預設 131,072，最高可設到 1,048,576。預設值已經足以應付絕大多數摘要、分析與改寫任務，會碰到上限的通常是「把整份文件重構成另一種格式」的極端需求。工程上要注意的是，輸入塞滿不等於輸出也該塞滿，大脈絡的正確用法是多輪提問榨取同一份輸入的價值，而不是期待模型一次吐出等長的完整改寫，這個使用模式直接影響下一節要算的帳。

還有一個容易被忽略的計費細節：視窗很大，不代表塞滿它是免費的。官方計費邏輯載明，凡是送進模型的內容都按用量計，包括你上傳文件後抽取出的文字，檔案抽取與儲存的介面本身暫不收費，但抽出來的內容一進模型就開始計費。正確的心態是把視窗當成要付租金的倉儲容量：需要反覆使用的長內容靠快取攤提成本，用不到的內容根本不要送，這比任何計價技巧都省錢。

計費模型拆解：快取寫入、命中價與兩檔 TTL

K3 的計費結構有三個欄位要分開算。第一是輸入，命中與未命中分別計價；第二是輸出，按生成量計；第三是快取寫入，單次收費，依存活期分兩檔，官方快取指南的示例為每 MTok 3 美元（五分鐘檔）與 6 美元（一小時檔）。Kimi API 計費說明強調 K3 的計價不因脈絡長度分級，同一個模型把視窗用滿一百萬與只用 8 千，單價結構相同，這對大體積文件場景是友善的設計。計價單位是每百萬 token（MTok），價格不含稅，實際稅負依帳單地區計算。每 MTok 的現行數字會調整，本文不抄錄，請以官方定價頁為準。

快取機制是 K3 成本工程的核心。規則是這樣的：重複出現的請求前綴會自動寫入快取，不必手動建立，之後命中相同前綴的請求改按優惠的命中價計費，寫入本身收單次費用。存活期有 5 分鐘與 1 小時兩檔，預設 5 分鐘；只有間隔超過 5 分鐘、前綴又會在一小時內重用的負載，才考慮指定 1 小時檔，而且要依重用量試算確認較省再切換，重用次數少的場景未必划算。快取以區塊為單位儲存，填不滿一個完整區塊的尾端內容不入快取，照樣按未命中計費。把這些規則組合起來，正確的應用形狀就很清楚了：把不變的長內容（知識庫、規章、原始程式）放在訊息序列的最前面，把每次不同的問題放在最後，同一份 30 萬 token 的手冊連續問 20 個問題，計費要拆開看：第一問把前綴寫入快取、付一次寫入費；之後每一問，與前綴相同的合格區塊按命中價計，新增加的問題內容與填不滿區塊的尾端按未命中計，輸出逐次照常計費。詳細的最佳實務，官方有官方快取指南可對照。

取得使用資格的門檻很低：K3 是旗艦模型，帳戶完成儲值後解鎖，最低儲值 1 美元，累積儲值金額同時決定帳戶層級與速率限制，併發數、每分鐘請求數、每分鐘與每日 token 數的具體門檻列在官方限流說明。另外有個省錢細節：文件抽取與檔案儲存的 API 在撰文當下暫不收費，如果你只上傳文件做抽取再自己送進模型，檔案處理這段目前不產生費用，這對先做文件預處理管線的團隊是個順手的緩衝。

命中率是新的成本指標：怎麼監控、怎麼調

傳統雲端服務的省錢指標是用量，K3 這類模型的省錢指標是命中率。原因在計費結構：同一份輸入，走未命中價與走命中價的差距，在多輪應用裡會被輪數放大，二十輪的知識庫問答，命中率從零拉到九成，輸入端的費用差距會隨輪數放大，實際倍數依現行價目試算。把命中率當成一級指標來監控，是長期使用的前提動作，API 回應裡的使用量欄位會區分命中與未命中的 token 數，把它接進既有的監控看板，每週看一次分佈，比月底收到帳單才發現異常便宜太多。

提升命中率有三個槓桿。第一是訊息形狀：把所有不變的內容固定放在最前、把會變的內容放在最後，任何一次順序調整都會讓後面的前綴全部失效，等於把快取打掉重練。第二是尾端對齊：快取以區塊為單位儲存，填不滿一個區塊的尾端不入快取、照未命中計費，佈局訊息時留意這個粒度，別讓長期不變的內容落在尾端。第三是存活期選擇：互動式應用間隔短，預設五分鐘就夠；間隔可能超過五分鐘、但前綴會在一小時內重用的批次應用，指定一小時檔。官方快取指南給出換檔的損益兩平：寫入費每 MTok 五分鐘檔 3 美元、一小時檔 6 美元，相較五分鐘檔，一小時檔要多保住至少兩次等量前綴的命中，才開始反超；請求節奏貼著五分鐘邊緣走時，五分鐘檔未必吃虧。另有一個容易踩到的規則：快取項目的存活期在首次寫入時鎖定，命中只會免費續期，要換檔必須等既有項目完全過期後重寫，切換時點要事先排進計畫。三個槓桿都源自官方文件的快取規則，調整前後的對照請留在實驗紀錄裡，讓數字說話。

文件改版是命中率的最大敵人。知識庫每改一個字，快取前綴從那一點起全部失效，如果貴公司的手冊每天微調、每週大改，快取收益會隨改版折損，幅度依變更落在前綴哪個位置與兩次改版之間的重用量而定。對策是繼續改版沒關係，但內容要先分成兩層：真正穩定的骨架（目錄、條文編號、通用說明）放前面吃快取，經常變動的補充（價格、時程、活動）放後面、把這部分的成本按未命中計，改版就只犧牲一小段。養出這個分層習慣，快取工程就從運氣變成設計。

實際要盯的四個欄位：每日請求總數看用量趨勢、命中率看快取形狀是否健康、未命中的輸入量看前綴設計有沒有跑掉、寫入次數看存活期選擇是否合理。四個數字配在一起，異常會自己說話：命中率驟降通常是文件改版或訊息順序被改動，寫入次數暴增通常是存活期選錯檔，未命中量攀升則多半是有人把變動內容插到了前綴中間。把這四個欄位做成一個看板，週會上花兩分鐘掃一遍，快取工程就從一次性設定變成持續營運。

思維鏈永遠開啟：reasoning_effort 三檔怎麼調

K3 在推理上有一個明確的設計決策：思維鏈無法關閉。模型每個請求都會先推理再回答，你能控制的只有推理力道，透過頂層的 reasoning_effort 參數在 low、high、max 三檔之間調整，預設 max。這個設計的含義要從兩面看：好處是艱難任務不會因為忘記開推理模式而少想一步，答案水準仍要以你的實際任務驗證；代價是回應延遲與 token 消耗有底線，對延遲敏感的應用（即時客服、互動式補全）要把力道降到 low，或考慮延遲表現更好的專職型號。

工程上有三個配套規則要記住。第一，多輪對話與工具呼叫時，要把 API 回傳的完整 assistant 訊息原封不動放回下一個請求，不能只取文字內容，否則推理狀態會斷；第二，串流模式下推理過程與最終答案分開輸出，前端可以選擇只展示答案、把推理留在後台；第三，取樣參數是固定的，temperature 固定 1.0、top_p 固定 0.95，請求裡不用也不應該傳這些參數。對提示詞結構怎麼影響推理模型的行為，可以參考我們整理的提示詞撰寫方法，原則相通：把任務邊界講清楚，讓思維鏈有明確的收斂目標。

多模態輸入的紅線：公開圖片 URL 不收

K3 的視覺輸入有一條硬性紅線：K3 官方指南明載不支援直接傳公開圖片網址，圖片必須以 base64 編碼或平台檔案系統的 ms:// 位址送入，而且 content 欄位要從字串改為物件陣列。這條限制乍看是麻煩，實際上強迫你的管線做對三件事：自己掌握下載時機與失敗重試、對來源圖片先做授權與隱私檢查、把媒體處理跟模型呼叫解耦。影片輸入走檔案上傳，用完即刪。對需要把螢幕截圖、掃描文件或 UI 畫面餵給模型的管線來說，這條紅線就是架構設計的起點。

圍繞模型的工程面還有三個值得知道的機制。結構化輸出用 JSON Schema 加嚴格模式，把答案約束成可直接解析的格式，解析時只讀答案欄位、不碰推理欄位；Partial Mode 讓你提供一段文字前綴，模型從前綴續寫，適合修正開場白、恢復被截斷的輸出；動態工具載入把工具定義放進不帶內文的 system 訊息，對話進行到一半才掛上需要的工具，省 token 也顧快取前綴。第一輪對話可以用 tool_choice 設為必須呼叫，確保模型不會跳過你給它的工具。把模型接到自家系統的整體方法，可以對照我們對工具串接協定的分析，那篇處理的是更通用的整合層問題。

快速接通：從儲值到第一支呼叫

整條接線流程照官方文件走，時間主要花在等待與驗證，程式本身很短。到 platform.kimi.ai 註冊帳號，在控制台建立 API 金鑰，完成至少 1 美元的儲值把 K3 解鎖，金鑰放在環境變數裡管理，永遠不進版本庫。API 相容 OpenAI 的 SDK，這是降低轉換成本的關鍵設計：已經用 OpenAI 客戶端的團隊，換 base_url 與模型名稱就能發出第一支請求。最小可用的 Python 起手式如下。

import os

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.ai/v1",
)

completion = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "user", "content": "用一句話介紹 Kimi K3"}],
)
print(completion.choices[0].message.content)

跑通之後，把第二支呼叫改成有利於快取的訊息排列：知識庫內容放 system 訊息，問題放 user 訊息，連續發幾個問題，再到帳務後台看命中數字有沒有如預期出現。這個起步檢查能先驗證三件事：金鑰權限、計費路徑與快取行為；回應品質要用你的代表性任務另外驗證。動手永遠比讀完所有文件更能建立判斷。如果是第一次接模型 API，我們的AI Agent 落地指南裡對授權範圍與流程設計的建議同樣適用。

開發者常見的五個誤區

把官方文件的限制清單換個角度讀，就是五個常見誤區。第一個，多輪對話只回傳文字內容：K3 要求把完整的回應訊息原樣放回下一輪請求，只取文字會丟掉推理狀態，模型表現會莫名變差，這個問題的徵兆是「單輪很好、多輪變笨」，排查時第一個想到它。第二個，在請求裡夾帶 temperature 或 top_p：這些參數在 K3 是固定值，傳了沒有效果還可能被拒絕，從 OpenAI 生態搬現成程式過來時記得清掉。第三個，把公開圖片網址直接塞進訊息：視覺輸入只收 base64 編碼與檔案系統位址兩種形式，塞網址不會報錯的那天還沒到，先在自己的下載層處理好。

第四個誤區，把百萬視窗當成輸出額度：輸入能塞一百萬，輸出預設上限是 131,072 個完成 token，期待模型一次吐出整份重寫的文件，通常得到的是被截斷的中段，正確形狀是把輸出切窄、分多次拿。第五個誤區，以為快取全自動就不需要設計：自動的是寫入與計費，不是你的訊息形狀，前綴亂排的應用照樣全額付帳。五個誤區共同點是都出自對限制的誤讀，把限制清單當成介面合約來讀，大部分坑在寫第一行程式前就能避開。

選型表：K3、K3.1 Pro 與 K2.7 Code 各自的位置

官方模型清單現行列有六個模型 ID、分屬四條產品線，其中兩個是高速變體，分工的座標相當清楚。整理成表如下。

↔ 左右捲動檢視完整表格

型號	定位	上下文	視覺輸入	適合的任務型態
kimi-k3.1-pro	現任旗艦，3 兆量級	100 萬 token	原生支援	高階編碼、3D 創作、金融研究與建模
kimi-k3.1-pro-highspeed	旗艦的高速版	100 萬 token	原生支援	同旗艦，速度約 2 到 3 倍，適合量產管線
kimi-k3	前代旗艦，開源 2.8 兆	100 萬 token	原生支援	長時程編碼、知識工作、深度推理，可自架
kimi-k2.7-code	專職編碼模型	256K token	支援	長上下文指令遵循、高成功率編碼任務；高速版每秒約 180 token
kimi-k2.7-code-highspeed	編碼模型的高速版	256K token	支援	輸出速度約每秒 180 token，短脈絡最高約 260 token
kimi-k2.6	通用多模態	256K token	支援	思考與非思考模式切換、對話與代理任務

選型的第一刀切在「要不要開源退場保險」：要，就先看 K3，它已完整釋出權重。第二刀切在延遲與產能：量產管線看 K3.1 Pro 的高速版，寫碼專職工作看 K2.7 Code 的高速版。第三刀才是價格：兩個 K3 世代同為百萬上下文，能力差距方面官方以編碼、3D 創作與金融研究建模描述 K3.1 Pro 有實質改進，實際選哪代，按你的任務跑對照再定，價差請回定價頁試算，因為快取命中率不同的兩個工作負載，對同一張價目表的感受可以差好幾倍。已經在用 K2 系列的團隊要注意時程：官方公告 K2 系列從 2026 年 10 月 31 日起不再開放給新註冊用戶，並規劃在 12 月底全面退役；更早之前的 kimi-latest 已於 1 月 28 日、kimi-k2 於 5 月 25 日、kimi-k2.5 與 moonshot-v1 系列於 8 月 31 日陸續停產。對既有整合來說，遷移是必要工程。跨家族的整體模型選型，我們在Claude 模型指南與AI 工具總整理裡有不同切法的對照。

OpenAI 相容介面的戰略意義：轉換成本怎麼算

K3 的 API 相容 OpenAI 的介面規格，這個設計決策值得從採購角度理解。相容帶來的好處很實際：既有程式可以沿用同一套 SDK 與基本的對話骨架，換個端點位址與模型名稱就能發出請求，後續的參數慣例與訊息格式仍要逐一適配，供應商之間的切換成本因此低於重寫，實際工時依整合深度而定。但相容也有邊界：推理力道這類參數各家的命名與支援值不同、行為也有差異，快取控制的參數形狀同樣各走各的，真正可攜的是基本的對話、串流與工具呼叫骨架。換句話說，相容介面降低了「入場」的轉換成本，沒有消除「深度使用」的相依，把專屬功能用在最關鍵的路徑上、大宗請求採用可攜的基本介面，是務實的架構折衷。

試算價格的方法也順手交代。第一步，用平台的 token 估算工具量出你典型文件的實際 token 數，不要用字數猜；第二步，照你的問答節奏把每天用量拆成四類：快取寫入、命中、其餘未命中與輸出，官方指南載明快取讀取、寫入與未快取餘額三類互斥，加總就是輸入總量；第三步，到定價頁拿現行單價相乘，得到日成本，再乘三十看月成本。試算本身不複雜，卻常常被跳過，憑印象決定的代價會在月底帳單上現形。把試算公式存進試點紀錄，單價調整時重跑一遍，成本模型就是活的。

從 K2 遷移到 K3：三件要提前做的事

官方已經排定 K2 系列的退場時程，新帳戶從 2026 年 10 月 31 日起不再能使用 K2 系列，全部 K2 型號預計在 12 月底除役，仍在 K2 上的整合，問題只剩下什麼時候動工。第一件要提前做的事是定義回歸測試集：抓五十到一百個生產環境的真實請求與理想回應，遷移前後各跑一次，差異用抽樣人工判讀，模型換代後的行為差異用眼睛看，比看跑分可靠。第二件是盤點視窗依賴：K2 系列的脈絡上限是 262,144，K3 是 1,048,576，如果你的程式曾經為了塞進 K2 做切塊與摘要壓縮，遷移時該評估哪些壓縮可以拆掉，讓模型直接讀原文，很多「必要之惡」其實是舊限制的遺跡。

第三件是重新校準推理開關的假設。K2.6 支援思考與非思考兩種模式的切換，K3 把推理變成無法關閉的預設行為，只能調整力道。這代表延遲預算與 token 消耗的模型要重算：過去靠關閉思考壓低延遲的路徑不存在了，改用低檔力道或考慮延遲取向的型號。三件事做完，還要完成參數、訊息與媒體格式的適配並跑回歸驗證，之後切換才安穩；做不完，遷移會變成線上事故的驚喜包。特別提醒：供應商的文件位址與價格資訊會不定期調整，寫死在監控管線裡的連結要定期檢查。

三個台灣落地場景：任務型態推演

以下三個場景是任務型態的推演，用來說明「什麼形狀的工作適合 K3」，實際效果請務必用自家資料驗證，任何模型都有你資料上的盲點。

場景一：繁中內規與產品手冊的知識庫問答

把公司內規、產品手冊、客服腳本彙整成一份長文件放進 system 訊息，員工或客服的問題放 user 訊息，這是快取機制的教科書場景：文件不動、問題常換，第一問把文件前綴寫入快取，之後每一問與前綴相同的部分有機會按命中價計。設計重點有三：文件版本更新時快取前綴會失效，改版頻率要納入成本預估；問題間隔若超過 5 分鐘（例如非尖峰時段）、又會在一小時內回來重用，才考慮 1 小時檔的存活期，並依預期重用次數試算確認較省再指定；敏感條款（薪資、個資、未公開財務）應在進模型前就過濾或分級，這是資料管理與合規的功課，不是模型的能力問題。

場景二：大型舊系統程式碼的盤點與重構評估

接手一個缺乏文件的中型系統時，先估算核心模組組合的 token 數、預留輸出空間，確認放得進 K3 的百萬脈絡，再讓模型在同一次視野裡讀完呼叫關係回答「這段邏輯為什麼存在」。長時間的工程協作正是 K3 的設計定位，官方也標舉它能以少量人工監督維持長時間的工程任務、協調終端工具。實務節奏建議分成兩層：K3 負責理解與規劃層的問答（架構盤點、風險清單、重構順序），執行層的寫碼可搭配編碼取向的型號或既有工具鏈；若考慮 K2.7 Code，留意它隸屬 K2 系列，2026 年 10 月 31 日起新帳戶無法使用、年底步入退役，只適合既有用戶短期過渡。盤點結論要抽樣人工複核，模型的因果推斷在陌生程式碼上偶爾會自信地說錯。

場景三：客服工單的多語摘要與截圖分類

客服工單常見兩種混合輸入：夾雜中英日文的文字描述，加上附件截圖。K3 的原生視覺理解讓同一支管線可以處理兩者：文字直接送、截圖走 base64 編碼送，輸出用結構化模式約束成固定的分類與摘要欄位，直接落進工單系統。延遲要求高的即時分類把推理力道調到 low；批次離峰處理保持預設。個資防護是這個場景的上線前提：截圖裡的客戶個資，進模型前的遮罩步驟不能省；至於分類正確率、多語理解與延遲，要用你的實際工單驗證。

供應商盡職調查：開源權重、中國主體與四個該問的問題

把工作負載放上任何模型前，供應商盡職調查都是必要程序，這家公司因為是中國主體，調查項目要再多幾條。維基百科的Moonshot AI公司條目記錄了一個值得參考的背景：美國國會委員會曾就美國企業採用 Kimi 等中國模型的議題向企業施壓，這代表跨國供應鏈裡的台灣公司，未來可能被客戶或合夥人問到「你們用了哪家的模型」。開源權重在此刻發揮雙重作用：它既是技術退場保險，也是採購談判裡的籌碼，因為把推論搬去自建或第三方基礎設施是一條附條件的退場路：K3 技術部落格對自架的建議是 64 張以上加速器的超節點配置，授權條款、硬體成本與部署相容性都要先驗證。

四個問題建議在採用前逐條寫下答案。第一，資料落地：你的輸入會被送到哪個司法管轄區的伺服器，條款怎麼寫；第二，訓練用途：輸入內容是否會進入供應商的訓練或改進管線， opt-out 的方法是什麼；第三，資料分級：哪些等級的資料可以上、哪些永遠不能上，邊界由誰簽核；第四，退場方案：供應商停服或條款轉向時，你的資料、提示詞資產與流程多久能搬到替代方案，開源權重讓這題有答案，但答案要事先演練過才算數。這四題的框架同樣適用於任何一家模型供應商，差別只在於答案的好壞。

資料分級怎麼落地：四層做法

盡職調查裡最難落地的是資料分級，這裡給一個可直接改用的四層範例框架，最終准駁由貴組織的資安與法務政策核定。第一層是公開資料，產品說明、公開報導、法規原文，原則上可用。第二層是內部一般資料，流程文件、會議紀錄、去識別化的統計數字，可以上，但輸入前跑一道敏感詞掃描，擋住混進去的個資。第三層是機密營運資料，客戶名單、定價策略、還沒對外公布的財務數字，原則不上，真有業務需要時走單獨帳號、單獨條款審查、單獨留存紀錄的專案流程。第四層是法規管制資料，個資、醫療、金融特許業務的客戶資料，原則不上，除非貴組織的法務與主管機關明確允許。

這個框架真正的價值在「先分級再談模型」這個順序。未確認資料等級就貼進對話框，是最該優先避免的風險來源。分級表要跟著部門走、每季複核一次，新資料型態出現時先問層級再問用途。分級表建好之後，哪個場景能用 K3、哪個場景只能用自建方案，答案會從表裡長出來，臨場判斷退居備援。

採用前的三週試點計畫

把評估收斂成三週的試點，比無限期的觀望更能產出決策。第一週跑知識庫問答場景：挑一份真實的內部文件（先拿不敏感的），照前面講的分層形狀接上，每天記錄請求數、命中與未命中的 token 量、每次輸出長度與使用者主觀滿意度，週末把帳單換算成「每百次問答的成本」，這個數字是你後續所有討論的錨點。第二週拉高難度：把延遲敏感的任務放進來測低檔推理力道，把影像混合型任務放進來測截圖管線，同時觀察限流欄位，確認你的層級在預期負載下不會撞牆，撞牆的解法是調升儲值層級還是節流，要在上線前想清楚。

第三週做兩件收尾的事。第一件是盡職調查答題：把前面那四個問題的答案寫成正式文件，給法務或資安同事過目，哪一題答不出來就標記為風險，誠實的未知比樂觀的猜測有價值。第二件是退場演練：把同一組提示詞與流程換到替代模型跑一遍，記錄品質落差與需要改寫的部分，這份紀錄的用途在於讓你知道搬家的代價，談判與應變都靠這個底氣，真要立刻搬家也有依據。三週結束，你手上有成本錨點、負載上限、風險清單與退場代價四項決策依據，採用與否、怎麼用、用到哪條線為止，答案會自己浮出來。

何時不該選 K3：六個反指標

反指標比正指標更能避免選型錯誤。以下六種情況，K3 不是合理選擇：第一，需要關閉推理過程的低延遲互動，K3 做不到；第二，依賴供應商內建網路搜尋的應用，官方已聲明該功能正在更新、近期不建議用於生產流程；第三，需要自由調整取樣參數做實驗的研究場景，參數是固定的；第四，高頻短問答為主的工作負載，經代表性任務實測後成本或延遲仍超出預算，旗艦級模型對你就是超配；第五，管線設計依賴直接餵公開圖片網址，你得先重構媒體處理層；第六，所處產業或標案環境對供應商國籍有硬性限制，這題不是技術能解的。命中任一條，先看家族內其他型號或乾脆換一家，比硬上再繞路便宜。

反指標清單的用法有個紀律：逐條打勾，命中任何一條就停，不要往下找理由說服自己。選型決策最常見的失敗模式是資訊充足卻先有結論再找證據，清單的價值正是強迫你把否決條件放在讚美之前。清單也該定期重看：供應商的政策、價格與功能狀態每季都在變，上一季不成立的反指標，這一季可能就是退場警訊，把它列進季度技術盤點的固定項目，比憑記憶判斷可靠。

回到採用決策本身：K3 的價值主張是把「大脈絡、長時工作、可自架」三件事打包在一個按量計費的結構裡，前代旗艦的身分讓它的定位單純，開放權重則提供一條附條件的退場路，兩者的價值都要用你的工作負載試算與驗證。合理的試點路徑是先跑知識庫問答這種快取結構清晰的場景，用實際帳單驗證成本模型，再逐步把更重的編碼與多模態任務放上來，每一步都帶著可退場的設計。模型市場每季都在洗牌，但「先用小成本驗證、再擴大依賴」的採用紀律，在任何一季都是對的。