วิธีโฮสต์ Kolibri-1 ด้วยตนเอง: สเปกฮาร์ดแวร์ที่ต้องใช้

การโฮสต์ Kolibri-1 ด้วยตนเอง: คำตอบโดยย่อ

การโฮสต์ Kolibri-1 ด้วยตนเองสามารถทำได้ แต่ไม่สามารถทำบน VPS ทั่วไปได้ Aleph Alpha จากเมือง Heidelberg ได้เผยแพร่โมเดลนี้ภายใต้สัญญาอนุญาต Apache 2.0 โดยน้ำหนักโมเดลในรูปแบบ FP8 มีขนาดประมาณ 78 GB วิธีการที่เป็นทางการคือการใช้ vLLM บน GPU รุ่น H200 อย่างน้อยหนึ่งตัว หรือบนการ์ดจอสองตัวที่มีหน่วยความจำตัวละ 80 GB ปัจจุบันยังไม่มีวิธีการที่เป็นทางการสำหรับการใช้งานบน CPU, GGUF, llama.cpp หรือ Ollama

สำหรับผู้อ่านจำนวนมากในเยอรมนี คำถามสำคัญคือข้อมูลจะยังคงอยู่ภายในองค์กรหรือไม่ ซึ่ง Kolibri-1 สามารถทำได้และสัญญาอนุญาตก็ไม่ได้เป็นอุปสรรคในเรื่องนี้ อุปสรรคสำคัญคือเรื่องฮาร์ดแวร์

สถานะของข้อมูล: ข้อมูลทั้งหมดในที่นี้อ้างอิงจาก Model Card ของ Aleph-Alpha/Kolibri-1 ในฉบับแก้ไข e52eb4627d11516b0c01de49210ab5a4e4061444 (Hugging Face, 3 ตุลาคม 2026) และแพ็กเกจ aleph-alpha-inference เวอร์ชัน 1.0.0 ตรวจสอบล่าสุดเมื่อวันที่ 10 ตุลาคม 2026 ฉบับแก้ไขในภายหลังอาจมีตัวเลขที่แตกต่างออกไป โปรดตรวจสอบข้อมูลก่อนที่คุณจะเช่าหรือซื้อฮาร์ดแวร์

สิ่งที่ Model Card ระบุเกี่ยวกับ Kolibri-1

• สถาปัตยกรรม: MoE (Mixture of Experts) โมเดลประกอบด้วยเครือข่ายย่อยจำนวนมากที่เรียกว่าผู้เชี่ยวชาญ (experts) โดยในแต่ละ token จะมีการประมวลผลเพียงไม่กี่ส่วนเท่านั้น
• ขนาด: พารามิเตอร์รวม 78 พันล้านตัว โดยมีพารามิเตอร์ที่ทำงานจริง 3.46 พันล้านตัวต่อหนึ่ง token ประกอบด้วย 50 เลเยอร์ แต่ละเลเยอร์มีผู้เชี่ยวชาญ 384 ตัว ซึ่งจะถูกเลือกมาใช้งาน 6 ตัวต่อหนึ่ง token
• บริบท (Context): รองรับ 262,144 token ตามค่าเริ่มต้น และข้อมูลใน Card ระบุว่าคุณภาพได้รับการตรวจสอบความถูกต้องจนถึง 1,048,576 token
• น้ำหนัก (Weights): ใช้รูปแบบ FP8 (8-bit floating point) ในรูปแบบ float8_e4m3fn โดยแบ่งเป็นบล็อกขนาด 128×128 ส่วน Embedding และ LM-Head ใช้รูปแบบ bfloat16 ข้อมูลใน Card ระบุว่าขนาดรวมอยู่ที่ประมาณ 78 GB ซึ่งสอดคล้องกับขนาดของ Repository ที่ 78.9 GB
• ข้อมูลการฝึกสอน: ภาษาอังกฤษ 62.5%, ภาษาเยอรมัน 23.9% และโค้ด 13.6% ผ่านการทำ Pre-training ด้วยข้อมูล 20 ล้านล้าน token นอกจากนี้ยังมี Tokenizer ที่ระบุใน Card ว่าปรับแต่งมาเพื่อโครงสร้างภาษาเยอรมันโดยเฉพาะ
• ใบอนุญาต: Apache 2.0 โดย Repository ไม่มีการจำกัดสิทธิ์ (not gated) จึงไม่จำเป็นต้องส่งคำขอเข้าถึง

ประเด็นสำคัญที่สุดอยู่ในสองบรรทัดแรก พารามิเตอร์ที่ทำงานจริง 3.46 พันล้านตัวหมายถึงภาระการคำนวณต่อหนึ่ง token ที่ต่ำ แต่ความต้องการหน่วยความจำจะขึ้นอยู่กับพารามิเตอร์ทั้งหมด 78 พันล้านตัว เนื่องจาก Router จะเลือกผู้เชี่ยวชาญที่แตกต่างกันสำหรับแต่ละ token ดังนั้นผู้เชี่ยวชาญทั้งหมดจึงต้องถูกโหลดไว้ในหน่วยความจำกราฟิก (VRAM) ตลอดเวลา สรุปคือโมเดล MoE จะประมวลผลเหมือนโมเดลขนาดเล็ก แต่ใช้หน่วยความจำเหมือนโมเดลขนาดใหญ่

นอกจากนี้ Tokenizer ยังส่งผลในทางปฏิบัติ Tokenizer มีหน้าที่แบ่งข้อความออกเป็น token หากทำงานได้ไม่ดีกับภาษานั้นๆ คำภาษาเยอรมันที่ยาวจะถูกแบ่งออกเป็นชิ้นเล็กๆ จำนวนมาก ซึ่งจะสิ้นเปลืองพื้นที่บริบทและเวลาในการประมวลผล Tokenizer ที่ปรับแต่งมาเพื่อภาษาเยอรมันจึงใช้จำนวน token น้อยกว่าสำหรับข้อความเดียวกัน

ตัวเลข Benchmark ใน Card

Aleph Alpha ระบุคะแนนรวมสองค่าสำหรับโมเดลที่ผ่านการฝึกสอนเพิ่มเติมนี้ ซึ่งเป็นตัวเลขจากการประเมินของผู้ผลิตเอง ไม่ใช่การทดสอบจากหน่วยงานอิสระ

[
  {
    "label": "Deutsch (Overall DE)",
    "overall": 70.8
  },
  {
    "label": "Englisch (Overall EN)",
    "overall": 75.5
  }
]

ในภาษาเยอรมัน Kolibri-1 ทำคะแนนได้ 70.8 คะแนน และในภาษาอังกฤษได้ 75.5 คะแนน โมเดลนี้จึงยังคงมีประสิทธิภาพในภาษาอังกฤษสูงกว่าเล็กน้อย การจะตัดสินว่าเพียงพอสำหรับงานของคุณหรือไม่นั้น จำเป็นต้องทดสอบด้วยเอกสารของคุณเองเท่านั้น

สิ่งที่เปลี่ยนแปลงไปจาก Pharia

โมเดลรุ่นก่อนหน้าของ Aleph Alpha มีชื่อว่า Pharia โดย Card ของ Pharia-1-LLM-7B-control ระบุถึง Open Aleph License ซึ่งอนุญาตให้ใช้เพื่อการวิจัยและการสอนที่ไม่ใช่เชิงพาณิชย์เท่านั้น หากต้องการใช้ในเชิงพาณิชย์จะต้องติดต่อ Aleph Alpha โดยตรง ในขณะที่ Kolibri-1 ใช้ใบอนุญาต Apache 2.0 คุณจึงสามารถนำโมเดลไปใช้ในองค์กรและแจกจ่ายต่อในรูปแบบที่ดัดแปลงได้ ตราบใดที่ยังคงแนบข้อความใบอนุญาตและประกาศแจ้งเตือนไว้ด้วย

Kolibri-1 ต้องการ GPU รุ่นใด

เอกสารระบุความต้องการไว้ 2 ระดับ ได้แก่ ขั้นต่ำ: 2× A100 80 GB, 2× H100 SXM5, 1× H200, 1× B200 หรือ 1× B300 และระดับแนะนำ: 2× H100 SXM5, 2× H200, 1× B200 หรือ 1× B300

เหตุใด H100 เพียงตัวเดียวจึงไม่เพียงพอ คำนวณได้ง่ายๆ คือให้นำขนาดของน้ำหนักโมเดล (weights) หักออกจากหน่วยความจำกราฟิกหรือ VRAM (video random access memory) พื้นที่ที่เหลืออยู่ vLLM จะนำไปใช้สำหรับ KV-Cache เป็นหลัก โดย KV-Cache จะทำหน้าที่จัดเก็บค่าคีย์ (keys) และค่า (values) ของชั้น Attention สำหรับทุกโทเค็นในบริบท หากไม่มีส่วนนี้ โมเดลจะไม่สามารถรักษาบริบทไว้ได้

[
  {
    "config": "1\u00d7 H100 80 GB",
    "vram_gb": 80,
    "gewichte_gb": 79,
    "rest_gb": 1
  },
  {
    "config": "1\u00d7 H200",
    "vram_gb": 141,
    "gewichte_gb": 79,
    "rest_gb": 62
  },
  {
    "config": "2\u00d7 A100 80 GB",
    "vram_gb": 160,
    "gewichte_gb": 79,
    "rest_gb": 81
  },
  {
    "config": "2\u00d7 H100 SXM5",
    "vram_gb": 160,
    "gewichte_gb": 79,
    "rest_gb": 81
  },
  {
    "config": "2\u00d7 H200",
    "vram_gb": 282,
    "gewichte_gb": 79,
    "rest_gb": 203
  }
]

H100 หนึ่งตัวมี VRAM 80 GB โดยน้ำหนักโมเดลใช้พื้นที่ไป 79 GB ในเชิงคำนวณจะเหลือพื้นที่ 1 GB ซึ่งไม่เพียงพอสำหรับบริบทที่มีความหมาย H200 หนึ่งตัวจะเหลือพื้นที่ 62 GB และ H200 สองตัวจะเหลือพื้นที่ 203 GB พื้นที่สำรองจริงนั้นน้อยกว่านี้ เนื่องจาก vLLM ใช้พื้นที่ VRAM เพียง 92% ตามค่าเริ่มต้น (--gpu-memory-utilization, ค่าเริ่มต้น 0.92 ใน vLLM 0.29.0) อีกทั้งส่วนของ activations ก็ต้องการพื้นที่เช่นกัน ค่าเหล่านี้เป็นการคำนวณโดยประมาณ ไม่ใช่การวัดผลจริง

คุณสมบัติสองประการของสถาปัตยกรรมนี้ช่วยลดภาระของ KV-Cache ประการแรก ตามเอกสารระบุว่า Kolibri-1 ผสมผสานชั้น Sliding-Window-Attention เข้ากับชั้น Full-Attention ในอัตราส่วน 4:1 โดยชั้น Sliding-Window จะจัดเก็บเฉพาะโทเค็นภายในหน้าต่างที่กำหนดเท่านั้น แคชของชั้นนี้จึงไม่เพิ่มขึ้นตามความยาวบริบททั้งหมด ประการที่สอง เอกสารแนะนำให้ใช้ --kv-cache-dtype fp8 ซึ่งทำให้รายการแคชแต่ละรายการใช้หน่วยความจำเพียงครึ่งหนึ่งเมื่อเทียบกับแบบ 16 บิต อย่างไรก็ตาม ชั้น Full-Attention ยังคงขยายตัวตามจำนวนโทเค็นที่เพิ่มขึ้น ซึ่งที่ระดับ 262.144 โทเค็น พื้นที่บน H200 เพียงตัวเดียวจะเริ่มไม่เพียงพอ

เหตุผลที่ VPS ทั่วไปไม่สามารถรัน Kolibri-1 ได้

Aleph Alpha เผยแพร่เฉพาะวิธีการใช้งานผ่าน vLLM โดยต้องใช้ GPU เท่านั้น ในเอกสารไม่ได้ระบุถึงการทำงานบน CPU หรือการรองรับ GGUF, llama.cpp หรือ Ollama แต่อย่างใด VPS ที่ใช้ CPU ทั่วไปไม่มีหน่วยความจำกราฟิก (VRAM) จึงขาดพื้นฐานสำคัญที่จำเป็นสำหรับวิธีการนี้

อย่างไรก็ตาม บน Hugging Face มีการแปลงไฟล์เป็นรูปแบบ GGUF โดยชุมชนผู้ใช้งาน การค้นหาคำว่า “kolibri-1 gguf” ณ วันที่ 6 ตุลาคม 2026 พบ repository สำหรับ Kolibri-1 ทั้งหมด 8 รายการ และมีรายการใหม่เพิ่มขึ้นอย่างต่อเนื่อง ไฟล์ขนาด Q4_K_M มีขนาดประมาณ 47,5 GB ซึ่งตามการคำนวณแล้วสามารถใส่ในเซิร์ฟเวอร์ที่มี RAM 64 GB ได้ แต่ repository ที่เราตรวจสอบเมื่อวันที่ 6 ตุลาคม 2026 ระบุชัดเจนว่า llama.cpp เวอร์ชันปกติยังไม่รู้จักสถาปัตยกรรม kolibri1 คุณจำเป็นต้องใช้เวอร์ชันที่ได้รับการแก้ไข (patched) บน commit ที่กำหนดเท่านั้น ผู้เขียนระบุว่าได้ทดสอบเพียงการรันระยะสั้นๆ โดยส่วนใหญ่ใช้บริบท (context) ขนาด 4.096 ถึง 8.192 token เท่านั้น ส่วนบริบทที่ยาวกว่านั้นและคุณภาพเมื่อเทียบกับต้นฉบับยังถือว่าไม่ได้ผ่านการตรวจสอบ สำหรับข้อมูลองค์กรแล้ว นี่ไม่ใช่พื้นฐานที่มั่นคง แต่เป็นเพียงการทดลองเท่านั้น

ปริมาณ RAM ที่โมเดลแต่ละระดับการทำ quantization ต้องการนั้น สามารถคำนวณได้ทีละขั้นตอนจาก คู่มือว่าด้วยขนาดของ LLM ที่เหมาะสมกับ RAM ของคุณ ส่วนเหตุผลที่ vLLM เป็นเครื่องมือที่เลือกใช้ในที่นี้ สามารถดูได้จาก การเปรียบเทียบระหว่าง Ollama และ vLLM: vLLM ถูกสร้างมาเพื่อรองรับคำขอจำนวนมากพร้อมกันบน GPU ในขณะที่ Ollama ออกแบบมาเพื่อการเริ่มต้นใช้งานโมเดลที่ผ่านการทำ quantization ได้อย่างง่ายดาย

การติดตั้ง Kolibri-1 ด้วย vLLM

คุณต้องมีเซิร์ฟเวอร์ Linux ที่มาพร้อมกับ GPU ของ NVIDIA และติดตั้งไดรเวอร์เรียบร้อยแล้ว สำหรับสิ่งที่ควรพิจารณาเมื่อเช่าเซิร์ฟเวอร์ โปรดดูที่ ภาพรวมของ VPS ที่มี GPU ก่อนอื่นให้ตรวจสอบว่าเครื่องของคุณมีทรัพยากรอะไรบ้าง:

nvidia-smi --query-gpu=name,memory.total --format=csv

ผลลัพธ์จะแสดงชื่อและหน่วยความจำของแต่ละการ์ดในหน่วย MiB โดยการ์ด H100 ควรแสดงค่าประมาณ 81,000 MiB และ H200 ประมาณ 143,000 MiB หากคำสั่งไม่แสดงข้อมูลไดรเวอร์ แสดงว่ายังไม่ได้ติดตั้งไดรเวอร์ NVIDIA ซึ่งจะทำให้ vLLM ไม่พบ GPU

จากนั้นให้สร้าง Python environment แยกต่างหาก แพ็กเกจนี้จะดึง vLLM และ PyTorch ตามช่วงเวอร์ชันที่กำหนด การใช้ environment แยกจะช่วยป้องกันไม่ให้กระทบกับโปรแกรมอื่นบนเซิร์ฟเวอร์

sudo apt update && sudo apt install -y python3-venv
python3 -m venv ~/kolibri
source ~/kolibri/bin/activate
pip install 'aleph-alpha-inference==1.0.0'
pip show vllm aleph-alpha-inference

การ์ดระบุไว้ที่ pip install 'aleph-alpha-inference>=1' โดยเวอร์ชันถูกล็อกไว้ที่ 1.0.0 เพื่อป้องกันไม่ให้เวอร์ชันที่ใหม่กว่าเปลี่ยนแปลงการตั้งค่าของคุณโดยไม่ตั้งใจ เวอร์ชัน 1.0.0 ต้องการ Python 3.10 ขึ้นไป และ vLLM ตั้งแต่ 0.29.0 แต่ต่ำกว่า 0.30.0 ดังนั้น pip show ควรแสดง vLLM เวอร์ชัน 0.29.x แพ็กเกจนี้เป็นปลั๊กอินสำหรับ vLLM ซึ่งจะลงทะเบียน Parser kolibri1 สำหรับการใช้เหตุผล (Reasoning) และการเรียกใช้เครื่องมือ (Tool calls) หากไม่มีปลั๊กอินนี้ vLLM จะไม่รู้จักชื่อเหล่านี้

นอกจากนี้ Aleph Alpha ยังมี Container image ให้ใช้งานคือ ghcr.io/aleph-alpha/aleph-alpha-inference สำหรับผู้ที่ใช้งาน GPU เซิร์ฟเวอร์ด้วยคอนเทนเนอร์สามารถเลือกใช้วิธีนี้ได้

การปิดระบบ Telemetry ของ vLLM

โดยปกติ vLLM จะส่งสถิติการใช้งานแบบไม่ระบุตัวตน หากเป้าหมายของคุณคือการไม่ให้ข้อมูลใดๆ ออกจากเซิร์ฟเวอร์ ให้ปิดระบบนี้ก่อนเริ่มใช้งาน:

export VLLM_NO_USAGE_STATS=1
export DO_NOT_TRACK=1

การเริ่มเซิร์ฟเวอร์

คำสั่งจะเป็นไปตามที่ระบุในการ์ด โดยมีการเพิ่มเติมสองส่วนคือการระบุ Revision ที่แน่นอนและการผูกไว้กับ localhost

vllm serve Aleph-Alpha/Kolibri-1 \
  --revision e52eb4627d11516b0c01de49210ab5a4e4061444 \
  --host 127.0.0.1 --port 8000 \
  --kv-cache-dtype fp8 \
  --reasoning-parser kolibri1 \
  --tool-call-parser kolibri1 \
  --enable-auto-tool-choice

--revision ใช้กำหนดสถานะของน้ำหนัก (Weights) ที่จะโหลด หากไม่มีตัวเลือกนี้ vLLM จะโหลดสถานะล่าสุดจาก main ซึ่งหาก Aleph Alpha เปลี่ยนแปลง Repository โมเดลของคุณจะเปลี่ยนไปในการดาวน์โหลดครั้งถัดไป --host 127.0.0.1 จะทำให้ API เข้าถึงได้เฉพาะภายในเครื่องเท่านั้น หากไม่มีตัวเลือกนี้ vLLM จะรับฟังการเชื่อมต่อจากทุก Network interface ซึ่งจะทำให้พอร์ต 8000 เปิดใช้งานทันทีหาก Firewall อนุญาต

หากมี GPU สองตัว ให้เพิ่ม --tensor-parallel-size 2 ตัวเลือกนี้จะกระจายแต่ละเลเยอร์ไปยังการ์ดทั้งสองใบ หากไม่มีตัวเลือกนี้ vLLM จะใช้ GPU เพียงใบเดียว ซึ่งน้ำหนักโมเดลจะไม่สามารถบรรจุลงในการ์ดขนาด 80 GB เพียงใบเดียวได้

ในการเริ่มครั้งแรก vLLM จะดาวน์โหลดข้อมูลประมาณ 79 GB จาก Hugging Face ไปยัง ~/.cache/huggingface โปรดตรวจสอบให้แน่ใจว่ามีพื้นที่ดิสก์เพียงพอสำหรับทั้งการดาวน์โหลดและ Python environment หลังจากดาวน์โหลดสำเร็จในครั้งแรก คุณสามารถใช้ export HF_HUB_OFFLINE=1 เพื่อป้องกันการเชื่อมต่อกับ Hugging Face ในอนาคตได้ โดยน้ำหนักโมเดลจะถูกดึงมาจาก Local cache เท่านั้น

หากหน่วยความจำไม่เพียงพอสำหรับ Context เต็มรูปแบบที่ 262,144 Token vLLM จะไม่เริ่มทำงาน ข้อความแสดงข้อผิดพลาดจะระบุว่า KV-cache มีขนาดเล็กเกินไปสำหรับความยาวลำดับสูงสุด ในกรณีนี้ให้กำหนดขีดจำกัดที่ต่ำลง เช่น --max-model-len 65536 สำหรับการขยาย Context สูงสุดถึง 1,048,576 Token การ์ดแนะนำให้ใช้ --max-model-len 1048576 และ --hf-overrides '{"max_position_embeddings": 1048576}' ซึ่งต้องใช้หน่วยความจำมากกว่าปกติมากและควรใช้กับ Configuration ที่แนะนำเท่านั้น

การตรวจสอบการตอบสนองของโมเดล

เมื่อ Log แสดงว่าเซิร์ฟเวอร์ทำงานบนพอร์ต 8000 แล้ว ให้ทดสอบ API ที่รองรับมาตรฐาน OpenAI:

curl http://127.0.0.1:8000/v1/models
curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "Aleph-Alpha/Kolibri-1", "messages": [{"role": "user", "content": "Was ist die Hauptstadt von Frankreich?"}], "chat_template_kwargs": {"enable_thinking": false}}'

การเรียกใช้งานครั้งแรกควรแสดง Aleph-Alpha/Kolibri-1 เป็นชื่อโมเดล ส่วนครั้งที่สองควรส่งคืน JSON ที่ระบุว่า choices[0].message.content คือปารีส enable_thinking: false จะปิดโหมดการคิด (Reasoning) สำหรับคำขอนี้ โดยปกติโหมดนี้จะเปิดอยู่ ตามการ์ดระบุว่า reasoning_effort ที่ค่า none ก็มีผลเช่นกัน สำหรับการ Sampling การ์ดแนะนำให้ใช้ temperature=1.0, top_p=0.97 และ top_k=128

สำหรับการเข้าถึงจากเครื่องของคุณเอง คุณไม่จำเป็นต้องเปิดพอร์ตทิ้งไว้ การใช้ SSH tunnel ก็เพียงพอแล้ว:

ssh -L 8000:127.0.0.1:8000 user@dein-server

หลังจากนั้นคุณจะสามารถเข้าถึง API ได้ที่เครื่องของคุณผ่าน http://127.0.0.1:8000 หากต้องการให้บริการอื่นในเครือข่ายเข้าถึงได้ ให้ตั้งค่า --api-key เพิ่มเติมและติดตั้ง Reverse proxy ที่มี TLS (transport layer security) ไว้ด้านหน้า

Kolibri-1 หนึ่งชั่วโมงมีค่าใช้จ่ายกี่ยูโร?

ราคาเช่า GPU มีความผันผวนสูงตามผู้ให้บริการและภูมิภาค การคำนวณด้านล่างใช้สมมติฐานสองประการ ณ เดือนตุลาคม 2026: 3,50 ยูโรต่อชั่วโมงสำหรับ H200 และ 2,50 ยูโรต่อชั่วโมงสำหรับ H100 SXM5 โดยเป็นราคาแบบ on demand และไม่รวมภาษีมูลค่าเพิ่ม ผู้ให้บริการ GPU เฉพาะทางบางรายอาจมีราคาต่ำกว่านี้ ในขณะที่ Hyperscaler ในภูมิภาค EU มักจะมีราคาสูงกว่ามาก ให้คุณใส่ราคาจากข้อเสนอที่คุณได้รับจริง วิธีการคำนวณยังคงเหมือนเดิม

[
  {
    "plan": "1\u00d7 H200, rund um die Uhr",
    "eur_pro_stunde": 3.5,
    "stunden_pro_monat": 730,
    "eur_pro_monat": 2555
  },
  {
    "plan": "2\u00d7 H100 SXM5, rund um die Uhr",
    "eur_pro_stunde": 5,
    "stunden_pro_monat": 730,
    "eur_pro_monat": 3650
  },
  {
    "plan": "1\u00d7 H200, nur B\u00fcrozeit",
    "eur_pro_stunde": 3.5,
    "stunden_pro_monat": 176,
    "eur_pro_monat": 616
  }
]

หนึ่งเดือนมีค่าเฉลี่ยอยู่ที่ 730 ชั่วโมง หากใช้งาน H200 ตลอด 24 ชั่วโมง จะมีค่าใช้จ่าย 2555 ยูโรต่อเดือน ตัวเลือกที่แนะนำคือการใช้ H100 สองตัว ซึ่งจะมีค่าใช้จ่าย 3650 ยูโร หากใช้งานเครื่องเฉพาะช่วงเวลาทำงาน คือ 8 ชั่วโมงต่อวัน เป็นเวลา 22 วันทำการ รวมเป็น 176 ชั่วโมง จะมีค่าใช้จ่าย 616 ยูโร อย่างไรก็ตาม การเริ่มใช้งานแต่ละครั้งจะต้องโหลดน้ำหนัก (weights) เข้าสู่หน่วยความจำกราฟิกใหม่ ซึ่งต้องใช้เวลาสักครู่

เมื่อใดที่การเช่า GPU คุ้มค่ากว่าการใช้ API Token?

ณ เดือนตุลาคม 2026 ข้อมูลระบุว่าไม่มี API สำหรับ Kolibri-1 ที่โฮสต์ไว้ให้ใช้งาน ดังนั้นการเปรียบเทียบกับราคา Token จึงหมายถึง: การรัน Kolibri-1 บน GPU ของตนเอง เทียบกับการใช้โมเดลอื่นผ่าน API สำหรับการคำนวณนี้ เราใช้สมมติฐานราคาต่อล้าน Token สองระดับ โดยเป็นราคาเฉลี่ยรวมทั้งขาเข้าและขาออก: 0,50 ยูโรสำหรับโมเดลราคาประหยัด และ 2 ยูโรสำหรับโมเดลที่มีราคาสูงกว่า

[
  {
    "plan": "1\u00d7 H200, rund um die Uhr",
    "mio_token_bei_0_50_eur": 5110,
    "mio_token_bei_2_eur": 1277.5,
    "token_pro_sekunde_bei_0_50_eur": 1944
  },
  {
    "plan": "2\u00d7 H100 SXM5, rund um die Uhr",
    "mio_token_bei_0_50_eur": 7300,
    "mio_token_bei_2_eur": 1825,
    "token_pro_sekunde_bei_0_50_eur": 2778
  },
  {
    "plan": "1\u00d7 H200, nur B\u00fcrozeit",
    "mio_token_bei_0_50_eur": 1232,
    "mio_token_bei_2_eur": 308,
    "token_pro_sekunde_bei_0_50_eur": 1944
  }
]

ที่ราคา 0,50 ยูโรต่อล้าน Token การใช้งาน H200 แบบต่อเนื่องจะคุ้มทุนเมื่อมีการใช้งานถึง 5110 ล้าน Token ต่อเดือน ซึ่งเฉลี่ยแล้วต้องได้ 1944 Token ต่อวินาที ตลอด 24 ชั่วโมงโดยไม่มีหยุดพัก หากราคาอยู่ที่ 2 ยูโรต่อล้าน Token เกณฑ์คุ้มทุนสำหรับตัวเลือกการใช้งานเฉพาะช่วงเวลาทำงานจะลดลงเหลือ 308 ล้าน Token คุณต้องวัดผลเองว่าการ์ดใบเดียวสามารถรองรับปริมาณงานนี้ได้หรือไม่ โดยพิจารณาจากความยาวของ Prompt และคำตอบที่คุณใช้งานจริง การคำนวณนี้เป็นเพียงการระบุว่าปริมาณงานเท่าใดที่ควรเริ่มพิจารณาความคุ้มค่า

วิธีการคำนวณโดยละเอียดที่รวมอัตราการใช้งานและช่วงเวลาว่าง (idle) อยู่ใน การคำนวณจุดคุ้มทุนระหว่าง GPU Server กับ API Token สำหรับ Kolibri-1 มีประเด็นเพิ่มเติมที่ไม่มีในตาราง หากคุณต้องการโฮสต์ Kolibri-1 ด้วยตนเองเพื่อเหตุผลด้านข้อมูล คุณอาจไม่ได้เปรียบเทียบกับ API ตั้งแต่แรก หากเอกสารสำคัญไม่สามารถนำออกนอกองค์กรได้ การใช้ API จะถูกตัดออกไปทันที คำถามที่แท้จริงจึงกลายเป็น: จะเช่า GPU ในศูนย์ข้อมูลใน EU ที่มีสัญญาประมวลผลข้อมูล (AVV) หรือจะซื้อฮาร์ดแวร์ของตนเอง ทั้งนี้ GPU ที่เช่ามาก็ยังถือว่าอยู่ในความดูแลของบุคคลที่สาม ตามกฎหมาย GDPR (ระเบียบการคุ้มครองข้อมูลส่วนบุคคลทั่วไป) นี่ถือเป็นการประมวลผลข้อมูลโดยผู้รับจ้าง ไม่ใช่การดำเนินการภายในองค์กรเอง

เมื่อโมเดลขนาดเล็กในเครื่องเป็นคำตอบที่เหมาะสมกว่า

Kolibri-1 จะคุ้มค่าเมื่อคุณต้องการใช้จุดแข็งของมัน ตามข้อมูลในเอกสารระบุว่าจุดแข็งดังกล่าวรวมถึงการเรียกใช้เครื่องมือ (tool calls) และการประมวลผลเอกสารที่มีบริบทขนาดยาว โดย 262.144 token สามารถรองรับเนื้อหาจากแฟ้มสัญญาได้ทั้งชุดในการสอบถามเพียงครั้งเดียว หากงานของคุณมีขนาดสั้นกว่านั้น ผลลัพธ์ที่ได้จะแตกต่างออกไป

สำหรับการคัดแยกอีเมลหรือการสรุปความสั้นๆ โมเดลที่มีพารามิเตอร์ขนาด 7 ถึง 14 พันล้านพารามิเตอร์มักจะเพียงพอ หากทำ quantization ที่ 4 bit โมเดลจะสามารถรันบน Ollama บน CPU-VPS ที่มี RAM ขนาด 16 ถึง 32 GB ได้ แม้จะทำงานช้ากว่า GPU แต่ก็เพียงพอสำหรับการสอบถามจำนวนหลายร้อยครั้งต่อวัน คุณสามารถดูวิธีการทำได้ที่ คู่มือการ self-host Ollama บน VPS ซึ่งค่าใช้จ่ายจะอยู่ที่ราคาเช่าเซิร์ฟเวอร์รายเดือนปกติ ไม่ใช่การคิดราคาแบบรายชั่วโมงของ GPU

โมเดลขนาดเล็กที่น่าสนใจจากผู้พัฒนาเดียวกันคือ Pharia-1-LLM-7B-control อย่างไรก็ตาม ตามข้อกำหนดใน Open Aleph License ระบุว่าอนุญาตให้ใช้เพื่อวัตถุประสงค์ที่ไม่ใช่เชิงพาณิชย์และไม่ใช่การบริหารจัดการเท่านั้น จึงไม่ใช่ทางเลือกสำหรับการใช้งานภายในองค์กร

คุณสามารถตัดสินใจได้อย่างถูกต้องก็ต่อเมื่อได้ทำการทดสอบจริง ให้นำงานจริงจากชีวิตประจำวันของคุณมา 50 รายการ แล้วให้ Kolibri-1 แก้ไขงานเหล่านั้นบน GPU ที่เช่าแบบรายชั่วโมง เปรียบเทียบกับโมเดลขนาดเล็กบน CPU-VPS จากนั้นจึงเปรียบเทียบคำตอบที่ได้ ค่าเช่าทดสอบเพียงไม่กี่ชั่วโมงมีราคาถูกมากเมื่อเทียบกับการซื้อฮาร์ดแวร์ที่ผิดพลาด

คุณสามารถดูผลลัพธ์ของคำถามเดียวกันเมื่อใช้โมเดลแบบเปิดตัวอื่นได้ที่ สิ่งที่ต้องใช้ในการ self-host Kimi K3 การเปรียบเทียบนี้จะช่วยให้คุณเห็นภาพชัดเจนขึ้น โดย Kolibri-1 ซึ่งมีน้ำหนักโมเดลประมาณ 78 GB จัดเป็นหนึ่งในโมเดลที่ยังสามารถรันบนการ์ดจอใบเดียวได้

FAQ

ฉันสามารถใช้ Kolibri-1 ในเชิงพาณิชย์ได้หรือไม่?

ได้ Kolibri-1 อยู่ภายใต้สัญญาอนุญาต Apache 2.0 ตามที่ระบุไว้ใน Model Card คุณสามารถนำไปใช้งานในองค์กรและแจกจ่ายต่อในรูปแบบที่แก้ไขแล้วได้ หากคุณแนบข้อความสัญญาอนุญาตและประกาศแจ้งเตือนไว้ด้วย ซึ่งจุดนี้ทำให้ Kolibri-1 แตกต่างจากตระกูล Pharia รุ่นก่อนหน้า โดยที่ Card ของ Pharia-1-LLM-7B-control ระบุถึง Open Aleph License ซึ่งตามข้อความในสัญญาอนุญาตนั้นอนุญาตให้ใช้ได้เฉพาะเพื่อวัตถุประสงค์ที่ไม่ใช่เชิงพาณิชย์และไม่ใช่การบริหารจัดการเท่านั้น

Kolibri-1 ทำงานร่วมกับ Ollama หรือบน CPU ได้หรือไม่?

ไม่รองรับอย่างเป็นทางการ Aleph Alpha เผยแพร่เฉพาะวิธีการใช้งานผ่าน vLLM บน NVIDIA GPU โดยใช้ปลั๊กอิน aleph-alpha-inference เท่านั้น ปัจจุบันมีไฟล์ GGUF จากคลังข้อมูลของชุมชนหลายแห่ง เช่น ขนาด 47,5 GB ในรูปแบบ Q4_K_M ซึ่งจำเป็นต้องใช้ llama.cpp ที่ผ่านการแพตช์แล้ว เนื่องจาก llama.cpp รุ่นมาตรฐานไม่รู้จักสถาปัตยกรรม kolibri1 ทั้งนี้ ผู้พัฒนาเองยังไม่ได้ตรวจสอบคุณภาพและบริบทระยะยาวของไฟล์เหล่านี้

การใช้ H100 ขนาด 80 GB เพียงใบเดียวเพียงพอสำหรับ Kolibri-1 หรือไม่?

ไม่เพียงพอ น้ำหนัก (weights) แบบ FP8 เพียงอย่างเดียวก็ใช้พื้นที่ไปประมาณ 78 GB แล้ว ทำให้แทบไม่เหลือพื้นที่สำหรับ KV-cache ที่ใช้เก็บข้อมูลบริบท (context) โดย Card ระบุความต้องการขั้นต่ำไว้ที่ H100 SXM5 จำนวนสองใบ หรือ H200 หนึ่งใบ หากใช้การ์ดสองใบ คุณต้องเริ่มการทำงานของ vLLM ด้วย --tensor-parallel-size 2

ฉันจะปิดโหมดการคิด (thinking mode) ของ Kolibri-1 ได้อย่างไร?

โหมดการคิดจะเปิดใช้งานเป็นค่าเริ่มต้น คุณสามารถปิดโหมดนี้ได้ในแต่ละคำขอด้วยการระบุ "chat_template_kwargs": {"enable_thinking": false} ใน JSON body ตามที่ระบุใน Card นอกจากนี้ยังสามารถใช้ reasoning_effort ร่วมกับค่า none ได้เช่นกัน หากเปิดโหมดนี้ไว้ ระบบจะใช้ --reasoning-parser kolibri1 ในการแยกข้อความส่วนที่เป็นการคิดออกจากคำตอบจริง