llama.cpp เริ่มออกเวอร์ชันจริงจังแล้ว — v0.1.0 ถึง v0.1.2 ภายใน 24 ชั่วโมง หลังใช้เลข build มาตลอดหลายปี

ใครที่รันโมเดลบนเครื่องตัวเองน่าจะเคยเจอปัญหานี้: จะบอกเพื่อนร่วมทีมว่าใช้ llama.cpp เวอร์ชันไหน ก็ต้องบอกเป็นเลขแบบ b10485 ซึ่งเป็นเลข build ที่ขยับวันละหลายสิบครั้ง ไม่มีทางรู้จากตัวเลขว่าอันไหนแค่แก้บั๊ก อันไหนเปลี่ยน API จนโค้ดพัง

เมื่อ 17–18 สิงหาคม 2026 สิ่งนั้นเริ่มเปลี่ยน โปรเจกต์ติดแท็ก v0.1.0 (17 ส.ค. 08:52 UTC) และ v0.1.1 (17 ส.ค. 13:14 UTC) ตามด้วย v0.1.2 (18 ส.ค. 08:30 UTC) ซึ่งเป็นตัวแรกที่มี GitHub Release พร้อม changelog ที่สร้างอัตโนมัติ ออกมาให้เห็นจริง ๆ

เกิดอะไรขึ้นในฝั่ง CI

ตัวที่ทำให้ v0.1.2 ต่างจากสองตัวก่อนหน้าคือ PR #27302 ของ ggerganov ที่ถูกเมิร์จเมื่อ 18 ส.ค. 07:14 UTC มันขยายเวิร์กโฟลว์ make-release ให้ทำสามอย่างหลังจากพุชแท็ก:

• สร้าง GitHub Release ผ่าน ggml-org/action-create-release — โดยตอนนี้ตั้งค่าเป็น pre-release ไว้ก่อน พร้อม TODO ในตัว PR ว่าจะถอดธงนี้ออกเมื่อ semantic versioning พร้อมจริง
• เพิ่มสคริปต์ scripts/make-release-desc.sh ที่สร้างคำบรรยายรีลีสเอง ประกอบด้วย เวอร์ชันก่อนหน้า (แท็ก semver สูงสุดที่ต่ำกว่าตัวปัจจุบัน), changelog รายคอมมิตระหว่างสองเวอร์ชัน และ ลิงก์ไปยัง nightly build ที่ตรงกัน
• bump เวอร์ชันเป็น 0.1.2

ตัว release note ของ v0.1.2 จึงหน้าตาเป็นรายการคอมมิตตรงไปตรงมา — sync ggml, bump ggml เป็น 0.20.2, แก้ xcframework/cmake, ปรับ CUDA MMVQ สำหรับ DGX Spark และอื่น ๆ พร้อมโน้ตกำกับไว้ชัดเจนว่า “Semantic versioning is still work in progress” และลิงก์ไปที่ discussion #1579

แผนที่อยู่เบื้องหลัง

discussion นั้น ggerganov เปิดไว้ตั้งแต่ 7 สิงหาคม 2026 ในหัวข้อการทำรีลีสและการกำหนดเวอร์ชันของโปรเจกต์ในเครือ ggml-org สาระสำคัญ:

• ggml ใช้ semantic versioning โดยแท็ก git ตรงกับหมายเลขเวอร์ชัน
• llama.cpp จะมี รีลีสอย่างเป็นทางการแบบ semver ควบคู่ไปกับ nightly build แบบเดิม — ไม่ใช่การเลิก nightly แต่เป็นการเพิ่มชั้นที่นิ่งกว่าให้คนที่ต้องการ (และ nightly ก็ยังเดินอยู่จริง วันนี้ออกถึง b10486)
• เงื่อนไขก่อนติดแท็กคือ สำเนา ggml ภายใน llama.cpp ต้องเหมือนกับ ggml ที่ปล่อยออกไปทุกประการ เพื่อไม่ให้ปลายน้ำเจอความไม่ตรงกัน
• ฝั่งการแจกจ่าย มีการคุยถึงการใช้ find_package() ของ CMake เพื่อระบุเวอร์ชัน ggml ขั้นต่ำ ซึ่งช่วยให้ระบบแพ็กเกจอย่าง Homebrew และ Debian ติดตามความเข้ากันได้ง่ายขึ้น
• ผู้ร่วมสนทนาเสนอเกณฑ์ตามมาตรฐาน: patch สำหรับแก้บั๊ก, minor สำหรับฟีเจอร์ใหม่, major สำหรับการเปลี่ยน API ที่ทำให้พัง — พร้อมข้อกังวลว่าด้วยจังหวะการพัฒนาของโปรเจกต์นี้ เลข minor อาจวิ่งเร็วมาก

มุมมอง AI Curator

ข่าวนี้ดูเป็นเรื่องเล็กและน่าเบื่อเมื่อวางข้าง ๆ ข่าวโมเดลใหม่ แต่สำหรับคนที่เอา llama.cpp ไปอยู่ใน production มันคือหนึ่งในการเปลี่ยนแปลงที่ ลดความเจ็บปวดต่อวันได้มากที่สุด ในรอบปี เพราะปัญหาที่แท้จริงของเลข build ไม่ได้อยู่ที่ความสวยงาม แต่อยู่ที่ว่ามัน ไม่มีความหมายเชิงสัญญา — b10480 กับ b10485 ต่างกันแค่ไหน? ต้องไปไล่อ่าน commit log เอาเอง และเมื่อ Dockerfile ของทีมคุณ pin เลข build ไว้ การอัปเดตทุกครั้งคือการเดา

ผลที่ตามมาที่จับต้องได้มีสามข้อ หนึ่ง — การ pin เวอร์ชันใน Dockerfile และ requirements ของทีมมีความหมายขึ้นทันที สอง — รายงานบั๊กจะคุยกันรู้เรื่องขึ้น เพราะ “เจอบน v0.1.2” สื่อสารได้ดีกว่า “เจอบน build เมื่อวานตอนบ่าย” สาม และอาจสำคัญที่สุดในระยะยาว — ตัวแจกจ่ายอย่าง Homebrew, Debian, Arch และ conda จะแพ็กเกจได้สะดวกขึ้นมาก ซึ่งเป็นเส้นทางที่ทำให้ llama.cpp ไปถึงคนที่ไม่ compile เอง

แต่อย่าเพิ่งตีความเกินจริงในสองเรื่อง เรื่องแรก — เลข 0.x ยังหมายถึงยังไม่รับประกันความเสถียรของ API ตามธรรมเนียม semver และตัวรีลีสเองยังติดธง pre-release อยู่ พร้อม TODO ในโค้ดว่าจะถอดออกทีหลัง เรื่องที่สอง — จังหวะการปล่อยสามเวอร์ชันในเวลาไม่ถึง 24 ชั่วโมงบอกชัดว่านี่คือช่วง ทดสอบท่อ CI ของตัวเอง ไม่ใช่การประกาศว่าเข้าสู่ยุคเสถียรแล้ว ใครที่รอ “เวอร์ชันที่ปลอดภัยจะย้าย” ควรรอให้ธง pre-release หายไปก่อน

สำหรับทีมในไทยที่ผมเห็นเลือกรัน LLM บนเครื่องตัวเองมากขึ้นเรื่อย ๆ ด้วยเหตุผลด้าน PDPA และต้นทุนต่อโทเค็น ประโยชน์ตรงที่สุดคือ การทำ reproducible deployment — เวลาลูกค้าองค์กรถามว่า “ระบบที่ส่งมอบใช้ซอฟต์แวร์เวอร์ชันอะไร” คำตอบที่เป็น v0.1.2 ผ่านการตรวจรับได้ ส่วนคำตอบที่เป็น b10485 มักจะตามมาด้วยคำถามอีกสิบข้อ ข้อเสนอเชิงปฏิบัติสำหรับตอนนี้: ยังใช้ nightly ในเครื่อง dev ได้ตามสบาย แต่เริ่ม pin แท็ก semver ในสภาพแวดล้อม staging และ production ตั้งแต่วันนี้ แล้วเก็บ changelog รายคอมมิตที่ระบบสร้างให้ไว้ใน release note ของทีมเอง

แหล่งข่าว

• llama.cpp v0.1.2 พร้อม changelog อัตโนมัติ — GitHub Releases (18 ส.ค. 2026)
• PR #27302 — ci: create pre-release with change log and nightly link in make-release
• Discussion #1579 — dist: releases and versioning of ggml-org projects