ใช้ Open LLM และผู้ช่วยเขียนโค้ดแบบเปิดบนเครื่องตัวเองอยู่ไหม? มาแชร์สภาพแวดล้อมกัน

 (news.ycombinator.com)
16 คะแนน โดย GN⁺ 2025-11-01 | 6 ความคิดเห็น | แชร์ทาง WhatsApp
  • เธรด Ask HN ที่ถามผู้ใช้ Hacker News ว่า พวกเขาใช้ Open LLM และผู้ช่วยเขียนโค้ดแบบเปิดบนเครื่องตัวเองอย่างไร บนฮาร์ดแวร์แล็ปท็อปแบบไหน
  • ใช้โมเดลอะไรบ้าง (เช่น Ollama, LM Studio ฯลฯ) และใช้ผู้ช่วยเขียนโค้ด/โซลูชันแบบบูรณาการโอเพนซอร์สอะไรบ้าง (เช่น ปลั๊กอิน VS Code)
  • ใช้ฮาร์ดแวร์โน้ตบุ๊กแบบไหน (CPU, GPU/NPU, หน่วยความจำ, GPU แยกหรือ GPU แบบรวม, OS) และได้ประสิทธิภาพแบบใดในเวิร์กโฟลว์จริง
  • ใช้กับงานประเภทไหนบ้าง (เติมโค้ด, รีแฟกเตอร์, ดีบัก, รีวิวโค้ด)? และมีความเสถียรแค่ไหน (อะไรที่ทำงานได้ดีและอะไรที่ยังขาดอยู่)

  • 1) MacBook Pro / Mac Studio (M2~M4 Max, 64~128GB) + LM Studio/Ollama + VS Code Continue

    • ข้อดี
      • ด้วย unified memory ของ Mac ทำให้ Qwen3-Coder-30B-A3B, gpt-oss-20b, Gemma 27B รันแบบโลคัลได้ตรง ๆ จนทำเวิร์กโฟลว์แนว “ดึงโค้ดมาอ่าน → สรุป → แก้ไขเล็กน้อย” ได้
      • แค่เปิด LM Studio API หรือ Ollama serve ไว้ VS Code Continue.dev, Zed, JetBrains ก็เชื่อมได้ทันที ให้ประสบการณ์ใช้งานคล้าย Claude Code พอสมควร
      • ความหน่วงต่ำแบบฉบับ Mac ทำให้ถ้าได้ราว 50~80 tok/s การช่วยเติมโค้ดและสร้างคอมเมนต์ก็ยังไม่อืดนัก
      • ใช้งานได้แม้บนเครื่องบิน/รถไฟ/ออฟไลน์ จึงเหมาะกับการทำให้ “โค้ดบริษัทไม่ต้องออกไปข้างนอก”
    • ข้อเสีย
      • ตั้งแต่โมเดลเกิน 20B ขึ้นไปจะเริ่มมีปัญหา ความร้อน + เสียงพัดลม และแม้เป็น M4 Max 128GB ก็ยังช้าหรือชนขีดจำกัดเมื่อไปถึง 120B
      • สถานการณ์แบบเอเจนต์ที่ “ลุย bash-in-a-loop จนจบเหมือน Claude 4.5 Sonnet” ยังทำได้ไม่ดีนัก
      • MacBook ระดับ 24GB, 32GB จัดสรร VRAM ได้น้อย สุดท้ายต้องลดลงมาใช้ระดับ 7B~12B และถ้าขยายคอนเท็กซ์มากก็จะช้าทันที

  • 2) เดสก์ท็อป/เวิร์กสเตชันติด RTX 3090·4090·Pro 6000 แล้วใช้โน้ตบุ๊กเป็น thin client

    • ข้อดี
      • ทดลองได้ครบทั้ง llama.cpp / vLLM / Ollama และแม้แต่ gpt-oss-120B ก็ยัง “รันได้จริงแม้จะช้า”
      • เปิด Continue หรือ llama-vscode ใน VS Code บนโน้ตบุ๊ก แล้วให้โมเดลไปรันอนุมานบนเครื่องที่บ้าน จึงแทบไม่มีภาระเรื่องแบตเตอรี่หรือความร้อนบนโน้ตบุ๊ก
      • อ้างอิงจาก RTX 3090 24GB, gpt-oss-20B, Qwen2.5/3 Coder 14~30B ให้ความเร็วโทเค็นระดับใช้งานจริง จึงพอสำหรับ autocomplete + รีแฟกเตอร์สั้น ๆ
      • มีคนใช้รูปแบบวาง Open WebUI + Ollama ไว้ที่บ้าน แล้วเชื่อมผ่าน VPN/Tailscale กันมาก ทำให้รักษาสภาพแวดล้อมส่วนตัวได้แม้อยู่ระยะไกล
    • ข้อเสีย
      • ถ้า VRAM ของ GPU มีไม่ถึง 24GB การรัน 120B ต้อง quantize หนักมากจนคุณภาพลดลงอย่างเห็นได้ชัด
      • vLLM ประสิทธิภาพดี แต่ติดตั้งและบิลด์ยุ่งยาก จนมีเสียงบอกกันว่าต้อง “ลองรันใหม่ด้วย runner เวอร์ชันอัปเดต” ทำให้ภาระดูแลรักษาสูง
      • แทบไม่มีความพกพา ดังนั้นถ้าต้องการ “ให้จบในโน้ตบุ๊กเครื่องเดียวจริง ๆ” โครงสร้างแบบนี้ก็ไม่ตอบโจทย์

  • 3) เซ็ตอัปที่เน้น gpt-oss-120B (Aider, Codex, เอเจนต์โลคัล)

    • ข้อดี
      • หลายคนบอกว่า “จากที่เคยใช้แบบโลคัลมา ตัวนี้ใกล้ GPT-5 ที่สุด” จนสะท้อนว่า ความแม่นยำในงานเขียนโค้ด อยู่ในระดับสูง
      • เชื่อมกับผู้ช่วยเขียนโค้ดแบบเปิดอย่าง Aider, Codex, roocode แล้วทดลองให้ทำ รีวิว → แก้ไข → ทดสอบ → คอมมิต ในรอบเดียวได้จริง
      • มีการแชร์เทคนิคใช้ CPU+GPU แบบผสม บน llama.cpp เพื่อฝืนรันแม้มี VRAM แค่ 8GB ทำให้ข้อกำหนดฮาร์ดแวร์ยืดหยุ่นกว่าที่คิด
    • ข้อเสีย
      • ปัญหาคือความเร็ว งานชุด 50 ข้อเดียวกันที่ ChatGPT ทำเสร็จใน 6 นาที 120B อาจใช้เวลากัดทีละข้อเกิน 1 ชั่วโมง จึงเหมาะกับคนที่ “ยอมรอได้”
      • ในเครื่องมืออย่าง Codex ต้อง ฮาร์ดโค้ด inference parameters เพื่อไม่ให้มันหยุดกลางทาง และต้องเขียน AGENTS.md ค่อนข้างหนักถึงจะทำงานได้เหมือนคน
      • ถ้าใช้แค่โน้ตบุ๊กล้วน ๆ ก็รันต่อเนื่องยากเพราะข้อจำกัดเรื่องความร้อน พลังงาน และหน่วยความจำ จึงควรมองว่าเป็นการ “ใช้โน้ตบุ๊กเชื่อม GPU ระยะไกล” มากกว่า

  • 4) โน้ตบุ๊กแรมใหญ่ เช่น AMD Strix Halo / Ryzen AI / Framework 128GB + llama.cpp/Continue.dev

    • ข้อดี
      • ถ้ามี RAM 128GB ก็ใช้ Qwen3 Coder 30B ได้จริง และทำแบบไฮบริดโดยวางบางเลเยอร์ไว้บน GPU/NPU แล้วให้ส่วนที่เหลือวิ่งบน RAM ได้
      • หลายคนมองว่านี่เป็นตัวเลือกที่ใช้งานได้จริงในสถานการณ์อย่าง “โค้ดห้ามออกนอกบริษัท” หรือ “ใช้ AMD ซึ่งฝั่งไดรเวอร์คลาวด์ยังไม่ค่อยดี”
      • โครงสร้างแบบให้ เซิร์ฟเวอร์ llama.cpp แบบง่าย ๆ อย่าง lemonade-server รันอัตโนมัติตอนบูต แล้วให้เอดิเตอร์เชื่อมผ่านเครือข่าย ใช้งานได้ผลดี
    • ข้อเสีย
      • มีรายงานว่าเรื่อง ประหยัดพลังงาน/กล้อง/ไดรเวอร์ บน Linux ยังไม่ค่อยลื่น และบางกรณีก็ต้องรอเคอร์เนล 6.18
      • ประสิทธิภาพ NPU ยังไม่ถึงระดับ NVIDIA ทำให้เอเจนต์ระดับ frontier แทบเป็นไปไม่ได้ และสุดท้ายก็หยุดอยู่ที่บทบาท “ผู้ช่วย” ขนาด 20~30B
      • ข้อมูลฝั่ง AMD ต้องไล่หาตาม GitHub repo หรือฟอรัม ทำให้ความหนาแน่นของข้อมูลยังน้อยกว่าฝั่ง Mac และ NVIDIA

  • 5) โน้ตบุ๊กทั่วไป 16~32GB (MacBook Air, M2/M3 Pro RAM ต่ำ) + โมเดล 7B~12B สำหรับ FIM autocomplete อย่างเดียว

    • ข้อดี
      • แค่ใช้ qwen2.5-coder:7b, mistral 7b instruct, gemma3:12b ก็พอช่วยงานแบบ “เขียนบรรทัดนี้ต่อให้หน่อย”, “SQL syntax ตรงนี้คืออะไรนะ” ได้ทันที
      • ถ้าต่อกับ llama-vscode plugin หรือ Continue.dev ต่อให้อินเทอร์เน็ตหลุด autocomplete ก็ยังทำงานต่อได้ จังหวะการทำงานไม่สะดุด
      • ภาระฮาร์ดแวร์ต่ำ จึงแทบไม่มีปัญหาความร้อนและเสียงพัดลม แบตเตอรี่ก็ไม่หมดเร็ว
    • ข้อเสีย
      • พอคอนเท็กซ์ยาวขึ้นนิดเดียว สัดส่วนคำตอบมั่วก็เพิ่มทันที และงานอย่างรีแฟกเตอร์หรือสร้างโค้ดทดสอบที่ต้อง “เข้าใจหลายไฟล์พร้อมกัน” แทบทำไม่ได้
      • คนส่วนใหญ่ย้ำชัดว่า “นี่ไม่ใช่ตัวแทนของโมเดลคลาวด์ แต่เป็นเครื่องมือสำหรับ autocomplete โดยเฉพาะ”
      • เพราะต้องบีบโมเดลลงเป็น 4-bit ค่อนข้างหนัก ตัวเลือกโมเดลจึงมีไม่กว้างนัก

  • 6) เซ็ตอัปออฟไลน์เต็มรูปแบบ/เน้นความเป็นส่วนตัว (Ollama + Open WebUI + VPN)

    • ข้อดี
      • ถ้ามี Mac Studio M4 Max 128GB หรือเดสก์ท็อปสักเครื่องที่บ้าน แล้วเปิด Ollama + Open WebUI ไว้ ข้างนอกจะใช้โน้ตบุ๊กหรือมือถือเชื่อมผ่าน VPN ก็ยังถือว่าเป็นโลคัลทั้งหมด
      • คนที่ใช้โครงสร้างนี้มองว่าจุดเด่นคือ “ตอนนี้แทบไม่ใช้ ChatGPT แล้ว” และ “เวอร์ชันไม่เปลี่ยน จึงไม่ทำให้พรอมป์ต์ที่จูนไว้พัง”
      • เมื่อในองค์กรมีข้อกำหนดว่า “โค้ดทั้งหมดต้องไม่ถูกนำไปใช้ฝึก” นี่คือโครงสร้างที่อธิบายได้ง่ายที่สุด
    • ข้อเสีย
      • ต้องอัปเกรดหรือเปลี่ยนโมเดลเอง จึงไม่มีความสะดวกแบบคลาวด์ที่ “ฉลาดขึ้นเอง”
      • ถ้า GPU อ่อน โมเดลเกิน 20B ก็จะช้าทันที สุดท้ายต้องเพิ่มฮาร์ดแวร์ และพอถึงจุดนั้นก็มักเริ่มคิดว่า “ทำไมไม่ใช้คลาวด์ไปเลย?”

  • 7) ข้อสรุปร่วมที่เห็นตรงกัน

    • ถ้าเป็น “โน้ตบุ๊กล้วน” ตอนนี้ยังแทน Claude Code / GPT-5 + agent ได้ยาก และโลคัลยังเหมาะที่สุดกับงาน สร้างโค้ดสั้น ๆ, ช่วยอธิบาย, สรุป, autocomplete
    • ดังนั้นรูปแบบที่เจอบ่อยจึงเป็น “โน้ตบุ๊ก ↔ เครื่องใหญ่ที่บ้าน” หรือ “Mac 128GB เอาไว้รันแค่ 20~30B ให้เร็ว”
    • ถึงอย่างนั้น ทุกคนก็พูดคล้ายกันว่า ถ้าต้องการ ความเป็นส่วนตัว + ความหน่วงต่ำมาก + เวอร์ชันไม่เปลี่ยน ตอนนี้คำตอบก็ยังเป็นโลคัล

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

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

 
kaydash 2025-11-02

ผมคิดว่าการตั้งค่า bearer token และใช้ SSH tunneling น่าจะดีกว่าการใช้ VPN
 
savvykang 2025-11-02

ผมคิดว่าการเริ่ม self-host LLM ตอนนี้ ตลอด 5 ปีข้างหน้ายังจะอยู่ในสภาพที่ต้นทุนลงทุนล่วงหน้าสูงเกินไปจนไม่คุ้มทุนอยู่ต่อไปครับ วางแผนว่าจะกลับมาคิดอีกทีในอีก 3~5 ปีข้างหน้า เมื่อมีฮาร์ดแวร์ที่เร็วพอในระดับเหมาะสมสำหรับงานเติมโค้ดอัตโนมัติโดยเฉพาะ และเริ่มมีความได้เปรียบด้านราคา

ชุดการตั้งค่าที่เคยพิจารณา

  1. แบบ all-in-one: ไม่สามารถรัน LLM บนอุปกรณ์ที่ใช้ทำงานได้ แรมไม่พอแม้แต่จะรันเครื่องมือพัฒนาและแอปที่ทำงานบนเบราว์เซอร์
  2. แบบเครื่องเฉพาะสำหรับ LLM: ที่บริษัทไม่มีการ์ดจอจึงรันไม่ได้ และสำหรับพีซีส่วนตัวก็ไม่ง่ายที่จะลงทุนสเปกสูงล่วงหน้า
 
GN⁺ 2025-11-01
ความเห็นจาก Hacker News

  • ซื้อ Dell Precision 3620 Tower i7-7700 มือสองมาเพราะอยากลองใช้งาน AI ด้วยตัวเอง
    อัปเกรด RAM และเปลี่ยนพาวเวอร์ซัพพลายเพื่อใส่ GPU RTX 3060
    ติดตั้ง Ubuntu Server แล้วตั้งเป็น โหนดในคลัสเตอร์ k3s ที่บ้าน กำลังรัน Ollama และ OpenWebUI
    ใช้หลัก ๆ กับ การแท็กและสรุปด้วย AI ของ Karakeep แต่ก็เอาไปใช้วิเคราะห์กล้องหน้าบ้านเพื่อตรวจจับรถส่งพัสดุด้วยโค้ด Python ด้วย

  • รัน Ollama แบบใช้ CPU บน Dell Precision T710 (Xeon E6320, RAM 120GB, RAID5 SSD 240TB) โดยไม่มี GPU
    กำลังทำโปรเจ็กต์ที่ใช้ RAG ทำดัชนีกฎหมายเลือกตั้งของทั้ง 50 รัฐเพื่อทำให้เห็นภาพ ปัญหาความไม่ตรงกันของคำศัพท์และอาการหลอน
    เป้าหมายคือระบุ ช่องว่างด้านความสมบูรณ์ของกระบวนการเลือกตั้ง
    ดู mindmap ที่เกี่ยวข้องได้ที่ Election Frauds v1.4 Mindmap PDF

    • เป็นเรื่องที่ยอดเยี่ยมมากที่นำความสามารถไปใช้กับโปรเจ็กต์เพื่อสังคมแบบนี้

  • เขียนโค้ดด้วย local LLM อยู่ แต่บนโน้ตบุ๊กนั้นนึกภาพไม่ออกเลย
    ใช้งานบนเซิร์ฟเวอร์ GPU โดยสลับโมเดลด้วย llama.cpp + llama-swap
    ชุดที่พอใจที่สุดคือ Aider + gpt-oss-120b
    อาจทำได้บน Ryzen AI Max+ RAM 128GB แต่ ฮาร์ดแวร์ที่ไม่ใช่ NVIDIA ช้ามาก
    และยังเลือกใช้ ผู้ให้บริการที่ไม่เก็บข้อมูล ผ่าน OpenRouter ได้ด้วย
    แต่ GPT5 หรือ Claude ก็ยังเร็วและถูกกว่าการรันแบบโลคัลมาก

    • สร้าง RAG agent ด้วย gpt-oss-120b แล้วให้เรียนรู้เอกสาร GCP
      ChatGPT ได้ 46/50 ใน 6 นาที ส่วน gpt-oss-120b ได้ 47/50 ใน 1 ชั่วโมง
      รันบนเครื่อง i7 + RAM 64GB + GPU VRAM 8GB
    • ลิงก์ GitHub ของ llama-swap

  • ถ้าอยากรัน local code agent บน Mac ให้ทำแบบนี้

    1. npm install -g @openai/codex
    2. brew install ollama; ollama serve
    3. ollama pull gpt-oss:20b
    4. codex --oss -m gpt-oss:20b
      ทำงานได้โดยไม่ต้องใช้อินเทอร์เน็ต และต้องใช้ Mac รุ่น M1 ขึ้นไป + หน่วยความจำ GPU 24GB
      โมเดล 120b มีประสิทธิภาพดีกว่า 20b อยู่ 1.5 เท่า แต่สเปกที่ต้องการสูงกว่า 5 เท่า
    • LM Studio ง่ายกว่ามาก และยังเชื่อมกับ JetBrains IDE หรือ Zed ได้ด้วย
    • อยากรู้ว่าโมเดล 20b สามารถสร้างโค้ดที่มีคุณค่าใช้งานจริงได้หรือไม่

  • กำลังรัน Qwen3-Coder-30B-A3B Q4 quant ด้วย llama.cpp บน MacBook Pro 64GB
    ใน VSCode ใช้ continue.dev และตั้ง system prompt ให้สั้น
    ได้ความเร็วสร้าง 50 โทเคนต่อวินาที และประมวลผล 550 โทเคนต่อวินาที
    สำหรับงานสั้นและชัดเจน คุณภาพ ใกล้เคียงกับ frontier model
    พอใจเพราะเร็วและเสถียรแม้อยู่ในสภาพแวดล้อมออฟไลน์
    งานที่ซับซ้อนกว่านี้จะใช้ Claude หรือ Deepseek API

    • มีคนถามว่าเคยลอง โมเดล Instinct ของ continue.dev หรือยัง และอยากรู้ว่าเทียบกับ Qwen เป็นอย่างไร
    • มีคำขอให้แชร์ลิงก์ดาวน์โหลดจาก Hugging Face และถามว่าถ้าเป็นเครื่อง 128GB ควรใช้ quant แบบอื่นไหม
    • มีคอมเมนต์ถามด้วยว่ารัน Qwen3 บน llama-vscode อย่างไร (ลิงก์ issue)

  • ถ้าจะซื้อ Mac แนะนำให้เลือก รุ่น Pro ขึ้นไป
    Air ไม่มีพัดลมจึง จัดการความร้อนไม่ได้ดี และคิดว่า Studio ดีกว่า Mac mini
    แอป TG Pro สามารถปรับพัดลมให้ตอบสนองไวขึ้นได้ (ประมาณ $20)
    รัน GPT OSS 20B บน MacBook Pro M4 Pro + RAM 24GB แต่ context window เล็ก
    ถ้าเป็นรุ่น 128GB ก็น่าจะเขียนโค้ดออฟไลน์ได้ทั้งวัน

    • Mac mini ก็มีพัดลมเช่นกัน และ Studio เป็นเพียงเวอร์ชันที่ใช้ชิปแรงกว่า
    • ถ้าจะซื้อ Mac สเปกที่เหมาะที่สุดคือ ชิป Max หรือ Ultra + หน่วยความจำสูงสุด
    • MacBook Pro 128GB ให้ ประสิทธิภาพ context cache เหนือชั้นมาก
    • context window พื้นฐานเล็กก็จริง แต่ใน gpt-oss-20b ขยายได้ 4 เท่า
    • มีความเห็นว่าแม้เป็น M3/M4 + 128GB ความเร็วประมวลผลพรอมป์ยาว ๆ ก็ยังช้า

  • ใช้งาน Apple M4 Max 128GB ร่วมกับ GPD Win 4 (Ubuntu 24.04) ผ่าน USB-C
    ผสม Claude Code, RA.Aid และ llama.cpp เพื่อกระจายงานด้วย Agent Organizer
    Claude ช่วย ทำงานอัตโนมัติตั้งแต่การออกแบบสถาปัตยกรรมไปจนถึง code review

    • มีคำถามว่า GPD Win 4 ทำหน้าที่อะไร ใช้กระจายงานให้โมเดลเล็กหรือไม่
    • มีคอมเมนต์ถามความเร็วประมวลผลโทเคนของแต่ละโมเดลด้วย
    • และมีคนสงสัยว่า Agent Organizer ที่ใช้อยู่นั้นคืออะไร

  • ถ้าอยากดูเวิร์กสเตชัน LLM แนะนำ ช่อง YouTube ของ Alex Ziskind (@AZisk)
    มีรีวิว เวิร์กสเตชันสำหรับ local LLM หลากหลายแบบ
    การนำเสนอดีและคำแนะนำก็ใช้ได้จริง

    • น่าจะมีสปอนเซอร์สนับสนุนอยู่บ้าง แต่ก็น่าประทับใจที่ยอม รับความเสี่ยงจากการซื้ออุปกรณ์เอง เพื่อมารีวิว
    • ยังมีคอมเมนต์แนะนำว่าเป็น “ช่องที่พูดแต่ประเด็น ไม่พูดน้ำ”

  • ใช้ LMStudio และ Ollama เป็นหลักบน MacBook Pro M4 Max 128GB
    โมเดลที่ใช้คือ qwen3-coder-30b A3B Instruct 8-bit MLX และ gpt-oss-120b-MXFP4-Q8
    แม้จะมีข้อจำกัดกับการสร้างโค้ดขนาดใหญ่ แต่ก็เพียงพอสำหรับ สรุปและทำเอกสารรีโพแบบโลคัล
    คอมมูนิตี้ที่เกี่ยวข้องก็ยังคึกคัก

    • r/LocalLLM
    • r/LocalLLaMA
    • บน Mac ถ้าใช้ Coderunner(ลิงก์ GitHub) จะสามารถ รันโค้ดที่ LLM สร้างขึ้นใน sandbox อย่างปลอดภัย ได้
    • ถ้าเชื่อม LM Studio API เข้ากับ qwen CLI ก็สร้าง สภาพแวดล้อมคล้าย Claude Code ได้
      สำหรับการสร้าง README ชอบใช้ gemma3-27b-it-qat กับ gpt-oss-120b

  • กำลังรัน Qwen3:32b ผ่าน CLI บน MacBook Pro M1 Pro 32GB + Asahi Linux
    ใช้ขอความช่วยเหลือเรื่อง ARMv8 assembly หรือเรื่องที่เกี่ยวกับ SoC
    ความเร็วช้ากว่าความเร็วอ่านเล็กน้อย จึงถือว่าใช้งานได้ดีพอ
    ได้ยินว่า Qwen3-coder เร็วกว่าเลยเริ่มสนใจ
    ชอบ สภาพแวดล้อมแบบโลคัลเต็มรูปแบบ โดยไม่มีคลาวด์หรือการเชื่อมต่อ agent
    เพราะ Ollama เริ่มห่างจากแนวทางออฟไลน์เป็นหลัก จึงกำลังจะ ย้ายไปใช้ llama.cpp
    กำลังกังวลว่าจะใช้โมเดลของ Ollama เดิมได้ไหม เพราะฟอร์แมตโมเดลต่างกัน
    [ข้อควรระวัง] บนลินุกซ์กินไฟมาก จึงต้องเสียบปลั๊กใช้งานเสมอ

    • Qwen3 Coder เป็น โครงสร้าง MoE (30B แต่มี 3B ที่ active) จึงเร็วกว่าเยอะ
      งานทั่วไปอาจฉลาดน้อยกว่า แต่ คุ้มค่ามากสำหรับงานที่เน้นการเขียนโค้ด
 
chcv0313 2025-11-02

พอไล่อ่านไปเรื่อยๆ..... ก็เริ่มคิดว่าอาจมีความต้องการ DGX SPARK มากกว่าที่คาดไว้เหมือนกันนะ? ตอนแรกผมคิดว่า ของนั้นความคุ้มค่าห่วยแตก จะซื้อไปทำไม! แต่
 
aer0700 2025-11-02

เนื่องจากนโยบายความปลอดภัยภายในบริษัท จึงไม่ได้ใช้ external LLM API เลยแม้แต่น้อย และกำลังใช้งานสิ่งที่ฝ่ายดูแลคลาวด์ภายในบริษัทจัดเตรียมให้ในรูปแบบ gpt oss บนพื้นฐานของ vllm อยู่
 
aer0700 2025-11-02

จะว่าเป็นการใช้งานแบบโลคัลก็ค่อนข้างกำกวมนิดหน่อยนะครับ