ข้อผิดพลาดที่พบมากที่สุดกับการโฮสต์ agent คือการกำหนดขนาดสำหรับ agent ตัวเดียว บางคนรัน agent ตัวเดียว เห็นมันใช้ 400 MB และสรุปว่า agent โฮสต์ราคาถูก จากนั้นขยายไปสู่กลุ่มจริงและเครื่องเริ่ม swap ตอนตีสาม
agent ตัวเดียวราคาถูกจริง นั่นไม่ใช่กรณีที่น่าสนใจ
หน่วยความจำหายไปไหนจริง ๆ
agent ที่แค่ยิงการเรียก API ไปยังโมเดลนั้นเบา — ส่วนใหญ่รอเครือข่าย รันสักโหลบนแพ็กเกจเล็กแล้วคุณจะไม่สังเกตเลย
RAM หายไปเมื่อ agent ถือสถานะ ประวัติที่โตทุกรอบ working set ที่หลาย agent อ่านและเขียน vector store สำหรับหน่วยความจำระยะยาวในโปรเซสเดียวกัน ทันทีที่สถาปัตยกรรมหยุดเป็น "เรียก API ลืม" และกลายเป็น "จำ ประสานงาน ส่งต่อ" หน่วยความจำคือข้อจำกัด — ไม่ใช่ CPU CrewAI, LangGraph, ลูปแบบ AutoGPT ล้วนมุ่งไปทางนี้เมื่อจริงจังขึ้น เฟรมเวิร์กไม่ได้กิน RAM สถานะต่างหาก เราเจาะตัวเลขไว้ที่นี่
การกำหนดขนาดคร่าว ๆ
- agent เบาผูกกับ API — คุณไม่ต้องมี Pro แพ็กเกจ NAT หรือ dedicated-IP ($3–20) เพียงพอ ข้ามส่วนที่เหลือของหน้านี้
- กลุ่มจริง (5–10 agent) พร้อมหน่วยความจำร่วมบวก vector store ที่มีประโยชน์ — Pro-32 (32 GB) คือจุดที่ลงตัว กองทัพส่วนใหญ่มาลงที่นี่
- กองทัพใหญ่กว่า ประวัติยาวกว่า ดัชนีหน่วยความจำระดับล้าน — Pro-64 (64 GB) นี่คือที่ที่เครื่องเดียวแทนที่สามเครื่องเล็กที่คุณต้องปวดหัวจัดการ
- กองทัพบวกบริการที่อยู่ร่วม หรือ agent บวกการอนุมานในเครื่อง — สูงสุด Pro-80 (80 GB)
เริ่มต่ำกว่าที่คุณคิดว่าต้องการ ดู htop สักวัน ปรับขนาดขึ้นเมื่อเห็น swap เดาสูงเปล่า ๆ แค่เสียเงิน
ทำไมโฮสต์รูปแบบนี้
กองทัพที่จัดเตรียมหรือจัดการเซิร์ฟเวอร์ของตัวเองต้องการ API ที่ขับได้โดยไม่มีมนุษย์ — และมากขึ้นเรื่อย ๆ ที่จะจ่ายโดยไม่มีมนุษย์ด้วย หน่วยความจำสูง, dedicated IP, จ่ายด้วยคริปโต, ไม่ต้อง KYC และทั้งหมดสั่งซื้อได้โดย agent ผ่าน MCP: การผสมนั้นหายาก และเป็นสิ่งที่สาย Pro สร้างขึ้นมาเพื่อสิ่งนี้ มันไม่ใช่ที่ถูกที่สุดต่อกิกะไบต์ และหาก agent ของคุณเบา คุณไม่ต้องการมันจริง ๆ แต่สำหรับระบบจริงจังที่ถือสถานะและให้ค่าความเป็นส่วนตัว มันคือความเหมาะสมที่ถูกต้อง
เมื่อคุณถึงจุดนั้น Pro-32 ครอบคลุมกลุ่มจริง ปรับขนาดขึ้นเป็น 64 หรือ 80 GB เมื่อกองทัพโต
ความคิดเห็น
ยังไม่มีความคิดเห็น เป็นคนแรกสิ