วิธีรัน 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 ระบุว่ามีพารามิเตอร์รวม 3 หมื่นล้านตัว โดยมีพารามิเตอร์ที่ทำงานจริง 3 พันล้านตัวต่อหนึ่งโทเค็น คุณต้องจ่ายทรัพยากรหน่วยความจำสำหรับจำนวนพารามิเตอร์ทั้งหมด แต่จะได้รับความเร็วในการประมวลผลตามจำนวนพารามิเตอร์ที่ทำงานจริง

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

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

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

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

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

[
  {
    "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 ดังนั้นการดาวน์โหลดเริ่มต้นจะเป็นบิลด์แบบ 4-bit ขนาด 25 GB ที่รองรับ 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 ซึ่งเป็นหน่วยความจำต่อโทเค็นของโมเดลสำหรับการสนทนา) ที่ต้องบวกเพิ่มเข้าไป ตัวเลขที่แท้จริงสำหรับฮาร์ดแวร์ของคุณนั้นได้มาจากการใช้คำสั่ง ไม่ใช่การคำนวณทางคณิตศาสตร์ ซึ่งระบุไว้ด้านล่างนี้ หากคุณยังไม่ได้ตัดสินใจเลือกระดับการทำ quantisation สิ่งที่ต้องแลกในระดับ Q4, Q8 และ FP16 จะอธิบายถึงสิ่งที่สูญเสียไปในแต่ละระดับ

ดึง tag ที่ระบุให้ชัดเจน อย่าใช้ latest

latest เป็นตัวชี้ที่เปลี่ยนแปลงได้ตลอดเวลา เมื่อไลบรารีเผยแพร่เวอร์ชันใหม่ พฤติกรรมของ 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

df -h /usr/share/ollama

การดึงข้อมูลที่หยุดชะงักกลางคันและรายงาน no space left on device หมายความตามนั้นจริง ๆ และข้อมูลบางส่วนที่ค้างอยู่จะยังคงอยู่ในดิสก์จนกว่าคุณจะลบออก จากนั้นให้ยืนยันสิ่งที่ถูกดาวน์โหลดมาจริง:

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

ollama show จะแสดงสถาปัตยกรรม, จำนวนพารามิเตอร์, ความยาวของ context และการ quantisation ที่ไฟล์นั้นมีอยู่จริง หากข้อมูลใดไม่ตรงกับหน้าไลบรารี แสดงว่าคุณดึง 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 จะถูกประมวลผลโดยหน่วยประมวลผลจาก 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 พันล้านต่อหนึ่งโทเค็น ทำให้การคำนวณต่อโทเค็นน้อยกว่าโมเดลแบบ dense ขนาด 30B อย่างมาก แต่ในส่วนของหน่วยความจำนั้นไม่ได้ช่วยอะไรเลย พารามิเตอร์ทั้ง 30 พันล้านตัวต้องถูกโหลดไว้ในหน่วยความจำตลอดเวลา เพราะตัว router สามารถเลือก expert ตัวใดก็ได้สำหรับทุกโทเค็น

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

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

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

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

[
  {
    "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 รายงานไว้ในช่วงเปิดตัว โดยวัดผลบน GPU endpoint ที่ให้บริการ ไม่ใช่บน VPS โมเดล Nemotron 3.5 Lightning ใช้เวลาเฉลี่ยประมาณ 30 วินาทีต่อภารกิจ โดยที่ gpt-oss-120b ใช้เวลาประมาณ 204 และ Qwen3.6 35B ใช้เวลาประมาณ 210 ให้ใช้ข้อมูลเหล่านี้เพื่อดูความแตกต่างของประสิทธิภาพเท่านั้น อย่าถือว่าเป็นคำมั่นสัญญาสำหรับฮาร์ดแวร์ของคุณ

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

หน้าต่างบริบทขนาด 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 จะเพิกเฉยต่อคีย์ดังกล่าว แต่ไคลเอนต์ส่วนใหญ่จะไม่ยอมเริ่มทำงานหากไม่มีการตั้งค่าคีย์ไว้ ในส่วนของเอเจนต์นั้นได้ครอบคลุมไว้ใน การชี้ coding agent ไปที่ Ollama และใน การสร้าง OpenClaw agent ของคุณเอง

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

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

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

โมเดลไม่โหลด 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 ว่าโมเดลยังคงพอดีกับหน่วยความจำ หากไม่พอดี วิธีแก้ไขคือการใช้เครื่องที่มีสเปกสูงขึ้นแทนการลดขนาดหน้าต่างบริบทลง

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

โมเดลแบบ MoE ขนาด 30B เป็นสิ่งที่ใช้ทรัพยากรสูงเกินความจำเป็นสำหรับงานขนาดเล็ก หากโมเดลแบบ dense ขนาด 8B สามารถจัดการงานของคุณได้อยู่แล้ว การใช้งานโมเดลนั้นจะมีต้นทุนต่ำกว่ามากและโหลดเสร็จภายในเวลาไม่กี่วินาที โดย Qwen 3 ขนาด 8B และ 27B บน VPS คือการเปรียบเทียบโดยตรงสำหรับการตัดสินใจในเรื่องนี้ สำหรับการสำรวจภาพรวมว่าแผนการใช้งานที่คุณมีอยู่สามารถรองรับโมเดลใดได้บ้าง ให้เริ่มจาก โมเดล AI ที่คุณสามารถ self-host ได้ หากคุณวางแผนที่จะให้บริการเอเจนต์หลายตัวพร้อมกันแทนที่จะเป็นตัวเดียว โปรดอ่าน การเปรียบเทียบ Ollama กับ vLLM ก่อน เนื่องจาก Ollama ไม่ได้ทำ batching สำหรับคำขอที่เข้ามาพร้อมกันในลักษณะเดียวกับ 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 ไม่ได้ระบุตัวเลขหน่วยความจำขั้นต่ำสำหรับ 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 เพียงพอที่จะเก็บ weight ของโมเดล และการออกแบบแบบ MoE ช่วยได้มากเนื่องจากมีการคำนวณพารามิเตอร์เพียงประมาณ 3 พันล้านจากทั้งหมด 30 พันล้านต่อหนึ่ง token ปัญหาคือเรื่องความเร็ว หากไม่มี GPU โมเดลจะถูกจำกัดด้วย memory bandwidth ดังนั้นการเพิ่ม vCPU แทบจะไม่ช่วยให้ผลลัพธ์เร็วขึ้น ให้รัน ollama run --verbose ด้วย prompt ที่กำหนดไว้ อ่านบรรทัด eval rate แล้วประเมินตัวเลขนั้นเทียบกับเวลาที่ agent ของคุณต้องทำงานให้เสร็จ สำหรับงาน batch ที่รันข้ามคืนมักจะไม่มีปัญหา แต่สำหรับงานที่ต้องรอผลลัพธ์แบบ real-time มักจะไม่เหมาะสม

ทำไม 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 และพร้อมสำหรับการใช้งานเชิงพาณิชย์ ซึ่งครอบคลุมถึง weight ที่คุณดาวน์โหลดและรันด้วยตนเอง แต่ไม่ได้ครอบคลุมถึงซอฟต์แวร์อื่นใน stack ของคุณ ดังนั้นควรตรวจสอบใบอนุญาตของ agent harness และเครื่องมืออื่นๆ ที่คุณเชื่อมต่อแยกต่างหาก และควรอ่าน model card ฉบับล่าสุดก่อนที่จะนำไปใช้ในงานที่มีข้อผูกพันทางสัญญา