คู่มือรัน LLM ระดับล้ำสมัยแบบโลคัลล่าสุดจาก Jamesob

 (github.com/jamesob)
2 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • รวบรวมการตั้งค่าฮาร์ดแวร์ การตั้งค่า PCIe switch และคอนฟิกการรัน Docker สำหรับการใช้งาน LLM ระดับล้ำสมัย และระบบแปลงเสียงเป็นข้อความบนเครื่องโลคัลไว้ในรีโพเดียว
  • งบประมาณประมาณ $2k ตั้งเป้าใช้ 2× RTX 3090 เพื่อให้ได้ 48GB VRAM สำหรับรัน Qwen3.6-27B และ STT แบบโลคัลที่อิง whisper-large-v3
  • งบประมาณประมาณ $40k ตั้งเป้าใช้ 4× RTX PRO 6000 Blackwell Workstation เพื่อให้ได้ 384GB VRAM และสมมติว่าได้ความฉลาดของโมเดลที่ใกล้เคียง Claude Opus พอสมควร
  • ระบบจริงแบบ 4× RTX 6000 Pro ใช้เครื่องหลักที่อิง EPYC/DDR4 มือสองร่วมกับ c-payne PCIe Gen4 switch เพื่อให้การสื่อสาร P2P ระหว่าง GPU วิ่งอยู่ใน switch fabric แทนการผ่าน CPU root complex
  • หลังปรับ BIOS, GRUB, ACS และ power limit แล้ว P2P ทำได้ที่ 27.5GB/s ทิศทางเดียว, 50.4GB/s สองทิศทาง และ latency 0.37–0.45µs ซึ่งแตะระดับ line-rate ของ Gen4

ช่วงงบประมาณสำหรับรัน LLM แบบโลคัล

  • คอนฟิกนี้มุ่งเป้าไปที่ผู้ใช้ที่ต้องการรันโมเดลระดับล้ำสมัยและระบบแปลงเสียงเป็นข้อความบนเครื่องโลคัล
  • ในรีโพมีทั้งฮาร์ดแวร์ที่ใช้งานอยู่ เหตุผลในการเลือกซื้อ ทิปการตั้งค่า วิธีรัน STT แบบโลคัล และคอนฟิกการรันโมเดลบน Docker container
  • มีหมายเหตุว่าเนื้อหาทั้งหมดนอกเหนือจากตารางใน README ไม่ได้เขียนโดย AI

  • คอนฟิกประมาณ $2k

    • เสนอคอนฟิกที่ใช้ 2× RTX 3090 เพื่อให้ได้ 48GB VRAM รวม
    • คอนฟิกนี้สามารถรัน Qwen3.6-27B ได้
    • STT แบบโลคัลใช้ whisper-large-v3 และใช้ stt harness แบบข้ามแพลตฟอร์ม สำหรับการเข้าถึง
    • ใน ./runners/stt มีคอนฟิก STT ที่พร้อมใช้งาน โดยสมมติว่าบน Nvidia GPU มี VRAM อยู่ราว 11GB เท่านั้น
    • STT แบบโลคัลถูกมองว่าเป็นเครื่องมือที่ใช้งานได้สะดวกกว่าบริการโฮสต์

  • คอนฟิกประมาณ $40k

    • สมมติคอนฟิกที่ใช้ 4× RTX 6000 Pro เพื่อให้ได้ 384GB VRAM รวม
    • ในช่วงราคานี้ถูกอธิบายว่าเป็นระดับที่เริ่มได้ความฉลาดของโมเดลที่ค่อนข้างใกล้เคียง Claude Opus
    • ณ 2026-07 โมเดลที่ดีที่สุดในตอนนี้สำหรับ 4× RTX6kPRO ที่ถูกยกมาคือ GLM-5.2-Int8Mix-NVFP4-REAP-594B
    • คอนฟิกการรันอยู่ที่ runners/GLM-5.2-594B
    • อีกแนวทางหนึ่งที่ถูกกล่าวถึงคือเชื่อมคลัสเตอร์ 4× DGX Spark เพื่อให้ได้ 512GB VRAM แล้วใช้ Qwen3.7-27B เป็นสมองขนาดใหญ่ที่ช้าแต่จัดการงานแบบวนซ้ำได้รวดเร็ว

ฮาร์ดแวร์จริงของ 4× RTX 6000 Pro

  • ระบบจริงถูกประกอบโดยมี 4× RTX PRO 6000 Blackwell Workstation เป็นแกนหลัก
  • GPU แต่ละตัวมี 96GB รวมเป็น 384GB VRAM และมีราคารวมประมาณ $46,000
  • ตัวเครื่องใช้ EPYC รุ่นก่อนหน้าและชิ้นส่วน DDR4 จาก eBay เพื่อลดต้นทุนของระบบพื้นฐานและทุ่มงบไปที่ VRAM
  • เนื่องจาก ณ กรกฎาคม 2026 ระบบที่อิง PCIe5/DDR5 มีราคาแพงมาก จึงเลือกใช้ PCIe Gen4 switch และเครื่องหลักที่อิง DDR4

  • BOM ของระบบพื้นฐาน

    • ระบบพื้นฐานประกอบจากชิ้นส่วน EPYC รุ่นก่อนหน้าที่หาจาก eBay เป็นส่วนใหญ่
    • ชิ้นส่วนหลักและราคามีดังนี้
    • เมนบอร์ด ASRock Rack ROMED8-2T: $715
    • CPU AMD EPYC Milan 7313P 16 คอร์ 3.0GHz: $504
    • 8× 16GB Crucial DDR4 ECC RDIMM รวม RAM 128GB: $642
    • 2× PSU Super Flower 1700W: $750
    • c-payne Microchip Switchtec PM40100 Gen4 PCIe switch: ประมาณ $1,330
    • NVMe สำหรับบูต 4TB: $291
    • 2× NVMe 8TB สำหรับเก็บน้ำหนักโมเดล: $1,200
    • รวมระบบพื้นฐานเป็น $5,587

  • PCIe Gen4 switch

    • ใช้ PCIe4 switch ของ c-payne เพื่อให้การสื่อสารระหว่าง GPU เกือบจะเป็นแบบตรง
    • ในขั้น allreduce ของ tensor parallelism ข้อมูลระหว่าง GPU จะเคลื่อนที่ภายใน switch fabric โดยไม่ผ่าน PCI root complex
    • BOM ย่อยของ switch อยู่ที่ประมาณ €1,220 หรือราว $1,330 USD
    • PCIe Gen4 5× x16 switch ที่ใช้ Microchip Switchtec PM40100
    • SlimSAS PCIe Gen4 Host Adapter x16
    • สาย SlimSAS SFF-8654 8i จำนวน 2 เส้น
    • มีการทำ enclosure ไม้สำหรับ GPU และ PCI switch ขึ้นเอง ใช้เวลาประมาณ 1 วัน
    • พัดลมที่ติดมากับ PCI switch มีเสียงดังมากและดูไม่มีประโยชน์ จึงถอดออกจากบอร์ด

การเก็บน้ำหนักโมเดลและวิธีรัน

  • น้ำหนักโมเดลทั้งหมดถูกเก็บแบบโลคัลบน ZFS filesystem ที่ทำสำเนาไว้บนไดรฟ์ 8TB สองลูก
  • ไฟล์ซิสเต็มถูกเมานต์ไว้ที่ ~/storage
  • โมเดลที่จะรันจะถูกดาวน์โหลดลงเครื่องก่อนด้วยคำสั่งต่อไปนี้
hf download <model-name> --local-dir ~/storage/<model-name>
  • แต่ละโมเดลมี docker-compose.yml ของตัวเองอยู่ในไดเรกทอรีแยก และรันภายใน Docker container ของตัวเอง
  • คอนฟิกการรันอยู่ใน ./runners/
  • แต่ละคอนเทนเนอร์จะเมานต์ ~/storage/models แบบ read-only เพื่ออ่านน้ำหนักที่แคชไว้
  • เมื่อโมเดลถูกเสิร์ฟที่ http://clank.j.co:5000 ก็จะเข้าถึงผ่าน opencode ที่โฮสต์อยู่บน VM ของอีกเครื่องหนึ่ง
  • มีการแมป clank.j.co ไปยังเครื่อง LLM ผ่าน internal DNS server แต่จะใช้รูปแบบ http://<llm-machine-ip>:5000 ก็ได้เช่นกัน

การจัด agent harness และเครื่องมือ

  • มีแอปพลิเคชันหนึ่งรันอยู่ใน VM แยก ซึ่งสร้าง tmux session สำหรับแต่ละไดเรกทอรีในต้นไม้ ~/src และรันอินสแตนซ์ opencode ในแต่ละ session
  • แต่ละอินสแตนซ์ของ opencode ใช้ http://clank.j.co:5000 ซึ่งเป็น HTTP API ของเครื่อง inference เป็น backend
  • หัวใจสำคัญของการใช้โมเดลโอเพนซอร์สให้ดีถูกอธิบายว่าอยู่ที่ การจัดเครื่องมือ
  • ในสรุป skills/ มีเครื่องมือดังนี้
    • camofox, API key ของ kagi.com และการท่องเว็บ/ค้นหาผ่าน searXNG
    • การสื่อสารและการแจ้งเตือนผ่าน Telegram bot
    • Gitea อินสแตนซ์ส่วนตัวแบบโลคัลสำหรับการทำงานร่วมกันบนซอร์สโค้ด
  • สามารถใช้ agent ให้ทำงานร่วมกันแบบโต้ตอบใน session หรือมอบหมายให้จัดการ Gitea issue และเปิด PR ก็ได้
  • งานนี้รันอยู่ภายใน sandbox VM และการสื่อสารกับโฮสต์เกิดขึ้นผ่าน shared filesystem mount เท่านั้น

PCIe switch และการตั้งค่า multi-GPU

  • การตั้งค่า BIOS

    • มีการปรับ BIOS บนเมนบอร์ด ROMED8-2T เพื่อไม่ให้ความเร็วของ PCI switch ลดลง
    • ตั้ง AMD PCIE Link Width เป็น x16 สำหรับสล็อตของ switch
    • การตั้งค่าแยกเดิมแบบ x8/x8 ทำให้สล็อตถูกแบ่ง และลิงก์ upstream เทรนที่ Gen4 x8
    • ต้องเสียบสาย SlimSAS 8i ทั้ง 2 เส้น โดยแต่ละเส้นรับผิดชอบ x8
    • บังคับ PCIe Link Speed เป็น Gen4
    • เมื่ออุปกรณ์ Blackwell Gen5 ต่อผ่าน Gen4 switch แล้วปล่อยให้เจรจาอัตโนมัติ อาจเทรนไม่สำเร็จและตกไปเป็น Gen1
    • ตั้ง ASPM เป็น Disabled
    • ASPM L1 จะลดลิงก์ที่ว่างอยู่ลงไปที่ 2.5GT/s
    • นี่เป็นสาเหตุที่ทำให้ใน lspci ดูเหมือนถูกลดลงเป็น Gen1 แต่ภายใต้โหลดจริงจะทำงานเป็น Gen4
    • ตั้ง Re-Size BAR เป็น Enabled
    • จำเป็นต่อการเปิดเผย BAR ของ VRAM 96GB ทั้งหมดและต่อ GPU P2P
    • ตั้ง SR-IOV เป็น Disabled
    • เป็นการตั้งค่าเพื่อหลีกเลี่ยง overhead ของ IOMMU และการรบกวน P2P ในสภาพแวดล้อม inference แบบ bare metal
    • ปล่อย Preferred IO ไว้ที่ Auto
    • ถ้ากำหนดบัส 81 ของ c-payne switch ด้วยตัวเอง อาจลด latency ได้เล็กน้อย แต่เป็นการจูนเพิ่ม ไม่ใช่การแก้ปัญหา และหมายเลขบัสอาจเปลี่ยนหลังแก้ BIOS

  • Redriver และสายเคเบิล

    • ตามคำแนะนำของ c-payne มีการใช้ เครื่องมือของ c-payne เพื่อลด redriver gain ลงเป็น lvl 3
    • ระดับ gain ขึ้นกับความยาวของสายที่คอนเน็กเตอร์ SAS ใช้
    • มีการสั่งสายจาก c-payne มาน้อยเกินไป จึงไปซื้อสาย SAS ที่ดูคล้ายกันจาก Amazon แต่ด้วยความต่างเล็กน้อยทำให้เกิดปัญหา จึงต้องสั่งใหม่อีกครั้ง

เคอร์เนล, ACS และ power limit

  • GRUB และ NVIDIA UVM

    • ตั้ง kernel parameter ต่อไปนี้ใน /etc/default/grub
    GRUB_CMDLINE_LINUX="iommu=off amd_iommu=off nomodeset"
sudo update-grub
    • ถ้าไม่มี iommu=off NCCL จะค้างเมื่อทำ multi-GPU P2P
    • เพื่อแก้ไข NVIDIA UVM P2P มีการใช้การตั้งค่าต่อไปนี้
    echo 'options nvidia_uvm uvm_disable_hmm=1' | sudo tee /etc/modprobe.d/uvm.conf
sudo update-initramfs -u

  • ปิด ACS

    • ถ้า ACS เปิดใช้งานอยู่ตามค่าเริ่มต้น ทราฟฟิก P2P จะไม่อยู่ภายใน switch fabric แต่จะวิ่งผ่าน CPU root port
    • ในสภาพนี้ข้อดีของ PCIe switch จะหายไป
    • เนื่องจาก pcie_acs_override ต้องใช้เคอร์เนลที่แพตช์ไว้ จึงเลือกปิด ACS ตอนรันไทม์ด้วย setpci
    • ตอนบูตแต่ละครั้งจะรัน /usr/local/bin/disable-acs.sh ผ่าน systemd oneshot service
    • วิธีตรวจสอบมีดังนี้
    • ใน lspci -vvv | grep ACSCtl ควรแสดงเป็นเครื่องหมายลบทั้งหมด
    • ใน nvidia-smi topo -m ระหว่าง GPU ทั้งสี่ตัวควรแสดงเป็น PIX ไม่ใช่ PHB/NODE
    • สามารถวัดแบนด์วิดท์และ latency ของ P2P ได้ง่ายด้วย ./tools/measure-gpu-speed.sh

  • การจำกัดกำลังไฟ GPU

    • เพื่อหลีกเลี่ยงการติดตั้งวงจร 220V จึงรันบนวงจร 110V เดียวและจำกัดกำลังไฟของ GPU
    • ใช้ systemd เพื่อตั้ง persistence mode และ power limit ตอนบูต
    sudo nvidia-smi -pm 1
sudo nvidia-smi -pl 350
    • power limit ของ GPU ถูกตั้งไว้ที่ 350W ต่อตัว โดยค่าเริ่มต้นคือ 600W
    • 4×350W หมายถึงโหลดฝั่ง GPU รวม 1,400W ซึ่งอยู่ในงบกำลังไฟของ PSU
    • ในช่วงที่ยังใช้ PSU 1700W ตัวเดียวก่อนมีวงจร 240V จะรัน GPU ที่ประมาณ 260W
    • 4×260W = GPU 1,040W
    • บวกระบบอีกราว 280W รวมเป็นประมาณ 1,320W
    • ตรวจสอบได้ด้วย nvidia-smi --query-gpu=index,power.limit,power.draw --format=csv

ผลการวัดและข้อมูลอ้างอิง

  • upstream ไปทาง CPU เป็น Gen4 x16 ที่ราว 30GB/s
  • P2P ผ่าน switch ทำได้ 27.5GB/s ทิศทางเดียว, 50.4GB/s สองทิศทาง
  • latency อยู่ที่ 0.37–0.45µs ซึ่งอยู่ในระดับ line-rate ของ Gen4
  • หาก ASPM ถูกเปิดใช้งานอยู่ที่ไหนสักแห่ง lspci อาจแสดงลิงก์ downstream ของ GPU ที่ว่างอยู่เป็น 2.5GT/s (downgraded)
  • การแสดงผลนี้เป็นเพียงเรื่อง cosmetic และลิงก์จะเทรนกลับเป็น Gen4 เมื่อมีโหลด

  • Resources

    • local-inference-lab/rtx6kpro: รีโพที่อัปเดตบ่อยเกี่ยวกับการใช้การ์ด RTX 6000 Pro จำนวน 4, 6, 8 ใบ
    • c-payne: ผู้ทำ PCI switch อิสระที่ใช้ในคอนฟิกนี้
    • RTX6kPRO Discord: Discord server สำหรับ benchmark RTX6kPRO และการทดสอบโมเดลใหม่

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 5 시간 전
ความคิดเห็นจาก Hacker News

  • ผมลองใช้ LLM แบบโลคัลมาเยอะ และทุ่มเงินกับฮาร์ดแวร์ไปมากเกินควร แต่ต้องลดความคาดหวังลงและอ่าน เงื่อนไขรายละเอียด ให้ดี
    บิลด์ขนาดใหญ่ในบทความเริ่มต้นด้วยงบ 40,000 ดอลลาร์ แต่รวม GPU 4 ใบที่ราคาใบละ 12,000 ดอลลาร์ ดังนั้นจริง ๆ แล้วใกล้เคียง 50,000~55,000 ดอลลาร์ มากกว่า
    การจัดชุดแบบโลคัลมักต้องพึ่งเทคนิคอย่าง quantization หรือ REAP เพื่อทำให้โมเดลพอดีกับฮาร์ดแวร์ มีคนอ้างกันมากว่า quantization แบบ 4-bit ไม่สูญเสียคุณภาพ แต่เป็นคำกล่าวที่มาจากการวัด KL divergence บนคอร์ปัสขนาดเล็ก และเมื่อนำไปใช้กับงานเขียนโค้ดที่มีบริบทยาว ๆ คุณภาพที่ลดลงจะเห็นได้ชัด แม้แต่งานที่ไม่ใช่การเขียนโค้ดอย่างการวิเคราะห์ชุดข้อมูล ก็ยังวัดความต่างด้านคุณภาพระหว่าง quantization แบบ 4-bit, 8-bit และบางครั้งรวมถึงต้นฉบับ 16-bit ได้ค่อนข้างชัด
    บทความนี้ยังแนะนำให้ใช้โมเดล REAP ด้วย ซึ่งหมายความว่ามีใครบางคนตัด weight บางส่วนออกเพื่อทำให้โมเดลเล็กลง แนวคิดคือกำจัด weight ที่มีประโยชน์น้อยกว่าสำหรับงานบางประเภท แต่คุณภาพผลลัพธ์โดยรวมก็ลดลงอีก
    กับดักคือ เมื่อคนพูดว่า “รัน GLM-5.2 แบบโลคัล” พอดู benchmark แล้วก็ดูยอดเยี่ยม แต่ในความเป็นจริงไม่ได้รัน GLM-5.2 หากเป็นโมเดลอนุพันธ์ที่ทิ้งบิตส่วนใหญ่ไปและเอา expert บางส่วนออก สำหรับงานเล็กมาก ๆ หรือแชต ความต่างระหว่างโมเดล quantization/REAP กับต้นฉบับอาจไม่ค่อยเห็น แต่สำหรับงานระยะยาวที่ข้อผิดพลาดเล็ก ๆ สะสมกัน ความต่างจะกลายเป็นเรื่องทรมาน
    แล้วพอใช้เงินไปแล้ว 50,000 ดอลลาร์ ก็จะไหลลงทางลาดลื่น ๆ ว่า ถ้าอยากเพิ่มคุณภาพอีกนิดและทำให้การลงทุนคุ้มค่า ก็แค่ซื้อ GPU ใบละ 12,000 ดอลลาร์เพิ่มอีกสักหนึ่งหรือสองใบ

    • ผมรัน Qwen3.6 บน RTX4090 และส่วนใหญ่ทำงานได้ดีมาก
      สำหรับงานเขียนโค้ด ต้องแบ่งเซสชันออกเป็นหลายการเรียก ผมทำ https://github.com/aka-rider/orqestra ไว้ แต่ทุกวันนี้ถ้าเป็นสภาพแวดล้อมที่รันเครื่องมือได้ แทบจะทำแบบคล้ายกันเองได้ทุกที่
      ประเด็นหลักคือแยกเซสชันที่ใช้บริบทไปกับการอ่านโค้ดและเรียกเครื่องมือออกมา แล้วให้มันสร้างรายงาน Markdown ว่า “โค้ดและเอกสารที่เกี่ยวข้องอยู่ตรงนี้ และหลักฐานคือสิ่งนี้” เพื่อลด hallucination แยกเซสชันวางแผนไว้อีกส่วน และเพราะโมเดลขนาดเล็กมักข้ามรายละเอียด จึงให้ critic กับ designer โต้ตอบกัน 1~3 รอบ และให้ worker กับ verifier โต้ตอบกันด้วยเหตุผลเดียวกัน
      Qwen3.6 ในโหมดอ่านอย่างเดียวสามารถไล่หาบั๊กซับซ้อนได้นานหลายชั่วโมง และโดยมากก็หาเจอ การแก้ไขที่มันเสนออาจจะ hacky แต่ Sonnet ก็เป็นเหมือนกัน
      Qwen3.6 สามารถเขียนโค้ดเชิงกลไกตามแผนที่ Opus สร้างไว้ได้ หลังจากนั้นต้อง prompt ประมาณว่า “ตรวจทานการเปลี่ยนแปลงของตัวเอง มีบั๊กไหม? เทียบกับแผนเดิมแล้วมีอะไรตกหล่นไหม? มีอะไรละเมิด CLAUDE.md ไหม?” แต่เรื่องนี้ก็ต้องทำกับ Sonnet เหมือนกัน
      LLM แบบโลคัลยังใช้สำหรับทำดัชนี knowledge base ใหม่ด้วย ในการจัดระเบียบทิกเก็ต แค่ทิ้งโน้ตดิบ ๆ อย่าง “แผงเดี่ยวสำหรับแสดง error, ย้ายข้อความ error ทั้งหมด” ก็สามารถได้สเปกที่เสร็จประมาณ 90% พร้อมเป้าหมายและบริบทกลับมา
    • ตอนรัน Qwen 26B แบบ 8-bit quantization, non-MoE แบบโลคัลบนคอมพิวเตอร์ของผม ก็คล้ายกัน
      ดีมากสำหรับงานเล็ก ๆ แต่พอให้ทำงานใหญ่ครั้งแรก มันลืมไปว่าสภาพแวดล้อมที่ agent รันอยู่คืออะไร และเริ่มใช้รูปแบบการเรียกเครื่องมือผิด ตอนนั้นรันอยู่บน Pi แต่มันเชื่อว่าตัวเองรันอยู่บน Claude และพยายามเรียกเครื่องมือของ Claude ที่ไม่มีอยู่จริง
    • ผมรัน ds4 บน MBP ที่ซื้อก่อนราคา RAM จะบ้าคลั่ง และมันค่อนข้างมีประโยชน์
      มันไม่ได้เขียนแอปพลิเคชันทั้งตัวให้คนเดียว แต่ช่วยแก้ปัญหาเครือข่ายจุกจิกใน tailnet ที่ผมไม่มีทั้งเวลาและแรงใจจะไปทำความเข้าใจเอง และมักทำให้ผมหยิบงานที่ง่ายแต่มีต้นทุนการค้นคว้าสูงจนไม่ได้ทำขึ้นมาทำได้บ่อยขึ้น มันไม่ใช่ Opus แต่มีประโยชน์ และไม่ต้องกังวลว่ากำลังดึงคุณค่าคุ้มกับค่าสมัครหรือค่า API อยู่หรือเปล่า
    • อยากให้บทความและคอมเมนต์ที่บอกว่า “รันแบบโลคัล” แนบผลการรัน benchmark สาธารณะ เดิมซ้ำไว้เพื่อเปรียบเทียบด้วย
    • ถูกต้องทั้งหมด กระแสร้อนแรงในการรัน LLM สำหรับเขียนโค้ดแบบโลคัล กลับทำร้าย AI แบบโลคัลที่ โมเดลภาษาขนาดเล็ก ซึ่งสร้างมาให้เหมาะกับวัตถุประสงค์เฉพาะอาจมีประโยชน์จริง ๆ
      เครื่องมือเล็ก ๆ อย่างการประมวลผลภาษาธรรมชาติ, การสังเคราะห์เสียง, การประมวลผลภาพ, วิศวกรรมเสียง, การประมวลผลสัญญาณ, ปลั๊กอิน diffusion สำหรับ Krita เหมาะมากกับการจัดชุดแบบโลคัล ผมเพิ่งเขียนสั้น ๆ เรื่องนี้ไว้เมื่อไม่กี่วันก่อนด้วย[1]
      [1] https://abishekmuthian.com/multiple-20-ai-plans-are-better-t...

  • คำว่า “ถ้ามีราว 40,000 ดอลลาร์ ความฉลาดของโมเดลจะขยับขึ้นไปอีกขั้นจนใกล้เคียง Claude Opus พอสมควร” นั้น เท่ากับค่าใช้จ่ายในการใช้ Claude Opus 4.8 หรือ Codex GPT 5.5 นาน 16.8 ปี ที่ราคาเดือนละ 200 ดอลลาร์
    ผมชอบการรันโมเดลโลคัลมากจริง ๆ แต่ก็ยังแพงอย่างไร้เหตุผล คุณภาพต่ำกว่า และถ้ามี backdoor ก็อาจอันตรายได้ หวังจากใจว่ามันจะไม่เป็นแบบนั้น

    • ราคาเดือนละ 200 ดอลลาร์เป็นกรณีที่ต้องจ่ายราคา API เต็ม เช่นถ้าเป็นบริษัท “enterprise” ก็อาจใกล้ 4,000 ดอลลาร์ ต่อเดือนอยู่แล้ว แบบนั้นต้นทุนที่เท่ากันจะลดเหลือ 10 เดือน
      แต่ก็น่าสงสัยว่าเครื่องโลคัลจะประมวลผลได้เทียบเท่าปริมาณการใช้ API มูลค่า 4,000 ดอลลาร์ต่อเดือนจริงหรือไม่ เพราะเครื่องโลคัลรันพรอมป์แบบขนานได้ยากเท่ากับดาต้าเซ็นเตอร์หลายแห่งของ Anthropic อย่างมีประสิทธิภาพ
    • เห็นด้วยกับประเด็นหลัก แต่การคำนวณนี้ตั้งอยู่บนสมมติฐานว่า ราคา LLM จะคงที่ต่อไป
      บริษัทอย่าง OpenAI และ Anthropic ยังขายแพ็กเกจในราคาที่ถูกอุดหนุนด้วยพลังของเงินทุน VC อยู่ และสักวันเงินทุนนั้นก็จะต้องการผลตอบแทน
    • การบอกว่าโมเดลแนวหน้าถูกฝัง backdoor ไว้นั้นฟังไม่ขึ้นเลย ไม่เคยได้ยินว่ามีโมเดลที่ถูกฝัง backdoor สักตัว และถ้าพบก็จะถูกลบออกจาก Hugging Face อย่างรวดเร็ว นี่ไม่ใช่ปัญหา
    • บนฮาร์ดแวร์ คุณใช้ โทเค็น ได้มากกว่าแพ็กเกจเดือนละ 200 ดอลลาร์มาก
      เดือนแรกผมใช้ OEM spark ไป 1 พันล้านโทเค็น ซึ่งถ้าคิดตามราคา Opus ก็เกิน 1,000 ดอลลาร์ แน่นอนว่ารูปแบบโทเค็นต่างกันจึงไม่ใช่การเทียบที่ยุติธรรม แต่หลังจากนั้นด้วยการปรับปรุง vLLM โดยเฉพาะ MTP ความเร็วก็เพิ่มขึ้น 2~3 เท่าแล้ว DiffusionGemma เร็วกว่า Gemma ปกติประมาณ 4 เท่า
    • ไม่ต้องพยายามรันโลคัลก็ได้ แค่เช่า cloud GPU
      เราไม่ได้เป็นเจ้าของสายไฟเบอร์ออปติกอยู่แล้ว แล้วทำไมต้องเป็นเจ้าของสินทรัพย์ที่เสื่อมราคาเร็ว แพง และน่าปวดหัวเพิ่มอีก
      ถ้าเช่า cloud GPU ก็ยังเข้าร่วมวัฒนธรรมการเป็นเจ้าของ การควบคุมข้อมูล การควบคุมราคา และวัฒนธรรมแฮ็กกิ้งได้ โดยไม่ต้องสร้างกล่องแฟรงเกนสไตน์ขนาดยักษ์เพื่อเป็นงานอดิเรก กล่องนั้นแพง ถูกกลั่นจนประโยชน์ใช้งานจริงลดลง และการดูแลรักษาก็น่าปวดหัว

  • แม้จะบอกว่า “40,000 ดอลลาร์ก็เกือบ Opus” แต่ถ้า GLM 5.2 คือ “เกือบ Opus” จริง การ inference ให้ลื่นไหลต้องใช้ขั้นต่ำ 8xH200 จึงใกล้ 400,000 ดอลลาร์ มากกว่า 40,000 ดอลลาร์
    ในบทความเสนอให้ใช้โมเดลที่ถูกปรับแก้: “GLM-5.2 ที่ถูก prune ด้วย REAP จนลบ expert ออกไปประมาณ 22% และ quantize เป็น Int8-mix NVFP4, ประมาณ 594B parameters”
    อยากรู้ว่าในการใช้งานจริงนอก benchmark จะทำงานเป็นอย่างไร Qwen3.6 เองก็ยังมักติดลูประหว่าง inference เมื่อ quantize เป็น 6-bit แต่กรณีนี้ยังลบ expert บางส่วนออกไปด้วย บางครั้งโมเดลขนาดเล็กแบบ 8-bit หรือ 16-bit อาจฉลาดกว่าโมเดลใหญ่ที่ถูกผ่าตัดสมองก็ได้ ดูเหมือนจะมีฉันทามติว่า สำหรับการเขียนโค้ด ไม่ควรต่ำกว่า 8-bit
    อีกอย่างยังไม่ชัดเจนว่าเมื่อยัดโมเดลที่ถูกผ่าตัดสมองให้พอดีกับ RTX 6000 4 ใบแล้ว จะเหลือ context ใช้งานได้เท่าไร ถ้าต่ำกว่า 100k มักแทบใช้ยาก เพราะมักชนการบีบอัดก่อนจะรวบรวม context ที่จำเป็นได้ พอไปดูใน repo แล้ว context คือ 240k

    • อยากรู้ว่าถ้ารัน GLM 5.2 ด้วย H200 ใบเดียว จะเป็นอย่างไร
      อยากรู้ว่ามันรันไม่ได้เลย หรือช้าจนใช้ไม่ได้ ผมอยากตรวจสอบ build และแนวคิดของโมเดลระดับล่าสุดในเครื่องโลคัลก่อน แล้วพออีก 18~24 เดือนราคา GPU ลดลงมากค่อยเติมส่วนที่เหลือ
    • อยากรู้ว่าสิ่งนี้เกี่ยวข้องกับ scalability อย่างไร
      ถ้าอย่างนั้นจะรันพรอมป์พร้อมกันได้หลายร้อยอันหรือเปล่า
    • ลูปก็เหมือนปรากฏการณ์ส่วนใหญ่ที่เกี่ยวกับ LLM คือเป็น ปัญหา sampling และแก้ได้ง่ายด้วย DRY penalty
      มีอยู่ใน llamacpp คนที่ทำ heretic ก็ทำกลยุทธ์ป้องกันลูปและเพิ่มความหลากหลายระดับล่าสุดไว้ด้วย
    • ถ้าใช้ NVFP4 quantization ของ lukealonso บน 8x RTX6000 ก็ทำ context 1M ได้ และยังคงความสอดคล้องกับความมีประโยชน์ไว้ได้อย่างน้อยถึง 400k
      ถ้าไม่ได้อยากทำเพราะแค่อยากทำ ก็แทบไม่มีความจำเป็นเชิงปฏิบัติที่จะรัน 8x H200 ยกเว้นกรณีต้องให้บริการผู้ใช้หรือ agent พร้อมกันจำนวนมากเป็นประจำ

  • ยังมีทางเลือกกึ่งกลางด้วย ถ้ามี VRAM 128GB ตอนนี้ก็มีตัวเลือกหลายแบบที่ได้ความจุระดับนั้นด้วยสถาปัตยกรรมหน่วยความจำแบบรวม และสามารถรัน DeepSeek V4 flash ผ่าน DwarfStar ได้ด้วยความเร็วที่ดี
    ผมคงไม่จ่ายเงินซื้อเอง แต่สำหรับหลายคน ระดับนี้น่าจะเป็นจุดประนีประนอมที่เหมาะสม

    • เพิ่งเริ่มลองใช้บน m4 max 128 และเป็นครั้งแรกหลังจากซื้อเครื่องนี้มาเมื่อหนึ่งปีก่อนที่รู้สึกว่า LLM โลคัล ใช้งานได้เลย สำหรับการเขียนโค้ดที่ค่อนข้างดี
      แต่ต้องใช้ Pi ส่วน claude code มี bootstrap context เยอะเกินไป ทำให้ทุกอย่างช้าลงมาก

  • แม้จะบอกว่า “ถ้ามี RTX 3090 สองใบ รวม VRAM 48GB ก็รัน Qwen3.6-27B ได้ และเป็นโมเดลที่ยอดเยี่ยม” แต่ถ้ามี 3,000 ดอลลาร์ก็ซื้อ M5 MacBook Pro ที่มีหน่วยความจำแบบแชร์ 48GB ได้ แถมไม่ใช่กล่องขนาดยักษ์ด้วย
    หรือจะพิจารณาเอาเงินนั้นไปใช้กับผู้ให้บริการโฮสติ้งบนคลาวด์ก็ได้ อย่างน้อยในระดับหนึ่ง หรืออาจจะถูกกว่ามากด้วยซ้ำ แน่นอนว่าการรันโมเดลบนเครื่องตัวเองได้ก็เป็นเรื่องเท่

    • เพราะเป็นคนโง่ที่จินตนาการสถานการณ์ที่ตัวเองไม่เคยเจอไม่ได้ เลยเคยคิดมาตลอดว่า LLM แบบโลคัลเป็นของเล่นที่ไม่คุ้มค่าให้ไล่ตาม
      แต่พอได้ลองใช้ของที่ดีจริง ๆ อย่าง Gemma 4 31B และ Qwen 3.6 27B สักครั้ง ถึงได้รู้ว่ามันมีประโยชน์แค่ไหน
      ทำให้เลิกกังวลว่ากำลังแชร์ข้อมูลอ่อนไหวอยู่ เลิกกังวลว่าโทเค็นจะหมด และไม่ต้องกังวลเรื่องความพร้อมใช้งานของ AI ระยะไกลด้วย LLM แบบโลคัลมีคุณค่ามาก
    • จุดที่เจ๋งของ 3090 คือ แบนด์วิดท์หน่วยความจำ การสร้างโทเค็นส่วนใหญ่ติดคอขวดที่แบนด์วิดท์หน่วยความจำ
      3090 สองใบมีแบนด์วิดท์หน่วยความจำรวม 1.87 TB/s หรือใบละ 0.936 TB/s แต่ M5 MacBook Pro มีแค่ 0.3 TB/s ส่วนชิป Max ได้สูงสุด 0.63 TB/s แต่คอนฟิกนั้นเป็นเครื่องราคา 10,000 ดอลลาร์
      ดังนั้น Qwen 27B จึงรันบน 3090 สองใบได้เร็วพอสำหรับงานจริง แต่บน MacBook Pro จะรู้สึกช้าอย่างทรมาน อีกทั้งถ้ารันโมเดลใหญ่บน MacBook Pro UI จะกระตุกและคีย์บอร์ดจะร้อน เอา 3090 สองใบไว้ในห้องใต้ดินแล้วเข้าจาก MacBook ดีกว่ามาก
    • มีทั้ง M5 MacBook Pro และชุด GPU แยกสำหรับรันโมเดลอยู่ แต่ ความต่างด้านความเร็ว ใหญ่มาก
      ไม่ใช่แค่ความเร็วสร้างโทเค็น แต่รวมถึงเวลาจนได้โทเค็นแรก หรือก็คือเวลาประมวลผลพรอมป์ด้วย ฮาร์ดแวร์ M5 เองนั้นยอดเยี่ยม แต่ GPU ก็ยังเร็วกว่าอยู่มาก
      ถ้ารันโมเดลบนกล่อง GPU ก็มีข้อดีตรงที่ใช้โน้ตบุ๊กวางบนตักได้โดยไม่ทำให้กลายเป็นจานร้อน
    • ผมรัน Qwen3.6-27B บน GPU 24GB ใบเดียวที่ 80 โทเค็น/วินาที อยู่ เลยไม่จำเป็นต้องใช้ถึงสองใบด้วยซ้ำ
    • เป็นตัวเลือกที่สมเหตุสมผล แต่ควรรู้ไว้ว่า M5 Pro มีแบนด์วิดท์หน่วยความจำประมาณ 1/3 และ M5 Max ก็ประมาณ 2/3 เท่านั้น คอนฟิกต่ำสุดของ M5 Max ก็ราคา 4,100 ดอลลาร์แล้ว
      ดังนั้นทั้งพรีฟิลที่ติด FLOPS และดีโค้ดที่ติดแบนด์วิดท์ก็น่าจะช้าทั้งคู่

  • สัปดาห์นี้เพิ่งตั้งค่า LLM แบบโลคัลเสร็จ เลยขอเสริมจากประสบการณ์ของตัวเอง ผมเลือกการ์ด 32GB ของ Intel ที่ชื่อ Arc B70 ซึ่งถูกกว่า 3090 และมี RAM มากกว่า แต่บัสหน่วยความจำช้ากว่า
    เหตุผลที่เลือกคือโมเดลที่อยากใช้มีขนาดใหญ่เกินกว่าจะใส่ใน 24GB ได้สบาย ๆ เล็กน้อย และยังต้องการพื้นที่สำหรับโหลดโมเดลเล็ก ๆ อีกหลายตัวสำหรับ autocomplete และการรู้จำเสียงด้วย อีกอย่างคือมีเซิร์ฟเวอร์ราคาถูกอยู่แล้ว และถ้าจะใช้ GPU คู่ก็ต้องเปลี่ยนเมนบอร์ดกับพาวเวอร์ซัพพลาย และอาจรวมถึงเคสด้วย
    การตั้งค่าค่อนข้างยุ่งยาก ไลน์ของ Intel ต้องใช้แพ็กเกจไดรเวอร์ชื่อ “level zero” เพื่อรองรับ SYCL ซึ่งคร่าว ๆ ก็คือ CUDA เวอร์ชัน Intel และทำให้มันทำงานได้ถูกต้องค่อนข้างยาก ผมรัน llama.cpp ใน Docker container และการทำให้คอนเทนเนอร์มองเห็นการ์ดก็ต้องลงมืออยู่พอสมควร ต้องใช้เคอร์เนลในช่วงไม่กี่เดือนล่าสุดด้วย
    พอทำงานได้แล้ว ผลลัพธ์น่าประทับใจมากสำหรับเงินลงทุน 1,000 ดอลลาร์ รัน Qwen 3.6 35B แบบ quantization q4 ใช้ RAM ประมาณ 3/4 และได้ราว 88 โทเค็น/วินาที ถ้าต้องการโมเดลขนาดพอเหมาะในราคาประหยัด นี่ก็เป็นอีกวิธีหนึ่ง

    • อันนั้นไม่ถูก ทั้งคู่เป็น GDDR6
      B70 เป็นบัส 256 บิตที่ 2375MHz ได้ 608 GB/s ส่วน 3090 เป็นบัส 384 บิตที่ 2438MHz ได้ 936 GB/s ไม่ได้ช้ากว่า แต่มีช่องสัญญาณน้อยกว่า หรือพูดอีกอย่างคือหน้ากว้างแคบกว่า

  • qwen3.6-27b สามารถรันตัวแปร q4 บน 3090 ใบเดียว พร้อม context รวมประมาณ 250K ได้ด้วย
    มันเร็วพอจนไม่อึดอัด ดังนั้นความเร็วที่เพิ่มขึ้นจาก 3090 สองใบจึงไม่คุ้มค่าสำหรับผม ยังมีตัวเลือกให้รัน q6 บนสองใบด้วยความเร็วครึ่งหนึ่งและ context ที่เล็กกว่า แต่ยังไงก็แข่งกับโมเดลระดับล่าสุดไม่ได้อยู่ดี ดังนั้นถ้าไม่ได้มี 3090 สองใบอยู่แล้ว ผมมองว่าที่ราคาปัจจุบัน ใบเดียวคือการลงทุนที่ดีที่สุด ถ้ามีสภาพแวดล้อมรันที่จัดไว้ดี ก็เพียงพอสำหรับทำงานได้หลายอย่าง

    • ตอนรัน qwen3.6-27b บน 3090 ใบเดียว คุณตั้ง KV cache เป็น q4 ด้วยหรือเปล่า?
      จากประสบการณ์ของผม ที่ความละเอียดระดับนั้น ความแม่นยำในการเรียกคืนบริบทยาว ๆ จะตกลงมาก ใช้ KV cache เป็น q8 แล้วทำงานกับ context 120k ดีกว่า
    • การคำนวณ 250k context, โมเดล Q4, VRAM 24GB จะลงตัวก็ต่อเมื่อ quantize K/V cache เป็น q4 ด้วยเท่านั้น และนั่นอาจไม่ใช่ความคิดที่ดี

  • เกี่ยวกับเรื่องนี้ ผมสงสัยว่าตอนนี้ ระบบแยกกักกัน ที่ดีที่สุดที่ใช้งานได้คืออะไร ไม่รู้ว่าต้องไปถึง VM หนา ๆ เต็มรูปแบบหรือไม่ หรืออะไรคล้าย Firecracker ก็พอแล้ว
    ตัวเลือกที่เป็นไปได้แต่ละแบบมีหลุมพรางละเอียดอ่อนที่ทำให้พังง่าย และดูเหมือนจะกลายเป็นสภาพที่แทบไม่มีความปลอดภัยเลยได้ง่ายมาก เหตุผลที่ใช้ VM คือเพราะเชื่อถือได้จริง ๆ ว่าความปลอดภัยเป็นหลักการพื้นฐานของเทคโนโลยีนี้ ไม่ใช่แนวทางแบบ “ใช้แฟล็ก 20 ตัวนี้แล้วหรี่ตามองก็จะโอเค”

    • บน MacOS มี seatbelt sandbox ในตัว ส่วนบน Linux สามารถใช้ Docker ที่วาง SELinux หรือยูทิลิตีคล้ายกันทับบน namespace ได้
      ก่อนอื่นต้องทำโมเดลเวกเตอร์โจมตี rm -rf ป้องกันได้ด้วยการจำกัดการเขียน ส่วน curl malware.sh | sh ก็จำกัดการรันจากไดเรกทอรีที่เขียนได้ก็พอ (seatbelt/SELinux) แค่จำกัดการเขียนไปยังไดเรกทอรีที่อ่อนไหว ก็มีโอกาสสูงที่จะทำให้มัลแวร์ส่วนใหญ่ไร้พิษสงลงได้มาก
      การรั่วไหลของข้อมูลรับรองก็แก้ได้ด้วยการล้างตัวแปรสภาพแวดล้อม ห้ามอ่าน .ssh, .aws เป็นต้น และอย่าวาง LLM ไว้ใกล้ระบบปฏิบัติการ
      ผมทำยูทิลิตีเล็ก ๆ สำหรับ MacOS ไว้ที่ https://github.com/aka-rider/leash แต่ใช้ bash script ก็ทำได้เช่นกัน
    • ขึ้นอยู่กับว่าใช้เพื่ออะไร ถ้าโมเดลความปลอดภัยคือการขังเอเจนต์ไว้ใน sandbox เพื่อไม่ให้มันทำพีซีพัง ก็มีตัวเลือกมากมาย
      ถ้าต้องการแบบเบา ๆ ก็ใช้อะไรอย่าง bubblewrap[1] หรือใช้ microVM อย่าง libkrun[2] ได้ และถ้าต้องการเครื่องมือที่เกี่ยวข้องพร้อม ๆ กัน ก็ไปถึง Docker เต็มรูปแบบได้
      [1] https://github.com/containers/bubblewrap
      [2] https://github.com/libkrun/libkrun
    • ผมคิดว่าคงไม่มี คอนฟิกพร้อมใช้ ที่เหมาะกับทุกคน เพราะไม่ว่าจะเป็นขอบเขตความปลอดภัยแบบใด การเสริมความแข็งแกร่งแต่ละชั้นย่อมต้องแลกกับความสะดวกในการใช้งาน
      ผมเห็นด้วยกับความไม่แน่ใจว่าเราจะรู้จริง ๆ ได้อย่างไรว่าทุกอย่างถูกล็อกแน่นแล้ว
      โดยส่วนตัวผมมองว่า VM หรือ microVM คือทางที่ถูกต้อง ต่างจากคอนเทนเนอร์ สิ่งเหล่านี้ถูกออกแบบมาให้เป็นขอบเขตความปลอดภัยจริง ๆ แม้เทียบกับ bubblewrap ก็ยังสามารถให้ไฟล์ซิสเต็มทั้งหมดแก่เอเจนต์แล้วรันในโหมด YOLO ได้ ขณะที่ bubblewrap ต้อง bootstrap ความพร้อมใช้งานของเครื่องมือพัฒนาแต่ละตัวทีละอย่าง ต้องเมานต์ไดเรกทอรีตั้งค่าและแคชแพ็กเกจอย่างปลอดภัย และถึงอย่างนั้นก็ยังมีโอกาสเจอข้อผิดพลาดเรื่องสิทธิ์อยู่เรื่อย ๆ การแยกกักกันก็อ่อนกว่ามากด้วย
      การรองรับสภาพแวดล้อมรันไทม์ยังจำกัด แต่ผมคิดว่าวิธีที่รันโปรเซสของสภาพแวดล้อมรันไทม์บนโฮสต์ แล้วมอบหมายการเรียกเครื่องมือทั้งหมดและปฏิสัมพันธ์กับไฟล์ซิสเต็มไปยัง VM นั้นค่อนข้างสมเหตุสมผล แบบนั้นจะเก็บข้อมูลเซสชันและคีย์ยืนยันตัวตนไว้บนเครื่องหลักได้ โดยไม่ให้เข้าไปอยู่ในบริบทเลย แต่ข้อแลกเปลี่ยนคือสภาพแวดล้อมรันไทม์เองจะกลายเป็นส่วนหนึ่งของขอบเขตความปลอดภัย
      วิธีเคลื่อนย้ายข้อมูลเข้าออก VM ก็เป็นปัญหาด้านความสะดวกเช่นกัน ผมใช้สคริปต์ที่ดัน local git repository เข้าไปใน VM แล้วดึงกลับมาเหมือนเป็นรีโมต วิธีนี้ทำให้ VM ไม่สามารถเริ่มการเชื่อมต่อไปยังโฮสต์ได้ และไม่จำเป็นต้องมีข้อมูลรับรองของ git ด้วย แต่สำหรับคนที่อยากให้เอเจนต์ push ไป GitHub โดยตรง อาจเป็นความพยายามที่มากเกินไป
      ตัวเลือกเกี่ยวกับ VM ที่ผมลองหรือเคยเห็นมี qemu + libvirt, crun-vm และตระกูล libkrun qemu + libvirt ต้องใช้แรงปรับให้เข้าที่ แต่ผ่านการพิสูจน์มามากและตั้งค่าได้สูง crun-vm เป็น PoC ของเลเยอร์ผสานระดับสูงระหว่าง podman กับ qemu ดูเหมือนจะถูกทิ้งไปแล้ว แต่น่าสนใจเพราะเน้นเครื่องมือและมาตรฐานที่มีอยู่ libkrun เป็นผู้เล่นใหม่กว่า และมี wrapper อย่าง microsandbox, smolvm, krunvm ทั้งหมดนี้อิง Linux
    • VM หนา ๆ ที่ต่อ GPU passthrough ผมเชื่อถือน้อยกว่า VM ที่ใช้ CPU อย่างเดียวมาก

  • รู้สึกแปลกที่ต้องพยายามถึงขนาดนี้เพื่อใช้ LLM โดยเฉพาะการไล่ตาม ล้ำหน้าสุด แบบนี้
    ถ้าพรุ่งนี้ของอย่าง Claude หายไป ผมก็คงไม่กะพริบตาเลย
    ผมไม่เข้าใจว่าทำไมผู้คนถึงเอารอยหยักในสมองของตัวเองไปแลกกับสิทธิ์เข้าถึงเครื่องผลิตสลอป ถ้าจะเปรียบเทียบให้ดี อาจคล้ายกับการให้ช่างไม้ฝีมือดีใช้เครื่องที่ผลิตเฟอร์นิเจอร์คุณภาพต่ำกว่า Ikea หนึ่งหรือสองระดับ มันทำงานสำเร็จไหม? ส่วนใหญ่ก็สำเร็จ ช่างไม้สนุกกับกระบวนการนั้นไหม? ไม่

  • จากประสบการณ์ของผม ผมไม่เคยลองรันโมเดลที่ถูก quantize อย่างหนักแบบ q4 หรือถูกดัดแปลงไปพอสมควรแล้วรู้สึกว่า “ว้าว สุดยอดจริง ๆ” เลย ตรงกันข้าม หลังจากใส่พรอมป์ไม่กี่ครั้งก็โยนลงถังขยะไป
    ผมมี RTX 6000 PRO ขนาด 96GB สิ่งที่รันได้อย่างสบาย ๆ คือประมาณ Qwen 3.6 27B หรือ MoE, Gemma 4 31B ตอนรันโมเดลด้วย precision เต็มและความยาวบริบทสูงสุด ขีดจำกัดก็อยู่แถวนี้
    โมเดลเหล่านี้ทำงานได้ดี และใช้ได้กับหลายงาน เช่น การเขียนโค้ด การค้นคว้าทางอินเทอร์เน็ต ฯลฯ ถ้าคำนวณแล้วคิดว่าจะจ่ายมากกว่า 2,400 ดอลลาร์ต่อปีให้ Anthropic การซื้อการ์ดแบบนี้ก็อาจสมเหตุสมผล แต่ต้องยอมรับคุณภาพที่ลดลงอยู่ดี อีกอย่าง อีก 5 ปีข้างหน้ามนุษย์จะยังเขียนโค้ดอยู่หรือเปล่าก็ยังน่าสงสัย