วิธีรัน Nemotron 3.5 Lightning บน VPS ด้วย Ollama

จุดประสงค์ของ Nemotron 3.5 Lightning

Nemotron 3.5 Lightning คือโมเดลแบบ mixture-of-experts ขนาด 30B แบบเปิดของ NVIDIA ซึ่งเปิดตัวในเดือนสิงหาคม 2026 โดยถูกสร้างมาเพื่อรองรับเอเจนต์ที่ต้องทำงานต่อเนื่องเป็นเวลาหลายชั่วโมง แทนที่จะเป็นเพียงหน้าต่างแชททั่วไป สถาปัตยกรรมแบบ MoE (mixture-of-experts) หมายความว่าค่าน้ำหนัก (weights) จะถูกแบ่งออกเป็นเครือข่ายย่อยของผู้เชี่ยวชาญจำนวนมาก และแต่ละโทเค็นจะถูกส่งผ่านไปยังผู้เชี่ยวชาญเพียงไม่กี่กลุ่มเท่านั้น ข้อมูลโมเดลของ NVIDIA ระบุว่ามีพารามิเตอร์รวม 30 พันล้านตัว โดยมีพารามิเตอร์ที่ทำงานจริง 3 พันล้านตัวต่อหนึ่งโทเค็น คุณต้องจ่ายค่าหน่วยความจำสำหรับจำนวนพารามิเตอร์ทั้งหมด แต่จะได้รับความเร็วในการประมวลผลตามจำนวนพารามิเตอร์ที่ทำงานจริง

การแลกเปลี่ยนประสิทธิภาพนี้คือเหตุผลที่คุณควรพิจารณาโมเดลนี้สำหรับเซิร์ฟเวอร์ที่คุณเช่าใช้งาน เอเจนต์ที่ทำงานจริงจะส่งคำขอสั้นๆ นับพันรายการตลอดทั้งวัน ดังนั้นปริมาณงาน (throughput) ต่อต้นทุนจึงเป็นตัวตัดสินว่าเอเจนต์นั้นจะสามารถรันบนเซิร์ฟเวอร์ของคุณเองได้หรือไม่ โมเดลที่ใช้เวลา 40 วินาทีต่อการตอบกลับอาจเป็นผู้ช่วยที่ดี แต่เป็นเอเจนต์ที่แย่ เพราะหนึ่งงานอาจต้องเรียกใช้งานถึง 20 ครั้ง และคุณต้องรอผลลัพธ์ในทุกๆ ครั้ง

NVIDIA อธิบายสถาปัตยกรรมนี้ว่าเป็นแบบไฮบริด โดยมีการสลับชั้น Mamba-2 และ MoE เข้าด้วยกันพร้อมกับชั้น attention บางส่วน ข้อมูลโมเดลระบุความยาวบริบทสูงสุดไว้ที่ 1M โทเค็น และใช้สัญญาอนุญาต OpenMDW-1.1 ซึ่งระบุว่าพร้อมสำหรับการใช้งานเชิงพาณิชย์ ภาษาหลักที่รองรับคือภาษาอังกฤษและภาษาโปรแกรม โดยมีภาษาสเปน ฝรั่งเศส เยอรมัน อิตาลี และญี่ปุ่นรวมอยู่ในรายการด้วย

Artificial Analysis ได้เผยแพร่ผลการวัดประสิทธิภาพในช่วงเปิดตัวเมื่อเดือนสิงหาคม 2026 โดยแสดงให้เห็นความเร็วเกือบ 670 โทเค็นต่อวินาทีบน endpoint ของ DeepInfra รุ่นทดสอบที่ใช้ค่าน้ำหนัก NVFP4 ซึ่งเป็น endpoint ของ GPU ที่โฮสต์ไว้ โปรดอ่านข้อมูลนี้ในฐานะขีดความสามารถที่สถาปัตยกรรมทำได้ ไม่ใช่ประสิทธิภาพที่ VPS ของคุณจะทำได้จริง

แท็ก Ollama ใดที่เหมาะสมกับ VPS ของคุณ

ไลบรารีของ Ollama เผยแพร่บิลด์ของน้ำหนัก (weights) ชุดเดียวกันหลายเวอร์ชัน สิ่งที่แตกต่างกันคือการทำ quantization ซึ่งหมายถึงจำนวนบิตที่ใช้จัดเก็บน้ำหนักแต่ละตัว และสิ่งนี้ส่งผลต่อขนาดไฟล์ดาวน์โหลดอย่างมาก

[
  {
    "label": "30b-a3b-q4_K_M",
    "size_gb": 25
  },
  {
    "label": "30b-a3b-q8_0",
    "size_gb": 35
  },
  {
    "label": "30b-a3b-bf16",
    "size_gb": 66
  },
  {
    "label": "30b-a3b-mlx",
    "size_gb": 23
  }
]

แท็กที่ชื่อ latest, 30b และ 30b-a3b ทั้งหมดชี้ไปยัง digest เดียวกันกับ 30b-a3b-q4_K_M ดังนั้นการดาวน์โหลดแบบปกติจะเป็นบิลด์ขนาด 25 GB ที่ระดับ 4-bit พร้อม context ขนาด 1M ส่วน Q8_0 มีขนาด 35 GB และ bf16 มีขนาด 66 GB ซึ่งทั้งคู่รองรับ context 1M เช่นกัน สำหรับบิลด์ MLX ที่ขนาด 23 GB นั้นออกแบบมาสำหรับ Apple silicon และจำกัด context ไว้ที่ 256K จึงไม่ใช่ตัวเลือกที่เหมาะสมสำหรับ Linux VPS

ตัวเลขเหล่านี้คือขนาดไฟล์ดาวน์โหลด ไม่ใช่ความต้องการหน่วยความจำ NVIDIA ไม่ได้ระบุตัวเลข VRAM (video RAM) ขั้นต่ำสำหรับบิลด์ของ Ollama ดังนั้นให้ถือว่าขนาดไฟล์ดาวน์โหลดเป็นเพียงค่าต่ำสุดเท่านั้น น้ำหนักของโมเดลจะต้องถูกโหลดไว้ในหน่วยความจำ ไม่ว่าจะเป็นหน่วยความจำ GPU หากการ์ดรองรับ หรือใน RAM ของระบบหากไม่รองรับ นอกจากนี้ยังมี KV cache (key/value cache ซึ่งเป็นหน่วยความจำต่อโทเค็นของโมเดลในการสนทนา) ที่ต้องนำมาคำนวณเพิ่มด้วย ตัวเลขที่แท้จริงสำหรับฮาร์ดแวร์ของคุณนั้นได้มาจากการใช้คำสั่งตรวจสอบ ไม่ใช่การคำนวณทางคณิตศาสตร์ ซึ่งระบุไว้ด้านล่างนี้ หากคุณยังไม่ได้ตัดสินใจเลือกระดับการทำ quantization ต้นทุนที่ต้องแลกของ Q4, Q8 และ FP16 จะอธิบายถึงสิ่งที่คุณต้องสูญเสียไปในแต่ละระดับ

ดึง tag ที่ระบุเจาะจง ห้ามใช้ latest

latest เป็นตัวชี้ที่เปลี่ยนแปลงได้ตลอดเวลา เมื่อ library มีการเผยแพร่เวอร์ชันใหม่ พฤติกรรมของ agent ของคุณจะเปลี่ยนไปในการดึงข้อมูลครั้งถัดไปโดยไม่มีบันทึกใดๆ อธิบายถึงสาเหตุที่เกิดขึ้น ดังนั้นให้ระบุชื่อ tag ให้ชัดเจน

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
ollama pull nemotron-3.5-lightning:30b-a3b-q4_K_M

สคริปต์ติดตั้งจะตั้งค่า systemd service ให้รันในฐานะผู้ใช้ ollama และเก็บโมเดลไว้ภายใต้ /usr/share/ollama/.ollama/models โดยปกติ path ดังกล่าวจะอยู่บน root filesystem ของ VPS ส่วนใหญ่ ดังนั้นควรตรวจสอบพื้นที่ว่างก่อนที่จะร้องขอ 25 GB หาก filesystem ดังกล่าวมีพื้นที่จำกัด การอ่าน ตำแหน่งที่ Ollama จัดเก็บโมเดลและวิธีการย้าย ก่อนที่จะทำการดึงข้อมูล จะดีกว่าการมาอ่านหลังจากที่ดิสก์เต็มไปแล้ว

df -h /usr/share/ollama

การดึงข้อมูลที่หยุดชะงักกลางคันและรายงานข้อผิดพลาด no space left on device หมายความตามนั้นจริงๆ และข้อมูลบางส่วนที่ค้างอยู่ (partial blobs) จะยังคงอยู่ในดิสก์จนกว่าคุณจะลบออก จากนั้นให้ยืนยันสิ่งที่ติดตั้งสำเร็จด้วยคำสั่ง:

ollama show nemotron-3.5-lightning:30b-a3b-q4_K_M

ollama show จะแสดงสถาปัตยกรรม, จำนวนพารามิเตอร์, ความยาวของ context และการทำ quantisation ที่ไฟล์นั้นมีอยู่จริง หากค่าเหล่านี้ไม่ตรงกับข้อมูลในหน้า library แสดงว่าคุณได้ดึง tag ที่ไม่ตรงกับที่คุณต้องการมา

ให้บริการและตรวจสอบว่ามันทำงานที่ไหน

sudo systemctl enable --now ollama
ollama run nemotron-3.5-lightning:30b-a3b-q4_K_M "Reply with one word: ready"

ในขณะที่โมเดลยังคงถูกโหลดอยู่ ให้เปิด shell ที่สองขึ้นมา:

ollama ps

นี่คือคำสั่งที่ตอบคำถามเรื่องหน่วยความจำสำหรับเครื่องของคุณ ollama ps จะแสดงโมเดลที่โหลดอยู่ ขนาดที่ใช้ในหน่วยความจำ และคอลัมน์ PROCESSOR ค่า 100% GPU หมายความว่าโมเดลทั้งหมดอยู่ใน VRAM ส่วน 100% CPU หมายความว่าไม่มีส่วนใดอยู่ใน VRAM เลย และทุก token จะถูกประมวลผลโดย CPU จาก system RAM การแบ่งส่วนเช่น 65%/35% CPU/GPU หมายความว่าเลเยอร์ทั้งหมดไม่สามารถบรรจุลงใน VRAM ได้ และสัดส่วนที่ CPU รับผิดชอบจะเป็นตัวกำหนดความเร็วของคุณ อย่าคาดเดาความต้องการหน่วยความจำ ให้โหลดโมเดลแล้วอ่านบรรทัดนี้

หากไม่สามารถโหลดได้เลย Ollama จะปฏิเสธการทำงานอย่างชัดเจนแทนที่จะเกิดการ crash:

Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB)

VPS ที่ใช้เฉพาะ CPU มีความเร็วเพียงพอหรือไม่?

VPS อเนกประสงค์ทั่วไปไม่มี GPU ดังนั้น CPU จึงต้องรับหน้าที่ประมวลผลทั้งหมดและอ่านค่าน้ำหนัก (weight) ทุกค่าที่จำเป็นจาก RAM ของระบบ เทคนิค MoE ช่วยในส่วนนี้ได้เนื่องจากมีการเรียกใช้พารามิเตอร์เพียงประมาณ 3 พันล้านจากทั้งหมด 30 พันล้านพารามิเตอร์ต่อหนึ่ง token ทำให้การคำนวณเลขคณิตต่อ token น้อยกว่าโมเดลแบบ dense ขนาด 30B มาก แต่ในส่วนของหน่วยความจำนั้นไม่ได้ช่วยอะไรเลย พารามิเตอร์ทั้ง 30 พันล้านตัวต้องถูกโหลดไว้ในหน่วยความจำตลอดเวลา เพราะตัว router สามารถเลือก expert ตัวใดก็ได้สำหรับทุก token

ดังนั้น การทำ inference บน CPU เพียงอย่างเดียวสำหรับโมเดลนี้จึงถูกจำกัดด้วย memory bandwidth มากกว่าจำนวน core การเพิ่ม vCPU ให้กับแผนบริการที่มีจำนวน core เพียงพออยู่แล้วจึงแทบไม่มีผล สิ่งที่คุณต้องการคือ RAM ที่มากพอสำหรับเก็บค่าน้ำหนักรวมถึง KV cache และหน่วยความจำที่เร็วที่สุดเท่าที่แผนบริการนั้นจะให้ได้

ให้ทำการวัดผลก่อนที่คุณจะมอบหมายงานให้ agent โดยใช้วิธีการใน การวัดจำนวน token ต่อวินาทีสำหรับ LLM ในเครื่อง:

ollama run --verbose nemotron-3.5-lightning:30b-a3b-q4_K_M "Write a 200 word summary of TCP slow start."

บรรทัด eval rate ที่แสดงผลในตอนท้ายคือความเร็วในการสร้างข้อความของคุณในหน่วย token ต่อวินาที ตัวเลขนี้เพียงค่าเดียวเป็นตัวตัดสินคำถามนี้ เพราะเวลาที่ใช้จริง (wall-clock time) ของ agent ขึ้นอยู่กับค่านี้เป็นหลัก ให้นำไปคูณกับความยาวของคำตอบที่คุณคาดหวัง หากคำตอบนั้นยาวเกินกว่าที่คุณจะรอได้ การจำกัดผลลัพธ์ด้วย num_predict คือเครื่องมือเดียวที่จะควบคุมการเรียกใช้งานแต่ละครั้งโดยไม่ต้องเปลี่ยนฮาร์ดแวร์

[
  {
    "label": "Nemotron 3.5 Lightning",
    "sec_per_task": 30
  },
  {
    "label": "gpt-oss-120b",
    "sec_per_task": 204
  },
  {
    "label": "Qwen3.6 35B",
    "sec_per_task": 210
  }
]

ตัวเลขเหล่านั้นเป็นตัวเลขจากบุคคลที่สามที่เผยแพร่ไว้ ซึ่งแปลงมาจากเวลาต่อภารกิจ (นาที) ที่ Artificial Analysis รายงานไว้ในช่วงเปิดตัว โดยวัดจาก endpoint ที่เป็น GPU บนคลาวด์ไม่ใช่บน VPS ตัว Nemotron 3.5 Lightning มีค่าเฉลี่ยอยู่ที่ 30 วินาทีต่อภารกิจ โดยที่ gpt-oss-120b ใช้เวลาประมาณ 204 และ Qwen3.6 35B ใช้เวลาประมาณ 210 ให้ใช้ตัวเลขเหล่านี้เพื่อดูสัดส่วนความแตกต่าง ไม่ใช่เพื่อการการันตีประสิทธิภาพบนฮาร์ดแวร์ของคุณ

คำแนะนำที่ตรงไปตรงมาขึ้นอยู่กับว่าใครเป็นผู้รอ หากมีคนรอคำตอบจาก agent หรือ agent ต้องเรียกใช้งานต่อเนื่องกันหลายครั้งเป็นลูกโซ่ ให้เช่า GPU หากงานรันตามกำหนดการในช่วงกลางคืนโดยไม่มีใครเฝ้าดู แผนบริการ CPU ที่มี RAM ขนาดใหญ่ก็เป็นทางเลือกที่เหมาะสม ไม่ว่าจะเลือกทางใด การตั้งค่าก็เหมือนกัน และ การรัน Ollama บน VPS จะครอบคลุมเรื่องการเลือกขนาดแผนบริการและการเปรียบเทียบระหว่างการใช้ instance GPU กับการจ่ายค่าบริการผ่าน API ตามจำนวน token จุดคุ้มทุนขึ้นอยู่กับการใช้งาน: instance GPU จะคิดค่าบริการทุกชั่วโมงที่เปิดใช้งาน ในขณะที่ API จะคิดค่าบริการเฉพาะตอนที่ใช้งานเท่านั้น ดังนั้น agent ที่ทำงานเกือบตลอดทั้งวันจะคุ้มค่ากว่าหากคุณเป็นเจ้าของเครื่องเอง ส่วน agent ที่ทำงานเพียงไม่กี่ครั้งต่อชั่วโมงมักจะไม่คุ้มค่าที่จะเช่าเครื่องไว้ตลอดเวลา

หน้าต่างบริบทขนาด 1M ไม่ได้ใช้งานได้ฟรี

1M tokens คือค่าสูงสุดของโมเดล แต่ Ollama ไม่ได้กำหนดค่านี้ให้คุณโดยอัตโนมัติ Ollama จะกำหนดหน้าต่างเริ่มต้นที่มีขนาดเล็กกว่ามาก และจะลบ tokens ที่เก่าที่สุดทิ้งเมื่อการสนทนาเกินขีดจำกัดดังกล่าว โดยไม่มีการบันทึก log ใดๆ เมื่อเกิดเหตุการณ์นี้ขึ้น สำหรับ agent แล้ว มันจึงดูเหมือนว่าโมเดลลืมจุดเริ่มต้นของงานที่ได้รับมอบหมายไป

คุณต้องกำหนดขนาดหน้าต่างด้วยตนเอง หากต้องการตั้งค่าสำหรับทั้งเซิร์ฟเวอร์ ให้แก้ไข service ดังนี้:

sudo systemctl edit ollama

เพิ่มบรรทัดต่อไปนี้ลงไป จากนั้นรัน sudo systemctl restart ollama:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

หากต้องการตั้งค่าเฉพาะคำขอ ให้ส่ง num_ctx ในออบเจกต์ options แทน:

curl http://localhost:11434/api/chat -d '{
  "model": "nemotron-3.5-lightning:30b-a3b-q4_K_M",
  "messages": [{"role": "user", "content": "Say ready"}],
  "options": {"num_ctx": 32768},
  "stream": false
}'

การเพิ่มขนาดทุกครั้งจะใช้หน่วยความจำเพิ่มขึ้น เนื่องจาก KV cache จะขยายตัวตามจำนวน tokens ที่คุณอนุญาต ให้เพิ่มค่าดังกล่าว รีสตาร์ท แล้วรัน ollama ps อีกครั้งเพื่อดูขนาดที่รายงานว่าเพิ่มขึ้น หากคอลัมน์ PROCESSOR เปลี่ยนจาก 100% GPU เป็น split หลังจากการเปลี่ยนแปลงนั้น แสดงว่า KV cache ได้ผลักเลเยอร์ของโมเดลออกจาก VRAM และความเร็วในการประมวลผลของคุณจะลดลงอย่างมาก การเลือก num_ctx ใน Ollama จะอธิบายรายละเอียดเกี่ยวกับข้อแลกเปลี่ยนนี้ อย่าตั้งค่าเป็น 1000000 เพียงเพราะ model card อนุญาตให้ทำได้ เนื่องจากการจองหน่วยความจำจะเกิดขึ้นทันทีและจะทำให้การโหลดล้มเหลวในที่สุด

การเชื่อมต่อเข้ากับเอเจนต์ที่ทำงานตลอดเวลา

โพสต์เปิดตัว Ollama สำหรับโมเดลนี้ได้ระบุทางลัดในการเริ่มเอเจนต์ที่รองรับซึ่งชี้ไปยังโมเดลดังกล่าวไว้แล้ว:

ollama launch claude --model nemotron-3.5-lightning

โพสต์ดังกล่าวระบุ claude, opencode, openclaw และ hermes ไว้ในตำแหน่งนั้น คำสั่งย่อยนี้ต้องการ Ollama เวอร์ชันปัจจุบัน ดังนั้นให้ตรวจสอบ ollama --version ก่อน หากไม่มี ให้กำหนดค่าเอเจนต์ให้ชี้ไปยัง API ด้วยตนเอง Ollama จะเปิดใช้งาน endpoint ที่เข้ากันได้กับ OpenAI ซึ่งเครื่องมือจัดการเอเจนต์ส่วนใหญ่รองรับ:

export OPENAI_BASE_URL=http://localhost:11434/v1
export OPENAI_API_KEY=ollama

Ollama จะเพิกเฉยต่อคีย์ดังกล่าว แต่ไคลเอนต์ส่วนใหญ่จะไม่ยอมเริ่มทำงานหากไม่มีการตั้งค่าคีย์ไว้ ส่วนการตั้งค่าฝั่งเครื่องมือจัดการนั้นครอบคลุมอยู่ใน การชี้เอเจนต์เขียนโค้ดไปยัง Ollama และใน การสร้างเอเจนต์ OpenClaw ของคุณเอง

การตั้งค่าเซิร์ฟเวอร์สองรายการมีความสำคัญเมื่อเอเจนต์ทำงานโดยไม่มีผู้ดูแล OLLAMA_KEEP_ALIVE จะควบคุมระยะเวลาที่โมเดลจะคงอยู่ในหน่วยความจำหลังจากคำขอสุดท้าย โดยค่าเริ่มต้นจะยกเลิกการโหลดโมเดลหลังจากผ่านไปห้านาที ทำให้การเรียกใช้งานครั้งถัดไปต้องเสียเวลาโหลดใหม่ทั้งหมด สำหรับไฟล์ขนาด 25 GB หากไม่มี GPU การหยุดชะงักนั้นจะนานพอที่จะทำให้เกิด timeout ให้ตั้งค่า OLLAMA_KEEP_ALIVE=-1 เพื่อให้โมเดลคงอยู่ในหน่วยความจำตลอดเวลา OLLAMA_HOST=0.0.0.0:11434 จะทำให้ API สามารถเข้าถึงได้จากเครื่องอื่น ซึ่งไม่มีการตรวจสอบสิทธิ์ใดๆ ทั้งสิ้น ดังนั้นควรเปิดใช้งานเฉพาะภายใต้กฎของ firewall หรือเครือข่ายส่วนตัวเท่านั้น

รูปแบบความล้มเหลวและข้อความที่คุณจะพบ

การดึงข้อมูล (pull) ล้มเหลวทันที Error: pull model manifest: file does not exist หมายความว่าแท็กนั้นไม่มีอยู่จริง ชื่อแท็กเป็นสตริงที่ต้องตรงกันทุกตัวอักษร ดังนั้นให้คัดลอกมาจากหน้าไลบรารีแทนการเดาส่วนต่อท้าย (quantisation suffix)

โมเดลไม่โหลด Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB) หมายความว่าแท็กมีขนาดใหญ่เกินกว่าที่กำหนดไว้ในแผนนี้ ให้เปลี่ยนไปใช้รุ่นที่มีการทำ quantisation เล็กลง หรือลดค่า OLLAMA_CONTEXT_LENGTH ลง เนื่องจาก KV cache จะถูกนับรวมอยู่ในข้อกำหนดนั้นด้วย

ไม่มีการตอบสนองที่พอร์ต 11434 curl: (7) Failed to connect to localhost port 11434 หมายความว่าบริการไม่ได้ทำงานอยู่ หรือไม่ได้ฟังพอร์ตในจุดที่คุณคาดหวัง ให้อ่าน systemctl status ollama และ journalctl -u ollama -n 50 หากคุณสั่งเริ่ม ollama serve ด้วยตนเองซ้ำอีกครั้ง สำเนาที่สองจะปิดตัวลงพร้อมกับข้อความ Error: listen tcp 127.0.0.1:11434: bind: address already in use

มีการตอบสนองแต่ช้ามาก ให้ตรวจสอบ ollama ps ก่อนที่จะปรับเปลี่ยนค่าใดๆ หากพบการใช้งาน CPU ในคอลัมน์ PROCESSOR บนเครื่องที่มี GPU หมายความว่าโมเดลบางส่วนถูกย้ายออกจาก VRAM ให้ลดขนาด context หรือใช้รุ่นที่มีการทำ quantisation เล็กลง สำหรับเครื่องที่ไม่มี GPU ความล่าช้าเป็นเรื่องปกติและไม่มีการตั้งค่าใดที่จะแก้ไขได้

เอเจนต์ลืมคำสั่งระหว่างทำงาน การสนทนาเกินขอบเขตของ context window ทำให้โทเค็นเก่าที่สุดถูกลบออกโดยไม่มีการแจ้งเตือน ให้เพิ่มค่า OLLAMA_CONTEXT_LENGTH และยืนยันด้วย ollama ps ว่าโมเดลยังคงโหลดได้พอดี หากไม่พอดี วิธีแก้ไขคือการใช้เครื่องที่มีสเปกสูงขึ้นแทนการลดขนาดหน้าต่าง context

ตำแหน่งของโมเดลนี้เมื่อเทียบกับทางเลือกอื่น

โมเดล 30B MoE เป็นโมเดลขนาดใหญ่เกินความจำเป็นสำหรับงานขนาดเล็ก หากโมเดลแบบ dense ขนาด 8B สามารถจัดการงานของคุณได้อยู่แล้ว การใช้งานโมเดลดังกล่าวจะมีต้นทุนต่ำกว่ามากและใช้เวลาโหลดเพียงไม่กี่วินาที โดย Qwen 3 ขนาด 8B และ 27B บน VPS คือการเปรียบเทียบโดยตรงสำหรับการตัดสินใจในเรื่องนี้ สำหรับการสำรวจภาพรวมว่าแผนบริการที่คุณเลือกสามารถรองรับโมเดลใดได้บ้าง ให้เริ่มต้นที่ โมเดล AI ที่คุณสามารถ self-host ได้ หากคุณวางแผนที่จะให้บริการเอเจนต์หลายตัวพร้อมกันแทนที่จะเป็นตัวเดียว โปรดอ่าน การเปรียบเทียบ Ollama กับ vLLM ก่อน เนื่องจาก Ollama ไม่ได้ประมวลผลคำขอพร้อมกันแบบ batch เหมือนกับ inference server ที่ใช้ในระดับ production ซึ่งเป็นจุดที่การตั้งค่าสำหรับผู้ใช้คนเดียวเริ่มขยายขีดความสามารถไม่ได้อีกต่อไป

FAQ

ฉันควรดึง tag ไหนของ Nemotron 3.5 Lightning บน Linux VPS?

ให้ใช้ nemotron-3.5-lightning:30b-a3b-q4_K_M ซึ่งมีขนาด 25 GB รองรับ context สูงสุดที่ 1M และเป็น digest เดียวกับที่ tag latest, 30b และ 30b-a3b ชี้ไป ณ เดือนสิงหาคม 2026 ให้ระบุชื่อ tag นี้โดยตรงแทนการดึง latest เพื่อป้องกันไม่ให้การ republish ในอนาคตเปลี่ยนพฤติกรรมของ agent โดยที่คุณไม่ทราบ ส่วน tag mlx เป็น build สำหรับ Apple silicon ซึ่งไม่สามารถใช้งานบน Linux ได้

Nemotron 3.5 Lightning ต้องการ RAM เท่าไร?

NVIDIA ไม่ได้ระบุตัวเลข RAM ขั้นต่ำสำหรับ build ของ Ollama ดังนั้นควรใช้วิธีวัดจริงแทนการคาดเดา ให้ดึง tag มาแล้วรันโมเดลหนึ่งครั้ง จากนั้นอ่านค่าจาก ollama ps ขณะที่โมเดลโหลดอยู่ ระบบจะแสดงขนาดที่ใช้จริงและระบุว่าโมเดลถูกโหลดลงบน GPU หรือ CPU ขนาดไฟล์ดาวน์โหลด 25 GB สำหรับ tag เริ่มต้นนั้นเป็นเพียงค่าต่ำสุด เนื่องจากต้องบวกเพิ่มด้วย KV cache ซึ่งจะขยายตัวตาม context window ที่คุณตั้งค่าไว้ หากแผนการใช้งานมี RAM ไม่เพียงพอ Ollama จะปฏิเสธการทำงานด้วยข้อผิดพลาด model requires more system memory พร้อมระบุตัวเลขทั้งสองค่า

ฉันสามารถรัน Nemotron 3.5 Lightning บน VPS ที่ไม่มี GPU ได้หรือไม่?

ได้ หากแผนการใช้งานมี RAM เพียงพอสำหรับเก็บน้ำหนักของโมเดล (weights) โดยการออกแบบแบบ MoE ช่วยให้รันได้เร็วขึ้นเนื่องจากมีการคำนวณเพียงประมาณ 3 จาก 30 พันล้านพารามิเตอร์ต่อหนึ่ง token แต่ความเร็วจะเป็นปัญหาหลัก หากไม่มี GPU โมเดลจะถูกจำกัดด้วย memory bandwidth ทำให้การเพิ่ม vCPU แทบไม่ช่วยเพิ่มความเร็ว ให้รัน ollama run --verbose ด้วย prompt คงที่ แล้วอ่านค่าจากบรรทัด eval rate เพื่อประเมินว่าความเร็วที่ได้ตรงตามความต้องการของ agent หรือไม่ สำหรับงาน batch ที่รันข้ามคืนมักจะไม่มีปัญหา แต่สำหรับงานที่ต้องรอผลลัพธ์แบบโต้ตอบ มักจะไม่สามารถใช้งานได้

ทำไม Ollama ถึงไม่ให้ context window เต็ม 1M?

1M คือค่าสูงสุดของโมเดล ไม่ใช่ค่าเริ่มต้นของ Ollama โดย Ollama จะตั้งค่า window ไว้เล็กกว่ามากและจะทิ้ง token ที่เก่าที่สุดเมื่อบทสนทนาเกินขีดจำกัดโดยไม่มีการแจ้งเตือนข้อผิดพลาด ซึ่งส่งผลให้ agent ลืมคำสั่งของตัวเอง ให้ตั้งค่า OLLAMA_CONTEXT_LENGTH ใน systemd service หรือส่งค่า num_ctx ในแต่ละ request ให้ค่อยๆ เพิ่มค่าและตรวจสอบ ollama ps ในแต่ละครั้ง เนื่องจากหน่วยความจำของ KV cache จะขยายตาม window และอาจทำให้ layer ของโมเดลถูกผลักออกจาก GPU ได้

Nemotron 3.5 Lightning สามารถใช้งานเชิงพาณิชย์ได้ฟรีหรือไม่?

Model card ของ NVIDIA ระบุว่าโมเดลนี้อยู่ภายใต้ใบอนุญาต OpenMDW-1.1 และพร้อมสำหรับการใช้งานเชิงพาณิชย์ ซึ่งครอบคลุมถึงน้ำหนักของโมเดลที่คุณดาวน์โหลดและรันเอง อย่างไรก็ตาม ใบอนุญาตนี้ไม่ครอบคลุมซอฟต์แวร์อื่นใน stack ของคุณ ดังนั้นควรตรวจสอบใบอนุญาตของ agent harness และเครื่องมืออื่นๆ ที่คุณเชื่อมต่อแยกต่างหาก และควรอ่าน model card ฉบับล่าสุดก่อนนำไปใช้ในงานที่มีข้อผูกพันทางสัญญา