ต้นทุนเซิร์ฟเวอร์ที่บอตดูดข้อมูลผลักให้เว็บสาธารณะจ่าย

คำถามว่าใครจ่ายค่าคอมพิวต์ให้ AI มักถูกตอบด้วยตัวเลขของบริษัทที่ซื้อชิปและสร้างดาต้าเซ็นเตอร์ แต่มีต้นทุนอีกก้อนที่ไม่เคยปรากฏในงบของใครเลย คือค่าเซิร์ฟเวอร์ของเว็บสาธารณะที่ถูกไล่เก็บข้อมูล บันทึกของผู้ดูแลระบบ kernel.org เมื่อ 29 สิงหาคม 2026 เป็นหนึ่งในไม่กี่ชิ้นที่ให้ตัวเลขจากเครื่องจริง (people.kernel.org)

ตัวเลขจากเครื่องจริง

ประโยคที่เป็นแกนของบันทึกคือ "we spend more CPU cycles rendering commits for scrapers than we spend on all other kinds of legitimate access, including git clones" (people.kernel.org)

ขอบเขตที่เขาพูดถึงคือ git.kernel.org ซึ่งเป็นหน้าเว็บสำหรับดูประวัติการแก้โค้ด ไม่ใช่ทุกบริการภายใต้ kernel.org บริการนี้รับคำขอขอดูคอมมิตแบบสุ่มราว 6 ล้านครั้งต่อวัน (LWN)

ภาระที่ลงไปถึงเครื่องคือจากทั้งหมด 90 คอร์บนเครื่อง 5 แห่งที่กระจายตามภูมิภาค มี 14 ถึง 16 คอร์ที่ไม่ได้ทำอะไรเลยนอกจากสร้างหน้าคอมมิตให้บอต โดยผู้เขียนสรุปเองว่าคิดเป็นราว 20 เปอร์เซ็นต์ของกำลังทั้งหมด (people.kernel.org)

ส่วนด่านกันบอตแบบให้แก้โจทย์คำนวณก่อนเข้าเว็บที่ชื่อ Anubis นั้น สกัดคำขอได้ทันที 66 เปอร์เซ็นต์ แต่อีก 33 เปอร์เซ็นต์แก้โจทย์ผ่านด่านเข้ามาได้แล้ว (LWN)

จุดที่ห้ามเล่าเกินกว่าที่หลักฐานรองรับ

ผู้เขียนระบุตัวผู้ที่ส่งบอตมาไม่ได้ และไม่ได้เอ่ยชื่อบริษัทใดเลยในบันทึก เขาเล่าเองว่าเมื่อก่อนบอตยังบอกชื่อตัวเองมาในคำขอ แต่ตอนนี้ปลอมเป็นเบราว์เซอร์ธรรมดาและกระจายผ่านไอพีบ้านเรือนกับมือถือนับล้าน (people.kernel.org)

ส่วนที่ว่าข้อมูลถูกเก็บไปฝึกโมเดลภาษา เป็นการอนุมานแรงจูงใจของผู้เขียนเอง โดยเขาให้เหตุผลว่าประวัติการแก้โค้ดเป็นข้อมูลที่การันตีได้ว่าเขียนโดยคน ไม่ใช่ข้อความที่โมเดลผลิตออกมา จึงมีค่าสูงสำหรับการฝึก แต่นี่ไม่ใช่การพิสูจน์ตัวตนว่าใครเป็นผู้เก็บ

ตัวเลขที่ว่าคำขอจากผู้ใช้จริงเหลือราว 2 เปอร์เซ็นต์ของทราฟฟิก ผู้เขียนกำกับไว้เองในประโยคเดียวกันว่าตั้งอยู่บนสมมติฐานที่ใจกว้างหลายข้อ

ตัวเลขทั้งหมดเป็นภาพ ณ วันที่ 29 สิงหาคม 2026 ของระบบที่กำลังปรับด่านกันบอตอยู่ตลอด และตัวบันทึกเองเล่าว่าบอตปรับตัวหนีมาตลอดหลายรอบ จึงไม่ควรอ่านเป็นสภาพปัจจุบันแบบถาวร

เรื่องที่คนเข้าใจผิดบ่อย

บันทึกนี้เป็นบล็อกส่วนตัวบนแพลตฟอร์มที่ kernel.org เปิดให้นักพัฒนาเขียน ไม่ใช่ประกาศทางการขององค์กร แต่ผู้เขียนคือคนที่ดูแลโครงสร้างพื้นฐานนั้นเอง ตัวเลขจึงเป็นข้อมูลจากผู้ปฏิบัติงานโดยตรง ไม่ใช่การประเมินจากคนนอก

ตัวเลข 66 กับ 33 รวมกันได้ 99 ไม่ใช่ 100 เพราะเป็นการปัดเลขของผู้เขียน ไม่ใช่ว่ามีอีก 1 เปอร์เซ็นต์ที่เป็นหมวดสาม

ทำไมเรื่องนี้ไม่ใช่ปัญหาเฉพาะของโครงการโอเพนซอร์ส

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

Simon Willison ซึ่งหยิบบันทึกนี้ไปเขียนต่อเมื่อ 7 กันยายน 2026 ไม่ได้เพิ่มตัวเลขใหม่ใดๆ แต่ระบุว่ากังวลเรื่องเดียวกันในฐานะคนดูแลเครื่องมือที่เสิร์ฟหน้าเว็บจำนวนมากเช่นกัน (simonwillison.net)

สิ่งที่ทำได้ตั้งแต่วันนี้

เปิดบันทึกการเข้าเว็บของตัวเองแล้วดูสัดส่วนคำขอที่ไม่ใช่คน โดยดูที่หน้าซึ่งสร้างจากฐานข้อมูลเป็นหลัก การกันด้วยไฟล์ระบุกติกาสำหรับบอตอย่างเดียวไม่พอแล้วเมื่อบอตปลอมตัวเป็นเบราว์เซอร์ทั่วไป ส่วนการทำหน้าที่หนักให้เป็นไฟล์นิ่งที่สร้างไว้ล่วงหน้าแทนการสร้างสดทุกครั้ง เป็นวิธีลดต้นทุนที่ได้ผลโดยไม่ต้องบล็อกใคร

ดูเพิ่ม cloudflare-kitesurf-2026 สำหรับฝั่งเครื่องมือที่ผู้ให้บริการโครงสร้างพื้นฐานทำมาแก้ปัญหาเดียวกัน และ perplexity-amazon-cfaa-2026 สำหรับข้อพิพาททางกฎหมายที่เกิดจากรากเดียวกัน