สรุปสั้น (TL;DR)

ข้อมูล ณ 7 พ.ย. 2026: inference แซง training ในค่าใช้จ่าย AI-optimized IaaS (55% ในปี 2026), เปรียบเทียบ vLLM v0.33.0 / SGLang v0.5.23 / llm-d 1.0, คู่มือเลือกโมเดล open-weight สำหรับ self-hosting ตั้งแต่ Qwen3.5 ถึง Kimi K3.1 Pro และภาพ data center ของ APAC ที่ไฟฟ้ากลายเป็นข้อจำกัดหลัก

ข้อมูล ณ 7 พฤศจิกายน 2026 เน้นหลักฐานช่วงปี 2025-2027 รายงานนี้รวบรวมสถานะล่าสุดของ AI Inference ซอฟต์แวร์ serving โมเดล open-weight สำหรับ self-hosting และภาพตลาด data center ในภูมิภาค APAC พร้อมข้อจำกัดของหลักฐานที่ควรรู้ก่อนนำไปตัดสินใจ

บทสรุปผู้บริหาร

  1. 2026 เรียกว่า "ปีแห่ง Inference" ได้ในเชิงเศรษฐศาสตร์ของ cloud infrastructure ไม่ใช่ข้อพิสูจน์ว่า inference ใช้ compute ทั่วโลกมากกว่า training ทุกประเภทแล้ว Gartner คาดว่าในปี 2026 ค่าใช้จ่าย AI-optimized IaaS สำหรับ inference จะอยู่ที่ 23.3 พันล้านดอลลาร์ เทียบกับ training 19 พันล้านดอลลาร์ หรือ 55% ของตลาด และเพิ่มเป็น 59% ในปี 2027 ตาม รายงาน JLL Asia Pacific Data Centre
  2. ตัวเลข ต้นทุนลดลง 47% ต่อไตรมาส หรือประมาณ 13 เท่าต่อปี มีงานวิจัยเดือนกันยายน 2026 รองรับจริง แต่หมายถึงค่าใช้จ่ายต่ำสุดในการทำคะแนนถึงระดับความสามารถคงที่ (quality-adjusted cost) ไม่ใช่ว่าราคา token ของโมเดลเดิม หรือค่าไฟของ cluster ที่ self-host ลดลง 13 เท่าทุกปี
  3. สำหรับ self-hosting ปี 2026 จุดเปลี่ยนสำคัญคือ software optimization เฉพาะโมเดลและฮาร์ดแวร์ เช่น speculative decoding, low-precision KV cache, prefix caching, paged experts และ prefill/decode disaggregation มากกว่าการเปรียบเทียบว่า vLLM หรือ SGLang "เร็วกว่าเสมอ"
  4. เฟรมเวิร์กที่ควรประเมินตอนนี้คือ vLLM v0.33.0, SGLang v0.5.23 และ llm-d 1.0 โดย vLLM/SGLang เป็น model-serving engine ส่วน llm-d เป็น distributed serving/control plane บน Kubernetes ซึ่งไม่ใช่คู่แข่งระดับเดียวกัน
  5. โมเดล open-weight แบ่งเป็นสองตลาดชัดเจน: โมเดล 4B-35B/MoE ขนาดกลาง เหมาะกับเซิร์ฟเวอร์ภายในองค์กรจริง เช่น Qwen3.5 และ Gemma 4 และ frontier open-weight ขนาดหลายร้อยพันล้านถึงหลายล้านล้านพารามิเตอร์ เช่น DeepSeek V4.1 Flash, GLM-5.3 และ Kimi K3.1 Pro ที่ต้องใช้ multi-GPU/multi-node อย่างจริงจัง
  6. APAC อยู่ในภาวะ power-constrained execution: pipeline ศูนย์ข้อมูลครึ่งแรกปี 2026 อยู่ที่ 26,455 MW โดยมี 4,764 MW กำลังก่อสร้าง และ 21,691 MW อยู่ในแผน ขณะที่กำลังไฟและ grid connection กลายเป็นข้อจำกัดหลัก

1. ข้อเท็จจริงเกี่ยวกับ "ปีแห่ง Inference"

ประเด็นข้อสรุปล่าสุด
Inference แซง training แล้วหรือไม่แซงในค่าใช้จ่าย AI-optimized IaaS ที่ Gartner ติดตาม: 23.3 พันล้านดอลลาร์ เทียบกับ 19 พันล้านดอลลาร์ในปี 2026 ไม่ควรขยายความว่า inference แซง training ใน compute ทุกระบบทั่วโลก
สัดส่วนปี 2027Gartner คาดว่า inference จะเป็น 59% ของ AI-optimized IaaS spending ในปี 2027
ตลาดรวมAI-optimized IaaS คาดว่าจะเพิ่มจากประมาณ 42.3 พันล้านดอลลาร์ในปี 2026 เป็น 66.1 พันล้านดอลลาร์ในปี 2027 ตาม การวิเคราะห์ของ BMI
ราคาลด 47% ต่อไตรมาสถูกต้องตามงานวิจัยล่าสุด แต่เป็น quality-adjusted cost per task ที่เลือกโมเดลราคาต่ำสุดซึ่งผ่านคะแนนเป้าหมาย ไม่ใช่ raw token price ของ deployment เดิม
Jevons paradoxเป็นสมมติฐานที่มีเหตุผล แต่ข้อมูลปัจจุบันพิสูจน์เพียงว่า cost ต่อระดับความสามารถลดเร็ว ขณะที่ inference spending รวมเพิ่มขึ้น ไม่ได้พิสูจน์อัตราการเพิ่มของ token consumption สำหรับทุกองค์กร

ปี 2026 เป็นจุดที่ค่าใช้จ่าย cloud AI infrastructure สำหรับการให้บริการ inference แซง training ตามประมาณการ Gartner ขณะที่ต้นทุนต่อระดับความสามารถลดลงอย่างรวดเร็ว แต่การใช้ agent, long context และ multi-step workflows ทำให้ความต้องการ compute และ infrastructure รวมยังเพิ่มขึ้น

2. สถานะล่าสุดของ inference software

เฟรมเวิร์ก/เวอร์ชันล่าสุดหลักฐานประสิทธิภาพล่าสุดเหมาะกับข้อจำกัดในการตีความ
vLLM v0.33.0 (2 พ.ย. 2026)DeepSeek-V4.1-Flash + DSpark บน GB300 เพิ่มจาก 1,373 เป็น 3,390 output tok/s; FlashInfer DCP prefill ลด mean TTFT 39-48% ที่ input 100K บน 8xB200; FP8 KV cache สำหรับ GLM-5.x ลด KV memory ต่อ rank ครึ่งหนึ่ง แต่เพิ่ม TTFT 7-11%OpenAI-compatible serving, deployment ตั้งแต่ GPU เดียวถึง multi-node, NVIDIA/AMD/Intel/CPU และระบบที่ต้องการ ecosystem กว้างตัวเลขส่วนใหญ่เป็น benchmark ในแต่ละ pull request ไม่ใช่ benchmark กลางแบบ apples-to-apples
SGLang v0.5.23 (2 พ.ย. 2026)DeepSeek-V4.1 บน GB300 ได้ prefill throughput สูงสุด 1.5 เท่า และ TTFT ต่ำลงราว 28% สำหรับ prompt 32K-64K; low-latency kernel ทำ single-user decode เร็วขึ้นสูงสุด 44% บน GB300 และ 75% บน MI350X; Paged Experts เร็วกว่า CPU offload สูงสุด 30 เท่าAgentic/long-context workloads, MoE, Radix/prefix caching, speculative decoding และการทดลอง optimization ใหม่อย่างรวดเร็วหลายฟีเจอร์เป็น opt-in และตัวเลขผูกกับรุ่นโมเดล, GPU, batch/concurrency และ kernel โดยเฉพาะ
llm-d 1.0 (20 ต.ค. 2026)บน agentic coding workload บน TPU 7x การใช้ prefix-aware routing และ host-memory offload ลด median TTFT มากกว่า 85% และเพิ่ม throughput 2.4 เท่าเทียบ Kubernetes Service; รองรับทั้ง vLLM และ SGLang ตาม ประกาศเปิดตัวของ Google CloudKubernetes cluster, mixed accelerators, multi-tenancy, cache-aware routing, KV offload, autoscaling และ prefill/decode disaggregationไม่ใช่ inference kernel engine; ประโยชน์เด่นเมื่อมีหลาย replicas, prefix reuse หรือทราฟฟิก bursty
llm-d v0.7 heterogeneousใน pool 20 GPUs จากสามผู้ผลิต ได้ 14.2K output tok/s เทียบ 9.6K peak ของ baseline; ที่โหลด 85 QPS สูงกว่า Kubernetes round-robin 91% และ TTFT 6.8 วินาทีเทียบ 36.4 วินาที ตาม benchmark heterogeneous ของ llm-dองค์กรที่มี GPU หลายรุ่น/ผู้ผลิตและต้องการรวมเป็น inference pool เดียวworkload มี shared prefix ยาวราว 7.2K tokens ทำให้ cache-aware routing ได้เปรียบมาก และ accelerator ถูกปิดชื่อ

ข้อสรุปเชิงวิศวกรรม: ไม่ควรตั้งคำถามเพียงว่า vLLM หรือ SGLang เร็วกว่ากัน แต่ควรเลือกตาม workload

  • เริ่มต้นด้วย vLLM ถ้าต้องการ API compatibility, ภาพรวมฮาร์ดแวร์กว้าง, integration จำนวนมาก และ production path ที่อนุรักษนิยมกว่า (ดู คู่มือ vLLM V1)
  • ทดสอบ SGLang ควบคู่ หากใช้ MoE รุ่นใหม่, agentic long context, speculative decoding หรือ workload ที่ prefix reuse สูง
  • เพิ่ม llm-d เมื่อ deployment ขยายเกินหนึ่ง replica/node และเริ่มมีปัญหา cache locality, queue fairness, mixed hardware หรือ prefill/decode contention
  • ไม่ควรใช้ตัวเลข headline จากคนละ release มาเปรียบเทียบโดยตรง เพราะ model, precision, prompt length, concurrency และ GPU ต่างกัน

3. โมเดล open-weight ล่าสุดสำหรับ self-hosting

กลุ่มการใช้งานโมเดลที่ควรทดสอบขนาด/ลักษณะความเหมาะสมต่อ self-hosting
GPU เดี่ยว/เซิร์ฟเวอร์เล็กQwen3.5-9BDense 9B; MMLU-Pro 82.5ตัวเลือกเริ่มต้นที่สมเหตุผล; weights ราว 18 GB ที่ BF16 หรือประมาณ 4.5 GB ที่ 4-bit ก่อนรวม runtime/KV overhead
GPU เดี่ยวขนาดใหญ่หรือ 2 GPUsQwen3.5-35B-A3BMoE 35B total/ประมาณ 3B active; MMLU-Pro 85.3compute ต่อ token ต่ำกว่า dense 35B แต่ยังต้องเก็บ weights ทั้ง 35B; ประมาณ 70 GB BF16 หรือ 17.5 GB ที่ 4-bit
Local multimodal/edge-serverGemma 4 12B หรือ 26B-A4Bมีทั้ง E2B, E4B, 12B, 26B MoE และ 31B Dense; Apache 2.0 รองรับ vLLM, SGLang, llama.cpp และ Ollamaเหมาะกับงาน multimodal ภายในองค์กรและอุปกรณ์ที่ทรัพยากรจำกัด
Multi-GPU ระดับองค์กรGLM-5.3-Flash320B total/18B active; GGUF ทางการประมาณ 328 GBต้องใช้ multi-GPU หรือ aggressive quantization/offload; active parameters ต่ำไม่ได้แปลว่าเก็บเฉพาะ 18B ได้
Cluster ระดับองค์กรDeepSeek-V4.1-Flash552B total/16B active, context 1M, MIT licenseเหมาะกับ multi-node inference; มี optimization เฉพาะใน vLLM/SGLang รุ่นล่าสุดมากกว่ารุ่นทั่วไป
Frontier on-premiseGLM-5.3753B total/ประมาณ 40B active, context 1M; repository ประมาณ 756 GBต้องใช้ cluster และ distributed serving; ไม่ใช่โมเดลสำหรับ GPU เดี่ยว
Frontier สูงสุดKimi K3.1 Proประมาณ 2.8T total/104B active; weights ขนาดดาวน์โหลดประมาณ 1.56 TBแม้เป็น open-weight แต่ต้องใช้โครงสร้างพื้นฐานขนาดใหญ่ และตรวจสอบ custom license ก่อนใช้เชิงพาณิชย์

หมายเหตุ: ตัวเลขหน่วยความจำเป็นการประมาณเฉพาะ weights (2 bytes/parameter ที่ BF16, 0.5 byte ที่ 4-bit) ของจริงต้องเผื่อ quantization metadata, CUDA graph, activations, runtime workspace และ KV cache อีกมาก โดยเฉพาะ long context และ concurrency สูง

ด้านคุณภาพกับความเร็ว Artificial Analysis ณ 7 พฤศจิกายน 2026 จัดให้ Kimi K3.1 Pro เป็น open-weight model ที่มี Intelligence Index สูงสุด แต่ API output speed ที่วัดได้อยู่ราว 33 tok/s และราคา $2/M input, $10/M output ขณะที่ DeepSeek V4.1 Flash อยู่ราว 205-221 tok/s และราคา $0.30/M input, $1.20/M output ตัวเลขนี้เป็นการเปรียบเทียบ hosted endpoints ไม่ใช่ throughput ที่จะได้จาก on-prem cluster ขององค์กร

4. แนวทาง self-hosting ที่ควรใช้ในปี 2026-2027

ลำดับการ optimize ที่แนะนำ

  1. กำหนด SLO ก่อนเลือกฮาร์ดแวร์: P50/P95 TTFT, TPOT หรือ inter-token latency, requests/s และ output tok/s, input/output length distribution, concurrency และ prefix reuse, รวมถึง availability และข้อกำหนด data residency
  2. เลือกระดับโมเดลให้เล็กที่สุดที่ผ่าน task evaluation: งาน retrieval, classification, extraction หรือ internal assistant จำนวนมากไม่จำเป็นต้องเริ่มจาก 300B+ ใช้ routing ส่งเฉพาะงานยากไป frontier model
  3. ใช้ quantization แยก weights กับ KV cache: weight quantization ช่วยให้โมเดลใส่ GPU ได้, FP8/FP4 KV cache ช่วย concurrency และ context capacity แต่ต้องทดสอบ accuracy, TTFT และ throughput พร้อมกัน
  4. เปิด prefix caching เมื่อ prompt มีส่วนซ้ำจริง: เหมาะกับ system prompt, RAG template, coding agents และ multi-turn sessions ถ้า prefix กระจายตัวสูงประโยชน์จะลดลงมาก
  5. ใช้ speculative decoding เมื่อ decode-bound: เหมาะกับ interactive generation และ batch/concurrency ต่ำถึงกลาง ต้องวัด acceptance rate เพราะ draft model ที่เร็วแต่เดาผิดบ่อยอาจไม่ช่วย
  6. ใช้ prefill/decode disaggregation เมื่อ workload มี prompt ยาว: prefill เน้น compute, decode เน้น memory bandwidth การแยก pool ช่วยลดการรบกวนกันแต่เพิ่ม network/KV-transfer complexity
  7. ใช้ llm-d หรือ control plane ลักษณะเดียวกันเมื่อมีหลาย replicas: cache-aware routing, load/saturation-aware scheduling, priority lanes, KV offload และ rolling upgrade ที่รักษา session state

Benchmark ที่องค์กรควรรันเอง

ใช้ trace จริงอย่างน้อยสามชุด: interactive (1-4K input, 200-1K output, concurrency ต่ำ), RAG/enterprise (8-32K input, shared prefix หลายระดับ) และ agentic/long-context (32-256K+ input, multi-turn, bursty concurrency) แล้วรายงานอย่างน้อย P50/P95/P99 TTFT, P50/P95 TPOT, output tok/s, request throughput, GPU utilization, HBM utilization, cache-hit rate, power draw และ cost per successful task ตามแนวทาง validation benchmark ของ llm-d

5. Data center และไฟฟ้าใน APAC

ภูมิภาค/ตลาดภาพล่าสุดและ projectionผลต่อ AI inference
APAC รวมJLL คาด supply ใหม่ 4.8 GW ภายในปี 2027 โดย 78% ถูก pre-lease แล้ว และเพิ่ม capacity รวม 24 GW ระหว่างปี 2025-2030capacity ที่ว่างจริงอาจตึงตัวเร็วกว่าตัวเลขการก่อสร้าง
APAC pipelineH1 2026 มี pipeline 26,455 MW: 4,764 MW ก่อสร้าง และ 21,691 MW ในแผนการอยู่ใน pipeline ไม่เท่ากับมีไฟและเปิดใช้ได้ตามกำหนด
ความหนาแน่นแร็กPwC คาดค่าเฉลี่ย AI rack จาก 15-20 kW เพิ่มเป็น 40-50 kW ภายในสิ้นปี 2027ควรออกแบบ liquid-ready แม้ rollout แรกยังต่ำกว่า 40 kW
จีนIEA ประเมิน data center ใช้ไฟมากกว่า 100 TWh ในปี 2024 และอาจเพิ่มเป็นสองเท่าภายในปี 2027แหล่งเพิ่ม load ขนาดใหญ่ที่สุดแห่งหนึ่งของภูมิภาค
มาเลเซียPwC คาด capacity จาก 522 MW ใน Q1 2025 เป็น 2,055 MW สิ้นปี 2026Johor เป็นตลาดสำคัญ แต่ grid, น้ำ และ renewable procurement เป็นข้อจำกัด
ไทยcapacity คาดเพิ่มจาก 242 MW ปี 2025 เป็น 550 MW ปี 2026 และ supply อาจผ่อนคลายในปี 2027 เมื่อ generation ใหม่เข้าระบบต้องตรวจสอบ grid-connection date มากกว่าวันเสร็จอาคาร
อินโดนีเซีย/BatamBatam มีประมาณ 70 MW ใช้งานจริงและ pipeline อีก 747 MWความเสี่ยงหลักคือ transmission, substation และเวลารอเชื่อมต่อ
อินเดียH1 2026 มี operational capacity 1,789 MW และ pipeline 3,860 MW สัดส่วนไฟฟ้าที่ใช้โดย data center อาจเพิ่มจาก 0.8% เป็น 2.6% ในปี 2030ตลาดโตสูง แต่ต้องวาง power procurement และ transmission ล่วงหน้า
สิงคโปร์มี capacity เดิมประมาณ 1.4 GW วางแผนเพิ่มอย่างน้อย 300 MW พร้อม 200 MW ที่ผูกกับ green-energy optionsconnectivity สูง แต่ capacity ใหม่ขึ้นกับ efficiency และพลังงานสะอาด

Rack power รุ่นใหม่: แยก "ค่าเฉลี่ยตลาด" กับ "frontier rack"

แร็กทั่วไปใน APAC อาจขยับไปที่ 40-50 kW ภายในปี 2027 แต่แร็ก frontier สูงกว่านั้นมาก ตาม การวิเคราะห์ของ Kearney ที่ชี้ว่า power คือตัวชี้ขาดผู้ชนะของ data center รุ่นถัดไป:

  • NVIDIA ระบุว่า Vera Rubin NVL72 มี provisioned rack power ประมาณ 136 kW และลดเหลือ 101 kW ได้ด้วย power smoothing ใน workload ที่ทดสอบ
  • NVIDIA กำลังผลักดันสถาปัตยกรรม 800 VDC เพื่อรองรับ IT rack ระดับ 1 MW ตั้งแต่ปี 2027
  • OCP ประเมิน H100-class rack ราว 40 kW, GB200 ราว 120 kW และ Rubin-generation ในปี 2027 อาจอยู่ที่ 600 kW ถึง 1 MW

ดังนั้น "600 kW ถึง 1 MW ต่อแร็ก" เป็น roadmap สำหรับ frontier rack รุ่นถัดไป ไม่ใช่ความหนาแน่นเฉลี่ยของศูนย์ข้อมูลในปี 2026

6. การสังเคราะห์สำหรับองค์กรใน APAC

  • เริ่ม production ด้วย Qwen3.5-9B/35B-A3B หรือ Gemma 4 สำหรับ workload ส่วนใหญ่
  • ใช้ DeepSeek/GLM/Kimi ขนาดใหญ่ผ่าน API หรือ dedicated hosted endpoint จนกว่า utilization จะสูงพอให้ cluster ภายในคุ้มค่า
  • รัน benchmark ทั้ง vLLM และ SGLang บนฮาร์ดแวร์จริง โดย pin: model revision, framework/container version, driver/CUDA/ROCm, quantization, context distribution และ concurrency
  • เลือก data center จาก available commissioned power และ grid-connection SLA ไม่ใช่จากประกาศ pipeline
  • สำหรับการจัดซื้อใหม่ ควรกำหนดอย่างน้อย: direct-to-chip liquid-cooling readiness, 80-150 kW/rack สำหรับ near-term AI cluster, เส้นทาง upgrade ไปสู่ 800 VDC และ telemetry ระดับ rack/GPU เพื่อวัด tokens per kWh

ข้อจำกัดของหลักฐาน

  • Benchmark ใน release note ของ vLLM และ SGLang เป็นหลักฐานจากนักพัฒนาโดยตรงและใหม่มาก แต่ส่วนใหญ่เป็น component/PR benchmarks ไม่ใช่การเปรียบเทียบเฟรมเวิร์กแบบควบคุมตัวแปร
  • Model-card benchmark มักมาจากผู้พัฒนาโมเดล จึงควรตรวจด้วยชุดข้อมูลภายในองค์กรและ benchmark อิสระ
  • ตัวเลข data-center อย่าง "capacity", "IT load", "utility capacity" และ "pipeline" ไม่ได้มีนิยามเดียวกัน ไม่ควรนำ MW จากต่างรายงานมาบวกรวมโดยตรง
  • Projection ด้านไฟฟ้ามีความไม่แน่นอนสูง เพราะโครงการจำนวนหนึ่งอาจเลื่อนจากข้อจำกัดของ transformer, transmission, น้ำ, permits หรือ power-purchase agreement

Next steps ที่แนะนำ

  1. สร้าง benchmark harness เดียวกันสำหรับ vLLM v0.33.0 และ SGLang v0.5.23
  2. ทดสอบ Qwen3.5-9B, Qwen3.5-35B-A3B และโมเดล frontier หนึ่งรุ่นด้วย trace จริง
  3. คำนวณ break-even ระหว่าง API กับ self-hosting จาก cost per successful task ไม่ใช่ cost/token อย่างเดียว
  4. ทำ capacity plan แยก HBM, KV cache, network bandwidth, rack power และ cooling
  5. เพิ่ม llm-d เฉพาะเมื่อผลทดสอบแสดงว่าการสูญเสียมาจาก routing, cache locality หรือการแย่งทรัพยากรระหว่าง prefill/decode ไม่ใช่จาก kernel ของโมเดลเอง

แหล่งอ้างอิง

  1. รายงาน JLL Asia Pacific Data Centre www.jll.com
  2. llm-d llm-d.ai
  3. การวิเคราะห์ของ BMI asian-power.com
  4. ประกาศเปิดตัวของ Google Cloud cloud.google.com
  5. benchmark heterogeneous ของ llm-d llm-d.ai
  6. vLLM github.com
  7. คู่มือ vLLM V1 docs.vllm.ai
  8. SGLang www.sglang.io
  9. Artificial Analysis artificialanalysis.ai
  10. validation benchmark ของ llm-d llm-d.ai
  11. PwC www.pwc.com
  12. IEA www.iea.org
  13. การวิเคราะห์ของ Kearney www.kearney.com