- lm.rs เป็นโปรเจกต์สำหรับรันการอนุมานโมเดลภาษาบนเครื่องแบบโลคัลบน CPU ด้วย Rust โดยมุ่งเป็นการใช้งานโค้ดขนาดเล็กที่ทำการอนุมานทั้งหมดโดยไม่ใช้ไลบรารี ML
- ได้แรงบันดาลใจจาก llama2.c และ llm.c ของ Karpathy ช่วงแรกสนับสนุนเฉพาะ Google Gemma 2 แต่ภายหลังขยายไปถึงการรองรับ Llama 3.2 และอินพุตรูปภาพของ PHI-3.5
- การเปลี่ยนแปลงล่าสุดมีการใช้งาน batch processing ทำให้ความเร็วในการเข้ารหัสภาพเพิ่มขึ้นสูงสุดประมาณ 3 เท่า และ Llama 3.2 1B รันได้ที่ 50 tok/s บนเครื่อง 16 คอร์ของผู้เขียน
- โมเดลที่เตรียมไว้สามารถดาวน์โหลดได้จาก Hugging Face โดย README แนะนำให้ใช้ Q8_0 และระบุว่าการ quantization แบบ Q4_0 ยังอยู่ระหว่างปรับปรุง
- ผู้ใช้สามารถดาวน์โหลดโมเดลรูปแบบ LMRS และ tokenizer มาบิลด์ได้ทันที หรือแปลงไฟล์โมเดลต้นฉบับจาก Hugging Face ด้วย export.py และ tokenizer.py เพื่อรันได้
เป้าหมายของ lm.rs
- lm.rs เป็น implementation สำหรับการอนุมานโมเดลภาษาแบบโลคัลบน CPU ที่เขียนด้วย Rust
- เป้าหมายคือการใช้งานโค้ดขนาดเล็กที่ทำ การอนุมานทั้งหมด ของโมเดลภาษาบน CPU โดยไม่ใช้ไลบรารี ML
- ได้แรงบันดาลใจจาก llama2.c และ llm.c ของ Karpathy
- README ระบุว่าโค้ดปัจจุบัน “ไม่ได้มินิมัลขนาดนั้น” และบางส่วนยังมีพื้นที่ให้ปรับแต่งและปรับปรุงได้
- โปรเจกต์นี้ยังเป็นโอกาสให้ผู้เขียนได้ลองใช้ Rust เป็นครั้งแรกด้วย
โมเดลที่รองรับและการขยายสู่มัลติโมดัล
- ช่วงแรกสนับสนุนเฉพาะโมเดล Google Gemma 2 แต่ต่อมาเพิ่มการรองรับโมเดล Llama 3.2
- ล่าสุดมีการเพิ่มตัวเลือกการใช้รูปภาพผ่าน PHI-3.5
- รายการรองรับที่เน้นในปัจจุบัน
- รองรับมัลติโมดัลผ่านโมเดล PHI-3.5-vision
- รองรับโมเดลข้อความอย่างเดียว PHI-3.5-mini
- ทรัพยากรที่เกี่ยวข้อง
ประสิทธิภาพและโมเดลที่เตรียมไว้
- ข่าวล่าสุดคือมีการใช้งาน batch processing ทำให้ความเร็วในการเข้ารหัสภาพดีขึ้นสูงสุดประมาณ 3 เท่า
- Llama 3.2 1B รันได้ที่ 50 tok/s บน เครื่อง 16 คอร์ ของผู้เขียน
- สามารถดาวน์โหลดโมเดลและ tokenizer ที่เตรียมไว้ได้จาก Hugging Face
- การวัดความเร็วทำบน AMD Epyc 16 คอร์
- README แนะนำให้ใช้ Q8_0 และระบุว่าการ quantization แบบ Q4_0 ยังอยู่ระหว่างปรับปรุง
-
ตารางโมเดลที่เตรียมไว้
- Gemma 2 2B IT Q4_0: 1.39G, 20 tok/s
- Gemma 2 2B IT Q8_0: 2.66GB, 24 tok/s
- Gemma 2 9B IT Q4_0: 4.91GB, 7 tok/s
- Gemma 2 9B IT Q8_0: 9.53GB, 8 tok/s
- Llama 3.2 1B IT: 4.94GB, 21 tok/s
- Llama 3.2 1B IT Q8_0: 1.27GB, 50 tok/s
- Llama 3.2 3B IT Q4_0: 1.71GB, 17 tok/s
- Llama 3.2 3B IT Q8_0: 3.31GB, 19 tok/s
- PHI 3.5 IT Vision Q8_0: 4.28GB, 17 tok/s
- PHI 3.5 IT Mini Q8_0: 3.94GB, 18 tok/s
ขั้นตอนการแปลงโมเดล
- หากดาวน์โหลดโมเดลที่ quantize แล้วและ tokenizer ที่เตรียมไว้จาก Hugging Face ก็สามารถข้ามขั้นตอนการแปลงได้
- หากต้องการแปลงโมเดลที่ Google หรือ Meta เผยแพร่บน Hugging Face ด้วยตัวเอง ต้องติดตั้ง dependency เพิ่มเติมของ Python
pip install -r requirements.txt
- ใช้ไฟล์ .safetensors และ config.json ที่ดาวน์โหลดจากหน้าโมเดลต้นฉบับ
- สำหรับโมเดลมัลติโมดัลอย่าง PHI3.5 Vision ต้องใช้ไฟล์ CLIP config ด้วย
export.py แปลงน้ำหนัก bfloat16 เป็น รูปแบบ LMRS
python export.py --files [ordered .safetensor files] --config [model config.json] --save-path [name and path to save] --type [model type (GEMMA/LLAMA/PHI)]
- หากต้องการส่งออกเวอร์ชัน quantize ให้ใช้แฟล็ก --quantize และ --quantize-type
- ขนาดโมเดลที่ quantize แบบ int8 อาจลดจากประมาณ 9.8G เหลือประมาณ 2.5G ขึ้นอยู่กับขนาดกลุ่ม
- โมเดลมัลติโมดัลต้องใส่อาร์กิวเมนต์ --vision-config
tokenizer.py แปลงโมเดล tokenizer เป็นรูปแบบ tokenizer ของ LMRS
python tokenizer.py --model-id [huggingface model_id] --tokenizer-type [type of the tokenizer (GEMMA/LLAMA/PHI)]
การบิลด์และการรัน
- โค้ด Rust คอมไพล์ด้วย
cargo และ README ระบุให้ส่งแฟล็ก target-cpu
RUSTFLAGS="-C target-cpu=native" cargo build --release --bin chat
- หากต้องการเปิดใช้ฟีเจอร์มัลติโมดัล ให้เพิ่มอาร์กิวเมนต์ --features multimodal
- การรันพื้นฐานทำโดยระบุไฟล์น้ำหนักโมเดล
./target/release/chat --model [model weights file]
- สามารถใช้อาร์กิวเมนต์เพิ่มเติมอย่าง tokenizer, temperature, top-p, show-metrics ได้
- ตรวจสอบอาร์กิวเมนต์ที่ใช้ได้ด้วย --help
- สำหรับโมเดลมัลติโมดัล ให้ระบุพาธรูปภาพด้วยอาร์กิวเมนต์ --image
- เมื่อใช้ PHI3.5-vision README แนะนำให้ตั้ง temperature เป็น 0
การรันแบ็กเอนด์ WebUI
- หากต้องการรันแบ็กเอนด์สำหรับ WebUI ให้คอมไพล์ด้วยฟีเจอร์ backend
RUSTFLAGS="-C target-cpu=native" cargo build --release --features backend --bin backend
- แบ็กเอนด์มัลติโมดัลให้เปิดใช้ฟีเจอร์ backend-multimodal
- รันแบ็กเอนด์โดยระบุไฟล์น้ำหนักโมเดล
./target/release/backend --model [model weights file]
- สามารถเปลี่ยน IP และพอร์ตได้ด้วย --ip และ --port
- สามารถใช้แฟล็กเพิ่มเติมอย่าง temperature ได้เช่นกัน
- สำหรับความเข้ากันได้กับมัลติโมดัล ให้ใช้แฟล็ก --multimodal
- หลังรันแล้วสามารถเชื่อมต่อผ่านเว็บอินเทอร์เฟซได้
สถานะ TODO และไลเซนส์
- รายการที่เสร็จแล้ว
- เพิ่มวิธี sampling อื่น ๆ
- ในรายการทดสอบโมเดล 9B และ 27B ทดสอบ 9B เสร็จแล้ว ส่วน 27B ระบุว่าน่าจะช้าเกินไป
- ทำ parallelization ให้ลูป multi-head attention
- เพิ่มตัวชี้วัดประสิทธิภาพ
- รองรับ int8, int4 quantization
- รายการที่เหลือ
- ฟีเจอร์สำหรับให้ system prompt
- ไลเซนส์คือ MIT
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ลองรัน
llama3.2-1b-it-q80.lmrsขนาด 1.2GB บน MacBook M2 64GB แล้วรู้สึกว่าค่อนข้างเร็ว และจาก Activity Monitor เห็นว่าใช้ CPU 1000% บน 13 เธรดโคลน
lm.rsไว้ที่/tmpแล้วบิลด์ด้วยRUSTFLAGS="-C target-cpu=native" cargo build --release --bin chatจากนั้นดาวน์โหลดtokenizer.binและllama3.2-1b-it-q80.lmrsจาก Hugging Face แล้วรันด้วย./target/release/chat --model llama3.2-1b-it-q80.lmrs./target/release/chat --model llama3.2-1b-it-q80.lmrs --show-metricsเพื่อดูว่าได้ จำนวนโทเคนต่อวินาที เท่าไรได้ไหมเหลือไว้แค่บางส่วนเพราะเรื่องฟอร์แมต แต่ลักษณะคือเป็นสายคำสุ่มยาว ๆ ต่อเนื่องไปเรื่อย ๆ
บทความเขียนได้ดีมาก และน่าจะนำซอร์สโค้ดบางส่วนไปใช้ในชั้นเรียนเวลาอธิบายว่า Transformer ทำงานจริงอย่างไรได้
โค้ดเป็นรูปธรรมและละเอียดกว่าภาพแสดง attention head มาก อย่างไรก็ตาม ถ้าไลบรารีพิมพ์ออก
stdoutโดยตรง อาจทำให้เอาต์พุตของแอปพลิเคชันประเภทที่ให้ตัวแก้ไขข้อความตรวจสไตล์เสียได้ ดังนั้นน่าจะดีกว่าถ้าเขียนลงบัฟเฟอร์สตริงของอินสแตนซ์ล็อกที่เชื่อมกับอ็อบเจกต์lm.rsอีกอย่าง เห็นส่วนที่ใช้
unsafeใน model reader เพื่อบังคับการจัดแนวข้อมูล เลยสงสัยว่าทำได้โดย ไม่ใช้unsafeแบบไม่ฝืนเกินไปหรือไม่แบบนั้นจะจัดการต่อได้ เช่น แสดงล็อกใน GUI
ทำเครื่องมือ Rust สำหรับโหลดโมเดลและงาน LLM หลายอย่างไว้พอสมควร
มีฟังก์ชันอย่างการเลือกโมเดลควอนไทซ์ที่ใหญ่ที่สุดโดยอัตโนมัติตามหน่วยความจำที่มีอยู่, ดึง tokenizer จาก
gguf, หรือใส่พรอมป์ต์ เป็นต้น ถ้าใช้สิ่งนี้น่าจะตัด dependency ฝั่ง Python บางส่วนออกได้ตอนนี้รองรับ
llama.cppแต่ตัวนี้ก็น่าสนใจมาก สงสัยว่ามีแผนรองรับ grammar constraints ด้วยหรือไม่https://github.com/ShelbyJenkins/llm_client
คำว่า no dependency ในชื่อเรื่องยังไม่ค่อยชัดเจน
ตอนเห็นครั้งแรกคิดว่าอาจหมายถึง
no_stdแต่จริง ๆ แล้วไม่ใช่no_stdและดูเหมือนมี dependency อยู่หลายตัว บางทีอาจหมายถึงเป็น dependency ฝั่ง Rust ทั้งหมดก็ได้ถ้าพูดอย่างโปร่งใส มี dependency พื้นฐานของ Rust อยู่ 5 ตัว โดยในนั้น
chronoกับclapควรจัดการด้วย feature flag สำหรับฟังก์ชันแชต ส่วนอีก 3 ตัวเป็น utility crate เพื่อดึงประสิทธิภาพฮาร์ดแวร์เพิ่มเล็กน้อย ได้แก่rayonสำหรับทำ parallelization ให้ง่ายขึ้น,wideสำหรับช่วย SIMD และmemmap2สำหรับ memory mapping ไฟล์โมเดลrequirements.txtเหมือนต้องใช้ PyTorch และ dependency ของ Python หลายตัว และจุดเดียวบนเพจที่เห็นคำว่า “dependency” ก็อยู่ตรงนั้น จึงทำให้ถ้อยคำในชื่อเรื่องค่อนข้างสับสนตัวโปรเจกต์เองดูเหมือนใช้คำโปรยว่า “Minimal LLM inference in Rust” เฉย ๆ จากประวัติ Git บัญชีที่โพสต์บทความนี้เป็น contributor แต่ไม่น่าจะใช่ผู้เขียนหลัก ถ้าอธิบายได้ว่า zero dependencies หมายถึงอะไรกันแน่ก็น่าจะช่วยได้
น่าเสียดายที่ HN มักลบคำออกจากชื่อเรื่องโดยแทบไม่มีเหตุผลหรือความโปร่งใส
cargoของ Rust ตอนนี้แทบจะเหมือนnpmแล้วหรือเปล่ามี dependency 16 ตัว แล้วจะบอกว่า ไม่มี dependency ได้อย่างไรไม่รู้
เคยทำของคล้าย ๆ กันมาก่อน แต่เมื่อเทียบกับโค้ด C/C++ ที่รันบน CPU แล้ว ประสิทธิภาพยังไม่น่าพอใจ
นั่นก็หมายความว่าตอนนั้นยังไม่รู้วิธีทำให้ Rust เร็วอย่างถูกต้องด้วย ถ้ามี benchmark ของ implementation ต่าง ๆ ใน Rust ก็คงดี
implementation สำหรับ LLM inference อาจกลายเป็น “Hello, world!” แบบใหม่สำหรับโปรแกรมเมอร์สายจริงจังก็ได้
https://github.com/gip/yllama.rs
https://github.com/crabml/crabml
ใช้คำสั่ง SIMD บางส่วนโดยตรง และดูเหมือนประสิทธิภาพจะทำได้ใกล้เคียงกับ
llama.cppแก่นสำคัญน่าจะอยู่ที่ การใช้ SIMD ในการคูณเมทริกซ์แบบควอนไทซ์ และการใช้ลูป busy-wait แทน condition variable ตอนแบ่งงานระหว่างเธรดอย่างไรก็ตาม ไม่มีเวลาทำงานต่อกับการ inference โมเดลแบบควอนไทซ์บน GPU ด้วย Vulkan จึงไม่ได้อัปเดตมาสักพักแล้ว
น่าสนใจที่ใช้ Dioxus อยู่แล้ว และสงสัยว่าในโรดแมปจะมี WASM รวมอยู่ด้วยได้ไหม
หากสามารถรัน LLM เบา ๆ อย่าง RWKV ในเบราว์เซอร์ได้ เบราว์เซอร์ก็อาจเปิดหมวดหมู่ฟีเจอร์ใหม่ ๆ ได้โดยไม่ต้องเรียก SaaS API
https://github.com/maedoc/rwkv.js
ใช้
Rwkv.cppที่คอมไพล์ด้วย Emscripten แต่ส่วน tokenizer ยังแก้ได้ไม่เรียบร้อยนัก ถึงอย่างนั้น 1.6B RWKV6 ก็น่าจะใช้งานได้เพียงพอสำหรับเบราว์เซอร์แบบออฟไลน์อย่างเดียวสำหรับแชตทั่วไปอาจยังความสามารถไม่พอ แต่สำหรับงานอย่าง RAG อาจเพียงพอทีเดียว
dependency จำเป็นอย่าง
rayonและwideรองรับ WASM โดยตรง และถ้าเปลี่ยน typeMmapในtransformer.rsเป็น&[u8]ก็ถอดmemmap2ออกได้อย่างไรก็ตาม RWKV มีโครงสร้างที่แตกต่างไปโดยสิ้นเชิง จึงต้อง implement ใหม่ทั้งหมด และดูมีโอกาสต่ำมากที่จะเข้าไปอยู่ในโรดแมป
สงสัยว่า implementation เหล่านี้ทั้งหมด จำกัดเฉพาะ CPU หรือไม่
กำลังถามว่าถ้ามี GPU ดี ๆ ก็ควรมองหาทางเลือกอื่นใช่ไหม
หากอยากลองใช้เฟรมเวิร์ก Rust ที่รองรับ GPU ก็น่าดู Candle https://github.com/huggingface/candle/tree/main
ถ้าจุดประสงค์คือจะเอาไปรันจริง แม้จะใช้แค่ CPU ก็น่าจะใช้ทางเลือกอื่นคือ
llama.cppดีกว่า โปรเจกต์นี้ใกล้เคียงกับสื่อการเรียนรู้ที่แสดงให้เห็นว่าภายในทำงานอย่างไรเมื่อเอาชั้นความซับซ้อนของ ecosystem ออกไปLLM อาจดูเหมือนเวทมนตร์ในแง่ผลลัพธ์ แต่จากมุมมองโค้ดแล้วค่อนข้างเรียบง่าย
ฝั่ง Rust มี wrapper ของ
llama.cppอย่างllm_clientของฉัน และมีโปรเจกต์ที่ใช้ Candle อย่างmistral.rsกับ Kalosmโปรเจกต์ของฉันก็พยายามจะให้ implementation ของ
mistral.rsด้วย แต่ยังย้ายออกจากllama.cppได้ไม่สมบูรณ์ การ implement ด้วย Rust ล้วนมีข้อดีมาก เช่น ทำให้เวลาติดตั้งเร็วขึ้น ตอนนี้ crate ของฉันยังต้อง clone แล้ว build แม้จะทำ automation บน macOS, Windows, Linux ไว้แล้ว แต่ก็ทำให้เวลา build เพิ่มขึ้นราว 1 นาทีเช่น RTX 3090 มี memory bandwidth เกือบ 1TB/s หากจะให้ทันระดับนี้ ต้องใช้ DDR5 ระดับ proof-of-concept ที่เร็วที่สุดในโลกอย่างน้อย 12 channel
ถ้ามี GPU แยก การใช้ implementation ที่ใช้ประโยชน์จากมันได้ถือเป็นคนละโลกเลย เหตุผลที่ตัวเลข inference ของ LLM บน Apple Silicon น่าประทับใจ ก็เพราะมีสถาปัตยกรรมหน่วยความจำ bandwidth สูงแบบรวม CPU-GPU และเท่าที่จำได้อยู่ที่ประมาณ 400GB/s
แม้แต่ 4090 ก็ไม่ได้มีหน่วยความจำเยอะนักตามมาตรฐาน LLM GPU น่าจะเร็วกว่า แต่มีโอกาสสูงที่จะโหลดโมเดลใหญ่ขึ้นไปไม่ได้
สงสัยว่าสิ่งนี้มีคุณค่าอะไรเมื่อเทียบกับ
llama.cppเจ๋งมาก และยินดีด้วยที่ทำไลบรารี Rust ตัวแรก แต่สำหรับการใช้งาน local แบบจริงจัง การรองรับ Metal/CUDA เป็นสิ่งจำเป็น
อย่างไรก็ตาม แม้ไม่ใช่ผู้เขียนหลัก แต่ในฐานะ contributor กำลังทดลองใช้
wgpuเพื่อให้ได้ GPU acceleration ในระดับหนึ่งอยู่ ผู้เขียนหลักอยากควบคุมความซับซ้อน จึงยังไม่รู้ว่าจะไปได้ไกลแค่ไหนในทางปฏิบัติรู้สึกว่าน่าสนใจและน่าขอบคุณกับ ความกระตือรือร้น ของชุมชน Rust ที่แทบจะอยากเขียนทุกอย่างขึ้นมาใหม่