| 想自架,應該由 K2.6 專屬部署文件開始睇。 |
| Hugging Face 模型頁 | Kimi K2.6 模型頁包括 Deployment 同 | 部署唔只係第三方討論,而係模型文件一部分。 |
| vLLM Recipes | vLLM 有 moonshotai/Kimi-K2.6 專頁,並標示 | vLLM 係相關 serving 路線;模型規模同 context 長度對硬件規劃好關鍵。 |
| Unsloth | Unsloth 有頁面題為 | 生態入面已有本機運行教學路線。 |
| Kimi API Platform | Moonshot 亦提供 Kimi K2.6 API quickstart。 | 如果唔想自己營運推理基建,託管 API 係低維運成本選項。 |
最穩陣嘅答案係:先睇 K2.6 專屬文件。自架部署方面,優先對照 Hugging Face 嘅 K2.6 deployment guidance 同 K2.6 vLLM recipe;如果你想跟本機 workflow,可以再比較 Unsloth 嘅 K2.6 local-run guide。
vLLM 明顯係一條相關路線,因為 vLLM Recipes 有 Kimi K2.6 專頁。 但要留神:目前摘錄入面見到最具體嘅
vllm serve--trust-remote-code、--tokenizer-mode auto
所以,vLLM、分散式 serving、BF16、FP8 呢啲可以作為理解 Kimi 部署生態嘅背景;但唔可以因此推斷 Kimi K2.6 一定要用完全相同 flags、相同拓撲或者相同硬件規模去啟動。
現有來源能夠支持「K2.6 有部署同本機運行文件」,但未能喺摘錄中確認以下細節:
呢啲唔係小問題。vLLM 嘅 K2.6 頁面將模型標示為 1T / 32B active · MOE · 256K ctx 因此,硬件 sizing、context length、quantization 同 serving 參數都應該以最新 K2.6 文件為準,而唔係由較舊 Kimi K2 範例估出嚟。
Kimi K2.6 唔應該被形容成「只能用 API」。現有文件指向 Hugging Face、vLLM、Unsloth 等本機或自架部署路線,同時亦有 Moonshot 官方 Kimi API 途徑。
真正未解決嘅係硬件門檻同精確啟動配置。未買 GPU、租 cluster,或者照抄另一個 Kimi 模型嘅 command 之前,最好先核對最新 K2.6 專屬 deployment guidance 同 recipe 頁面。
Comments
0 comments