บริการ
GPU Token Platform for Data Centers
ขาย GPU ใน Data Center เป็นราย Token ไม่ใช่รายเครื่อง
เปลี่ยน GPU ใน Data Center ให้เป็นบริการ AI แบบคิดตามการใช้งาน ทั้ง API แบบ OpenAI-compatible, Metering ราย Token, Prepaid Wallet และ Billing แบบไทย สร้างอยู่บน GPU Cluster ของคุณ
เหมาะกับใคร
องค์กรที่มีหรือกำลังสร้าง GPU Capacity และต้องการขายหรือจัดสรรเป็นบริการ AI
Data Center & Colocation Operators
มี GPU ติดตั้งในแร็กแล้ว แต่ยังไม่มี Product Layer ที่ขาย Inference ให้ Developer ตาม Usage
Telco & Cloud Providers
บริการ AI Inference ในประเทศ ที่ต้องเรียกเก็บเงินผ่านบัญชีลูกค้าและระบบ Invoice เดิม
Sovereign & Public-Sector AI
โมเดลที่ต้องรันบนฮาร์ดแวร์ในประเทศ และต้องแยก Usage พร้อม Audit ได้รายหน่วยงานหรือรายโครงการ
Enterprises with Private GPU Clusters
GPU ภายในที่หลายหน่วยธุรกิจใช้ร่วมกัน และต้องทำ Chargeback รายทีมและรายโครงการ
Universities & Research Institutes
Cluster ส่วนกลางที่แบ่ง Quota ให้แล็บและนักศึกษา พร้อม Spend Limit รายกลุ่ม
AI Startups & Model Providers
ให้บริการโมเดลของตัวเองหรือ Open-weight Model กับลูกค้า โดยมี Metered Prepaid Billing ตั้งแต่วันแรก
ขั้นตอนการสร้าง Platform
4 เฟส เรียงตามชั้นของ Platform เริ่มจาก Access แล้วจึง Token Core และ Commercial Layer
- 01
Scope
ตกลงขอบเขต ทั้งโมเดลที่จะให้บริการ กลุ่มลูกค้า และใครดูแล Inference Layer ทีมของคุณ (Option A) หรือ HarmonyX (Option B)
- 02
Access
ตั้ง Gateway แบบ OpenAI-compatible พร้อม TLS และ Streaming, API Key ตาม Organization และ Project และ RPM/TPM Limit กับ Spend Cap ราย Key
- 03
Token core
Route แต่ละโมเดลไปยัง Cluster ที่ถูกต้องพร้อม Load Balancing และ Fallback นับ Input/Output Token เป็น Usage Event ที่แก้ไม่ได้ และ Settle ทุก Request กับ Prepaid Wallet ใน Double-entry Ledger
- 04
Commercial
ตั้งราคาต่อ 1M Token พร้อม Tier และราคา Enterprise เก็บเงินผ่าน PromptPay บัตร หรือโอน พร้อม e-Tax Invoice แล้วเปิด Developer Portal และ Admin Console พร้อม Daily Reconciliation
สิ่งที่เราสร้างอยู่บน
ทุกชั้นระหว่างผู้ใช้กับ GPU ของคุณ รันอยู่บน Cluster ที่คุณดูแลอยู่แล้ว
Access Layer
- OpenAI-compatible API
- TLS & SSE Streaming
- API Key & Organization
- RPM / TPM Limit
- Spend Cap
Token Core
- Model Router
- Load Balancing & Fallback
- Token Metering
- Wallet แบบ Reserve & Settle
- Double-entry Ledger
Inference Layer
- vLLM
- SGLang
- Model Registry
- Usage Reporting
- Kubernetes
Commercial & Ops
- ราคาต่อ 1M Token
- PromptPay / บัตร / โอน
- e-Tax Invoice
- Observability & Audit Log
- Daily Reconciliation
Data Center ที่มี GPU มี Compute อยู่แล้ว แต่สิ่งที่มักยังไม่มีคือ Product ที่ให้ Developer สมัคร รับ API Key เรียกโมเดล แล้วจ่ายตาม Token ที่ใช้จริง พอไม่มีชั้นนี้ GPU ก็ต้องขายแบบเดิม คือขายเป็นเครื่องเป็นรายเดือน ให้ลูกค้าไม่กี่รายที่ใหญ่พอจะรัน Inference Stack เองได้ เราสร้างทุกชั้นระหว่างผู้ใช้กับ GPU ของคุณ เพื่อให้ขาย Capacity เป็นราย Token ได้
ระหว่างผู้ใช้กับ GPU มีอะไรบ้าง?
มีสามชั้น ทั้งหมดสร้างอยู่บน Cluster ที่คุณรันอยู่แล้ว
- Access Layer: API Gateway แบบ OpenAI-compatible รองรับ TLS และ Streaming (SSE) ออกและเพิกถอน API Key ตาม Organization และ Project พร้อม RPM/TPM Rate Limit, Spend Cap และการแจ้งเตือนราย Key
- Token Core: Model Router ที่เลือก Cluster ตามโมเดล พร้อม Load Balancing และ Fallback ระบบนับ Input/Output Token และ Wallet กับ Ledger ที่ทุก Request ต้อง Settle
- Commercial Layer: Pricing Engine คิดราคาต่อ 1M Token มี Tier และราคา Enterprise ระบบ Billing รับ PromptPay บัตร และโอนเงิน พร้อม Invoice และ e-Tax Invoice และ Developer Portal กับ Admin Console ที่มีรายงาน
ใต้ทั้งสามชั้นมี Observability, Audit Log, Notification และงาน Daily Reconciliation ที่ตรวจว่ายอด Usage, Ledger และการชำระเงินตรงกัน
ทำไม Metering กับ Ledger คือหัวใจ
ทุกบาทที่ลูกค้าถูกเรียกเก็บย้อนกลับไปได้ที่สองส่วนนี้ Metering บันทึก Input และ Output Token ของทุก Request เป็น Usage Event ที่แก้ไขย้อนหลังไม่ได้ Wallet จะ Reserve ค่าใช้จ่ายโดยประมาณก่อน Request รัน และ Settle ยอดจริงเมื่อรันเสร็จ ลูกค้าแบบเติมเงินจึงใช้เกินยอดคงเหลือไม่ได้ ทั้งสองส่วนเขียนลง Double-entry Ledger ทำให้ไล่ทุกบาทจาก Invoice กลับไปถึง Request ต้นทางได้ ถ้าสองส่วนนี้ถูก เรื่อง Pricing, Billing และ Report ก็ตรงไปตรงมา ถ้าผิด Dashboard สวยแค่ไหนก็แก้ข้อพิพาทไม่ได้
ถ้าไล่บรรทัดใน Invoice กลับไปหา Request ต้นทางไม่ได้ แปลว่าคุณไม่ได้ขาย Token แต่กำลังขายตัวเลขประมาณการ
ใครดูแล Inference Layer?
Inference Layer ให้บริการโมเดลด้วย vLLM หรือ SGLang เก็บ Model Registry ของโมเดลและเวอร์ชัน และส่งจำนวน Token กลับไปที่ Metering ผ่าน Internal API เราตกลงกันตั้งแต่เริ่มว่าใครเป็นคนดูแล
- Option A: ทีมของคุณดูแล Inference บน Cluster ของคุณเอง แล้วเราเชื่อม Platform เข้ากับมันผ่าน Internal API
- Option B: HarmonyX ติดตั้งและดูแล Inference Layer บน GPU Cluster ของคุณเป็นส่วนหนึ่งของ Engagement
ส่วนที่ยังเป็นของคุณ
ตัว Data Center เอง ได้แก่ GPU Server ที่คุณหรือ Vendor จัดหา, Kubernetes Cluster ทั้ง Compute, Storage และ Network และ Facility ทั้งไฟฟ้า ความเย็น และ Security Platform ของเรารันอยู่บนโครงสร้างพื้นฐานนั้น ไม่ได้มาแทนที่
ถ้ามี GPU Capacity แต่ยังขายตาม Usage ไม่ได้ เริ่มด้วย Architecture Workshop เรา Map Cluster ของคุณ โมเดลที่อยากให้บริการ และกลุ่มลูกค้า แล้วตกลง Scope รวมถึงว่าใครดูแล Inference
สิ่งที่ Platform รับประกัน
คุณสมบัติที่ออกแบบไว้ตั้งแต่ Release แรก ไม่ใช่ Feature ที่มาเติมทีหลัง
ถูกบันทึกเป็น Usage Event ที่แก้ไม่ได้ ไล่ทุกบรรทัดใน Invoice กลับไปหา Request ได้
Request ต้อง Reserve จาก Wallet ก่อนรัน และ Settle เมื่อรันเสร็จ
OpenAI-compatible ใช้ SDK และ Tool เดิมได้แค่เปลี่ยน Base URL
Usage, Ledger และการชำระเงิน Reconcile ทุกวัน พร้อม Flag ยอดที่ไม่ตรง
คำถามที่พบบ่อย
คำถามที่พบบ่อย
HarmonyX สร้างอะไรบ้างใน GPU Token Platform?
ทุกชั้นระหว่างผู้ใช้กับ GPU ของคุณ ได้แก่ API Gateway แบบ OpenAI-compatible, API Key และ Rate Limit, Model Router, Metering ราย Token, Prepaid Wallet กับ Double-entry Ledger, Pricing Engine ต่อ 1M Token, Billing ผ่าน PromptPay บัตร และโอนเงิน พร้อม e-Tax Invoice และ Developer Portal กับ Admin Console โดยมี Observability, Audit Log และ Daily Reconciliation ครอบทั้งหมด
ต้องยก GPU Cluster ให้ HarmonyX ดูแลไหม?
ไม่ต้อง GPU Server, Kubernetes Cluster และ Facility ยังเป็นของคุณ ส่วน Inference Layer ที่ให้บริการโมเดลด้วย vLLM หรือ SGLang เลือกได้สองแบบ คือทีมของคุณดูแลเองแล้วเราเชื่อมผ่าน Internal API (Option A) หรือ HarmonyX ติดตั้งและดูแลบน Cluster ของคุณ (Option B)
มั่นใจได้อย่างไรว่าเรียกเก็บเงินลูกค้าถูกต้อง?
Input และ Output Token ของทุก Request ถูกบันทึกเป็น Usage Event ที่แก้ไม่ได้ Wallet จะ Reserve ค่าใช้จ่ายโดยประมาณก่อน Request รัน แล้ว Settle ยอดจริงหลังรันเสร็จ ทั้งคู่เขียนลง Double-entry Ledger และมีงาน Daily Reconciliation ตรวจว่า Usage, Ledger และการชำระเงินตรงกัน ทุกบรรทัดใน Invoice จึงไล่กลับไปหา Request ต้นทางได้
มี GPU Capacity แต่ยังขายตาม Usage ไม่ได้?
เริ่มด้วย Architecture Workshop เรา Map Cluster ของคุณ โมเดลที่อยากให้บริการ และกลุ่มลูกค้า แล้วตกลง Scope รวมถึงว่าทีมของคุณหรือทีมเราจะดูแล Inference Layer