ในโลกของการพัฒนา AI ที่เปลี่ยนแปลงอย่างรวดเร็ว การทดลองล่าสุดได้จุดประกายการอภิปรายอย่างร้อนแรงเกี่ยวกับความสามารถและข้อจำกัดของผู้ช่วยการเขียนโค้ด AI เมื่อต้องเผชิญกับความท้าทายด้านความเข้ากันได้ของฮาร์ดแวร์ในโลกจริง เมื่อนักพัฒนา Simon Willison มอบหมายให้ Claude Code รัน DeepSeek-OCR บนอุปกรณ์ NVIDIA Spark ชุมชนได้เฝ้าดูด้วยความสนใจขณะที่ AI เดินทางผ่านหนึ่งในปัญหายอดนิยมที่ยังคงเกิดขึ้นในแมชชีนเลิร์นนิง: ความเข้ากันได้ของ PyTorch และ CUDA บนสถาปัตยกรรมที่ไม่เป็นมาตรฐาน
การทดลองนี้เผยให้เห็นทั้งความสามารถในการแก้ปัญหาที่น่าประทับใจของผู้ช่วย AI สมัยใหม่ และความท้าทายที่กำลังดำเนินอยู่ซึ่งนักพัฒนาต้องเผชิญเมื่อทำงานกับฮาร์ดแวร์ล้ำสมัย ดังที่ผู้แสดงความคิดเห็นหนึ่งระบุ นี่แสดงถึงการเปลี่ยนแปลงในวิธีที่นักพัฒนาเข้าหางานติดตั้งและกำหนดค่าที่ซับซ้อน
ความท้าทายความเข้ากันได้ของสถาปัตยกรรม ARM
อุปสรรคทางเทคนิคหลักเกิดขึ้นเมื่อ Claude Code ค้นพบว่า GPU GB10 ของ NVIDIA Spark ต้องการความสามารถในการคำนวณ CUDA sm_121 ในขณะที่ PyTorch 2.5.1 ที่ติดตั้งไว้ล่วงหน้า รองรับได้เพียงสูงถึง sm_90a เท่านั้น ช่องว่างความเข้ากันได้นี้เป็นความ frustrate ทั่วไปสำหรับนักพัฒนาที่ทำงานกับระบบที่ใช้ ARM ซึ่งแพ็คเกจที่สร้างไว้ล่วงหน้าอาจตามหลังความสามารถของฮาร์ดแวร์อยู่เสมอ ความพยายามครั้งแรกของ AI ล้มเหลวด้วยข้อความแสดงข้อผิดพลาดที่คุ้นเคย: CUDA error: no kernel image is available for execution on the device
ประสบการณ์นี้สะท้อนอย่างลึกซึ้งกับชุมชนนักพัฒนา ดังที่ผู้แสดงความคิดเห็นหนึ่งแบ่งปัน ฉันเพิ่งติดตั้ง unsloth บนกล่อง Thor เสร็จสำหรับการ finetuning บางอย่าง มันเหมือนกับการวิ่งมาราธอนที่ยาวนาน การดิ้นรนหา PyTorch builds ที่เหมาะสมสำหรับอุปกรณ์ ARM ของ NVIDIA ดูเหมือนจะเป็นปัญหาที่แพร่หลาย โดยนักพัฒนาแสดงความประหลาดใจที่ NVIDIA ไม่ได้ให้ pre-builds ที่ได้รับการสนับสนุนดีกว่าสำหรับฮาร์ดแวร์ของตัวเอง
มีคนที่ไม่ถูกขวางไม่ให้ทำงานโดยรอคอยข้อมูลจากภายนอกเพื่อให้งานเช่นนี้สำเร็จ ซึ่งฉันคิดว่านั่นคือการเปรียบเทียบที่ตั้งใจไว้ มีระดับของสัญชาตญาณที่นักพัฒนารุ่นจูเนียร์และ LLMs ไม่มี แต่ที่นักพัฒนารุ่น senior มี
ปัญหาความเข้าได้กันของ PyTorch บน NVIDIA Spark
| ส่วนประกอบ | ความต้องการ | การรองรับที่มีอยู่ | ปัญหา |
|---|---|---|---|
| ความสามารถในการคำนวณของ GPU | sm_121 (GB10 GPU) | sm_90a (PyTorch 2.5.1) | ไม่มี kernel image ที่ใช้งานได้ |
| แนวทางแก้ไข | PyTorch 2.9.0 | CUDA 12.8/12.9/13.0 ARM64 wheels | เข้ากันได้บางส่วนพร้อมคำเตือน |
วิธีแก้: การตามล่าหา Wheels ที่หายาก
ความก้าวหน้าครั้งสำคัญเกิดขึ้นเมื่อ Willison กระตุ้นให้ Claude ค้นหาเวอร์ชัน PyTorch อื่นที่มี ARM CUDA wheels AI ค้นพบว่า PyTorch 2.9.0 มี ARM64 wheels ที่เข้ากันได้กับ CUDA 12.8, 12.9 และ 13.0 ซึ่งให้ความเข้ากันได้เพียงพอที่จะทำให้ GPU GB10 ทำงานได้ แม้จะมีคำเตือนเกี่ยวกับความสามารถสูงสุดที่รองรับ วิธีแก้ปัญหานี้ แม้จะมีประสิทธิภาพ แต่ก็เน้นย้ำถึงการตรวจสอบด้วยตนเองที่ยังคงจำเป็นสำหรับงานดังกล่าว
การตอบสนองของชุมชนต่อวิธีแก้ปัญหานี้แตกต่างกัน บางคนมองว่ามันเป็นการสาธิตการแก้ปัญหาของ AI ที่น่าประทับใจ ในขณะที่บางคนตั้งคำถามว่าการหา wheel ที่สร้างไว้ล่วงหน้าที่ใหม่กว่าจะแสดงถึงความสำเร็จทางเทคนิคที่แท้จริงหรือไม่ Compute well spent... finding out to download a version and hardware appropriate wheel ผู้แสดงความคิดเห็นหนึ่งกล่าวอย่างประชดประชัน อย่างไรก็ตาม คนอื่นๆ โต้แย้งว่านักพัฒนาที่เป็นมนุษย์ใช้เวลานับไม่ถ้วนในการแก้ไขปัญหาในทำนองเดียวกัน
กว่าการใช้ Wheels: วิธีการทางเลือกที่เกิดขึ้น
การอภิปรายพัฒนาอย่างรวดเร็วเกินกว่าวิธีแก้ปัญหาเฉพาะหน้าเพื่อพิจารณาปัญหาสถาปัตยกรรมที่กว้างขึ้น ผู้แสดงความคิดเห็นหลายคนแนะนำว่า ONNX (Open Neural Network Exchange) อาจให้วิธีแก้ปัญหาที่สง่างามกว่าสำหรับความท้าทายด้านความเข้ากันได้เหล่านี้ The beauty of it is that the underlying ai accelerator/hardware is completely abstracted away นักพัฒนาคนหนึ่งอธิบาย There's a CoreML ONNX execution provider... No more fighting with hardcoded cuda:0 everywhere
มุมมองนี้เน้นย้ำการเปลี่ยนแปลงที่กำลังดำเนินอยู่ใน ecosystem ของ ML ไปสู่รูปแบบโมเดลที่พกพาได้มากขึ้น ซึ่งสามารถหลีกเลี่ยง dependency hell ที่มักเกี่ยวข้องกับการรวมกันของ PyTorch และ CUDA อย่างไรก็ตาม ดังที่ผู้แสดงความคิดเห็นอีกคนระบุ กระบวนการแปลงจาก PyTorch เป็น ONNX ยังคงต้องการการแทรกแซงด้วยตนเองอยู่บ่อยครั้ง เว้นแต่จะเกี่ยวข้องกับโมเดลที่นิยมมาก
แนวคิดการทำงานร่วมกันระหว่างมนุษย์และ AI
สิ่งที่ทำให้การทดลองนี้น่าสนใจเป็นพิเศษคือวิธีที่มันแสดงให้เห็นถึงความสัมพันธ์ที่กำลังพัฒนาระหว่างสัญชาตญาณของมนุษย์และการดำเนินการของ AI การแทรกแซงที่สำคัญของ Willison — การแนะนำให้ค้นหาเวอร์ชัน PyTorl อื่น ๆ — สาธิตให้เห็นว่าประสบการณ์ของมนุษย์ยังคงจำเป็นสำหรับการชี้นำ AI ผ่านพื้นที่ปัญหาที่ซับซ้อน AI สามารถดำเนินการค้นหาและการติดตั้งได้เมื่อถูกชี้ไปในทิศทางที่ถูกต้อง แต่ต้องการสัญชาตญาณของมนุษย์เพื่อรับรู้ว่า wheels ทางเลือกอาจมีอยู่
พลวัตนี้นำไปสู่การเปรียบเทียบระหว่างผู้ช่วย AI กับนักพัฒนามนุษย์ It's not a junior dev, it's just a dev perpetually in their first week at a new job ผู้แสดงความคิดเห็นหนึ่งสังเกต A pretty skilled one, at that! การอภิปรายเผยให้เห็นว่าในขณะที่ AI สามารถจัดการการดำเนินการและเอกสารได้ดีอย่างน่าทึ่ง การกำกับดูแลของมนุษย์ยังคงสำคัญสำหรับทิศทางเชิงกลยุทธ์และการรับรู้ว่าเมื่อใดที่วิธีการแบบเดิมจำเป็นต้องได้รับการพิจารณาใหม่
การเปรียบเทียบประสิทธิภาพ DeepSeek-OCR Prompt
- Free OCR Prompt: ประมวลผล 24 วินาที ข้อความที่สะอาด 2257 โทเค็น
- Markdown Prompt: ประมวลผล 39 วินาที จัดรูปแบบเป็น markdown พร้อมพิกัดบางส่วน
- Grounding Prompt: ประมวลผล 58 วินาที ข้อความพร้อมพิกัดกรอบขอบเขตแบบเต็ม
- Detailed Prompt: ประมวลผล 1 วินาที คำอธิบายภาพ (<300 โทเค็น)
คำถามเรื่องฮาร์ดแวร์: Spark คุ้มค่ากับความยุ่งยากหรือไม่?
น่าสนใจที่การสนทนาหันไปสู่คำถามว่า NVIDIA Spark เองเป็นเครื่องมือที่เหมาะสมสำหรับการทดลองดังกล่าวหรือไม่ ผู้แสดงความคิดเห็นบางคนแสดงความสงสัยเกี่ยวกับข้อเสนอคุณค่าของอุปกรณ์ For inference might as well get a strix halo for half the price นักพัฒนาคนหนึ่งแนะนำ ในขณะที่อีกคนเตือนว่า it's also going to be unsupported after a few years
การอภิปรายเกี่ยวกับฮาร์ดแวร์นี้เน้นย้ำว่า ecosystem การพัฒนา AI ยังคงสำรวจการแลกเปลี่ยนระหว่างอุปกรณ์ edge ที่เชี่ยวชาญและฮาร์ดแวร์อเนกประสงค์มากขึ้น ความท้าทายด้านความเข้ากันได้ที่ประสบกับ Spark เป็นตัวแทนของความเจ็บปวดจากการเติบโตของอุตสาหกรรมในวงกว้าง ในขณะที่ workloads ของ AI ย้ายออกจากศูนย์ข้อมูลแบบดั้งเดิมไปสู่สภาพแวดล้อมการคำนวณ edge ที่หลากหลาย
การทดลองประสบความสำเร็จในท้ายที่สุด โดย Claude Code ไม่เพียงแต่ทำให้ DeepSeek-OCR ทำงานได้ แต่ยังสร้างเอกสารประกอบอย่างกว้างขวางที่เปรียบเทียบคำสั่ง OCR ต่างๆ และลักษณะการทำงานของพวกมัน กระบวนการทั้งหมดใช้เวลาน้อยกว่า 40 นาที โดยมีการแทรกแซงของมนุษย์น้อยที่สุด สาธิตให้เห็นว่าผู้ช่วยการเขียนโค้ด AI กำลังมีความสามารถมากขึ้นเรื่อยๆ ในการจัดการกับความท้าทายในการพัฒนาของโลกจริง — แม้ว่าบางครั้งพวกเขาอาจต้องการการกระตุ้นเล็กน้อยในทิศทางที่ถูกต้อง
ในขณะที่เครื่องมือเติบโตเต็มที่และ ecosystem พัฒนาวิธีแก้ปัญหาที่ดีขึ้นสำหรับการ abstraction ฮาร์ดแวร์ เราอาจเห็นการดิ้นรนเรื่องความเข้ากันได้เหล่านี้ลดลง แต่สำหรับตอนนี้ การรวมกันของสัญชาตญาณของมนุษย์และการดำเนินการของ AI ดูเหมือนจะเป็นแนวทางที่มีประสิทธิภาพที่สุดสำหรับการเดินทางผ่านภูมิทัศน์ที่ซับซ้อนของการพัฒนา AI สมัยใหม่
อ้างอิง: Getting DeepSeek-OCR working on an NVIDIA Spark via brute force using Claude Code