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

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

میزبانی شخصی Kimi K3 به معنای فراهم کردن فضا برای 2.8 تریلیون پارامتر است. Moonshot وزن‌های متن‌باز را با فرمت MXFP4 منتشر کرده است که تقریباً نیم بایت برای هر وزن است؛ بنابراین وزن‌ها به تنهایی به حدود 1.4 ترابایت می‌رسند، آن هم پیش از آنکه حتی یک توکن برای حافظه کش (cache) اختصاص دهید. هیچ شتاب‌دهنده‌ای که امروزه در بازار موجود باشد، نمی‌تواند این حجم را به تنهایی در خود جای دهد. 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-بیتی، حجم وزن‌ها را به 0.7 ترابایت می‌رساند و دقت مدل را به میزانی کاهش می‌دهد که هنوز توسط کسی روی این چک‌پوینت اندازه‌گیری نشده است. با این حال، شما همچنان بسیار فراتر از ظرفیت هر کارت گرافیک تکی خواهید بود.

Kimi K3 به چند GPU نیاز دارد

[
  {
    "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 متخصص (experts) همیشه چنین امکانی را فراهم نمی‌کنند.

دستورالعمل‌های منتشرشده بسیار بالاتر از این حداقل هستند. تا اوت 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 KiB به ازای هر توکن.

[
  {
    "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 GiB دارد. یک کاربر با متن کامل یک میلیونی، هزینه‌ای معادل 128 GiB دارد که برای یک مکالمه، از ظرفیت هر کارت گرافیک تکی بیشتر است.

مدل 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 دلار هزینه خواهد داشت.

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

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 برای tensor parallel و از --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 ذکر شده در model card را نصب کنید یا منتظر انتشار نسخه‌ای بمانید که شامل آن باشد.

یک نکته هزینه‌ای که کاربران را غافلگیر می‌کند: کنتور از لحظه شروع 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

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 اجرا می‌شوند، بنابراین به‌محض اینکه مدل دیگر در حافظه جا نشود، سرعت تولید متن به میزان یک مرتبه بزرگی کاهش می‌یابد. تفاوت‌ها و اولویت‌های بین این دو ابزار در مقایسه 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 در صورت عدم جای‌گیری مدل در حافظه گرافیکی، و هم‌روندی (concurrency) پایین است. از نظر فنی، llama.cpp می‌تواند یک مدل MoE بسیار بزرگ را با نگهداری اکثر لایه‌ها در RAM سیستم بارگذاری کند، اما برای یک مدل 2.8T، سرعت تولید در این حالت به چندین ثانیه برای هر توکن می‌رسد. این موضوع فقط ثابت می‌کند که فایل قابل پارس است، نه اینکه سرویسی باشد که بتوانید کاربران را روی آن قرار دهید. مقایسه کامل در Ollama در برابر vLLM آمده است و این مقایسه با تغییر مدل عوض نمی‌شود: پرسش همواره این است که آیا به کاربران زیادی روی سخت‌افزار اشتراکی سرویس می‌دهید یا به یک کاربر روی سخت‌افزار شخصی خودتان.

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

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

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

FAQ

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

خیر. وزن‌های مدل در دقت MXFP4 که توسط Moonshot عرضه شده است، حدود 1.4 ترابایت است و بزرگ‌ترین شتاب‌دهنده موجود در بازار تنها 288 گیگابایت حافظه دارد. یک مدل MoE نمی‌تواند expertهای غیرفعال خود را با سرعتی قابل‌استفاده از دیسک فراخوانی کند، زیرا router ممکن است برای هر token هر expertای را انتخاب کند و زمان واکشی از طریق 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 گیگابایت حافظه را منتشر کرده است؛ بنابراین عدد مربوط به وزن‌ها را به‌عنوان حداقل کفِ نیاز در نظر بگیرید، نه کل نیاز.

آیا کوانتایزیشن (quantisation) باعث می‌شود Kimi K3 روی یک گره جا شود؟

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

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

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

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

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