Mesh LLM - การประมวลผล AI แบบกระจายบน iroh

 (iroh.computer)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • รวม GPU และหน่วยความจำที่กระจายอยู่บนหลายเครื่องให้เป็น ทรัพยากรประมวลผลเดียว เพื่อให้บริการการรันในเครื่อง การส่งต่อไปยังเพียร์ และการรันแบบแบ่งส่วน ผ่าน OpenAI-compatible API เพียงตัวเดียว
  • คำขอจะถูกประมวลผลบน GPU ภายในเครื่องหรือบนเพียร์ที่โหลดโมเดลไว้แล้ว และสำหรับโมเดลที่ไม่สามารถใส่ลงในเครื่องเดียวได้ ก็สามารถแบ่งรันเป็น ขั้นตอนแบบไปป์ไลน์ บนหลายโหนดได้
  • แคตตาล็อกแบบปลั๊กอินมีโมเดลมากกว่า 40 รุ่น ตั้งแต่โมเดลขนาด 500 ล้านพารามิเตอร์สำหรับโน้ตบุ๊ก ไปจนถึง โมเดล MoE ขนาด 235B โดยไคลเอนต์เรียกเพียง localhost:9337/v1 โดยไม่ต้องสนใจการจัดวางภายใน
  • แต่ละโหนดรัน iroh endpoint ที่ใช้กุญแจสาธารณะเป็นทั้ง ID และพื้นผิวเครือข่ายเพียงหนึ่งเดียว และสร้างการเชื่อมต่อ QUIC ที่ยืนยันตัวตนแล้วผ่าน NAT traversal, hole punching และเส้นทางรีเลย์สำรอง โดยไม่ต้องมีเซิร์ฟเวอร์กลาง
  • ด้วยซอฟต์แวร์ขนาดประมาณ 18MB ผู้ใช้สามารถสร้างเมชแบบสาธารณะหรือดีพลอยแบบส่วนตัวได้ และมีแผนรองรับแอปมือถือผ่าน iroh Swift SDK และ ACP เพื่อลดการพึ่งพาเซิร์ฟเวอร์แบบปิดในอนาคต

ใช้ฮาร์ดแวร์ที่มีอยู่แทนดาต้าเซ็นเตอร์ภายนอก

  • วิธีใช้งาน LLM ทั่วไปมักพึ่งพาดาต้าเซ็นเตอร์ GPU ของผู้ให้บริการภายนอกและ API แบบคิดค่าบริการตามการใช้งาน ซึ่งยิ่งใช้งานมากต้นทุนก็ยิ่งสูง
  • เมื่อส่งพรอมป์ตไปยังบริการภายนอก ผู้ใช้จะควบคุมสิ่งต่อไปนี้ได้ยากโดยตรง
    • ช่วงเวลาที่โมเดลถูกอัปเดต
    • สถานที่ที่ข้อมูลถูกส่งไป
    • หน่วยความจำและฮาร์ดแวร์พื้นฐานที่โมเดลใช้งาน
    • การเปลี่ยนแปลงของราคาและนโยบายจัดการข้อมูลส่วนบุคคล
  • องค์กรและบริการที่มี GPU อยู่แล้วในสำนักงาน คลังสินค้า หรือใต้โต๊ะทำงาน ต้องการวิธีใช้หลายเครื่องให้ทำงานเหมือน ทรัพยากรประมวลผลเดียว
  • Mesh LLM ถูกออกแบบมาเพื่อรวม GPU และหน่วยความจำที่มีอยู่ข้ามจำนวนเครื่องตามต้องการ เพื่อรันโมเดลที่ใหญ่ขึ้น และแบ่งปันทรัพยากรประมวลผลได้ทั้งแบบส่วนตัวภายในทีม หรือแบบสาธารณะกับภายนอก

สามเส้นทางในการประมวลผลคำขอ

  • เมื่อเรียก http://localhost:9337/v1 จาก OpenAI client มาตรฐาน เมชจะเป็นผู้ตัดสินว่าคำขอนั้นควรถูกรันที่ใดจริง
  • คำขอจะถูกจัดการผ่านหนึ่งในสามเส้นทางต่อไปนี้
    • รันโมเดลบน GPU ภายในเครื่อง ปัจจุบัน
    • ส่งต่อคำขอไปยังเพียร์ที่โหลดโมเดลที่ต้องการไว้แล้ว
    • แบ่งโมเดลที่ไม่สามารถใส่ลงในเครื่องเดียวได้ให้รันแบบ ไปป์ไลน์ ข้ามหลายเครื่อง
  • ผู้ใช้สามารถเริ่มจากโหนดเดียวแล้วค่อยเพิ่มเมื่อจำเป็น และ OpenAI client ไม่จำเป็นต้องรู้รายละเอียดของการทำ routing ภายในหรือวิธีรันแบบแบ่งส่วน

โครงสร้างปลั๊กอินและแคตตาล็อกโมเดล

  • ปลั๊กอินจะประกาศความสามารถที่มีใน manifest และ runtime จะเริ่มต้นปลั๊กอินเหล่านี้พร้อมทำ routing ให้กับการเรียกใช้งาน
  • ความสามารถของแต่ละปลั๊กอินถูกเปิดเผยผ่าน MCP·HTTP·การอนุมาน·เหตุการณ์ของเมช
  • แคตตาล็อกพื้นฐานมีโมเดลมากกว่า 40 รุ่น
    • โมเดลประมาณ 500 ล้านพารามิเตอร์ ที่รันบนโน้ตบุ๊กได้
    • ไปจนถึง Mixture-of-Experts ขนาด 235B

การรันแบบแบ่งส่วนของ Skippy

  • โหมดแบ่งส่วนสำหรับโมเดลขนาดใหญ่ถูกเรียกภายในว่า Skippy
  • ระบบจะแบ่งช่วงชั้นของโมเดลออกเป็นหลายสเตจแล้ววางลงบนแต่ละโหนด
    • โหนดหนึ่งรับผิดชอบชั้น 0~15
    • โหนดถัดไปรับผิดชอบชั้น 16~31
    • หลังจากนั้นก็แจกจ่ายชั้นต่อไปในลักษณะเดียวกันจนสุดไปป์ไลน์
  • activation ที่สร้างขึ้นในแต่ละสเตจจะถูกส่งต่อไปยังสเตจถัดไป ทำให้สามารถรันโมเดลที่ไม่สามารถใส่ลงในเครื่องเดี่ยวได้ ด้วยการรวมเครื่องระดับกลางหลายเครื่องเข้าด้วยกัน
  • กระบวนการแบ่งส่วนนี้ไม่ปรากฏต่อ OpenAI client และไคลเอนต์ยังคงเรียกเพียง local endpoint เช่นเดิม

เครือข่าย P2P บน iroh

  • ทั้งโหนดที่ให้บริการโมเดลและโหนดที่มีหน้าที่ส่งคำขอเท่านั้น ต่างก็เริ่มต้น iroh endpoint
  • endpoint นี้ทำหน้าที่สามอย่าง
    • ID ของโหนด
    • กุญแจสาธารณะ
    • พื้นผิวเครือข่ายเพียงหนึ่งเดียวที่โหนดเปิดเผยต่อภายนอก
  • iroh จัดการ hole punching, NAT traversal และเส้นทางรีเลย์สำรองโดยไม่ต้องมีเซิร์ฟเวอร์กลาง เพื่อสร้าง การเชื่อมต่อ QUIC แบบตรงและยืนยันตัวตนแล้วระหว่างโหนดที่อยู่คนละสถานที่
  • สำหรับโหนดที่ไม่สามารถเชื่อมต่อกันโดยตรงได้ ระบบมี iroh relay 2 ตัวในคนละภูมิภาคเพื่อให้เส้นทางสำรองที่อยู่ใกล้กว่า
  • เนื่องจากสามารถระบุเครื่องด้วยกุญแจสาธารณะและใช้ QUIC แบบ NAT traversal ที่ยืนยันตัวตนแล้วได้ การส่งคำขอไปยังเพียร์หรือการส่ง activation ไปยังสเตจถัดไปในไปป์ไลน์ จึงใช้ primitive การสื่อสารเดียวกันที่แตกต่างกันเพียง endpoint ID

แยกโปรโตคอลด้วย QUIC ALPN

  • โปรโตคอลทั้งหมดใช้ การเจรจา ALPN ของ QUIC และแบ่งออกเป็นสามแบบตามการใช้งาน
    • mesh-llm/1: ข้อความพื้นฐานของเมช รวมถึง gossip, routing, HTTP tunnel และช่องทางปลั๊กอิน
    • mesh-llm-control/1: control plane ของเจ้าของระบบ สำหรับซิงก์การตั้งค่าและการพิสูจน์ความเป็นเจ้าของ
    • skippy-stage/2: การส่ง activation สำหรับโมเดลแบบแบ่งส่วนที่ไวต่อ latency
  • ในการเชื่อมต่อ mesh-llm/1 งานทั้งหมดจะถูกส่งผ่าน QUIC stream แบบสองทิศทาง และไบต์แรกของ stream จะใช้ระบุประเภท
    • 0x01 GOSSIP: การประกาศเพียร์ที่รวมถึงโมเดล, GPU, RTT และความสามารถ
    • 0x04 TUNNEL_HTTP: คำขออนุมานที่ถูกพร็อกซีไปยังเพียร์
    • 0x05 ROUTE_REQUEST: ค้นหาโมเดลที่เพียร์โฮสต์อยู่
    • 0x06 PEER_DOWN: แจ้งเตือนว่าเพียร์ขาดการเชื่อมต่อ
    • 0x07 PEER_LEAVING: แจ้งการปิดระบบตามปกติ
    • 0x08 PLUGIN_CHANNEL: ปลั๊กอิน RPC
    • 0x0e DIRECT_PATH_REQUEST: แชร์ที่อยู่โดยตรงสำหรับ NAT traversal
  • การเชื่อมต่อเดียวสามารถจัดการ gossip, inference, การค้นหาเส้นทาง และเหตุการณ์วงจรชีวิตของเพียร์ได้ โดยใช้ ไบต์นำหน้า เพื่อ demultiplex แต่ละ stream

แยกชั้นขนส่งที่ปลอดภัยออกจากการควบคุมเมช

  • iroh มอบ secure transport layer ระหว่างเครื่องต่าง ๆ
  • Mesh LLM สร้าง gossip layer ของตัวเองบนชั้นดังกล่าว เพื่อควบคุมนโยบายต่อไปนี้ได้โดยตรง
    • จะอนุญาตให้ใครเข้าร่วมเมชได้บ้าง
    • เวอร์ชันใดที่เข้ากันได้
    • จะเชื่อถือเพียร์ใดบ้าง

การติดตั้งและการรองรับในอนาคต

  • สามารถติดตั้งซอฟต์แวร์ขนาดเบาประมาณ 18MB เพื่อเข้าร่วมเมชสาธารณะหรือจัดตั้งดีพลอยแบบส่วนตัวได้
  • ระบบถูกเปิดให้ใช้งานกับ OpenAI client มาตรฐานผ่าน endpoint localhost:9337/v1
  • มีแผนพัฒนาแอปมือถือด้วย iroh Swift SDK และเตรียมรองรับมาตรฐานเอเจนต์ใหม่อย่าง ACP เพื่อให้ไคลเอนต์อื่นเข้าร่วมเมชได้
  • โครงการนี้มุ่งเพิ่มการใช้งาน P2P และลดการพึ่งพาเซิร์ฟเวอร์แบบปิดและการผูกติดกับระบบใดระบบหนึ่ง
  • สามารถดูโครงการได้ที่ ซอร์สโค้ด และ เว็บไซต์ Mesh LLM

ไลบรารีเครือข่าย iroh

  • iroh เป็น ไลบรารีเครือข่ายโอเพนซอร์ส สำหรับการเชื่อมต่อระหว่างอุปกรณ์ โดยสามารถนำโปรโตคอลที่เตรียมไว้มาใช้ร่วมกัน หรือสร้างโปรโตคอลแบบกำหนดเองบน abstraction การสื่อสารที่เรียบง่ายได้
  • ปัจจุบันถูกใช้งานแล้วบนอุปกรณ์ระดับหลายแสนเครื่องในสภาพแวดล้อม production
  • มี เอกสาร, ซอร์สโค้ด และ ช่อง Discord ให้ใช้งาน

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

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

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

  • พอเห็นอุปกรณ์ GPU, โน้ตบุ๊ก, เซิร์ฟเวอร์, คลาวด์โหนด ฯลฯ ในภาพแรก ก็ยิ่งรู้สึกชัดเลยว่า ทรัพยากรประมวลผลที่ฉันมีมันน้อยแค่ไหน ไม่มีทั้งโน้ตบุ๊ก 24GB VRAM หรือเวิร์กสเตชัน 96GB และถึงจะระดมเกมมิ่งพีซีของเพื่อนมารัน LLM ทั้งหมด ก็คงยังสู้ VRAM รวมในภาพไม่ได้
    ในบทความยังพูดถึง เครือข่าย mesh สาธารณะ ด้วย แต่ฉันหาข้อมูลรายละเอียดไม่เจอ

  • สิ่งที่สะดุดตาคือ ข้อมูลด้านประสิทธิภาพมีน้อย ฉันคาดว่ามันน่าจะช้ากว่าวิธีรันโมเดลขนาดใหญ่แบบอื่นมาก โดยเฉพาะเมื่อรวม RAM ของระบบหรือการสตรีมจากดิสก์เข้าไปด้วย เครือข่ายสำหรับผู้ใช้ทั่วไป แม้แต่ 10Gbps Ethernet ก็ยังช้ามากเมื่อเทียบกับ RAM หรือดิสก์ในเครื่อง เลยสงสัยว่าโมเดลที่ถูกแบ่งส่วนนี้จะทำได้แค่ 1 token ต่อวินาทีหรือน้อยกว่านั้นหรือเปล่า
    แต่พอดูรายการโมเดลก็เห็นว่า Qwen 235B A22B ถูกระบุว่าเป็น “MoE 235B/22B ที่ยืนยันแล้วว่าได้ 16 tok/s บน 2 โหนด” แม้จะไม่ได้เปิดเผยสเปกของโหนดหรือการเชื่อมต่อเครือข่าย แต่ก็ถือว่าเร็วพอสมควร และถึงจะยังไม่ถึงระดับที่สบายสำหรับการโต้ตอบแบบเรียลไทม์ ก็ใกล้เคียงมากแล้ว

    • มันไม่ได้จำเป็นต้องช้ากว่าเสมอไป และน่าจะมีหลายคอนฟิกที่ตรงกันข้ามด้วย ถ้าออฟโหลดน้ำหนักโมเดลไปไว้ใน RAM หรือ NVMe ทุกโทเค็นจะต้องย้ายน้ำหนักขนาดมหาศาลจากสตอเรจที่ช้าไปยัง GPU ระหว่างประมวลผลแต่ละเลเยอร์ ทำให้คอขวดอยู่ที่แบนด์วิดท์ DRAM หรือความเร็วอ่านดิสก์
      แต่ใน การกระจายข้ามหลายเครื่อง น้ำหนักโมเดลยังคงอยู่ใน VRAM ของแต่ละเครื่อง จึงใช้ประโยชน์จากแบนด์วิดท์หน่วยความจำ GPU ที่เร็วกว่ามากได้ ข้อมูลผลลัพธ์ของเลเยอร์ที่ส่งข้ามอุปกรณ์มีขนาดแค่ระดับกิโลไบต์ ไม่ใช่น้ำหนักระดับกิกะไบต์ ดังนั้นอัตรารับส่งข้อมูลเครือข่ายจึงไม่ใช่คอขวด
      ข้อจำกัดจริงคือ latency ของเครือข่าย ถ้าแบ่งโมเดลออกเป็น 4 อุปกรณ์ ก็จะเกิด latency เครือข่าย 3 ครั้งต่อโทเค็น และถ้า latency อยู่ที่ 1ms ก็จะเพิ่ม 3ms ต่อโทเค็น แม้สมมติว่าเวลาคำนวณเป็นศูนย์ ความเร็วสูงสุดตามทฤษฎีโดยไม่มี speculative decoding ก็จะอยู่ที่ราว 30 tok/s
      บนอินเทอร์เน็ต latency น่าจะสูงเกินไปจนไม่ค่อยใช้งานได้จริง แต่ในเครือข่ายภายในหรือเครือข่ายองค์กร ถ้าใช้ speculative decoding ก็น่าจะทำได้สบาย ส่วนช่วง prefill หรือการประมวลผล prompt นั้น latency จะไม่สะสม จึงแทบจะแน่นอนว่าการกระจายหลายเครื่องจะเร็วกว่า
    • ฉันลองวัดโดยจำลอง latency 5ms และ jitter ระหว่างเครื่องในโฮมแล็บของตัวเอง การรันแบบแบ่งส่วนยังทำงานได้ค่อนข้างดีในระดับ WAN ภายในเขตมหานคร แต่ถ้าเป็น WAN ทั่วโลกก็ไม่ค่อยเร็วเท่าไร
      เป้าหมายคือรวมหลายเครื่องที่ไม่มี dedicated RDMA หรือ NVLink fabric เข้าด้วยกัน เพื่อให้ใช้ฮาร์ดแวร์ที่ตัวเองมีในการให้บริการโมเดลขนาดใหญ่และแชร์กับคนอื่น ตอนนี้กำลังทำงานเพื่อรัน GLM 5.2 ที่ประมาณ 10 tok/s บนคอนฟิกแบบแบ่งส่วนลักษณะเดียวกัน
    • ประสิทธิภาพพอจะประเมินคร่าว ๆ ได้ค่อนข้างง่าย ใน autoregressive decoding ต้องส่งข้อมูลผ่านเครือข่ายประมาณ 2 × hidden_size × num_shards ไบต์ต่อโทเค็น และใน prefill ก็แค่หารค่านี้ด้วยขนาดชังก์
    • ตอนรัน Qwen3.6-35B-A3B บน Framework 13 ที่ใช้ AMD Ryzen AI 9 HX 370 ฉันได้ความเร็วใกล้เคียงกัน ถ้ารุ่นที่ใหญ่กว่ามากยังได้ความเร็วเท่านี้ก็น่าประทับใจ

  • ฉันสนใจ distributed inference ของโมเดลภาษาขนาดเล็ก ที่ทำมาเฉพาะงานมากกว่า LLM สำหรับเขียนโค้ด ถ้านำไปใช้กับงานประมวลผลภาพ, software-defined radio (SDR), การสังเกตสภาพอากาศในพื้นที่ ฯลฯ ก็น่าจะรันได้บนเครื่องสเปกธรรมดาและยังให้ผลลัพธ์ที่เชื่อถือได้

    • แทนที่จะมีโมเดลเดียวที่มีผู้เชี่ยวชาญที่ถูกเปิดใช้งาน X ตัว ฉันว่าการเอา โมเดลขนาดเล็กแบบ dense ที่แตกต่างกัน 10 ตัว ซึ่งฝึกด้วยข้อมูลเฉพาะทาง ไปวางบนเซิร์ฟเวอร์ 10 เครื่องแล้วเชื่อมด้วยเราเตอร์ตัวเดียว ดูจะเหมาะกว่า

  • ฉันเป็นผู้มีส่วนร่วมใน Mesh LLM และเป็นคนสร้าง เอนจิน skippy ที่ทำให้แบ่งโมเดลขนาดใหญ่ข้ามหลายโหนดได้ ถ้ามีคำถามก็ยินดีตอบ

    • ดีใจที่ได้เห็นเทคโนโลยีสาย IPFS กลับมาอีกครั้ง มีสองเรื่องที่สงสัย
      หนึ่ง เมื่อกระจายการคำนวณแบบนี้ ผู้เข้าร่วมทุกคนใน computation graph จะรู้ลำดับข้อมูลที่กำลังประมวลผล แล้วจัดการเรื่อง ความเป็นส่วนตัว อย่างไร? สอง มีมาตรการป้องกันไม่ให้ผู้เข้าร่วมที่เป็นอันตรายทำให้ activation ของโมเดลปนเปื้อนหรือไม่?
    • ฉันสงสัยว่า แรงจูงใจในการเข้าร่วม public mesh คืออะไร ถ้าฉันให้ VRAM 1/8 ของที่จำเป็นต่อการรันโมเดลหนึ่งตัว อย่างน้อยจะได้รับสิทธิ์ใช้งาน inference 1/16 แบบรับประกันความยุติธรรมหรือไม่?
    • ถ้ารวมเข้ากับ โปรเจ็กต์ Colibri ที่เพิ่งเปิดตัวเมื่อไม่กี่วันก่อน จะมีข้อดีอะไรไหม?
    • ฉันไม่เคยลงลึกกับการทำ KV cache มากนัก เลยสงสัยว่ามันใช้งานแคชที่แทบจะเป็นอิสระต่อกันในแต่ละเลเยอร์หรือเปล่า
      ถ้าใช่ มันก็น่าจะแบ่งส่วนได้อย่างสวยงามทั้งในแง่ปริมาณงานคำนวณและขนาดข้อมูล และสิ่งที่ช้าลงก็คงมีแค่เวลาที่แต่ละเลเยอร์ต้องรอคิว ถ้าทำเป็น pipeline ก็น่าจะรันหลายคำขอพร้อมกันได้ด้วย
      เคยมีกรณีที่ใช้ pipeline แบบ N-stage โดยป้อนคำขอให้เหลื่อมกันทีละขั้น เพื่อทำ best-of-N บ้างไหม?
    • ฉันดูแลแล็บวิจัยที่มีทั้งโปรเซสเซอร์ EPYC และโมเดลหลายแบบต่างกันไป และรู้สึกประทับใจที่สามารถรวมทุกอย่างเข้าด้วยกันแบบนี้ได้

  • ตอนตามหา LLM ที่ใช้แนวทาง distributed computing คล้ายกัน ฉันไปเจอ AI Horde, ความพยายามขนาดเล็กฝั่ง Aphrodite และการเทรนแบบกระจายของ Nous Research
    ในบรรดานี้ AI Horde น่าจะใหญ่ที่สุด API ของมันใช้รูปแบบ text completion ของ KoboldCPP แทนที่จะเป็น chat completion ดูเหมือนชุมชนจะชอบแนวทางนี้มาก เพราะเปิดให้ปรับพารามิเตอร์ได้เยอะกว่า ทำให้ได้ผลลัพธ์ที่ดีกว่าสำหรับ roleplay ส่วนการใช้งานอื่น ๆ ส่วนใหญ่ก็น่าจะต้องใช้การเรียกเครื่องมือ เลยยังไม่ค่อยแน่ใจว่าจะเอาไปใช้กับอะไรนอกจาก roleplay
    สัปดาห์นี้ฉันเริ่มปรับปรุง OpenAI bridge ให้รองรับ chat template และการ parse คำตอบแล้ว ถ้าปล่อยอย่างเป็นทางการได้สำเร็จ ต่อให้ต้องใช้โมเดล roleplay ก็น่าจะเอาไปใช้เขียนโค้ดได้
    เรื่อง มาตรการป้องกันการใช้ในทางที่ผิด ก็ทำไว้ค่อนข้างแน่น เพื่อกันการโจมตีแบบจัดตั้ง ผู้ปฏิบัติงานจะต้องสะสม uptime ให้ครบ 1 สัปดาห์ก่อนถึงจะถูกนับว่าเชื่อถือได้ และผู้ใช้สามารถเลือกใช้เฉพาะ worker ที่เชื่อถือได้เท่านั้น ถ้ารัน worker ก็จะได้ kudos ซึ่งใช้กับการสร้างข้อความที่ยาวเกิน 512 โทเค็นได้ ส่วนคำขอฟรีจะถูกดันไปอยู่ท้ายคิวเสมอ

  • ฉันสงสัยว่า botnet แบบพหุสัณฐาน ที่รัน distributed LLM ตั้งแต่หนึ่งตัวขึ้นไปจะทำอะไรได้บ้าง แนวคิดคือใช้โฮสต์ทั้งหมดใน botnet เป็นทรัพยากรคลัสเตอร์เพื่อรัน LLM แล้วปล่อยให้วิธีแพร่กระจายและ payload ของแต่ละคลัสเตอร์วิวัฒน์ไป
    สายพันธุ์ที่แย่จะถูกตรวจจับและกำจัด ส่วนวิธีแพร่กระจายที่ไม่มีประสิทธิภาพก็จะไม่แพร่ แต่เวอร์ชันที่ดีที่สุดจะอยู่รอดและเติบโตต่อไป โครงสร้างนี้คล้ายกับสิ่งที่นำเสนอที่นี่มาก และ QUIC มีความไดนามิกสูงมากจนบางทีอาจตรวจจับได้ยากกว่าที่คิด

  • โปรเจ็กต์ https://query.mt/ ใช้ mesh ที่สร้างบน iroh มาสักพักแล้ว ถ้าอยากลองใช้โมเดลแบบ mesh บนมือถือก็น่าลองดู

  • ฉันพยายามรัน mesh-llm อยู่พักหนึ่ง แต่ไม่มีบิลด์ llama.cpp แบบติดตั้งได้ตัวไหนเลยที่ทำงานกับ GPU รุ่นเก่าของฉันได้ ดูเหมือนจะสามารถพร็อกซีไปยังบริการ llama.cpp ภายนอกได้ แต่ฉันก็ตั้งค่านั้นไม่สำเร็จเหมือนกัน
    เป็นโปรเจ็กต์ที่น่าสนใจมาก แต่ยังมี ส่วนที่ยังไม่ขัดเกลา อยู่พอสมควร

    • ถ้าส่งรายงานบั๊กมา ฉันยินดีช่วยไล่แก้จนทำงานได้

  • ฉันเคยคิดว่าวิธีนี้น่าจะเป็นไปได้ เลยถาม ChatGPT เมื่อประมาณ 1 ปีก่อน แต่ได้คำตอบว่า latency สูงเกินไปจนเป็นไปไม่ได้ ตอนนั้นฉันกำลังเรียนรู้ libp2p มาเกือบปีและมองหาโปรเจ็กต์ที่จะเอามันไปใช้