มุมมองของ Anderson
ยอดติดตั้งแพ็กเกจ Python ในฐานะดัชนีการนำ AI มาใช้ภายในเครื่อง

การเพิ่มขึ้นของยอดดาวน์โหลดแพ็กเกจ Python ซึ่งวัดปริมาณได้ยาก บอกเล่าเรื่องการแพร่กระจายของ AI หากรู้ว่าต้องมองจากตรงไหน
ความคิดเห็น ใครก็ตามที่สำรวจศักยภาพของ AI ภายในเครื่องคงเสียพื้นที่ดิสก์ไปในปริมาณน่าตกใจแล้ว ทั้งให้กับโมเดลขนาดมหึมาและระบบ Python ที่เกี่ยวข้อง ตลอดจนระบบคล้ายกันซึ่งประสานการอนุมาน การฝึก และการใช้งานที่เป็นไปได้อีกนับร้อย รวมถึงการสร้างระบบอัตโนมัติภายในเครื่อง
กรณีใช้งานอย่างหลังเป็นสิ่งที่พบมากที่สุดในเครื่องต่างๆ บน LAN ของผม ผมใช้ AI ตั้งกิจวัตรอัตโนมัติแบบ “แบนราบ” ที่เขียนด้วย Python เช่น การสำรองข้อมูล การตรวจสอบเป็นระยะ การดูแลเว็บไซต์ และงานอื่นอีกนับสิบอย่าง
แทบทุกสิ่งที่ผมต้องการทำระหว่างการเขียนโค้ดดูเหมือนต้องใช้ไลบรารี Python ใหม่ จน PIP หรือ Package Installer for Python กลายเป็นหนึ่งในตัวกินพื้นที่รายใหญ่ที่สุดบนเครื่องใน LAN ของผม:

รูปลักษณ์อันเล็กจิ๋วของ PIP ใน CLI และ GUI ไม่สอดคล้องกับผลกระทบต่อระบบไฟล์ แคชอาจมีขนาดใหญ่มากจนทำให้ระบบใช้งานไม่ได้
การทดลอง AI ภายในเครื่องทำให้ความฟุ่มเฟือยแบบเหลือใช้ของคอมพิวเตอร์ส่วนบุคคลก่อนยุคแย่งชิงฮาร์ดแวร์ AI ในปัจจุบันหวนกลับทาง หากมี RAM มาก ก็จะถูกใช้ไปกับการถ่ายงานไปยัง GPU ดิสก์หนึ่งเทราไบต์ก็จะเต็มอย่างรวดเร็วด้วยโมเดลปริมาณมาก ไม่ว่าจะผ่านการควอนไทซ์หรือไม่ และแม้จะติดตั้ง VRAM 24GB เหมือนผม ซึ่งอาจเป็นขั้นต่ำใหม่ ระบบก็ยังต้องใช้ทางลัดและกลเม็ดหลายแบบเพื่อให้อนุมานได้ในระยะเวลาที่สมเหตุสมผล
แพ็กเกจ PyPi หรือ Python Package Index ที่ติดตั้งไว้ไม่ปรากฏในหน้าต่าง “โปรแกรมที่ติดตั้ง” มาตรฐานของระบบปฏิบัติการทั่วไป ต้องเรียกดูโดยตรงผ่าน Python เช่นคำสั่ง PowerShell pip freeze --all
รายการอาจยาวจนน่าประหลาดใจ:
| แพ็กเกจ | เวอร์ชัน | แพ็กเกจ | เวอร์ชัน | แพ็กเกจ | เวอร์ชัน |
|---|---|---|---|---|---|
| absl-py | 2.3.0 | Jinja2 | 3.1.4 | pip | 25.1.1 |
| attrs | 25.3.0 | jsonpatch | 1.33 | platformdirs | 4.3.8 |
| beets | 2.5.1 | jsonpointer | 3.0.0 | protobuf | 4.25.8 |
| certifi | 2025.11.12 | kiwisolver | 1.4.8 | psutil | 7.2.1 |
| cffi | 1.17.1 | lap | 0.5.12 | pybrisque | 1.0 |
| charset-normalizer | 3.4.4 | lazy_loader | 0.4 | pycparser | 2.22 |
| click | 8.2.1 | libsvm | 3.23.0.4 | pyparsing | 3.2.3 |
| colorama | 0.4.6 | Markdown | 3.8.2 | python-dateutil | 2.9.0.post0 |
| confuse | 2.1.0 | MarkupSafe | 2.1.5 | PyYAML | 6.0.2 |
| contourpy | 1.3.2 | matplotlib | 3.10.3 | pyyaml_env_tag | 1.1 |
| cycler | 0.12.1 | mediafile | 0.13.0 | requests | 2.32.5 |
| dlib | 20.0.0 | mediapipe | 0.10.21 | scikit-image | 0.25.2 |
| face-recognition | 1.3.0 | mergedeep | 1.3.4 | scipy | 1.16.0 |
| face_recognition_models | 0.3.0 | mkdocs | 1.6.1 | sentencepiece | 0.2.0 |
| filelock | 3.13.1 | mkdocs-get-deps | 0.2.0 | setuptools | 65.5.0 |
| filetype | 1.2.0 | ml_dtypes | 0.5.1 | six | 1.17.0 |
| flatbuffers | 25.2.10 | mpmath | 1.3.0 | sounddevice | 0.5.2 |
| fonttools | 4.58.4 | musicbrainzngs | 0.7.1 | sympy | 1.13.1 |
| fsspec | 2024.6.1 | mutagen | 1.47.0 | tifffile | 2025.6.11 |
| ghp-import | 2.1.0 | networkx | 3.3 | torch | 2.5.1+cu118 |
| idna | 3.11 | numpy | 2.1.2 | torchvision | 0.20.1+cu118 |
| image-quality | 1.2.7 | opencv-contrib-python | 4.11.0.86 | tqdm | 4.67.1 |
| imageio | 2.37.0 | opencv-python | 4.11.0.86 | typing_extensions | 4.12.2 |
| internetarchive | 5.7.1 | opt_einsum | 3.4.0 | Unidecode | 1.4.0 |
| jax | 0.6.2 | packaging | 25.0 | urllib3 | 2.6.2 |
| jaxlib | 0.6.2 | pathspec | 0.12.1 | watchdog | 6.0.0 |
| jellyfish | 1.2.1 | pillow | 11.0.0 |
รายการติดตั้ง PyPi จากหนึ่งในเครื่องที่ผมใช้งานหนัก คำสั้นๆ บางคำซ่อนพื้นที่ดิสก์หลายกิกะไบต์ไว้ โดยเฉพาะสิ่งที่เกี่ยวข้องกับ Torch/PyTorch
กล่าวโดยย่อ AI ภายในเครื่องอาจพาประสบการณ์ใช้คอมพิวเตอร์ย้อนกลับไปต้นทศวรรษ 1990 เลยจากช่วงที่โปรแกรมอย่าง Word ต้องโหลดลง RAM ไม่กี่กิโลไบต์จากฟลอปปีดิสก์ขนาดใหญ่ทีละแผ่นมาเล็กน้อย แต่ยังไม่ถึงยุคที่พื้นที่ฮาร์ดดิสก์ทำให้หายใจได้สะดวก
ค้นหากระแสที่ซ่อนอยู่
ผมสงสัยว่าการพุ่งขึ้นของการติดตั้ง PyPi ในช่วงไม่กี่ปีที่ผ่านมาใช้เป็นดัชนีการนำ AI ภายในเครื่องมาใช้ได้หรือไม่ เพราะโดยทั่วไปเรื่องนี้ติดตามได้ยาก นอกจากอาศัยสัญชาตญาณจากการเข้าร่วมชุมชน AI ต่างๆ และสังเกตว่าแพลตฟอร์มกับแพ็กเกจใดได้รับความสนใจ
การมองเว็บไซต์สถิติ PyPi แบบคร่าวๆ พบช่วงวันที่ที่แคบอย่างน่าผิดหวัง แต่ทุกช่วงที่มีล้วนแสดงการเติบโตของยอดดาวน์โหลดอย่างต่อเนื่อง:

ยอดดาวน์โหลดรวมของแพ็กเกจ Python เพิ่มขึ้นตั้งแต่ต้นปี 2026 แม้ช่วงวันที่ที่มีให้ดูจะแคบมาก แหล่งที่มา
คงดีมากหากขยายช่วงวันที่กลับไปถึงปี 2020 เพื่อดูว่าการเพิ่มขึ้นคงที่หรือพุ่งชันกว่าเดิมในปี 2024-2026 อย่างที่อาจคาด โดยเฉพาะจากการกระทำโดยไม่มีผู้กำกับของระบบ Agentic AI
น่าเสียดายที่แหล่งข้อมูลทางการของ PyPi ระบุว่าไม่เปิดเผยสถิติการดาวน์โหลด PyPi ด้วยเหตุผลหลายประการ เช่น ภาระจากแคช CDN จำนวนดาวน์โหลดคลาดเคลื่อนเพราะแคชและมิเรอร์ การเพิ่มยอดดาวน์โหลดอย่างไม่เป็นทางการ คุณภาพข้อมูลในอดีต และตามที่เว็บไซต์ Python ระบุ สถิติเหล่านี้มีประโยชน์จำกัดในการวัดคุณภาพแพ็กเกจ
อย่าเพิ่งรีบสรุป
อย่างไรก็ตาม PyPi เปิดองค์ประกอบที่จำเป็นให้ผู้อื่นวิเคราะห์แนวโน้มการดาวน์โหลด จึงมีเว็บไซต์หลายแห่งที่ดูข้อมูลได้นานกว่าหนึ่งเดือน เช่น PepySite แต่ส่วนใหญ่ใช้ระบบสมาชิก และต้องจ่ายเพื่อดูแนวโน้มกับสถิติระยะยาว โดยกรณีหนึ่งคิดสูงถึง 490 ดอลลาร์ต่อเดือนสำหรับแพ็กเกจ “VC”
แล้วเราพอจะเรียนรู้อะไรเกี่ยวกับ Python ในฐานะดัชนีการเร่งตัวของ AI ได้บ้าง หากไม่ใช้ API ราคาแพงซึ่งจัดแนวโน้มเหล่านี้ให้ผู้ที่มีกำลังจ่าย
แม้ PyPiStats จะเป็นทรัพยากร FOSS แต่ด้วยเหตุผลบางอย่างกลับให้ดูสถิติเฉพาะเดือนล่าสุด และไม่สามารถขยายช่วงได้แม้ยินดีจ่ายเงิน
โชคดีที่มีเว็บไซต์หนึ่งใจกว้างกว่า ที่ ClickPy อย่างน้อยผู้ใช้ค้นหาประวัติการนำแต่ละแพ็กเกจมาใช้ได้ แม้เว็บไซต์จะไม่ได้รวมผลเหล่านั้นเป็นภาพรวมที่ดึงแนวโน้มกว้างๆ ร่วมกันออกมาได้ง่าย ตัวอย่างต่อไปนี้คือเส้นทางของไลบรารี Transformers ตั้งแต่ปี 2016 แม้ข้อมูลจะใช้ได้จริงตั้งแต่เปิดตัวในปี 2019:

การเติบโตอย่างรวดเร็วของ Transformers แหล่งที่มา
แล้ว Torch รุ่นเก๋าซึ่งเปิดตัวครั้งแรกในปี 2002 ล่ะ มันยังไม่ถึงคราวสร้างความปวดหัวให้ผู้ชื่นชอบ AI ที่ประกอบระบบเอง จนกระทั่งพัฒนาเป็น PyTorch และเกิดการเติบโตของ VLM ที่ใช้ Transformer รวมถึง Generative AI สำหรับภาพกับวิดีโอ

ยอดดาวน์โหลด Torch ตั้งแต่ปี 2017 ซึ่งเพิ่มขึ้นอย่างชันในช่วงสองถึงสามปีล่าสุด

PyTorch ในช่วงเดียวกัน ซึ่งทรงตัวก่อนพุ่งขึ้นเป็นระยะจากฐานที่คงที่
สิ่งที่น่าสนใจยิ่งกว่าในกรณี PyTorch ดังภาพด้านบน คือภาพรวมการนำไปใช้ใน Python หลากหลายเวอร์ชันตั้งแต่ปี 2017:

ยอดดาวน์โหลด PyTorch ตามเวอร์ชัน Python ตั้งแต่ปี 2017 ให้มุมมองเพิ่มเติมต่อการนำไปใช้ตั้งแต่ยุค “ร้อนแรง” ของการปฏิวัติ AI ครั้งที่สาม
หากสถิติข้างต้นสะท้อนการนำไปใช้อย่างพุ่งสูงนับจาก LLM และ VLM ที่มีความสามารถจริงถือกำเนิด ภาพนี้จะชัดยิ่งขึ้นเมื่อแยกตามระบบ:

การนำ PyTorch มาใช้ตั้งแต่ปี 2017 จำแนกตามระบบปฏิบัติการ
เรื่องราวคล้ายกันเกิดกับแพ็กเกจ accelerate ซึ่งเป็นหนึ่งในไลบรารีที่ผู้ใช้ AI ซึ่งมี VRAM จำกัดต้องใช้มากที่สุด เพื่อรีดประสิทธิภาพจากข้อจำกัดของระบบให้ได้มากที่สุด:

การเติบโตของ “accelerate” จำแนกตามระบบปฏิบัติการ
รูปแบบนี้เกิดขึ้นกับแพ็กเกจหรือไลบรารีจำนวนมากที่ค้นใน ClickPy และคงน่าสนใจมากหากสร้างภาพรวมขึ้นมาแทนการค้นทีละชิ้น
สิ่งหนึ่งที่เห็นชัดจากกราฟ “ตามระบบปฏิบัติการ” คือการนำ Linux มาใช้เพิ่มขึ้น แม้การใช้ Linux บนเดสก์ท็อปจะเพิ่มขึ้นอย่างช้าๆ แต่ต่อเนื่องท่ามกลางกลยุทธ์ Windows ที่ไม่ได้รับความนิยม แต่การใช้สภาพแวดล้อม Linux กำลังเพิ่มขึ้นอย่างมีนัยสำคัญอย่างชัดเจน
ตัวอย่างเช่น ผมรัน Ubuntu แบบเสมือนบน WSL2 ใน Windows สำหรับคอนเทนเนอร์ Docker หลายชุด ทำให้ Docker ใช้ระบบ Linux จริงได้ตามเงื่อนไขที่นักพัฒนา ซึ่งน่าจะใช้ Linux โดยตรง วางไว้ นั่นเท่ากับมีระบบ Linux ที่ทำงานอยู่สองระบบใน LAN ที่เป็น Windows ทั้งหมดเมื่อมองจากฮาร์ดแวร์จริง และยังมีแล็ปท็อป Linux เครื่องจริงที่ถอดปลั๊กรอเวลาสบายกว่านี้อยู่ข้างๆ
บทสรุป
เมื่อพิจารณาการดาวน์โหลดแพ็กเกจผ่าน CLI น่าสนใจที่ได้เห็นว่าพื้นที่ซึ่งมีความเป็นสายเทคนิคสูงมากนี้คึกคักและได้รับการติดตามเพียงใดหลังการมาถึงของ AI
การใช้แพ็กเกจที่เพิ่มขึ้นเริ่มก่อความเสี่ยงด้านความปลอดภัยในขั้นปลายจากการเกิด slopsquatting เนื่องจาก LLM มีแนวโน้มสร้างชื่อแพ็กเกจที่ไม่มีอยู่จริง จึงอาจส่งคำขอแพ็กเกจที่แต่งขึ้นจริงๆ และเพราะโมเดลหลายระบบอาจบรรจบไปที่ชื่อคล้ายกัน แพ็กเกจปลอมจึงมีโอกาสปรากฏซ้ำในการเรียกไลบรารีอื่น จนคุ้มค่าสำหรับผู้ไม่หวังดีที่จะสร้างแพ็กเกจปลอมให้ดาวน์โหลดได้จริงสำหรับการดึงหรือเรียกใช้ในอนาคต พร้อมเพย์โหลดประสงค์ร้าย:

จากงานวิจัย “We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs” การสร้างโค้ดด้วย AI กำลังขยายพื้นผิวโจมตีซัพพลายเชน LLM มักสร้างชื่อแพ็กเกจที่ไม่มีอยู่จริง ทำให้เกิดช่องโหว่ “slopsquatting” ซึ่งผู้ไม่หวังดีใช้ประโยชน์เมื่อไปป์ไลน์อัตโนมัติดึง dependency ที่ไม่ได้ตรวจสอบโดยไม่ไตร่ตรอง แหล่งที่มา
เผยแพร่ครั้งแรกวันศุกร์ที่ 24 กรกฎาคม 2026












