Kimi K3-ஐ self-host செய்வது எப்படி? முழுமையான வழிகாட்டி

Kimi K3-ஐ self-host செய்வதற்குத் தேவையானவை

Kimi K3-ஐ self-host செய்வது என்பது 2.8 டிரில்லியன் parameters-க்கு இடம் கண்டறிவதாகும். Moonshot இதன் open weights-ஐ MXFP4 வடிவில் வெளியிட்டுள்ளது; இது ஒரு weight-க்கு அரை byte அளவு கொண்டது. எனவே, cache-க்கு ஒரு token-ஐ ஒதுக்குவதற்கு முன்பே, weights மட்டுமே தோராயமாக 1.4 TB அளவு வரும். இன்று விற்பனையில் உள்ள எந்தவொரு accelerator-ம் இதைத் தனியாகத் தாங்காது. K3 என்பது ஒரு multi-node model ஆகும்; எனவே, ஒரு server-ல் இதை இயக்குவது சாத்தியமில்லை.

இதுவே இறுதி முடிவு. கீழே உள்ளவை இதற்கான கணக்கீடுகள்; ஏனெனில், அடுத்தடுத்த releases-ல் நீங்கள் இதே கணக்கீட்டு முறையைத்தான் பயன்படுத்த வேண்டியிருக்கும். 17 July 2026 அன்று அறிவிப்பு வெளியான சில வாரங்களிலேயே, பல infrastructure vendors K3 deployment வழிகாட்டிகளை வெளியிட்டனர். அவை ஒவ்வொன்றும் உங்களிடம் ஏற்கனவே ஒரு cluster இருப்பதாகவே கருதுகின்றன. இந்தப் பக்கம் மறுமுனையிலிருந்து தொடங்குகிறது: இதற்கு ஆகும் செலவு என்ன, அதற்குப் பதிலாக எதை இயக்கலாம், மற்றும் இந்த இரண்டில் நீங்கள் எந்த நிலையில் இருக்கிறீர்கள் என்பதை எவ்வாறு கண்டறிவது என்பது குறித்து இங்கே காண்போம்.

மொத்த அளவுருக்களும் (total parameters) செயல்படும் அளவுருக்களும் (active parameters) சமமானவை அல்ல

K3 என்பது ஒரு mixture of experts (MoE) மாதிரி ஆகும். MoE என்பது ஒரு network-ஐ பல sub-networks-ஆகப் பிரித்து, ஒவ்வொரு token-க்கும் ஒரு router மூலம் சிலவற்றை மட்டும் தேர்வு செய்ய அனுமதிக்கும் முறையாகும். இந்த மாதிரியின் விவரக்குறிப்பில் 2.8T மொத்த அளவுருக்களும், ஒவ்வொரு token-க்கும் 104B செயல்படும் அளவுருக்களும் இருப்பதாகக் குறிப்பிடப்பட்டுள்ளது. இது 93 layers-ல் பரவியுள்ள 896 routed experts-ல், ஒவ்வொரு token-க்கும் 16 experts-ஐப் பயன்படுத்துகிறது.

இந்த இரண்டு அளவுரு எண்ணிக்கைகளும் வெவ்வேறு கேள்விகளுக்குப் பதிலளிக்கின்றன. "இதை என்னால் இயக்க முடியுமா?" என்ற விவாதங்களில் இவற்றைத் தவறுதலாகக் குழப்பிக்கொள்வதுதான் மிகப்பொதுவான பிழை.

செயல்படும் அளவுருக்கள் (Active parameters) கணக்கீட்டுச் செலவைத் தீர்மானிக்கின்றன. ஒரு token சுமார் 104B அளவுருக்கள் வழியாகப் பெருக்கப்படுவதால், நீங்கள் எதிர்பார்க்கும் throughput என்பது 2.8T மாதிரியைப் போன்றதல்ல, 104B dense மாதிரியைப் போன்றதே. இதுவே MoE மாதிரிகளை உருவாக்குவதற்கான முழுமையான நோக்கமாகும்.

மொத்த அளவுருக்கள் (Total parameters) நினைவகச் செலவைத் (memory cost) தீர்மானிக்கின்றன. எந்தவொரு token-க்கும் router எந்த expert-ஐ வேண்டுமானாலும் தேர்வு செய்யலாம் என்பதால், முதல் கோரிக்கை வருவதற்கு முன்பே அனைத்து experts-ம் நினைவகத்தில் இருக்க வேண்டும். 104B அளவுருக்களை மட்டும் VRAM-ல் வைத்துக்கொண்டு, மற்றவற்றைத் தேவைப்படும்போது பெற்றுக்கொள்ள முடியாது. ஏனெனில், அந்தத் தரவுப் பரிமாற்றம் மைக்ரோ விநாடிகளில் முடிய வேண்டும், ஆனால் PCIe link விநாடிக்குச் சில gigabytes-ஐ மட்டுமே நகர்த்தும். சிலர் இதை முயற்சி செய்கிறார்கள். NVMe-லிருந்து experts-ஐ streaming செய்வது, விநாடிக்கு டஜன் கணக்கான tokens-ஐ உருவாக்கும் ஒரு மாதிரியை, சில விநாடிகளுக்கு ஒரு token-ஐ உருவாக்கும் அளவுக்கு மந்தமாக்கிவிடும்.

எனவே, இதைக் கணக்கிடுவது மலிவானது, ஆனால் சேமித்து வைப்பது செலவு மிக்கது. உங்கள் hardware-ஐ 2.8T அளவுக்கு ஏற்பத் திட்டமிடுங்கள். உங்கள் வேக எதிர்பார்ப்புகளை 104B அளவுக்கு ஏற்ப வைத்துக்கொள்ளுங்கள்.

எடைக்கு ஏற்ப பைட்டுகள் மற்றும் டெராபைட்டுகள் எங்கிருந்து வருகின்றன

அளவுருக்களின் எண்ணிக்கை (parameter count) மற்றும் ஒரு எடைக்கான பைட்டுகளின் பெருக்கற்பலனே இதற்கான முழுமையான சூத்திரம்.

[
  {
    "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-ஐ உணர்ந்தவாறு (quantisation aware) பயிற்றுவிக்கப்பட்டு, MXFP4 எடைகள் மற்றும் MXFP8 ஆக்டிவேஷன்களுடன் வெளியிடப்பட்டது. எனவே, 4-bit வரிசையே உண்மையானது. அதற்கு மேல் உள்ள வரிசைகள் ஒப்பீட்டிற்காக வழங்கப்பட்டுள்ளன: bf16 வடிவில் இதே மாதிரிக்கு 5.6 TB தேவைப்படும். MXFP4 ஒவ்வொரு 32 எடைகள் கொண்ட தொகுதிக்கும் ஒரு 8-bit அளவுகோலைப் (shared scale) பகிர்ந்து சேமிக்கிறது. இது சுமார் 6 சதவீத கூடுதல் இடத்தைப் பிடிக்கும். எனவே, வெளியிடப்பட்ட களஞ்சியம் (repository) துல்லியமான 1.4 TB-ஐ விட 1.5 TB-க்கு அருகிலேயே உள்ளது.

இது வழக்கமான தப்பிக்கும் வழியை அடைத்துவிடுகிறது. "வெறுமனே quantise செய்யுங்கள்" என்பது இங்கே உதவாது, ஏனெனில் வெளியிடப்பட்ட checkpoint ஏற்கனவே 4-bit அளவில் உள்ளது. 2-bit அளவுக்குக் குறைத்தால், எடைகள் 0.7 TB-க்கு வரும், ஆனால் இந்த checkpoint-ல் யாரும் அளவிடாத துல்லிய இழப்பு ஏற்படும். அப்படியிருந்தாலும், அது எந்தவொரு தனிப்பட்ட கார்டின் (single card) திறனையும் தாண்டிவிடும்.

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
  }
]

இவற்றை இலக்காகக் கொள்ளாமல், குறைந்தபட்சத் தேவையாகக் கருதவும். இவை எடைகளை (weights) மட்டுமே கணக்கிடுகின்றன: KV cache, activation buffers, allocator fragmentation அல்லது ஒரே நேரத்தில் வரும் இரண்டாவது கோரிக்கையை இவை கணக்கில் கொள்ளவில்லை. மேலும், இவை பாராமீட்டர்கள் சமமாகப் பிரிக்கப்படுவதாகக் கருதுகின்றன, ஆனால் 93 layers மற்றும் 896 experts எப்போதும் அவ்வாறு பிரிவதற்கு அனுமதிப்பதில்லை.

வெளியிடப்பட்ட வழிகாட்டுதல்கள் இந்த குறைந்தபட்சத் தேவையை விட அதிகமாகவே உள்ளன. ஆகஸ்ட் 2026 நிலவரப்படி, Moonshot 64 அல்லது அதற்கு மேற்பட்ட accelerators கொண்ட supernode-ஐப் பரிந்துரைக்கிறது. SGLang cookbook, 18 கார்டுகள் என்ற குறைந்தபட்சத் தேவைக்கு மாறாக, நான்கு 8-GPU nodes, 32 GPUs மற்றும் 2,560 GB மொத்த நினைவகம் கொண்ட H100 கட்டமைப்பைப் பயன்படுத்துகிறது. இந்த இடைவெளி வீணானதல்ல. இது KV cache, activation memory மற்றும் ஒரே நேரத்தில் பல கோரிக்கைகளைச் செயலாக்க server-க்குத் தேவையான கூடுதல் திறன் (headroom) ஆகும். மிகக் குறைந்த தேவையாகக் கருதப்படும் 5 GB300 ரக கார்டுகள் கூட, பெரும்பாலான service providers ஒரே SKU-வாக வாடகைக்கு விடாத ஒரு இயந்திரத்தையே குறிக்கின்றன.

KV cache என்பதுதான் பலரை ஆச்சரியப்படுத்தும் பகுதி

Weights என்பது நிலையான செலவு. ஆனால் KV (key value) cache அப்படி அல்ல: இது context length மற்றும் ஒரே நேரத்தில் பயன்படுத்தும் பயனர்களின் எண்ணிக்கையைப் பொறுத்து வளரும். சாதாரண attention-க்கு இதற்கான சூத்திரம் bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element ஆகும், இதை context length மற்றும் concurrency ஆகியவற்றால் பெருக்க வேண்டும்.

இதோ ஒரு உதாரணம், இது ஒரு எடுத்துக்காட்டு மட்டுமே: 64 layers, 8 KV heads, head dimension 128, fp8. இது 2 64 8 128 1 = 131,072 bytes, அதாவது ஒரு token-க்கு 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 context-ல் ஒரு பயனர் 16 GiB-ஐப் பயன்படுத்துகிறார். முழு ஒரு மில்லியன் context-ல் ஒரு பயனர் 128 GiB-ஐப் பயன்படுத்துகிறார், இது ஒரு உரையாடலுக்கு எந்தவொரு தனிப்பட்ட card-ன் கொள்ளளவை விடவும் அதிகம்.

K3 சாதாரண attention-ஐப் பயன்படுத்துவதில்லை, அந்த கடைசி எண் தான் அதற்குக் காரணம். அதன் 93 layers-ல் 69 KDA (Kimi Delta Attention) layers மற்றும் 24 Gated MLA (multi-head latent attention) layers உள்ளன. KDA ஒவ்வொரு token-க்கும் வளரும் cache-க்கு பதிலாக நிலையான அளவுள்ள recurrent state-ஐ வைத்திருக்கிறது, மேலும் MLA என்பது key மற்றும் value-ஐ ஒரு low rank latent vector-ஆகச் சுருக்குகிறது, எனவே ஒரு token-க்கான உண்மையான செலவு மேலே உள்ள உதாரணத்தை விட மிகக் குறைவாகவே இருக்கும். Moonshot அதன் latent dimensions-ஐ வெளியிடவில்லை, எனவே K3-க்கு நான் ஒரு பயனர் சார்ந்த மதிப்பீட்டை வழங்கப்போவதில்லை. அதற்குப் பதிலாக நீங்களே அளவிடுங்கள்: ஒரு சிறிய --max-model-len-உடன் server-ஐத் தொடங்குங்கள், nvidia-smi மூலம் memory-ஐக் கவனியுங்கள், பிறகு allocation தோல்வியடையும் வரை limit-ஐ உயர்த்துங்கள்.

Reasoning-ன் வடிவம் அடுத்த வெளியீட்டிலும் தொடரும். ஒரு model ஒரு மில்லியன் token context-ஐக் குறிப்பிட்டும், அதன் attention design பற்றி எதுவும் சொல்லவில்லை என்றால், யாராவது அதை நிரூபிக்கும் வரை cache தான் தடையாக இருக்கும் என்று கருதுங்கள்.

Tier 1: மணிநேர அடிப்படையில் cluster-ஐ வாடகைக்கு எடுத்தல்

K3-ஐ நேரடியாக இயக்கும் ஒரே tier இதுவாகும். நீங்கள் hardware-ஐ வாங்க வேண்டியதில்லை. உங்களுக்குத் தேவையான மணிநேரங்களுக்கு மட்டும் வாடகைக்கு எடுத்துவிட்டு, பிறகு அதை நிறுத்திவிடலாம்.

[
  {
    "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-ஆம் ஆண்டு வரை, datacentre accelerators-க்கான on-demand சந்தை விலை ஒரு GPU-க்கு ஒரு மணிநேரத்திற்கு சுமார் 2 முதல் 5 USD வரை இருந்தது; reserved capacity-க்கு விலை இன்னும் குறைவாக இருக்கும். உங்கள் service provider வழங்கும் உண்மையான விலையைக் கொண்டு கணக்கீட்டை மீண்டும் செய்யவும்: GPU-களின் எண்ணிக்கை பெருக்கல் மணிநேரம் பெருக்கல் கட்டணம். இந்த அட்டவணையின் நோக்கம் விகிதத்தை (ratio) விளக்குவதே ஆகும். 8 GPU-கள் கொண்ட node-ஐ ஒரு நாளைக்கு நான்கு மணிநேரம் பயன்படுத்துவது மாதத்திற்கு 2,400 USD செலவாகும், அதே சமயம் SGLang-க்கு ஏற்ற 32 GPU configuration-ஐ தொடர்ந்து இயங்கவிட்டால் அது 57,600 USD செலவாகும்.

இரண்டு mainstream server-களும் model card-ல் ஒரு launch command-ஐக் குறிப்பிடுகின்றன.

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

இந்தக் கட்டளைகளை அப்படியே ஒரு real cluster-ல் இயக்கக்கூடாது. உங்கள் hardware-க்கு ஏற்ற parallelism flags-ஐச் சேர்க்கவும்: SGLang-ல் tensor parallel-க்கு --tp-size-ஐயும், expert parallel-க்கு --ep-size-ஐயும் பயன்படுத்தவும். இவற்றின் பெருக்கற்பலன் உங்களிடம் உள்ள GPU-களின் எண்ணிக்கைக்குச் சமமாக இருக்க வேண்டும்.

உண்மையான traffic-ஐ அனுப்பும் முன் server இயங்குகிறதா என்பதைச் சரிபார்க்கவும்:

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

சரியாக இயங்கும் server, model id-ஐக் கொண்ட ஒரு JSON object-ஐப் பதிலளிக்கும். Connection refused என்பது process இன்னும் weights-ஐ load செய்துகொண்டிருக்கிறது அல்லது ஏற்கனவே நின்றுவிட்டது என்று பொருள், எனவே மீண்டும் முயற்சிக்கும் முன் server log-ஐப் படிக்கவும்.

முதல் நாளில் ஏற்படும் பொதுவான தோல்வி, model-ஐ விட runtime பழையதாக இருப்பதுதான். K3, KDA மற்றும் புதிய MoE layer-உடன் வெளியானது; stable vLLM மற்றும் SGLang releases-ல் தொடக்கத்தில் இவை இல்லை. இதன் அறிகுறி, server தொடங்கும்போதே Model architectures [...] are not supported for now என்ற வரியுடன் நின்றுவிடுவதுதான். எந்த configuration மாற்றமும் இதைச் சரிசெய்யாது, ஏனெனில் அந்த layer-களை இயக்குவதற்கான code உங்கள் build-ல் இல்லை. Model card-ல் குறிப்பிடப்பட்டுள்ள nightly version-ஐ install செய்யவும் அல்லது அந்த வசதி உள்ள release வரும் வரை காத்திருக்கவும்.

பயனர்களைக் குழப்பும் ஒரு செலவு குறிப்பு: instance தொடங்கும்போதே meter ஓடத் தொடங்கிவிடும், model தயாராகும் வரை காத்திருக்காது. 1 GB/s வேகத்தில் 1.5 TB தரவிறக்கம் செய்ய சுமார் 25 நிமிடங்கள் ஆகும், முதல் token-க்கு முன்பே இவ்வளவு cluster நேரம் செலவாகும். Instance-ஐ அழித்தாலும் அழியாத ஒரு volume-ல் weights-ஐச் சேமித்து வைக்கவும், அப்போதுதான் இரண்டாவது முறை இயக்கும்போது சில நிமிடங்களிலேயே வேலை தொடங்கும்.

Tier 2: ஒரு accelerator-ல் சிறிய மாதிரியை இயக்குதல்

இந்த நிலையில் நீங்கள் K3-ஐ இயக்கவில்லை. இதைத் தொடங்குவதற்கு முன்பே தெளிவாகக் கூறிவிடுங்கள், ஏனெனில் "K3-ஐ உள்ளூரில் இயக்குவது" குறித்த பெரும்பாலான விவாதங்கள் இதை ஒப்புக்கொள்ளாமலேயே முடிந்துவிடுகின்றன.

பொருந்தும் விதி (fit rule) அதே சூத்திரத்தின் சிறிய வடிவம் தான்: parameters பெருக்கல் bytes per weight, அதனுடன் KV cache, மற்றும் சுமார் 2 GB runtime overhead ஆகிய அனைத்தும் உங்கள் VRAM-க்குள் அடங்க வேண்டும். 4-bit அளவில் இது ஒரு parameter-க்கு தோராயமாக அரை byte ஆகும், இது வசதியான இணைகளை வழங்குகிறது:

• 16 GB card: 7B மாதிரி (4-bit), நீண்ட context-க்கு இடவசதியுடன்
• 24 GB card: 14B மாதிரி (4-bit)
• 48 GB card: 32B மாதிரி (4-bit)
• 80 GB card: 70B மாதிரி (4-bit), அல்லது 30B வகுப்பு MoE (8-bit)

GPU இணைக்கப்பட்ட VPS-ல் இயங்கும் server-ஐப் பெற Ollama மிக விரைவான வழியாகும்:

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

ollama run முதல்முறை பயன்படுத்தும்போது மாதிரியைப் பதிவிறக்கும், பிறகு உங்களை prompt-க்குக் கொண்டு செல்லும். இல்லாத tag-ஐக் குறிப்பிட்டால் Error: model "..." not found பிழை வரும், எனவே library பக்கத்திலிருந்து tag-களை நகலெடுத்துப் பயன்படுத்தவும், நினைவிலிருந்து தட்டச்சு செய்ய வேண்டாம். systemd unit மற்றும் remote access உள்ளிட்ட முழுமையான வழிமுறைகள் 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 அனைத்து layer-களையும் GPU-வில் கேட்கிறது. load log-ஐப் படியுங்கள்: எத்தனை layer-கள் offload செய்யப்பட்டன என்பதை அது காட்டும். system RAM-க்குச் செல்லும் layer-கள் HBM bandwidth-க்கு பதிலாக RAM bandwidth-ல் இயங்கும், எனவே மாதிரி VRAM-ல் அடங்காத தருணத்தில் generation வேகம் மிகக் கடுமையாகக் குறையும். இந்த இரண்டு கருவிகளுக்கும் இடையிலான வேறுபாடுகள் Ollama மற்றும் llama.cpp ஒப்பீடு பகுதியில் விளக்கப்பட்டுள்ளன.

Tier 3: hosted API, self-hosted orchestration

[
  {
    "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-உடன் இணக்கமானது (compatible), எனவே base URL-ஐ மாற்றிய பிறகு ஏற்கனவே உள்ள client-ஐப் பயன்படுத்தலாம்.

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."}]}'

சரியான key-ஐப் பயன்படுத்தினால், அது choices array-ஐக் கொண்ட JSON object-ஐத் தரும். 401 என்பது key தவறானது அல்லது Bearer prefix விடுபட்டுள்ளது என்பதைக் குறிக்கும். model-not-found பிழை பொதுவாக model id மாறியிருப்பதைக் குறிக்கும், ஏனெனில் வழங்குநர்கள் (providers) checkpoints-க்கு இடையில் பழைய id-களை நீக்கிவிடுவார்கள்.

இப்போது, மேலே குறிப்பிடப்பட்ட வாடகைக் கட்டணத்தின் அடிப்படையில் லாப-நட்ட சமநிலையை (break-even) கணக்கிடுவோம். எப்போதும் இயங்கிக்கொண்டிருக்கும் 8 GPU node-க்கு மாதம் 14,400 USD செலவாகும். 15.00 USD per million output tokens என்ற விலையில், அதே பணத்திற்கு API மூலம் சுமார் 960 மில்லியன் output tokens-களைப் பெற முடியும். செலவில் லாபம் ஈட்ட வேண்டுமானால், மாதம் ஒரு பில்லியன் output tokens-களை உருவாக்க வேண்டும், அதாவது ஒரு நாளைக்கு சுமார் 30 மில்லியன் tokens. மேலும், cluster-ஐ எப்போதும் பயன்பாட்டில் வைத்திருக்க வேண்டும், ஏனெனில் GPU பயன்பாட்டில் இல்லாதபோதும் அதே கட்டணம் வசூலிக்கப்படும். அதிக prompt-களைக் கொண்ட agent workloads இந்த இலக்கை இன்னும் கடினமாக்கும்: மீண்டும் மீண்டும் பயன்படுத்தப்படும் context, cache-miss rate-ஆன 3.00 USD-க்கு பதிலாக, cache-hit rate-ஆன 0.30 USD-க்கு வசூலிக்கப்படும்.

இந்த நிலையில் நீங்கள் self-host செய்வது model-ஐச் சுற்றியுள்ள அனைத்து அம்சங்களையும் ஆகும்: API key-ஐப் பாதுகாப்பாக வைத்திருக்கும் gateway (இது client-க்கு ஒருபோதும் தெரியாது), request மற்றும் response logs, retries, rate limits, மற்றும் பயனர் வாரியான வரவுசெலவுத் திட்டங்கள் (budgets). இது GPU இல்லாத ஒரு சிறிய VPS-ல் இயங்கும். இதே பிரிவினை closed weights-க்கும் பொருந்தும், அங்கு Claude-ஐ self-hosting செய்வது model அளவில் சாத்தியமில்லை, orchestration மட்டுமே உங்கள் கட்டுப்பாட்டில் இருக்கும்.

எந்த serving stack எந்த tier-ஐச் சேர்ந்தது

vLLM மற்றும் SGLang வகை servers tier 1-ஐச் சேர்ந்தவை. இவை ஒரே நேரத்தில் பல கோரிக்கைகளை (requests) கையாளும் வகையில் வடிவமைக்கப்பட்டுள்ளன. இதில் continuous batching, paged KV cache, மற்றும் பல nodes-களில் பரவியுள்ள tensor மற்றும் expert parallelism ஆகியவை உள்ளன. இவை datacenter accelerators மற்றும் அவற்றுக்கிடையேயான வேகமான interconnect வசதியை எதிர்பார்க்கின்றன. ஒரு சாதாரண consumer card-ல் இவற்றை நிறுவுவது கடினம், மேலும் இதனால் பெரிய பயன் ஏதும் இருக்காது.

llama.cpp மற்றும் Ollama ஆகியவை tier 2-ஐச் சேர்ந்தவை. இவை ஒரு machine, GGUF quantisation, model முழுமையாகப் பொருந்தாதபோது CPU-க்கு மாற்றுதல் (offload), மற்றும் குறைந்த concurrency ஆகியவற்றை இலக்காகக் கொண்டுள்ளன. llama.cpp தொழில்நுட்ப ரீதியாக ஒரு பெரிய MoE-ஐ system RAM-ல் வைத்துக்கொண்டு இயக்க முடியும், ஆனால் 2.8T model-க்கு ஒரு token-க்கு சில நொடிகள் வரை ஆகலாம். இது கோப்பு சரியாகப் பகுப்பாய்வு செய்யப்படுவதை உறுதிப்படுத்துமே தவிர, பயனர்களுக்கு வழங்கும் ஒரு service ஆக இதைப் பயன்படுத்த முடியாது. முழுமையான ஒப்பீடு Ollama மற்றும் vLLM ஒப்பீடு பகுதியில் உள்ளது. இது model-ஐப் பொறுத்து மாறுவதில்லை: நீங்கள் பகிரப்பட்ட hardware-ல் பல பயனர்களுக்கு சேவை செய்கிறீர்களா அல்லது உங்கள் சொந்த machine-ல் ஒரு பயனருக்கு சேவை செய்கிறீர்களா என்பதே கேள்வி.

இந்த checkpoint-ஐத் தாண்டி நிலைத்திருக்கும் நான்கு எண்கள்

1. மொத்த parameters-ன் எண்ணிக்கையை ஒரு weight-க்குத் தேவைப்படும் bytes-ஆல் பெருக்கினால், நினைவகத்தின் (memory) குறைந்தபட்ச அளவு கிடைக்கும். இதற்கு கீழே எதையும் இயக்க முடியாது. ஒரு release ஏற்கனவே 4-bit-ல் இருக்கும்போது, quantisation நுட்பங்களால் இந்த அளவை பெரிதாக மாற்ற முடியாது.
2. செயல்படும் (active) parameters-ன் எண்ணிக்கை throughput-ன் அளவைத் தீர்மானிக்கிறது. 104B active parameters கொண்ட 2.8T MoE மாதிரி, 104B மாதிரி போலவே கணக்கீடுகளைச் செய்யும்.
3. ஒரு token-க்கான KV cache, context length மற்றும் concurrency ஆகியவற்றின் பெருக்கற்பலனே, weights-க்கான கட்டணத்தைச் செலுத்திய பிறகும் தொடர்ந்து அதிகரிக்கும் செலவாகும்.
4. ஒரு டாலருக்கு எத்தனை tokens per second என்பது மட்டுமே ஒரு tier-ஐத் தேர்வு செய்யும் ஒரே எண். மேலே உள்ள அனைத்தும் இதற்கான உள்ளீடுகள் (input) மட்டுமே.

இந்த நான்கு விதிகளையும் எந்தவொரு release-க்கும் பயன்படுத்தினால், vendor வழிகாட்டியைத் திறக்கும் முன்பே சரியான விடையைப் பெறலாம். நீங்கள் எழுதும் ஒவ்வொரு புள்ளிவிவரத்திற்கும் தேதியைக் குறிப்பிடவும். K3 அறிமுகப்படுத்தப்பட்ட இரண்டு வாரங்களுக்குள்ளேயே விலைகளும், ஆதரிக்கப்படும் architecture பட்டியல்களும் மாறின. இந்தப் பக்கத்தில் உள்ள ஒவ்வொரு எண்ணும் July 2026-ல் வெளியிடப்பட்டவை.

FAQ

Kimi K3-ஐ ஒரே ஒரு GPU-வில் இயக்க முடியுமா?

முடியாது. Moonshot வழங்கும் MXFP4 precision-ல் இதன் weights சுமார் 1.4 TB அளவு இருக்கும். சந்தையில் கிடைக்கும் மிகப்பெரிய accelerator-ன் கொள்ளளவு 288 GB மட்டுமே. ஒரு MoE model-ன் inactive experts-ஐ disk-லிருந்து தேவைப்படும் வேகத்தில் stream செய்ய முடியாது. ஏனெனில், ஒவ்வொரு token-க்கும் router எந்த expert-ஐ வேண்டுமானாலும் தேர்வு செய்யலாம். PCIe fetch வேகம், ஒரு token-க்கான கால அவகாசத்தை விட மிக அதிகமாக இருப்பதால் இது சாத்தியமில்லை. K3-ஐ இயக்குவதற்கு குறைந்தபட்சம் பல GPU-க்கள் கொண்ட node தேவை. வெளியிடப்பட்ட வழிமுறைகள் 32 அல்லது அதற்கு மேற்பட்ட accelerators-ஐப் பயன்படுத்தப் பரிந்துரைக்கின்றன.

Kimi K3-க்கு எவ்வளவு VRAM தேவை?

weights-க்கு மட்டும் 1.4 TB-ல் தொடங்கவும். இது 18 H100 80GB cards அல்லது 5 GB300 class cards-க்கு சமம். இதனுடன் KV cache மற்றும் activation memory-ஐயும் சேர்த்துக்கொள்ள வேண்டும். ஆகஸ்ட் 2026 நிலவரப்படி, Moonshot 64 அல்லது அதற்கு மேற்பட்ட accelerators-ஐப் பரிந்துரைக்கிறது. SGLang cookbook-ல் 32 GPU H100 கொண்ட 2,560 GB aggregate திறன் கொண்ட configuration வெளியிடப்பட்டுள்ளது. எனவே, weights-க்கான அளவை ஒரு அடிப்படைத் தேவையாகக் கருதாமல், குறைந்தபட்ச அளவாகக் கருதவும்.

Quantisation மூலம் Kimi K3-ஐ ஒரே node-ல் பொருத்த முடியுமா?

பயனுள்ள வகையில் முடியாது. வெளியிடப்பட்ட checkpoint ஏற்கனவே 4-bit quantisation-aware training செய்யப்பட்டவை, எனவே எளிதான சேமிப்பு ஏற்கனவே செய்யப்பட்டுவிட்டது. மீண்டும் பாதியாகக் குறைத்து 2-bit-க்கு மாற்றினால், weights 0.7 TB ஆகும். இதுவும் சந்தையில் உள்ள மிகப்பெரிய card-ன் கொள்ளளவை விட இரண்டு மடங்கு அதிகம். மேலும், இந்த model-ல் 2-bit-க்கு மாறுவதால் ஏற்படும் துல்லியக் குறைபாடு (accuracy cost) இன்னும் அளவிடப்படவில்லை.

Kimi K3 API-ஐ விட GPU-க்களை வாடகைக்கு எடுப்பது மலிவானதா?

அதிகமான மற்றும் சீரான பயன்பாடு இருந்தால் மட்டுமே இது மலிவானது. ஒரு GPU-க்கு ஒரு மணி நேரத்திற்கு 2.50 USD என வைத்துக்கொண்டால், எப்போதும் இயங்கும் 8 GPU node-க்கு மாதம் 14,400 USD செலவாகும். அதே தொகையில், 15.00 USD per million என்ற விலையில் சுமார் 960 மில்லியன் output tokens-ஐப் பெறலாம். மேலும், பயன்பாடற்ற நேரத்திற்கு (idle hours), weights download செய்ய மற்றும் cluster-ஐப் பராமரிக்கும் நபருக்கான செலவுகளையும் நீங்கள் கவனிக்க வேண்டும். எப்போதாவது தேவைப்படும் பயன்பாட்டிற்கு (bursts) மணிநேர அடிப்படையில் வாடகைக்கு எடுக்கவும். உங்கள் சொந்த token பயன்பாட்டை அளவிட்டு, அதனுடன் ஒப்பிட்டுப் பார்க்கவும்.

104B active parameters என்பது வேகத்தைப் பொறுத்தவரை எதைக் குறிக்கிறது?

ஒரு token-க்கான கணக்கீடு 104B model-க்கு இணையானது என்று பொருள். எனவே, இதன் throughput 2.8T class-ல் இல்லாமல், 104B class-ல் இருக்கும். இது memory-ஐப் பற்றி எதையும் கூறவில்லை: அனைத்து 2.8T parameters-ம் memory-ல் இருக்க வேண்டும். ஏனெனில், router எந்த token-க்கும் எந்த expert-ஐயும் அழைக்கலாம். tokens per second-ஐக் கணிக்க active count-ஐயும், VRAM அளவைத் தீர்மானிக்க total count-ஐயும் பயன்படுத்தவும்.