LLMOps& AI Platforms
Model Serving & Inference บน GPU ขององค์กร
ต่อยอดจาก AI Infrastructure เป็น API สำหรับโมเดล ตั้งแต่ DGX Spark และ DGX Station GB300 ไปจนถึง SuperPOD พร้อม Kubernetes / Slurm, RDMA และการจัดสรร GPU ให้หลายทีม
Model Serving
& Inference on GPU
ต่อจาก GPU ที่ติดตั้งพร้อมแล้ว เราวาง software stack ให้ application เรียกใช้โมเดลผ่าน API ได้ พร้อมจัดสรรทรัพยากรให้แต่ละทีมและวัดผลก่อนส่งมอบ
เชื่อมกับบริการ AI Infrastructure ↗API, model version และ configuration ที่ทีม application ใช้งานต่อได้
สิทธิ์, quota และขอบเขตของแต่ละ tenant ที่ตรวจสอบได้
รายงาน benchmark, dashboard, runbook และขั้นตอน rollback
จากเครื่องบนโต๊ะ ถึง inference cluster
เลือกจากโมเดลและรูปแบบการใช้งาน แล้วค่อยกำหนด GPU, network และจำนวน replicas
DGX แต่ละรุ่น เริ่ม serving โมเดลอะไรได้บ้าง
ตัวอย่างโมเดลสำหรับเริ่มประเมินตาม memory และ precision โดยต้องยืนยัน checkpoint, engine และ license ก่อนติดตั้งจริง
DGX Spark
1 × GB10 Grace Blackwell
- Memory
- 128 GB LPDDR5x unified
- Bandwidth
- 273 GB/s
- Peak compute
- 1 PFLOP · FP4 sparse
ทดลอง RAG และ private assistant · 1 เครื่อง
โมเดล / precision ตั้งต้นQwen3-32B · FP4 / gpt-oss-120b · MXFP4
เริ่มจาก NVIDIA Spark playbook และ runtime ที่รองรับ GB10 เผื่อ unified memory ให้ OS และ KV cache
Model card / แนวทางติดตั้ง ↗DGX Station GB300
1 × Blackwell Ultra + Grace CPU
- Memory
- 252 GB HBM3e + 496 GB CPU
- Bandwidth
- 7.1 TB/s · GPU HBM
- Peak compute
- 15 / 20 PFLOPS · FP4 dense / sparse
พัฒนาและประเมินโมเดลภายในทีม · 1 เครื่อง
โมเดล / precision ตั้งต้นQwen3-32B · BF16 / Llama 3.3 70B · BF16 / FP8
ตัวเลือกประเมินบน GPU เดียว: 70B BF16 ใช้ weights ประมาณ 140 GB ก่อน KV cache หน่วยความจำ CPU มี bandwidth ต่างจาก HBM
Model card / แนวทางติดตั้ง ↗เริ่ม pilot chatbot หรือ coding assistant · 1 node
โมเดล / precision ตั้งต้นLlama 3.3 70B · BF16 / DeepSeek-R1 671B · FP8
ตัวเลือกประเมิน: 70B ใช้ 2–8 GPUs; R1 FP8 เริ่มที่ 8 GPUs พร้อม tensor / expert parallel แล้ววัด KV cache และ concurrency
Model card / แนวทางติดตั้ง ↗DGX B200
8 × B200 · Blackwell
- Memory
- 180 GB / GPU · 1,440 GB total
- Bandwidth
- 8 TB/s / GPU · 64 TB/s total
- Peak compute
- 72 / 144 PFLOPS · FP4 dense / sparse
ประเมินโมเดลใหญ่หรือแยก serving replicas · 1 node
โมเดล / precision ตั้งต้นLlama 3.3 70B · BF16 / DeepSeek-R1 671B · FP8
ตัวเลือกประเมิน R1 FP8 บน 8 GPUs หรือแยก 70B เป็นหลาย replicas เลือกจำนวน GPU ต่อ replica จาก latency ที่ต้องการ
Model card / แนวทางติดตั้ง ↗DGX B300
8 × B300 · Blackwell Ultra
- Memory
- 288 GB / GPU · 2,304 GB total
- Bandwidth
- 8 TB/s / GPU · 64 TB/s total
เพิ่ม memory สำหรับโมเดลและ KV cache · 1 node
โมเดล / precision ตั้งต้นLlama 3.3 70B · BF16 / DeepSeek-R1 671B · FP8 / BF16 (converted)
R1 FP8 เป็นจุดเริ่มต้น; หากแปลงเป็น BF16 ด้วย engine ที่รองรับ weights ใช้ประมาณ 1.34 TB บน 8 GPUs ก่อน KV cache
Model card / แนวทางติดตั้ง ↗GB300 NVL72
72 × Blackwell Ultra · 36 Grace CPUs
- Memory
- 20 TB GPU HBM · rack total
- Bandwidth
- 576 TB/s · rack aggregate
- Peak compute
- 1,080 / 1,440 PFLOPS · FP4 dense / sparse
Inference pool สำหรับหลายโมเดลและหลายทีม · 1 rack
โมเดล / precision ตั้งต้นDeepSeek-R1 671B · FP8 / BF16 (converted) · multi-replica
แบ่ง GPU เป็น serving groups สำหรับหลาย replicas หรือแยก prefill / decode เริ่มวัดทีละกลุ่มก่อนขยายทั้ง rack
Model card / แนวทางติดตั้ง ↗DGX Vera Rubin NVL72
72 × Rubin · 36 Vera CPUs
- Memory
- 20.7 TB HBM4 · rack total
- Bandwidth
- 1,400 TB/s · rack aggregate
- Peak compute
- 3,600 PFLOPS · NVFP4 inference
วางแผน reasoning และ long-context inference · 1 rack
โมเดล / precision ตั้งต้นDeepSeek-R1 671B · FP8 · evaluation candidate
สเปก preliminary ตาม NVIDIA; ค่า NVFP4 inference ไม่ระบุ sparsity ในตารางอ้างอิง โมเดลเป็นตัวเลือกประเมิน ต้องยืนยัน runtime และ kernel ที่รองรับ Rubin ก่อนติดตั้ง
Model card / แนวทางติดตั้ง ↗Peak compute เป็นค่าสูงสุดตาม precision และ sparsity ที่ระบุ ไม่ใช่ tokens/s ของโมเดลจริง ตัวเลข memory รวมหลาย GPU ต้องใช้ parallelism และเผื่อ weights, KV cache กับ runtime; ตัวอย่างนี้ยังไม่ใช่ผล benchmark ของ Zotect
ตรวจสเปก · H200 / B200 / B300 bandwidth ↗ · Spark model support ↗
ขยายจากเครื่องเดียว เมื่อ workload ต้องการ
เลือกเพิ่ม replicas สำหรับหลายทีม หรือกระจายโมเดลข้าม nodes ตัวอย่างด้านล่างเป็นจุดเริ่มต้นสำหรับ benchmark; concurrency เป็น test load ที่ต้องวัดกับงานจริง
DGX / HGX H200 · B200 · B300
8–256 nodes / 64–2,048 GPUsReplicas & service continuityInference หลายทีมที่ต้องมี replica และ capacity สำรองเวลาปิดซ่อมหรือเปลี่ยนเวอร์ชัน
เมื่อโมเดลหนึ่ง replica ใช้ไม่เกิน 1 node: ตัวอย่าง 8 nodes = serving 4 + spare 2 + batch 2; ถ้าใช้ 2 nodes ต่อ replica ต้องคำนวณสำรองใหม่
H200 · B200 · B300 cluster
8–256 nodes / 64–2,048 GPUsDistributed inferenceประเมิน frontier MoE ระดับ 1–3T parameters หรือแยก prefill/decode สำหรับ long-context และ agent workloads
ช่วงนี้เป็นขนาด cluster รวมหลาย replicas; เริ่ม benchmark ต่อ serving group ที่ FP4/FP8 ที่โมเดลรองรับ, context 32–64K และ 8–32 requests; นับน้ำหนักทุก expert, KV cache, communication buffers และ replica สำรอง
GB300 NVL72 → SuperPOD
1–48 racks / 72–3,456 GPUs18 compute trays per rack · 4 GPUs per trayInference pool ขนาดใหญ่สำหรับหลายโมเดล หลาย tenant และงาน online แยกจาก batch
ตัวอย่างวางแผนเป็น rack ไม่เทียบกับ node แบบ 8 GPUs; 1–48 racks = 18–864 compute nodes แบบ 4 GPUs ชื่อ SuperPOD ใช้เมื่อแบบตรง NVIDIA reference architecture
DGX Vera Rubin NVL72
1–48 racks / 72–3,456 GPUs72 Rubin GPUs + 36 Vera CPUs per rackวางแผน inference pool สำหรับ reasoning, long-context และหลาย tenant บน Rubin
ช่วง rack เป็นตัวอย่างวางแผน; สเปก NVIDIA ยังเป็น preliminary ต้องยืนยัน configuration, software support, power และ cooling ก่อนออกแบบจริง
วิธีเปลี่ยนตัวอย่างให้เป็นขนาดระบบจริง
วัด memory ของ weights + KV cache + runtime overhead ก่อน แล้ว benchmark ด้วย prompt/output และ concurrency จริง เพิ่ม replicas เพื่อ throughput และเผื่อการเสียของทั้ง replica ส่วน multi-node parallelism ใช้เมื่อ memory หรือรูปแบบการคำนวณจำเป็น; การเพิ่ม node ไม่ได้เพิ่ม tokens/s แบบเส้นตรง
MoE ต้องนับ weights ทุก expert พร้อม KV cache และ runtime วัด TTFT p95, เวลาแต่ละ token p95 และ tokens/s รวม ด้วย context, output และ concurrency ของงานจริง ก่อนกำหนด capacity และ HA
ติดตั้งให้ GPU, network และ scheduler ทำงานร่วมกัน
เลือก orchestration ตามงาน ไม่จำเป็นต้องติดตั้งทุกเครื่องมือในทุกระบบ
Kubernetes + NVIDIA Operators
ติดตั้ง NVIDIA GPU Operator สำหรับ driver, container runtime, device plugin และ telemetry ตาม support matrix พร้อม NVIDIA Network Operator สำหรับ networking drivers, RDMA device plugins และ secondary networks เช่น Multus / SR-IOV ตาม topology
เอกสารอ้างอิง ↗RDMA & distributed serving
ตรวจ GPU–NIC locality, InfiniBand หรือ RoCE fabric, GPUDirect RDMA และ NCCL ข้าม nodes ก่อนรัน inference เลือก tensor / pipeline / expert parallel จากโมเดลจริง RDMA ต้องรองรับทั้ง hardware, driver และ fabric ไม่ได้เกิดจากติดตั้ง plugin เพียงอย่างเดียว
เอกสารอ้างอิง ↗Slurm for scheduled workloads
จัด batch inference, evaluation และ fine-tuning ผ่าน Slurm partitions, GRES, QoS และ accounting เลือก Kubernetes สำหรับ API ที่ต้องให้บริการต่อเนื่อง หรือแยก resource pools เมื่อใช้ทั้งสองระบบ ไม่ให้ schedulers แย่ง GPU ชุดเดียวกัน
เอกสารอ้างอิง ↗Spark / Station เป็นจุดเริ่มต้นสำหรับพัฒนาและ local inference ส่วน stack บน cluster ต้องตรวจ GPU architecture, Arm64/x86, OS, driver, NIC และ Kubernetes/Slurm version ร่วมกัน ยืนยัน NIM/Operator support ของแต่ละเครื่องก่อนเสนอแบบ
ให้หลายทีมใช้ GPU ร่วมกันอย่างมีขอบเขต
ผู้ดูแลจัดสรรผ่าน UI/API ผู้ใช้เห็นและใช้งานทรัพยากรตามสิทธิ์ของทีม
NVIDIA Base Command Manager
Provision OS images, ตั้งค่า nodes และติดตามสุขภาพ cluster จากศูนย์กลาง เชื่อมการจัดการ Kubernetes หรือ Slurm ตามแบบที่เลือก
อ่านความสามารถของระบบ ↗NVIDIA Run:ai · GPU / CPU / RAM
ให้ผู้ดูแลกำหนด department, project, node pool, quota และนโยบายการยืม capacity ผ่าน UI/API ผู้ใช้ส่งงานภายใต้สิทธิ์ของตน ปรับ GPU, CPU และ CPU memory quota ตามทีม พร้อม scheduling และ visibility ของทรัพยากร
อ่านความสามารถของระบบ ↗Storage / disk & tenancy
ผูก PVC / storage class, requests.storage และ ephemeral-storage quota กับ Kubernetes ResourceQuota และนโยบาย storage backend แยก namespace, RBAC, secrets และ network policy ต่อ tenant; quota อย่างเดียวไม่ใช่ security isolation
อ่านความสามารถของระบบ ↗Monitoring & capacity trends
เชื่อม DCGM Exporter, Prometheus และ Grafana ให้เห็น GPU utilization / memory, CPU / RAM, storage, fabric errors และการใช้ quota ต่อทีม เก็บประวัติเพื่อดูแนวโน้ม พร้อม inference metrics เช่น TTFT, latency, tokens/s และ queue depth
อ่านความสามารถของระบบ ↗เลือก serving stack ให้ตรงกับทีมดูแล
มีทั้ง NVIDIA enterprise และ open source สามารถประกอบร่วมกันได้ตาม compatibility และรูปแบบ support
NVIDIA AI Enterprise + NIMNVIDIA enterprise
Inference microservices พร้อมเส้นทาง enterprise support เลือก container และ GPU ที่อยู่ใน support matrix; production entitlement และ license ของโมเดลตรวจแยกกัน
ดูเอกสารเครื่องมือ ↗NVIDIA Dynamo + TensorRT-LLMNVIDIA open source
ออกแบบ distributed serving, prefill/decode และ KV-aware routing ด้วย Dynamo; เลือก TensorRT-LLM เป็น engine ตาม model/backend support
ดูเอกสารเครื่องมือ ↗vLLM / SGLangOpen source
Serving engine สำหรับ API และ continuous batching เลือก runtime ตาม architecture, quantization และผล benchmark ของโมเดล
ดูเอกสารเครื่องมือ ↗KV cache + LMCacheOpen source
KV cache เป็นกลไกเก็บ attention state; LMCache ช่วย reuse / offload / transfer cache ใน backend ที่รองรับ ตรวจ memory budget, hit rate และ isolation ก่อนเปิดใช้
ดูเอกสารเครื่องมือ ↗LiteLLMOpen source + enterprise options
API gateway สำหรับ routing, keys, rate limits และ token budgets ตาม edition; ไม่ใช่ GPU scheduler และ token budget ไม่ใช่ GPU quota
ดูเอกสารเครื่องมือ ↗DCGM Exporter · Prometheus · GrafanaOpen tooling
Telemetry, dashboards และ alerts สำหรับทรัพยากรและ endpoint พร้อม retention ที่เหมาะกับการวาง capacity
ดูเอกสารเครื่องมือ ↗เลือกหนึ่ง serving engine เป็น baseline ก่อน แล้วเพิ่ม gateway, KV-cache layer หรือ distributed serving เมื่อ benchmark ชี้ว่าจำเป็น NVIDIA AI Enterprise support/entitlement และฟีเจอร์เชิงพาณิชย์ของแต่ละเครื่องมือต้องตรวจตามรุ่นที่ส่งมอบ; open weights ไม่ได้หมายความว่าทุก license เป็น open source
โมเดลสำหรับเริ่ม ประเมินกับงานของคุณ
คัดตัวอย่างจากกลุ่มอันดับสูงของ LLM Stats แล้วเชื่อมไปยัง weights ของผู้พัฒนา ไม่ใช่รายการที่ Zotect ทดสอบรับรองทุก configuration แล้ว
LLM Stats · ตรวจข้อมูล · อันดับรวมทุกโมเดล ณ วันที่ตรวจ
Kimi K3
ตัวเลือกประเมินงาน coding, reasoning และ multimodal agents
moonshotai/Kimi-K3GLM-5.3
ตัวเลือกประเมินงาน coding และ agent ที่ต้องทำงานหลายขั้นตอน
zai-org/GLM-5.3Qwen3.8 Max / open checkpoint
คะแนนเป็นของ Qwen3.8 Max; open checkpoint เป็นฐานที่เกี่ยวข้อง ไม่ใช่ hosted API เดียวกัน ต้องทดสอบคุณภาพและฟีเจอร์ใหม่
Qwen/Qwen3.8-2.4T-A95BDeepSeek-V4-Pro-0813
ตัวเลือกประเมินงาน reasoning, coding และ tool-using agents
deepseek-ai/DeepSeek-V4-Pro-0813อันดับ benchmark ไม่ใช่สถิติการใช้งานจริง และไม่บอกผลภาษาไทยหรือข้อมูลเฉพาะองค์กร จึงต้องทดสอบคุณภาพ, license, engine support และ memory ของ checkpoint ที่เลือกใหม่ รวมทั้งวัด context ที่ใช้งานจริง ไม่ใช้ maximum context ใน model card เป็น capacity รับประกัน
Open-weight เทียบกับ frontier AI ได้แค่ไหน
ดูความสามารถแยกตามประเภทงาน เพื่อเลือกโมเดลที่ควรนำมาทดสอบบน GPU ของคุณ
Snapshot ตรวจเมื่อ 23 กันยายน 2026 · เทียบกับ frontier รุ่นที่อยู่ในตารางต้นทาง ไม่ใช่อันดับล่าสุดแบบ live คำว่า open-weight หมายถึงมี weights ให้ใช้งานภายใต้ license ของแต่ละรุ่น และอาจเป็น frontier model ได้เช่นกัน
Kimi K3 (max)เทียบกับGPT-5.6 Sol (max)
ผลรายงานโดย Moonshot AI ↗GPQA Diamond
Terminal-Bench 2.1
คะแนนใกล้กันในสองชุดทดสอบนี้ งาน terminal ใช้ agent harness ต่างกัน จึงต้องทดสอบซ้ำใน workflow เดียวกัน
GLM-5.3เทียบกับGPT-5.6 Sol
ผลรายงานโดย Z.AI ↗Terminal-Bench 2.1
DeepSWE v1.1
ใกล้กันในงาน terminal แต่ยังมีช่องว่างใน DeepSWE การเลือกโมเดลสำหรับ coding ต้องดูชนิดงานและ harness
DeepSeek-V4-Pro-0813เทียบกับClaude Fable 5 (w/ fallback)
ผลรายงานโดย DeepSeek ↗Terminal-Bench 2.1
DeepSWE
งาน terminal ใกล้กัน ขณะที่ DeepSWE ยังต่างกัน 7.3 จุด ผล Claude ในตารางต้นทางระบุว่ามี fallback
คะแนนสูงกว่าดีกว่าในชุดทดสอบที่แสดง แถบใช้สเกล 0–100 เดียวกัน แต่ห้ามนำคะแนนคนละ benchmark มาเฉลี่ยรวม ผลจากผู้พัฒนาอาจใช้ reasoning budget, tools และ harness ต่างกัน ความใกล้ของตัวเลขไม่ยืนยันว่าเก่งเท่ากันทางสถิติหรือทดแทนกันได้ทุกงาน รวมถึงไม่ได้ยืนยันผลภาษาไทย ความเร็ว หรือต้นทุนบน GPU ของคุณ
มี GPU อยู่แล้ว? เริ่มจาก serving baseline
ส่งรุ่น GPU / จำนวน nodes, โมเดลเป้าหมาย, context, requests พร้อมกัน และ latency ที่ต้องการ เพื่อคุยขอบเขตติดตั้งและ benchmark
Deployment และ Release
กำหนด version, promotion และ rollback ของ model และ configuration
- Model version
- Promotion
- Rollback
RAG Production Integration
เชื่อมแหล่งข้อมูล retrieval และ application พร้อมจุดตรวจสอบ
- Data sources
- Retrieval
- Application
Performance และ Cost
เก็บ throughput, latency และ resource usage เพื่อใช้ตัดสินใจ
- Throughput
- Latency
- Resource usage
Observability และ Governance
บันทึกสัญญาณการทำงาน การเปลี่ยนแปลง และสิทธิ์การเข้าถึง
- Operating signals
- Change records
- Access
Managed AI Platform Operations
ดูแล platform เชิงรุกหลังยืนยัน technical baseline
- Technical baseline
- Platform care
- Service agreement
สิ่งที่ต้องติดตาม ทุกครั้งที่ระบบเปลี่ยน
กำหนด owner, release record, rollback path และสัญญาณการทำงานของแต่ละบริการ
Release Control
เก็บ version และการอนุมัติของ model, prompt และ configuration
Observability
ติดตามสัญญาณของ application, model และ infrastructure ในบริบทเดียวกัน
Security
กำหนดการเข้าถึงข้อมูล model endpoint และ operational tools
เริ่มจากสถานะ ของระบบคุณ
แต่ละระยะเป็นขอบเขตงานแยกกัน เริ่มได้หลังทบทวน baseline ของระบบร่วมกัน
Discover
ประเมิน serving, data path และ operation แล้วจัดลำดับ gap
Build
ติดตั้ง platform, integration, observability และ release path
Support
ช่วย incident, configuration review และ model change เชิงรับ
Operate
ดูแล platform เชิงรุกภายใต้ service agreement
คุยจากโมเดล ข้อมูล และระบบที่คุณมี
ทบทวน serving, data path และ operation เพื่อกำหนดขอบเขตงานร่วมกัน
ดูบริการ AI Infrastructure