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-ல் இதை இயக்குவது சாத்தியமில்லை.

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

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

K3 என்பது ஒரு mixture of experts (MoE) மாதிரி ஆகும். MoE என்பது ஒரு network-ஐ பல sub-network-களாகப் பிரித்து, ஒவ்வொரு 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-ஐ வேண்டுமானாலும் தேர்ந்தெடுக்கலாம் என்பதால், முதல் கோரிக்கை வருவதற்கு முன்பே அனைத்து expert-களும் நினைவகத்தில் (VRAM) இருக்க வேண்டும். 104B அளவுருக்களை மட்டும் VRAM-ல் வைத்துக்கொண்டு, தேவைப்படும்போது மற்றவற்றைத் தரவிறக்கம் செய்ய முடியாது. ஏனெனில், அந்தத் தரவிறக்கம் microseconds-க்குள் முடிய வேண்டும், ஆனால் PCIe link-ன் வேகம் வினாடிக்குச் சில gigabytes மட்டுமே. சிலர் இதை முயற்சி செய்கிறார்கள். NVMe-லிருந்து experts-ஐ streaming செய்வது, வினாடிக்கு டஜன் கணக்கான tokens-ஐ உருவாக்கும் மாதிரியை, சில வினாடிகளுக்கு ஒரு token-ஐ உருவாக்கும் அளவுக்கு மந்தமாக்கிவிடும்.

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

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

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

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

இது வழக்கமான தப்பிக்கும் வழியை அடைத்துவிடுகிறது. "வெறுமனே quantise செய்யுங்கள்" என்பது இங்கே உதவாது, ஏனெனில் வெளியிடப்பட்ட checkpoint ஏற்கனவே 4-bit அளவில் உள்ளது. 2-bit அளவிற்குச் சென்றால் எடைகள் 0.7 TB-க்குக் குறையும், ஆனால் இந்த checkpoint-ல் யாரும் அளவிடாத துல்லிய இழப்பு (accuracy loss) ஏற்படும். அப்படியிருந்தும், உங்களால் எந்தவொரு தனிப்பட்ட கார்டிலும் (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, நான்கு 8-GPU nodes கொண்ட H100 கட்டமைப்பைப் பயன்படுத்துகிறது; இதில் மொத்தம் 32 GPUs மற்றும் 2,560 GB memory உள்ளது. இது 18 கார்டுகள் என்ற குறைந்தபட்ச அளவோடு ஒப்பிடப்படுகிறது. இந்த இடைவெளி வீணானதல்ல. இது KV cache, activation memory மற்றும் ஒரே நேரத்தில் பல கோரிக்கைகளைச் செயலாக்க server-க்குத் தேவையான கூடுதல் இடவசதி (headroom) ஆகும். மிக எளிமையான கட்டமைப்பான 5 GB300 வகை கார்டுகள் கூட, பெரும்பாலான service providers ஒரே SKU-வாக வாடகைக்கு விடாத ஒரு இயந்திரத்தையே குறிக்கின்றன.

KV cache என்பது பலரை வியப்பில் ஆழ்த்தும் ஒரு பகுதியாகும்

Weights என்பது ஒரு நிலையான செலவு (fixed cost). ஆனால் KV (key value) cache அப்படி அல்ல: இது context length அதிகரிக்கும்போதும், ஒரே நேரத்தில் பல பயனர்கள் (concurrent users) பயன்படுத்தும்போதும் வளரக்கூடியது. சாதாரண 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 தோல்வியடையும் வரை அந்த வரம்பை உயர்த்துங்கள்.

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

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

இரண்டு mainstream servers-ம் 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

இந்த அடிப்படை command-களை அப்படியே ஒரு 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-ஐ ஏற்றிக்கொண்டிருக்கிறது அல்லது ஏற்கனவே நின்றுவிட்டது என்று பொருள், எனவே மீண்டும் முயற்சிக்கும் முன் server log-ஐப் படிக்கவும்.

முதல் நாளில் ஏற்படும் பொதுவான தோல்வி, model-ஐ விட runtime பழையதாக இருப்பதுதான். K3, KDA மற்றும் புதிய MoE layer-உடன் வெளியானது; stable vLLM மற்றும் SGLang releases-ல் இவை தொடக்கத்தில் இல்லை. இதன் அறிகுறி, server தொடங்கும்போதே Model architectures [...] are not supported for now என்ற வரியுடன் நின்றுவிடுவதுதான். எந்த config மாற்றமும் இதைச் சரிசெய்யாது, ஏனெனில் அந்த layers-ஐ இயக்குவதற்கான 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-ல் சிறிய model-ஐ இயக்குதல்

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

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

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

மேலே உள்ள ஒவ்வொரு இணைப்பும் ஒரு நேரத்தில் ஒரு கோரிக்கையை (request) மட்டுமே கருதுகிறது. இரண்டாவது நபர் prompt அனுப்பும் தருணத்தில், ஒவ்வொரு concurrent slot-க்கும் தனித்தனி KV cache தேவைப்படும். இதற்காகத்தான் Ollama-வின் NUM_PARALLEL மற்றும் MAX_QUEUE அமைப்புகள் parallel slots, queued requests மற்றும் மீதமுள்ள VRAM ஆகியவற்றுக்கு இடையே சமநிலையை ஏற்படுத்துகின்றன.

GPU இணைக்கப்பட்ட VPS-ல் ஒரு server-ஐ உருவாக்க Ollama மிக எளிதான வழியாகும்:

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

ollama run முதல்முறை பயன்படுத்தும்போது model-ஐ பதிவிறக்கம் செய்து, உங்களை 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-ல் இயங்கும், எனவே model முழுமையாக 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 பிழை பொதுவாக 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-ஐ எப்போதும் பயன்பாட்டில் வைத்திருக்க வேண்டும், ஏனெனில் idle-ஆக இருக்கும் GPU-களுக்கும் பயன்பாட்டில் இருக்கும் அதே கட்டணமே வசூலிக்கப்படும். Prompt-களை அதிகம் பயன்படுத்தும் agent workloads இந்த இலக்கை இன்னும் கடினமாக்கும்: மீண்டும் மீண்டும் பயன்படுத்தப்படும் context-க்கு 0.30 USD per million என்ற cache-hit விலையே வசூலிக்கப்படும், இது 3.00 USD என்ற cache-miss விலையை விடக் குறைவு.

இந்த tier-ல் நீங்கள் self-host செய்வது model-ஐச் சுற்றியுள்ள அனைத்தையும் ஆகும்: API key-ஐத் தன்னுள் வைத்திருக்கும் gateway (இது client-க்குச் செல்லாது), request மற்றும் response logs, retries, rate limits, மற்றும் பயனர் வாரியான வரவுசெலவுத் திட்டங்கள் (budgets). இது GPU இல்லாத ஒரு சிறிய VPS-ல் இயங்கும். இதே பிரிவினை closed weights-க்கும் பொருந்தும், அங்கு self-hosting Claude என்பது 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-ஐ, அதன் பெரும்பாலான layers-ஐ system RAM-ல் வைத்திருப்பதன் மூலம் load செய்யும். ஒரு 2.8T model-க்கு, இந்த முறையில் ஒரு token-க்கு சில நொடிகள் ஆகலாம். இது கோப்பு சரியாகப் parse ஆகிறது என்பதை உறுதிப்படுத்துமே தவிர, பயனர்களுக்கு வழங்கும் ஒரு service ஆக இதைப் பயன்படுத்த முடியாது. முழுமையான ஒப்பீடு Ollama மற்றும் vLLM ஒப்பீடு பகுதியில் உள்ளது. model மாறினாலும் இந்த அடிப்படை மாறாது: நீங்கள் பகிரப்பட்ட hardware-ல் பல பயனர்களுக்கு service வழங்குகிறீர்களா அல்லது உங்கள் சொந்த 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 என்பது மட்டுமே ஒரு tier-ஐத் தேர்வு செய்யும் ஒரே எண். மேலே உள்ள அனைத்தும் இதற்கான உள்ளீடுகள் மட்டுமே.

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

FAQ

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

முடியாது. Moonshot வழங்கும் MXFP4 precision-ல் இதன் weights சுமார் 1.4 TB அளவு இருக்கும். சந்தையில் கிடைக்கும் மிகப்பெரிய accelerator-ன் கொள்ளளவு 288 GB மட்டுமே. ஒரு MoE model-ன் செயலற்ற experts-ஐ disk-லிருந்து தேவையான வேகத்தில் stream செய்ய முடியாது. ஏனெனில், router எந்த token-க்கும் எந்த expert-ஐ வேண்டுமானாலும் தேர்ந்தெடுக்கலாம்; PCIe fetch நேரம், token budget அனுமதிக்கும் கால அளவை விட மிக அதிகம். Kimi 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, 2,560 GB aggregate கொண்ட 32 GPU H100 configuration-ஐ வெளியிடுகிறது. எனவே, weights அளவை ஒரு அடிப்படைத் தேவையாகக் கருதுங்கள், அதுவே முழுமையான தேவை அல்ல.

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

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

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-ஐப் பராமரிக்கும் நபருக்கான செலவுகளையும் நீங்கள் கவனிக்க வேண்டும். அவ்வப்போது தேவைப்படும் பயன்பாட்டிற்கு மணிநேர அடிப்படையில் வாடகைக்கு எடுங்கள்; உங்கள் சொந்த 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-ஐயும் பயன்படுத்துங்கள்.