เจาะลึกภายใน M4 Apple Neural Engine ตอนที่ 1: รีเวิร์สเอนจิเนียริง

 (maderix.substack.com)
4 คะแนน โดย GN⁺ 2026-03-03 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • วิเคราะห์โครงสร้างภายในของ Apple Neural Engine(ANE) โดยตรง และทำวิธี ข้าม CoreML เพื่อเข้าถึงฮาร์ดแวร์โดยตรง
  • ตัดชั้น abstraction ของ CoreML ออก และผ่าน API _ANEClient เพื่อ คอมไพล์·โหลด·รันโมเดลได้โดยตรง
  • วิเคราะห์ MIL(Machine Learning Intermediate Language) และ ฟอร์แมตไบนารี E5 จนยืนยันได้ว่า ANE เป็น เอนจินรันกราฟที่อิงกับ operation primitive แบบคงที่
  • พิสูจน์ความเป็นไปได้ของ การส่งข้อมูลแบบ zero-copy ระหว่าง GPU↔ANE โดยใช้ หน่วยความจำที่แชร์ผ่าน IOSurface
  • งานวิจัยนี้เป็นตอนแรกของซีรีส์ 3 ตอนที่สำรวจ การวัดประสิทธิภาพจริงและความเป็นไปได้ในการเทรนบน M4 ANE และมีความหมายในฐานะ กรณีแรกของการควบคุมฮาร์ดแวร์ปิดของ Apple ได้โดยตรง

แนวทางรีเวิร์สเอนจิเนียริงผ่านความร่วมมือระหว่างมนุษย์–AI

  • งานวิจัยนี้ดำเนินการร่วมกันระหว่างนักวิจัยมนุษย์กับ Claude Opus 4.6 ของ Anthropic
    • มนุษย์กำหนดทิศทางการสำรวจ และ AI ทำการวิเคราะห์ข้อมูลกับเขียนโค้ด
  • เป้าหมายเริ่มต้นจากคำถามว่า “สามารถฝึกโมเดลโดยตรงบน Apple Neural Engine ได้หรือไม่”
  • Apple ไม่เปิดเผย ISA, โครงสร้างภายใน, และอินเทอร์เฟซการเขียนโปรแกรมโดยตรง ของ ANE
    • เข้าถึงได้ผ่าน CoreML เท่านั้น ซึ่งทำให้เข้าใจการทำงานของฮาร์ดแวร์ได้ยาก
  • ด้วยเหตุนี้จึงทำ การไล่ย้อนทั้งซอฟต์แวร์สแตกตั้งแต่ CoreML ไปจนถึงไดรเวอร์เคอร์เนล IOKit และได้มา เส้นทางโค้ดสำหรับควบคุม ANE โดยตรง

โครงสร้างของ Neural Engine

  • ANE ไม่ได้อยู่ในรูปแบบ GPU หรือ CPU แต่เป็น graph execution engine
    • รันกราฟโครงข่ายประสาทที่คอมไพล์แล้วทั้งก้อนเป็นการทำงานเชิงอะตอมหนึ่งครั้ง
  • ANE ของชิป M4 (โค้ดเนม H16G) มี 16 คอร์, ความลึกของ request queue 127 รายการ, การควบคุม DVFS แบบอิสระ, และ ตัดพลังงานเป็น 0mW เมื่อว่างงาน
  • Apple เริ่มนำ ANE แบบ 2 คอร์มาใช้ครั้งแรกใน A11 (2017) ก่อนจะขยายต่อในแต่ละเจเนอเรชัน

จุดต่างจากงานวิจัยก่อนหน้า

  • ข้อมูลสาธารณะที่มีอยู่ก่อนหน้านี้:
    • เอกสารอธิบายการทำงานและการวิเคราะห์ประสิทธิภาพ ANE ของ Matthijs Hollemans
    • ตัวอย่างรีเวิร์สเอนจิเนียริงยุคแรกจาก mdaiter/ane
    • ไดรเวอร์ Linux ที่รีเวิร์สเอนจิเนียริงโดย Asahi Linux
    • โค้ด optimization สำหรับทรานส์ฟอร์เมอร์อย่างเป็นทางการจาก apple/ml-ane-transformers
  • ผลลัพธ์เฉพาะของงานวิจัยนี้:
    • เข้าถึง API _ANEClient ได้โดยตรงโดยไม่ต้องผ่าน CoreML
    • ถอดรหัส เส้นทางคอมไพล์ MIL ในหน่วยความจำ
    • วัด throughput จริงหลัง ตัดโอเวอร์เฮดของ CoreML ออก
    • รันการเทรนโมเดลบนฮาร์ดแวร์ที่ออกแบบมาสำหรับ inference เท่านั้น

ระเบียบวิธีวิเคราะห์

  • การสำรวจคลาส: ใช้คำสั่ง dyld_info -objc เพื่อดึงรายการคลาสภายใน AppleNeuralEngine.framework
  • method swizzling: ดักการเรียกของ CoreML เพื่อดูเส้นทางการเรียกไปยังเฟรมเวิร์กภายใน
  • การวิเคราะห์ไบนารี: ถอดรหัส E5 bundle ที่คอมไพล์แล้วเพื่อทำความเข้าใจฟอร์แมตโปรแกรม
  • การวิเคราะห์การสเกล: เปลี่ยนขนาดเมทริกซ์ ความลึกของกราฟ และจำนวนแชนเนล เพื่ออนุมาน topology ของฮาร์ดแวร์
  • ผลลัพธ์คือพบ คลาสภายในมากกว่า 40 รายการ เช่น _ANEClient, _ANEModel, _ANERequest, _ANEIOSurfaceObject, _ANEInMemoryModel

ข้าม CoreML: เข้าถึง _ANEClient โดยตรง

  • ผ่าน _ANEClient สามารถควบคุมไปป์ไลน์ทั้งหมดของ คอมไพล์ → โหลด → evaluate โมเดล ได้โดยตรง
  • CoreML เป็นเพียง ชั้นอำนวยความสะดวก ที่ครอบกระบวนการนี้ไว้
  • ANE รองรับ คำขอ evaluate พร้อมกันได้สูงสุด 127 รายการ (queue depth) เหมาะกับงาน inference แบบสตรีมที่ต้องการ throughput สูง
  • ใช้ I/O buffer ที่อิงกับ IOSurface ทำให้ส่งข้อมูลผ่าน หน่วยความจำที่แชร์ร่วมกันระหว่าง GPU และ ANE ได้

MIL: ภาษาขาเข้าของ ANE

  • CoreML ใช้ MIL(Machine Learning Intermediate Language) แทน ONNX หรือ protobuf
    • อิงกับ static single assignment (SSA) และระบุ type กับ shape อย่างชัดเจน
    • ในโค้ดตัวอย่าง มีการแสดง operation matmul อย่างชัดเจน
  • layout ของเทนเซอร์อยู่ในรูปแบบ NCDHW + Interleave เป็นโครงสร้าง [Batch, Channels, Depth, Height, Width]

ฟอร์แมตไบนารี E5

  • โปรแกรม MIL จะถูกคอมไพล์เป็น ไบนารี E5 แบบ FlatBuffer
    • เมทริกซ์คูณ 1024×1024: 2,688 ไบต์, เมทริกซ์คูณ 128×128: 2,680 ไบต์
    • ขนาดโค้ดแทบไม่ต่างกัน → มีเพียง ข้อมูลคอนฟิกแบบ parameterized ไม่ใช่อัลกอริทึมการคูณเมทริกซ์
  • สิ่งนี้บ่งชี้ว่า ANE รันกราฟโดยผสม operation primitive แบบคงที่ เช่น Conv, MatMul, Elementwise เป็นต้น

เส้นทางคอมไพล์ในหน่วยความจำ

  • ใช้ _ANEInMemoryModelDescriptor เพื่อ คอมไพล์ MIL ในหน่วยความจำได้โดยไม่ต้องเข้าถึงดิสก์
  • ปัญหาหลักและวิธีแก้:
    • milText ต้องเป็น NSData (ไบต์ UTF-8) ไม่ใช่ NSString
    • weights ต้องอยู่ในรูป ดิกชันนารี mapping ระหว่างชื่อกับข้อมูล
    • ภายในยังต้องเข้าถึงไดเรกทอรีชั่วคราว → จำเป็นต้องมีสิทธิ์เขียน
  • พบการสะกดผิดคำว่า Desctiptor ในโค้ดภายในของ Apple

โปรไฟล์ฮาร์ดแวร์

  • จาก การวิเคราะห์ IOKit พบว่า ANE มีช่องทาง จัดการพลังงานและสัญญาณนาฬิกา (DVFS) แยกอิสระ
    • มีทริกเกอร์ทั้งฮาร์ดแวร์และซอฟต์แวร์หลายแบบ เช่น ANE_ADCLK_TRIG, ANE_PPT_TRIG
  • ใน ANECompiler.framework พบว่าในบรรดา operation ที่รองรับ Conv เป็น operation primitive หลัก
    • ตอนที่ 2 จะยืนยันว่าเมื่อแปลง 1×1 Conv เป็น MatMul จะได้ ประสิทธิภาพเพิ่มขึ้น 3 เท่า

โปรโตคอล IOSurface

  • ข้อมูลเข้าออกทั้งหมดทำผ่าน อ็อบเจ็กต์หน่วยความจำแชร์ของ IOSurface
    • เป็นกลไกเดียวกับการแชร์ GPU texture
    • มีความเป็นไปได้ในการสร้าง ไปป์ไลน์ GPU↔ANE แบบ zero-copy

โครงสร้าง compile cache

  • คอมไพเลอร์ของ ANE จะ แคชไบนารี E5 ลงดิสก์
    • พาธ: ~/Library/Caches/.../com.apple.e5rt.e5bundlecache/.../H16G.bundle/
    • การคอมไพล์ครั้งแรกใช้ 20–40ms และถ้าแคชถูกใช้จะรันทันที
    • เป็นประโยชน์กับ inference แต่ การเทรนต้องคอมไพล์ใหม่เมื่อมีการเปลี่ยนน้ำหนัก

พื้นที่ที่ยังไม่ได้สำรวจ

  • คลาสที่ยังไม่ได้วิเคราะห์:
    • _ANEChainingRequest — อาจเชื่อมหลายโมเดลเข้าด้วยกันในการ dispatch ครั้งเดียว
    • _ANESharedEvents, _ANESharedSignalEvent, _ANESharedWaitEvent — fence/signal สำหรับซิงก์ GPU↔ANE
    • _ANEPerformanceStats — อาจเกี่ยวข้องกับ hardware performance counter
    • _ANEVirtualClient — อาจใช้สำหรับการเข้าถึงแบบ virtualization หลายโปรเซส
  • สิ่งที่ยังไม่ยืนยัน:
    • microarchitecture และ ISA ของคอร์ ANE
    • วิธีจัดสรรคอร์ให้กับ operation ภายในกราฟ
    • ความถี่สัญญาณนาฬิกาและโครงสร้าง SRAM

แผนถัดไป

  • Part 2: การสเกลของเมทริกซ์คูณ, คอขวดของ SRAM, การเปรียบเทียบประสิทธิภาพ Conv กับ MatMul, และการตรวจสอบตัวเลข “38 TOPS” ของ Apple
  • Part 3: เทรนโครงข่ายประสาทบน ANE
  • โค้ดทั้งหมดเปิดเผยไว้ในไดเรกทอรี ane/ ของ github.com/maderix/ANE
  • สภาพแวดล้อมทดสอบ: M4 Mac Mini, macOS 15.x

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

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

 
GN⁺ 2026-03-03
ความคิดเห็นจาก Hacker News
  • ฉันเคยทำงานในทีม Xcode มาหลายปี รู้ดีว่า Apple มีวิธี ทำให้เรื่องพวกนี้ยากโดยตั้งใจ อย่างไร
    คิดว่าผู้เขียนทำงานได้ยอดเยี่ยมมาก และกำลังรออ่านตอนที่ 3 อยู่
    • เมื่อก่อน Xcode console เคย แยกออกเป็นหน้าต่างต่างหาก ได้ แต่สงสัยว่าทำไมฟีเจอร์นั้นถึงถูกถอดออก
  • ฉันไม่เข้าใจว่า Neural Engine จะทำงานเมื่อไรในซอฟต์แวร์โอเพนซอร์ส
    ปกติฉันใช้ไลบรารี Python ML อย่าง lightgbm, sklearn, xgboost และ numpy เป็นหลัก
    เลยสงสัยว่าการคำนวณพวกนี้ถูกเร่งความเร็วบนฮาร์ดแวร์ของ Apple หรือไม่ และมีวิธี benchmark แบบง่าย ๆ ไหม
    benchmark ส่วนใหญ่ไปอยู่ระดับฟังก์ชัน C เลยไม่แน่ใจว่ามันมีผลกับไลบรารีระดับสูงหรือเปล่า
    ขำตรงที่ ChatGPT บอกให้เปรียบเทียบ Intel Mac กับ Apple Silicon นี่คงเป็นเหตุผลว่าทำไมคนยังเกลียด AI อยู่
    • ในโอเพนซอร์สส่วนใหญ่ แทบไม่มีการใช้ NPU
      เพราะ NPU ถูกออกแบบมาเฉพาะตามผู้ผลิต ทำให้นักพัฒนาโอเพนซอร์สรองรับได้ยาก
      Apple ANE ก็ไม่ใช่ข้อยกเว้น และงานวิจัยครั้งนี้ก็ดูเหมือนเป็นความพยายามแก้ปัญหานั้นเฉพาะกับ Apple ANE
  • ตอนที่ 2 มี benchmark รวมอยู่ด้วย
    ตามบทความ Inside the M4 Apple Neural Engine บอกว่ามันทำได้ 6.6 FLOPS/W และเมื่อไม่ใช้งานก็ปิดสนิทจนกินไฟ 0W
    • แต่ตัวเลข 38 TOPS ที่ Apple อ้างนั้นไม่ตรงกับความจริง
      Apple คำนวณ “38 TOPS INT8” จาก FP16 19 TFLOPS × 2 แต่ฮาร์ดแวร์จริงไม่ได้รันงาน INT8 ได้เร็วเป็นสองเท่า
      การคำนวณแบบนี้ให้ความรู้สึกเหมือนเป็น การกล่าวเกินจริง ซึ่งดูไม่ค่อยเป็น Apple เท่าไร
  • ในบทความบอกว่า “เรา” หมายถึงการทำงานร่วมกันของ maderix(คน) กับ Claude Opus 4.6(Anthropic) แต่พูดตรง ๆ ว่าเชื่อได้ยาก
    LLM สามารถสร้าง ข้อมูลเท็จที่ดูน่าเชื่อมาก จนแม้แต่ผู้เชี่ยวชาญก็อาจหลงเชื่อ
    เลยสงสัยว่าข้อเท็จจริงทั้งหมดได้รับการตรวจสอบด้วยมือจริงหรือไม่ ในแง่นี้ก็ยังดีที่เขาเตือนล่วงหน้า ทำให้ไม่ต้องอ่านก็ได้
    • Claude มีแนวโน้มจะซ่อน benchmark เพื่อให้ผู้ใช้ เห็นแต่ผลลัพธ์ที่ดูดี
      ในบทความนี้ก็เห็น benchmark แปลก ๆ แบบนั้นอยู่
    • มนุษย์เองก็เขียน งานวิจัยเทียมที่ดูน่าเชื่อ มานานแล้ว
      ต่อให้ก่อนยุค LLM ในวงวิชาการก็มีทั้งงานที่ถูกบิดเบือนและงานที่ทำซ้ำไม่ได้อยู่มาก
      สุดท้ายแล้วการวิเคราะห์แบบนี้จะน่าเชื่อถือได้ก็ต่อเมื่อมีวิศวกรมากขึ้นมาตรวจสอบ
  • ฉันก็พลาดแบบนี้เหมือนกัน แต่ดูเหมือนคอมเมนต์ส่วนใหญ่จะไหลไปเป็น “อะไรก็ได้ที่เกี่ยวกับ Apple”
    มีหลายเรื่องที่ไม่เกี่ยวกับหัวข้อเลย
  • น่าแปลกใจที่ ซอร์สโค้ดของ ANE แม้แต่ทีม MLX ก็ยังเข้าถึงไม่ได้
    อาจเป็นหนึ่งในเหตุผลที่ Awni ซึ่งเป็นหัวหน้าโครงการ MLX ออกจาก Apple ก็ได้
  • ข้อมูลพื้นฐานของ ANE บน M1/M2 นั้นเป็นที่รู้กันอยู่แล้วผ่าน เอกสาร Asahi Linux
    แต่บทความนี้ดีตรงที่ยืนยันและขยายรายละเอียดเหล่านั้นให้ลึกขึ้น
    เมื่อบอกว่า CoreML แทบไม่มี overhead กับงาน matmul ขนาดใหญ่ ก็แปลว่ายังมีโอกาสให้เฟรมเวิร์ก AI แบบรันในเครื่องใช้ ANE สำหรับงาน prefill ได้มาก
    เพียงแต่ขั้น decode ถูกจำกัดด้วย memory bandwidth และกระบวนการแปลง matmul เป็น 1x1 convolution ก็ไม่มีประสิทธิภาพ จึงยังไม่ใช่ข้อได้เปรียบที่ชัดเจน
  • ตามข่าวล่าสุด Apple กำลังเตรียม เฟรมเวิร์กใหม่ที่จะมาแทน Core ML
    มันชื่อว่า Core AI และว่ากันว่าจะช่วยให้รวม LLM ของบุคคลที่สามเข้ากับแอปได้ง่ายขึ้น
    บทความที่เกี่ยวข้อง: Bloomberg newsletter
  • บทความนี้เห็นชัดว่าเป็นคนเขียน แต่บางประโยคก็มี สำนวนแบบฉบับของ LLM โผล่มา
    ถึงอย่างนั้นก็ยังอ่านได้อย่างมีประโยชน์และน่าสนใจมาก
    Github repository ที่กล่าวถึงในบทความก็ควรดูประกอบด้วย
    • อีกประมาณปีหนึ่งข้างหน้า คนคงโต้ตอบกับ LLM ทุกวันจนเกิด ปรากฏการณ์ที่สำนวนของ AI ซึมเข้าไปในภาษามนุษย์
    • ถ้าดูส่วน ‘Prior Art’ จะเห็นกริยาซ้ำซ้อนที่ ไม่จำเป็น อย่าง “documenting”, “providing insight into” อยู่มาก
      ส่วนนี้เป็นร่องรอยว่า AI เขียนอย่างชัดเจน
  • ปัจจุบันของวิศวกรซอฟต์แวร์ก็คืออนาคตอยู่แล้ว
    สิ่งสำคัญยิ่งกว่าการรีเวิร์สเอนจิเนียร์ ANE คือ Manjeet ขยายขีดความสามารถทางวิศวกรรมของตัวเองได้มากแค่ไหนด้วยความช่วยเหลือของ AI
    ตอนนี้คือยุคที่ AI กำลังเร่งผลิตภาพของนักพัฒนาโดยตรง