راهنمای میزبانی شخصی مدل Kimi K3 و پیش‌نیازهای سخت‌افزاری

پیش‌نیازهای میزبانی شخصی Kimi K3

میزبانی شخصی Kimi K3 به معنای فراهم کردن فضا برای 2.8 تریلیون پارامتر است. Moonshot وزن‌های متن‌باز را با فرمت MXFP4 منتشر کرده است که تقریباً نیم بایت برای هر وزن است؛ بنابراین وزن‌ها به‌تنهایی پیش از تخصیص حتی یک توکن برای حافظه کش (cache)، به حدود 1.4 ترابایت می‌رسند. هیچ شتاب‌دهنده‌ای که امروزه در بازار موجود باشد، به‌تنهایی چنین ظرفیتی ندارد. K3 یک مدل چند-گره‌ای (multi-node) است و پاسخ برای یک سرور واحد، منفی است.

این حکم نهایی است. تمام مطالب زیر محاسبات ریاضی پشت این موضوع است، زیرا این محاسبات همان بخشی است که در نسخه بعدی دوباره به کار خواهید برد. چندین فروشنده زیرساخت در هفته‌های پس از اعلامیه 17 July 2026 راهنماهای استقرار K3 را منتشر کردند و هر کدام فرض را بر این گذاشتند که شما از قبل یک کلاستر در اختیار دارید. این صفحه از سمت دیگر شروع می‌شود: هزینه‌ها چقدر است، چه چیزی را می‌توانید به‌جای آن اجرا کنید و چگونه تشخیص دهید که در کدام‌یک از این دو وضعیت قرار دارید.

تعداد پارامترهای کل و پارامترهای فعال یکسان نیستند

مدل K3 یک مدل Mixture of Experts یا به اختصار MoE است. مدل‌های MoE شبکه را به زیرشبکه‌های متعددی تقسیم می‌کنند و به یک مسیریاب (router) اجازه می‌دهند برای هر توکن، تعداد کمی از آن‌ها را انتخاب کند. کارت مدل، 2.8T پارامتر کل و 104B پارامتر فعال به ازای هر توکن را ذکر کرده است که از میان 896 متخصص (expert) مسیریابی‌شده انتخاب می‌شوند؛ به‌طوری که برای هر توکن مشخص، 16 متخصص در 93 لایه فعال می‌شوند.

این دو عدد پارامتر به پرسش‌های متفاوتی پاسخ می‌دهند و جابه‌جا گرفتن آن‌ها، رایج‌ترین اشتباه در تمام بحث‌های مربوط به «آیا می‌توانم این مدل را اجرا کنم» است.

پارامترهای فعال، هزینه محاسباتی را تعیین می‌کنند. یک توکن در حدود 104B پارامتر ضرب می‌شود، بنابراین خروجی (throughput) مورد انتظار شما مشابه یک مدل متراکم 104B است، نه یک مدل 2.8T. دلیل اصلی ساخت مدل‌های MoE دقیقاً همین است.

پارامترهای کل، هزینه حافظه را تعیین می‌کنند. مسیریاب ممکن است برای هر توکن، هر متخصصی را انتخاب کند؛ بنابراین تمام متخصص‌ها باید پیش از رسیدن اولین درخواست، در حافظه مستقر باشند. شما نمی‌توانید 104B پارامتر را در VRAM نگه دارید و بقیه را در صورت نیاز فراخوانی کنید، زیرا این فراخوانی باید در چند میکروثانیه انجام شود، در حالی که پهنای باند لینک PCIe ده‌ها گیگابایت در ثانیه است. برخی افراد این کار را امتحان می‌کنند. استریم کردن متخصص‌ها از روی NVMe، مدلی را که باید ده‌ها توکن در ثانیه تولید کند، به مدلی تبدیل می‌کند که هر چند ثانیه یک توکن تولید می‌کند.

بنابراین، محاسبه آن ارزان و ذخیره‌سازی آن گران است. سخت‌افزار خود را بر اساس 2.8T و انتظارات سرعت خود را بر اساس 104B تنظیم کنید.

بایت به ازای هر وزن و منشأ ترابایت‌ها

تعداد پارامترها ضرب‌در بایت به ازای هر وزن. برای وزن‌ها، فرمول کلی همین است.

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

مدل K3 با آگاهی از کوانتایزیشن (quantisation aware) آموزش دیده و با وزن‌های MXFP4 و اکتیویشن‌های MXFP8 عرضه شده است، بنابراین ردیف 4-bit مقدار واقعی است. ردیف‌های بالاتر برای مقیاس‌سنجی آورده شده‌اند: در حالت bf16، همین مدل به 5.6 ترابایت فضا نیاز داشت. MXFP4 همچنین یک مقیاس (scale) 8-بیتی مشترک برای هر بلوک 32 تایی از وزن‌ها ذخیره می‌کند که حدود 6 درصد به حجم اضافه می‌کند؛ بنابراین مخزن منتشرشده به جای 1.4 ترابایت خالص، به 1.5 ترابایت نزدیک‌تر است.

این موضوع راه فرار معمول را می‌بندد. «فقط آن را کوانتایز کن» در اینجا کمکی نمی‌کند، زیرا چک‌پوینت منتشرشده همین حالا هم 4-بیتی است. کاهش به 2-bit، وزن‌ها را به 0.7 ترابایت می‌رساند و دقت مدل را به میزانی کاهش می‌دهد که هنوز کسی روی این چک‌پوینت اندازه‌گیری نکرده است. شما همچنان بسیار فراتر از ظرفیت هر کارت گرافیک تکی خواهید بود.

تعداد GPUهای مورد نیاز برای Kimi K3

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

این اعداد را به عنوان حداقل کفِ نیاز در نظر بگیرید، نه هدف نهایی. این ارقام فقط وزن‌ها را محاسبه می‌کنند: بدون در نظر گرفتن KV cache، بافرهای فعال‌سازی (activation buffers)، قطعه‌قطعه شدن حافظه توسط تخصیص‌دهنده (allocator fragmentation) و بدون فضای کافی برای پردازش همزمان درخواست دوم. همچنین، این محاسبات فرض را بر تقسیم موازیِ کاملاً متقارن می‌گذارند، در حالی که 93 لایه و 896 متخصص (expert) همیشه چنین اجازه‌ای نمی‌دهند.

توصیه‌های رسمی منتشرشده بسیار بالاتر از این حداقل هستند. تا اوت 2026، Moonshot استفاده از یک supernode با 64 شتاب‌دهنده یا بیشتر را توصیه می‌کند. همچنین، دستورالعمل SGLang یک پیکربندی H100 را ارائه می‌دهد که از چهار نودِ 8-GPU، مجموعاً 32 GPU و 2560 گیگابایت حافظه تشکیل شده است، در حالی که حداقلِ مورد نیاز 18 کارت است. این فاصله هدررفت نیست؛ بلکه مربوط به KV cache، حافظه فعال‌سازی و فضای خالی (headroom) است که به سرور اجازه می‌دهد چندین درخواست را به‌طور همزمان دسته‌بندی (batch) کند. حتی در بهینه‌ترین حالت، یعنی کارت‌های کلاس 5 GB300، توصیف‌کننده ماشینی است که اکثر ارائه‌دهندگان خدمات ابری آن را به عنوان یک SKU واحد اجاره نمی‌دهند.

کش KV بخشی است که باعث تعجب افراد می‌شود

وزن‌ها هزینه‌ای ثابت هستند. اما کش KV (کلید-مقدار) این‌طور نیست: این کش با طول متن (context length) و همچنین با هر کاربر همزمان رشد می‌کند. برای مکانیزم توجه (attention) معمولی، فرمول bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element است و سپس باید آن را در طول متن و تعداد کاربران همزمان ضرب کنید.

در اینجا یک مثال عملی آورده شده است، که البته فقط یک مثال است: 64 لایه، 8 هد KV، ابعاد هد 128، با فرمت fp8. این مقادیر برابر است با 2 64 8 128 1 = 131,072 بایت، یعنی 128 کیلوبایت به ازای هر توکن.

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

یک کاربر با متن 128k هزینه‌ای معادل 16 گیگابایت دارد. یک کاربر با متن کامل یک میلیون توکنی، هزینه‌ای معادل 128 گیگابایت دارد که برای یک مکالمه، از ظرفیت هر کارت گرافیک تکی بیشتر است.

مدل K3 از مکانیزم توجه معمولی استفاده نمی‌کند و عدد آخر، دلیل آن است. 93 لایه این مدل شامل 69 لایه KDA (مخفف Kimi Delta Attention) و 24 لایه Gated MLA (مخفف multi-head latent attention) است. KDA به جای کشی که با هر توکن رشد می‌کند، یک وضعیت بازگشتی (recurrent state) با اندازه ثابت نگه می‌دارد و MLA کلید و مقدار را در یک بردار نهفته (latent vector) با رتبه پایین فشرده می‌کند، بنابراین هزینه واقعی به ازای هر توکن بسیار کمتر از مثال عملی فوق است. شرکت Moonshot ابعاد فضای نهفته را منتشر نکرده است، بنابراین من عدد مشخصی برای هر کاربر در مورد خود K3 ارائه نمی‌دهم. در عوض، خودتان اندازه‌گیری کنید: سرور را با یک --max-model-len کوچک شروع کنید، حافظه را با nvidia-smi زیر نظر بگیرید و سپس محدودیت را تا زمانی که تخصیص حافظه با شکست مواجه شود، افزایش دهید.

شکل استدلال در نسخه بعدی نیز حفظ می‌شود. اگر مدلی ادعای پشتیبانی از متن یک میلیون توکنی را دارد و هیچ توضیحی درباره طراحی مکانیزم توجه خود نمی‌دهد، فرض کنید که کش، محدودیت اصلی (binding constraint) است، مگر اینکه خلاف آن ثابت شود.

سطح 1: اجاره کلاستر به صورت ساعتی

این تنها سطحی است که K3 را مستقیماً اجرا می‌کند. شما سخت‌افزار را خریداری نمی‌کنید، بلکه آن را برای ساعات مورد نیاز اجاره کرده و پس از اتمام کار، آن را متوقف می‌کنید.

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

این نرخ یک فرض است، نه یک قیمت قطعی. قیمت‌های لیست‌شده برای شتاب‌دهنده‌های دیتاسنتر در سال 2026 تقریباً بین 2 تا 5 دلار به ازای هر ساعت GPU بوده است و ظرفیت‌های رزرو شده ارزان‌تر هستند. عدد واقعی ارائه‌دهنده خود را بردارید و ضرب را دوباره انجام دهید: تعداد GPUها ضرب‌در ساعت‌ها ضرب‌در نرخ. هدف این جدول نشان دادن نسبت است. اجرای یک نود با 8 عدد GPU به مدت چهار ساعت در روز، ماهیانه 2,400 دلار هزینه دارد، در حالی که روشن نگه داشتن پیکربندی 32 عدد GPU برای SGLang، ماهیانه 57,600 دلار هزینه در بر دارد.

هر دو سرور اصلی، یک دستور راه‌اندازی را در کارت مدل منتشر می‌کنند.

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

هیچ‌کدام از این دستورات خام، چیزی نیستند که شما روی یک کلاستر واقعی اجرا می‌کنید. فلگ‌های موازی‌سازی (parallelism) متناسب با سخت‌افزار خود را اضافه کنید: SGLang از --tp-size برای موازی‌سازی تانسور و --ep-size برای موازی‌سازی متخصص (expert parallel) استفاده می‌کند و حاصل‌ضرب این دو باید با تعداد GPUهایی که واقعاً در اختیار دارید برابر باشد.

پیش از ارسال ترافیک واقعی، بررسی کنید که سرور بالا آمده باشد:

curl http://127.0.0.1:30000/v1/models

یک سرور سالم با یک شیء JSON که شناسه مدل را لیست می‌کند، پاسخ می‌دهد. Connection refused به این معنی است که فرآیند هنوز در حال بارگذاری وزن‌هاست یا از قبل خارج شده است؛ بنابراین پیش از تلاش مجدد، لاگ سرور را بخوانید.

خطای رایج در روز اول، قدیمی بودن runtime نسبت به مدل است. K3 با KDA و یک لایه MoE جدید عرضه شد که نسخه‌های پایدار vLLM و SGLang در زمان انتشار آن را نداشتند. نشانه این مشکل، خروج سرور در حین راه‌اندازی با خطی به فرم Model architectures [...] are not supported for now است. هیچ تغییر پیکربندی‌ای این مشکل را حل نمی‌کند، زیرا کد لازم برای اجرای آن لایه‌ها در build شما وجود ندارد. نسخه nightly که در کارت مدل ذکر شده را نصب کنید یا منتظر نسخه‌ای بمانید که آن را شامل می‌شود.

یک نکته هزینه‌ای که کاربران را غافلگیر می‌کند: کنتور از لحظه شروع instance شروع به کار می‌کند، نه از لحظه آماده شدن مدل. دانلود 1.5 ترابایت با سرعت 1 گیگابایت بر ثانیه، حدود 25 دقیقه از زمان کلاستر را پیش از تولید اولین توکن مصرف می‌کند. وزن‌ها را روی یک volume که عمر آن از instance بیشتر است ذخیره کنید تا اجرای دوم در عرض چند دقیقه آغاز شود.

لایه 2: اجرای یک مدل کوچک‌تر روی یک شتاب‌دهنده

در این لایه، شما K3 را اجرا نمی‌کنید. پیش از شروع، این موضوع را با صدای بلند اعلام کنید، زیرا اکثر بحث‌های «اجرای محلی K3» بدون اعتراف به این نکته در همین‌جا به پایان می‌رسند.

قانون تناسب، همان فرمول قبلی در مقیاس کوچک‌تر است: تعداد پارامترها ضرب‌در بایت به ازای هر وزن، به‌علاوه KV cache، به‌علاوه حدود 2 GB سربار زمان اجرا، باید کمتر از VRAM شما باشد. در حالت 4-bit، این مقدار تقریباً نیم بایت به ازای هر پارامتر است که ترکیب‌های مناسبی را ارائه می‌دهد:

• کارت 16 GB: مدل 7B با دقت 4-bit و فضای کافی برای context طولانی
• کارت 24 GB: مدل 14B با دقت 4-bit
• کارت 48 GB: مدل 32B با دقت 4-bit
• کارت 80 GB: مدل 70B با دقت 4-bit، یا مدل MoE کلاس 30B با دقت 8-bit

تمام ترکیب‌های بالا فرض را بر یک درخواست در لحظه می‌گذارند. به محض اینکه نفر دوم یک prompt ارسال کند، هر slot همزمان به KV cache اختصاصی خود نیاز دارد؛ این همان مبادله‌ای است که تنظیمات NUM_PARALLEL و MAX_QUEUE در Ollama برای شما بین slotهای موازی، درخواست‌های در صف و VRAM باقی‌مانده انجام می‌دهد.

Ollama کوتاه‌ترین مسیر برای داشتن یک سرور فعال روی یک VPS مجهز به GPU است:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run مدل را در اولین استفاده دانلود می‌کند و سپس شما را به یک prompt می‌برد. تگی که وجود نداشته باشد، خطای Error: model "..." not found برمی‌گرداند، بنابراین تگ‌ها را از صفحه کتابخانه کپی کنید و از حفظ تایپ نکنید. راهنمای کامل، شامل unit مربوط به systemd و دسترسی از راه دور، در اجرای Ollama روی VPS موجود است.

ابزار llama.cpp کنترل بیشتری روی quantisation و offload به شما می‌دهد:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

-ngl 99 درخواست می‌کند که تمام لایه‌ها روی GPU قرار گیرند. لاگ بارگذاری را بخوانید: این لاگ تعداد لایه‌های offload شده را چاپ می‌کند. لایه‌هایی که به RAM سیستم سرریز می‌شوند، به جای پهنای باند HBM از پهنای باند RAM استفاده می‌کنند، بنابراین به محض اینکه مدل دیگر در VRAM جا نشود، سرعت تولید متن به شدت کاهش می‌یابد. مبادلات بین این دو ابزار در مقایسه Ollama و llama.cpp بررسی شده است.

سطح 3: API میزبانی‌شده، ارکستراسیون خودمیزبان

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

این endpoint با OpenAI سازگار است، بنابراین کلاینت موجود پس از تغییر base URL به درستی کار می‌کند.

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

یک کلید معتبر، یک شیء JSON حاوی آرایه choices برمی‌گرداند. خطای 401 به این معناست که کلید اشتباه است یا پیشوند Bearer وجود ندارد. خطای model-not-found معمولاً به این معنی است که شناسه تغییر کرده است، زیرا ارائه‌دهندگان، شناسه‌ها را در فواصل بین checkpointها بازنشسته می‌کنند.

حال نقطه سربه‌سر را با استفاده از نرخ اجاره فرض‌شده در بالا محاسبه می‌کنیم. یک نود با 8 پردازنده گرافیکی که همیشه روشن است، ماهیانه 14,400 دلار هزینه دارد و با نرخ 15.00 دلار به ازای هر میلیون توکن خروجی، همین مبلغ معادل خرید حدود 960 میلیون توکن خروجی از API است. برای صرفه اقتصادی، باید نزدیک به یک میلیارد توکن خروجی در ماه، یعنی تقریباً 30 میلیون توکن در روز تولید کنید و کلاستر را در تمام مدت مشغول نگه دارید، زیرا پردازنده‌های گرافیکی بیکار نیز با همان نرخ پردازنده‌های مشغول محاسبه هزینه می‌شوند. بارهای کاری عامل‌محور (agent workloads) که متکی بر promptهای سنگین هستند، این مرز را باز هم دورتر می‌کنند: متن‌های تکراری (context) با نرخ کش‌هیت (cache-hit) یعنی 0.30 دلار به ازای هر میلیون توکن محاسبه می‌شوند، نه نرخ کش‌میس (cache-miss) که 3.00 دلار است.

آنچه در این سطح خودمیزبان می‌کنید، تمام اجزای پیرامون مدل است: یک gateway که کلید API را نگه می‌دارد تا هرگز به کلاینت نرسد، لاگ‌های درخواست و پاسخ، مکانیزم‌های تلاش مجدد (retries)، محدودیت نرخ (rate limits) و بودجه‌بندی به ازای هر کاربر. این بخش روی یک VPS کوچک بدون نیاز به پردازنده گرافیکی اجرا می‌شود. همین تفکیک برای مدل‌های با وزن بسته (closed weights) نیز صدق می‌کند، جایی که خودمیزبانی Claude در سطح مدل امکان‌پذیر نیست و ارکستراسیون تنها بخشی است که شما مالکیت آن را در اختیار دارید.

کدام پشتهٔ سرویس‌دهی به کدام لایه تعلق دارد

سرورهای کلاس vLLM و SGLang به لایه 1 تعلق دارند. هدف آن‌ها پاسخ‌دهی به تعداد زیادی درخواست به‌صورت هم‌زمان، با استفاده از قابلیت continuous batching و paged KV cache، به همراه tensor parallelism و expert parallelism در چندین گره (node) است. این ابزارها فرض را بر وجود شتاب‌دهنده‌های دیتاسنتر و اتصالات سریع بین آن‌ها می‌گذارند. روی یک کارت گرافیک مصرفی (consumer card)، نصب آن‌ها سنگین‌تر است و مزیت قابل‌توجهی برای شما نخواهند داشت.

ابزارهای llama.cpp و Ollama به لایه 2 تعلق دارند. تمرکز این ابزارها بر یک ماشین واحد، کوانتایزیشن GGUF، انتقال بار به CPU در صورت عدم جای‌گیری مدل در VRAM، و هم‌زمانی (concurrency) پایین است. از نظر فنی، llama.cpp می‌تواند یک مدل MoE بسیار بزرگ را با نگه داشتن اکثر لایه‌ها در RAM سیستم بارگذاری کند، اما برای یک مدل 2.8T، سرعت تولید در این حالت به ثانیه برای هر توکن می‌رسد. این فقط ثابت می‌کند که فایل قابل پارس است؛ این سرویسی نیست که بتوانید کاربران را روی آن قرار دهید. مقایسه کامل در مقایسه Ollama با vLLM آمده است و با تغییر مدل نیز تغییری نمی‌کند: پرسش اصلی همیشه این است که آیا به تعداد زیادی کاربر روی سخت‌افزار اشتراکی سرویس می‌دهید یا به یک کاربر روی سخت‌افزار شخصی خودتان.

چهار عددی که از این نقطه بازرسی فراتر می‌روند

1. حاصل‌ضرب تعداد کل پارامترها در بایت‌های هر وزن، حداقل حافظه مورد نیاز را تعیین می‌کند. هیچ پردازشی کمتر از این مقدار اجرا نمی‌شود و هنگامی که نسخه از قبل 4-bit باشد، هیچ ترفند کوانتایزیشنی نمی‌تواند این مقدار را به‌طور قابل‌توجهی تغییر دهد.
2. پارامترهای فعال، کلاس توان عملیاتی (throughput) را مشخص می‌کنند. یک مدل 2.8T MoE با 104B پارامتر فعال، مشابه یک مدل 104B محاسبه انجام می‌دهد.
3. حافظه KV cache به ازای هر توکن، ضرب‌در طول کانتکست و ضرب‌در همزمانی (concurrency)، هزینه‌ای است که پس از پرداخت هزینه وزن‌ها، همچنان در حال افزایش است.
4. تعداد توکن بر ثانیه به ازای هر دلار، تنها عددی است که یک رده (tier) را تعیین می‌کند. تمام موارد فوق، ورودی‌های این محاسبه هستند.

این چهار مورد را برای هر نسخه اعمال کنید تا پیش از باز کردن راهنمای فروشنده، به پاسخ درست برسید. سپس برای هر رقمی که یادداشت می‌کنید، تاریخ بزنید. قیمت‌ها و لیست معماری‌های پشتیبانی‌شده، هر دو در طول دو هفته پس از عرضه K3 تغییر کردند و تمام اعداد موجود در این صفحه، ارقامی هستند که در ژوئیه 2026 منتشر شده‌اند.

FAQ

آیا می‌توانم Kimi K3 را روی یک GPU اجرا کنم؟

خیر. وزن‌های مدل در دقت MXFP4 که Moonshot ارائه می‌دهد، حدود 1.4 ترابایت است و بزرگ‌ترین شتاب‌دهنده موجود در بازار 288 گیگابایت حافظه دارد. یک مدل MoE نمی‌تواند expertهای غیرفعال خود را با سرعت مناسب از دیسک فراخوانی کند، زیرا router ممکن است برای هر token هر expertای را انتخاب کند و زمان لازم برای fetch از طریق PCIe بسیار طولانی‌تر از بودجه زمانی هر token است. کوچک‌ترین استقرار منطقی برای K3 یک node چند GPU است و دستورالعمل‌های منتشرشده از 32 شتاب‌دهنده یا بیشتر استفاده می‌کنند.

Kimi K3 به چه مقدار VRAM نیاز دارد؟

تنها برای وزن‌ها از 1.4 ترابایت شروع کنید که معادل 18 کارت H100 80GB یا 5 کارت کلاس GB300 است. سپس باید حافظه KV cache و activation را نیز به آن اضافه کنید. تا اوت 2026، Moonshot استفاده از 64 شتاب‌دهنده یا بیشتر را توصیه می‌کند و کتابچه راهنمای SGLang یک پیکربندی 32 GPU از نوع H100 با مجموع 2,560 گیگابایت حافظه را منتشر کرده است؛ بنابراین عدد مربوط به وزن‌ها را به عنوان حداقل کفِ نیاز در نظر بگیرید، نه کل نیاز.

آیا کوانتیزاسیون باعث می‌شود Kimi K3 روی یک node جا شود؟

به‌صورت کاربردی خیر. checkpoint منتشرشده هم‌اکنون 4-bit است و با آموزش آگاه از کوانتیزاسیون (quantisation-aware training) تهیه شده، بنابراین صرفه‌جویی‌های آسان انجام شده است. کاهش مجدد به 2-bit وزن‌ها را به 0.7 ترابایت می‌رساند که همچنان بیش از دو برابر ظرفیت بزرگ‌ترین کارت موجود است و هزینه افت دقت در 2-bit روی این مدل اندازه‌گیری نشده است.

آیا اجاره GPU ارزان‌تر از API مدل Kimi K3 است؟

فقط در حجم کاری بالا و مداوم. با فرض هزینه 2.50 دلار برای هر ساعت GPU، یک node با 8 GPU که همیشه روشن باشد، ماهانه 14,400 دلار هزینه دارد. با همین مبلغ می‌توان حدود 960 میلیون token خروجی با نرخ اعلام‌شده 15.00 دلار به ازای هر میلیون token خریداری کرد. همچنین باید هزینه‌های زمان‌های بیکاری، دانلود وزن‌ها و نیروی انسانی برای نگهداری کلاستر را نیز در نظر بگیرید. برای بارهای کاری مقطعی، از اجاره ساعتی استفاده کنید و هزینه‌ها را بر اساس حجم token مصرفی واقعی خود مقایسه کنید، نه بر اساس حدس و گمان.

104B پارامتر فعال برای سرعت به چه معناست؟

این یعنی محاسبات ریاضی برای هر token معادل یک مدل 104B است، بنابراین throughput در آن کلاس قرار می‌گیرد، نه در کلاس 2.8T. این موضوع ارتباطی به حافظه ندارد: تمام 2.8T پارامتر باید در حافظه مقیم باشند، زیرا router ممکن است برای هر token هر expertای را فراخوانی کند. از تعداد پارامترهای فعال برای پیش‌بینی تعداد token در ثانیه و از تعداد کل پارامترها برای تعیین اندازه VRAM استفاده کنید.