โดย Farruh Kushnazarov

บทสอนใช้งานเพื่อการลงมือทำจริงโดยเปรียบเทียบ Token API, PTU, Model Unit และ Bare Metal GPU สำหรับการอนุมาน LLM ในการใช้งานจริง ตัวเลขจริง การใช้งานจริง
ในบ่ายวันอังคาร ซาราห์ หัวหน้าทีมวิศวกรรมในสตาร์ทอัพฟินเทคแห่งหนึ่งที่เติบโตอย่างรวดเร็ว ได้กระแทกปิดแล็ปท็อปของเธอลงอย่างแรง
ทีมของเธอใช้เวลาสองสัปดาห์ในการผนวก DeepSeek V4-Flash เข้ากับแชทบอทฝ่ายสนับสนุนลูกค้าของพวกเขา โมเดลนี้ทำงานได้อย่างยอดเยี่ยมในระหว่างการทดสอบ ตอบเร็ว ให้เหตุผลเป็นเฉียบคม และอัตราการหลอนอยู่ในระดับต่ำกว่าโมเดลที่พวกเขาได้ลองมาก่อน การสาธิตดำเนินไปอย่างราบรื่น
จากนั้น พวกเขาก็ดูบิลค่าคลาวด์
ในปริมาณการใช้งานในปัจจุบันของพวกเขา พบว่าใช้ไปประมาณ 8 ล้านโทเค็นต่อวัน ค่าใช้จ่ายโทเค็น API ทำให้งบประมาณด้าน AI ของพวกเขาลดลงอย่างมาก และมันก็จะยิ่งแย่ลงไปอีกเมื่อพวกเขาขยายการให้บริการไปยังลูกค้าในจำนวนที่มากขึ้น
ซาร่าห์มีตัวเลือกอยู่สี่อย่าง แต่ประเด็นก็คือ ทุกบล็อกโพสต์ที่เธออ่าน และทุกเอกสารนำเสนอจากผู้ขายที่เธอนั่งฟัง ต่างก็อ้างว่าตัวเลือกของตนนั้น "ดีที่สุด" Token API นั้น "เริ่มต้นใช้งานได้เร็วที่สุด" PTU นั้น "คาดการณ์ได้แม่นยำที่สุด" Model Unit นั้น "ประหยัดต้นทุนที่สุดเมื่อใช้งานในวงกว้าง" และหัวหน้าวิศวกรของเธอก็คอยพูดอยู่เสมอเกี่ยวกับการเช่า GPU และลงมือทำทุกอย่างด้วยตนเอง
ปัญหาคืออะไร ไม่มีใครเคยเปรียบเทียบประสิทธิภาพของทั้งสี่ระบบนี้เทียบกันอย่างจริง ๆ จัง ๆ เมื่อใช้งานบนโมเดลเดียวกัน ในปริมาณงานเดียวกัน และบนระบบคลาวด์เดียวกันมาก่อน
ดังนั้น เราจึงทำมันขึ้นมา
บทความนี้เป็นการอธิบายอย่างละเอียดถึงสิ่งที่เราค้นพบ พร้อมด้วยคำแนะนำในการนำไปใช้งานทีละขั้นตอน ตัวเลขประสิทธิภาพจริง และกรอบการตัดสินใจที่ชัดเจนซึ่งคุณสามารถนำไปใช้กับภาระงานของคุณเองได้
ก่อนที่เราจะเริ่มเขียนโค้ดแม้แต่บรรทัดเดียว คุณต้องเข้าใจโมเดลการนำไปใช้ทั้งสี่แบบที่มีให้บริการบน Alibaba Cloud ก่อน เพราะไม่ใช่แค่แบ่งระดับตามราคาที่แตกต่างกันเท่านั้น แต่ยังเป็นโมเดลวิศวกรรมและเศรษฐกิจที่แตกต่างกันโดยพื้นฐานด้วย

หมายเหตุ: ราคาที่แสดงทั้งหมดเป็นราคาโดยประมาณและนำมาจากแหล่งข้อมูลสาธารณะ ราคาจริงอาจแตกต่างกันไปขึ้นอยู่กับภูมิภาค ข้อกำหนดของสัญญา และข้อเสนอโปรโมชันต่าง ๆ
นี่คือจุดเริ่มตามค่าเริ่มต้น คุณเรียกใช้ชุดเชื่อมต่อ API ส่งพรอมต์ รับข้อความตอบกลับ และชำระเงินสำหรับทุกโทเค็นที่ผ่านเข้าระบบ
PTU คือคำตอบของ Alibaba Cloud สำหรับปัญหาเรื่องความสามารถในการคาดการณ์ แทนที่จะจ่ายเงินต่อโทเค็น คุณซื้อระดับอัตราความเร็วที่กันไว้ล่วงหน้าซึ่งวัดเป็นโทเค็นต่อนาที (TPM)
นี่คือจุดที่เริ่มน่าสนใจ Model Unit ให้บริการคลัสเตอร์ GPU ที่ออกแบบมาสำหรับภาระงานของคุณโดยเฉพาะ ซึ่งได้รับการจัดการอย่างเต็มรูปแบบโดย Alibaba Cloud
ตัวเลือกจิ๋วแต่แจ๋ว คุณเช่าอินสแตนซ์ GPU ดิบ (H20, H200 หรือ B300 ในอนาคตอันใกล้) และติดตั้งสแต็คการอนุมานของคุณเอง
เรามาเริ่มจากตัวเลือกที่ง่ายที่สุดกันก่อน หากคุณไม่เคยใช้บริการ AI ของ Alibaba Cloud มาก่อน นี่คือจุดเริ่มต้นของคุณ

เข้าสู่ระบบคอนโซล Alibaba Cloud และไปที่ Model Studio นี่คือศูนย์รวมโมเดลและเกตเวย์ API สำหรับบริการ AI ทั้งหมดของ Alibaba Cloud
ในแคตตาล็อกโมเดล ให้ค้น DeepSeek V4-Flash คุณจะเห็นมันอยู่ในรายชื่อเดียวกับรุ่นยอดนิยมอื่น ๆ เช่น Qwen3, GLM และ Wan

คลิกที่หน้าโมเดล DeepSeek V4-Flash คุณจะเห็นปุ่ม รับคีย์ API คลิกที่นี่ สร้างคีย์ API ใหม่ แล้วคัดลอกไปยังคลิปบอร์ดของคุณ
เก็บคีย์นี้ไว้อย่างปลอดภัย นี่เป็นโทเค็นการตรวจสอบสิทธิ์ของคุณสำหรับการเรียกใช้ API ทั้งหมด
นี่คือสคริปต์ Python อย่างง่ายเพื่อตรวจสอบว่าทุกอย่างทำงานได้ถูกต้อง:
import requests
API_KEY = "your-api-key-here"
ENDPOINT = "https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions"
headers = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json"
}
payload = {
"model": "deepseek-v4-flash",
"messages": [
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Explain quantum computing in one paragraph."}
],
"max_tokens": 256
}
response = requests.post(ENDPOINT, headers=headers, json=payload)
print(response.json()["choices"][0]["message"]["content"])

รันคำสั่ง หากคุณเห็นย่อหน้าที่สอดคล้องกันเกี่ยวกับคอมพิวเตอร์ควอนตัม ขอแสดงความยินดีด้วย ตอนนี้ คุณกำลังเรียกใช้ DeepSeek V4-Flash ผ่าน Token API แล้ว
การกำหนดราคา API โทเค็นเป็นไปตามโมเดลอย่างง่ายโดยคิดราคาต่อโทเค็น คุณชำระเงินแยกต่างหากสำหรับโทเค็นอินพุตและเอาต์พุต ซึ่งโทเค็นเอาต์พุตโดยทั่วไปจะมีราคาสูงกว่าโทเค็นอินพุตประมาณ 4 เท่า
สำหรับการโต้ตอบแชททั่วไปที่มีพรอมต์อินพุต 2K และการตอบกลับเอาต์พุต 1K ต้นทุนต่อคำขอจึงอยู่ที่ไม่ถึงเซนต์ เมื่อปริมาณการใช้งานต่ำ (เช่น 10,000 คำขอต่อวัน) ค่าใช้จ่ายรายเดือนก็จะอยู่ในระดับที่เหมาะสม แต่ต้นทุนจะเพิ่มขึ้นตามสัดส่วนเส้นตรง และนั่นคือปัญหา
หากเป็นการสร้างโปรโตไทป์ ถือว่าไม่เป็นไร แต่จะเกิดอะไรขึ้นเมื่อมีคำขอถึง 100,000 คำขอต่อวัน หรือ 1 ล้านคำขอ
เราจะขอยกตัวอย่างรูปแบบการขยายขนาด ดังนี้:
| คำขอรายวัน | โทเค็นเฉลี่ยต่อคำขอ | ค่าใช้จ่ายรายเดือนเชิงเปรียบเทียบ |
|---|---|---|
| 10,000 | 3K | 1x (เกณฑ์มาตรฐาน) |
| 50,000 | 3K | ประมาณ 5 เท่า |
| 100,000 | 3K | ประมาณ 10 เท่า |
| 500,000 | 3K | ประมาณ 50 เท่า |

ตัวเลขจะพุ่งขึ้นอย่างรวดเร็ว นี่คือสิ่งที่ซาราห์ได้เห็นในสตาร์ทอัพฟินเทคของเธอจริง ๆ
สมมติว่าปริมาณการใช้งานของคุณไม่ได้เกิดขึ้นแบบสุ่ม คุณมีผลิตภัณฑ์ SaaS ที่มีผู้ใช้งานรายวัน 10,000 ราย และคาดว่าการใช้งานสูงสุดจะอยู่ในช่วงเวลาประมาณ 9 โมงเช้าถึง 6 โมงเย็น คุณทราบว่าคุณต้องการโทเค็นประมาณ 500,000 โทเค็นต่อนาทีในช่วงเวลาที่มีการใช้งานสูงสุด
PTU ออกแบบมาเพื่อสิ่งนี้
แทนที่จะจ่ายต่อโทเค็น คุณจะซื้อ PTU ในระดับที่รับประกันปริมาณงานที่แน่นอน Alibaba Cloud สำรองความจุ GPU สำหรับภาระงานของคุณ ในช่วงเวลาที่มีการใช้งานสูงสุด คำขอของคุณจะส่งตรงไปยังความจุที่คุณสงวนไว้ โดยไม่ผ่านพูลที่ใช้ร่วมกัน
รูปแบบการกำหนดราคามีประกอบด้วยสองส่วน:
หากคุณใช้เกินความจุที่คุณสงวนจองไว้ คำขอที่เกินจำนวนจะเปลี่ยนไปใช้การกำหนดราคาแบบ Token API แทน
PTU จะเริ่มคุ้มค่าทางการเงินเมื่อปริมาณโทเค็นรายวันของคุณสูงพอที่ค่าธรรมเนียมการจองบวกกับอัตราการใช้งานที่ลดลงคุ้มค่ากว่าต้นทุนของ Token API เพียงอย่างเดียวได้ จุดคุ้มทุนขึ้นอยู่กับระดับและอัตราค่าบริการที่ตกลงกันไว้ แต่โดยคร่าว ๆ แล้วจะมีหลักการดังนี้:
สำหรับทีมของซาราห์แล้ว PTU ถือเป็นการก้าวไปอีกขั้นจาก Token API แต่ก็ยังมีเพดานกำหนดไว้ เมื่อพวกเขาใช้เกินระดับที่สงวนไว้ ต้นทุนก็จะพุ่งสูงขึ้นอีกครั้ง และพวกเขาวางแผนที่จะเพิ่มฐานผู้ใช้เป็น 10 เท่าในไตรมาสถัดไป
นี่คือจุดสำคัญที่สุดแล้ว ทีมของซาราห์ต้องการสิ่งที่สามารถขยายขนาดได้ตามการเติบโตของทีมโดยไม่ทำให้พวกเขาล้มละลาย พวกเขาต้องการทรัพยากรที่ออกแบบมาโดยเฉพาะ ประสิทธิภาพที่รับประกันได้ และรูปแบบการกำหนดราคาที่ยิ่งใช้มากเท่าไหร่ ก็ยิ่งถูกลงเท่านั้น
พวกเขาต้องการ Model Unit
นี่คือประเด็นสำคัญที่ทำให้ Model Unit แตกต่างจากสิ่งอื่น ต้นทุนคงที่
คุณชำระค่าธรรมเนียมรายเดือนคงที่ต่อ Model Unit ไม่สำคัญว่าคุณจะประมวลผลโทเค็น 1 ล้านหรือ 1 พันล้านโทเค็น ต้นทุนก็เท่าเดิม
สำหรับ DeepSeek V4-Flash การกำหนดค่าทั่วไปจะใช้ MU1 จำนวน 4 ยูนิตบน GPU ที่ใช้ H20-141G อ้างอิงจากการประมาณการคร่าว ๆ จากแหล่งข้อมูลสาธารณะ:
ลองเปรียบเทียบกับ Token API ในปริมาณที่เท่ากัน หากใช้งานประมาณ 500 ล้านโทเค็นต่อวัน (ซึ่งโดยประมาณเท่ากับที่ MU1 จำนวน 4 ยูนิตสามารถรองรับได้ในขณะที่มีการใช้งานสูงสุด) ต้นทุน Token API จะอยู่ที่ประมาณ:
สรุปได้ว่า: ที่ระดับปริมาณงานสูงอย่างต่อเนื่อง Model Unit สามารถประหยัดค่าใช้จ่ายได้ประมาณ 40-50% เมื่อเทียบกับการใช้จ่าย Token API ในปริมาณที่เท่ากัน และคุณจะได้รับทรัพยากรที่ออกแบบมาโดยเฉพาะพร้อม SLA ที่รับประกันไว้
หมายเหตุ: ตัวเลขเหล่านี้เป็นเพียงค่าประมาณการคร่าว ๆ เพื่อเป็นตัวอย่างเท่านั้น ราคาจริงขึ้นอยู่กับภูมิภาค เงื่อนไขข้อผูกพัน และปริมาณงาน ควรตรวจสอบการกำหนดราคาอย่างเป็นทางการก่อนตัดสินใจจัดซื้อเสมอ
แต่ตัวเลขที่น่าสนใจยิ่งกว่าคือ ต้นทุนที่แท้จริงต่อโทเค็นหนึ่งล้านโทเค็น
ที่การใช้งาน MU1 จำนวน 4 ยูนิตเต็ม 100% (TPM สูงสุดประมาณ 550,000):
แน่นอนว่าไม่มีใครรันเต็มประสิทธิภาพ 100% ตลอด 24 ชั่วโมง เรามาดูเรื่องนี้จากมุมที่เกิดขึ้นจริงมากขึ้น ภาระงานด้านการผลิตส่วนใหญ่จะดำเนินการในช่วงเวลาทำการ ซึ่งอาจอยู่ที่ 8-12 ชั่วโมงต่อวัน โดยที่ภาระงานอาจเปลี่ยนแปลงได้

แผนภูมิข้างต้นแสดงต้นทุนที่แท้จริงต่อหนึ่งล้านโทเค็นในระดับการใช้งานรายวันที่แตกต่างกัน หากใช้งานจริงวันละ 4 ชั่วโมง ต้นทุนที่แท้จริงของคุณยังคงอยู่ในระดับที่แข่งขันได้กับ Token API หากใช้งานมากกว่า 12 ชั่วโมงต่อวัน ค่าใช้จ่ายของ Model Unit จะประหยัดลงอย่างมาก
และนี่คือการเปรียบเทียบต้นทุนรายเดือน:

จุดคุ้มทุนเมื่อเทียบกับ Token API อยู่ที่ประมาณ 2.6 พันล้านโทเค็นต่อวัน ถ้าต่ำกว่านั้น Token API ยังมีราคาถูกกว่า ถ้าสูงกว่านั้น Model Unit ชนะขาด
Model Unit ไม่ได้มีดีแค่ราคา ประเด็นสำคัญคือ คุณทำอะไรได้บ้างด้วยโครงสร้างพื้นฐานที่ออกแบบมาโดยเฉพาะ:
สำหรับแอปพลิเคชันฟินเทคของซาราห์ ประเด็นสุดท้ายเพียงอย่างเดียวก็คุ้มค่ากับการเปลี่ยนแล้ว ข้อมูลทางการเงินไม่สามารถเปิดเผยสู่พูลที่ใช้ร่วมกันได้
ก่อนที่เราจะเริ่มดำเนินการใด ๆ เราควรตระหนักถึงปัญหาสำคัญที่ทุกคนรู้แต่ไม่มีใครพูดถึงเสียก่อน ทำไมไม่เช่า GPU แล้วรันทุกอย่างด้วยตัวเองล่ะ
นับเป็นคำถามที่สมเหตุสมผล และสำหรับบางทีม นี่คือคำตอบที่ถูกต้องอย่างแน่นอน
คุณเช่าอินสแตนซ์ GPU ที่ใช้ H20 หรือ H200 คุณติดตั้ง vLLM หรือ SGLang คุณดาวน์โหลดไฟล์ข้อมูลของ DeepSeek V4-Flash แล้ว คุณกำหนดค่าการประมวลผลแบบขนานของเทนเซอร์ การประมวลผลแบบขนานของไปป์ไลน์ การควอนไทเซชัน และการตั้งค่าแคช KV ได้ คุณตั้งค่าการปรับสมดุลปริมาณงาน การตรวจสอบ การขยายขนาดอัตโนมัติ และการสลับการทำงานเมื่อเกิดข้อผิดพลาด
จากนั้นก็ดูแลรักษาต่อไป
ค่าเช่า GPU ไม่ใช่ต้นทุนที่แท้จริง ต้นทุนที่แท้จริงคือทีม:
แม้ว่าการเช่า GPU จะมีราคาถูกกว่าราคาที่ระบุไว้เล็กน้อยเมื่อเทียบกับ Model Unit แต่ค่าใช้จ่ายเต็มจำนวนของทีม (มักจะเป็น 2-3 เท่าของค่าเช่า GPU เอง) มักจะทำให้ Model Unit เป็นตัวเลือกทางเศรษฐกิจที่ดีกว่าสำหรับการอนุมานการผลิต
จุดที่ Bare Metal ชนะ:
สำหรับทีมของซาราห์แล้ว Bare Metal ถือว่าปัดตกไปได้เลย พวกเขามีหน้าที่ส่งมอบฟีเจอร์ใหม่ ๆ ไม่ใช่มานั่งจัดการคลัสเตอร์ GPU
ตอนนี้ เรามาลงมือทำกันเลยดีกว่า นี่คือการอธิบายการนำไปใช้อย่างละเอียดทีละขั้นตอน

PAI-EAS (Elastic Algorithm Service) คือแพลตฟอร์มการให้บริการโมเดลที่ได้รับการจัดการของ Alibaba Cloud ลองนึกภาพว่ามันคือห้องเครื่องยนต์ที่ซึ่งเป็นแหล่งจัดสรรทรัพยากรสำหรับ Model Unit และเป็นจุดที่โมเดลของคุณให้บริการจริง ๆ
เมื่อคุณซื้อ Model Unit สิ่งที่คุณทำจริง ๆ คือการจองความจุ PAI-EAS เฉพาะพร้อมการรับประกัน SLA Model Unit ถือเป็นชั้นเชิงพาณิชย์ PAI-EAS คือเทคโนโลยีที่อยู่เบื้องหลัง
ก่อนที่จะนำไปใช้ คุณต้องตัดสินใจเกี่ยวกับการกำหนดค่าก่อน:
สำหรับบทช่วยสอนนี้ เราจะนำไปใช้ด้วย MU1 จำนวน 4 ยูนิตบน GPU ที่ใช้ H20-141G ในภูมิภาคสิงคโปร์

นำทางไปยังคอนโซล PAI และเลือก EAS จากเมนูด้านซ้าย
คลิก สร้างบริการ คุณจะเห็นวิซาร์ดสำหรับการนำไปใช้

ชื่อบริการ: deepseek-v4-flash-prod
แหล่งที่มาของโมเดล: เลือก "โมเดลที่กำหนดเอง" และระบุอาร์ติแฟกต์ของโมเดล DeepSeek V4-Flash หากโมเดลมีอยู่ในรีจิสทรีโมเดลของ Alibaba Cloud คุณจะสามารถเลือกได้ทันที อีกวิธีหนึ่ง ให้ระบุเส้นทาง OSS ไปยังไฟล์ข้อมูลโมเดลของคุณ

การกำหนดค่าทรัพยากร:
การกำหนดค่าเฟรมเวิร์ก:

ตั้งค่า VPC และ vSwitch ของคุณ สำหรับ API ที่ต้องเปิดให้ภายนอกใช้งานผ่านอินเทอร์เน็ต ให้เปิดใช้งานจุดเชื่อมต่อสาธารณะ สำหรับบริการภายใน ให้ใช้จุดเชื่อมต่อส่วนตัวภายใน VPC ของคุณ
เปิดใช้งานการตรวจสอบสิทธิ์คีย์ API สร้างคีย์ API เฉพาะบริการ

คลิก นำไปใช้ กระบวนการจัดเตรียมใช้เวลา 5-10 นาที เนื่องจาก PAI-EAS จะจัดสรรทรัพยากร GPU เฉพาะของคุณและโหลดไฟล์ข้อมูลโมเดลลงในหน่วยความจำ

คุณจะเห็นการเปลี่ยนสถานะของบริการจาก "กำลังสร้าง" → "กำลังนำไปใช้" → "กำลังทำงาน"
เมื่อบริการเริ่มทำงานแล้ว โปรดจด URL จุดเชื่อมต่อไว้ โดยจะมีลักษณะประมาณนี้:
https://deepseek-v4-flash-prod.123456.ap-southeast-1.pai-eas.aliyuncs.com

ทดสอบการใช้งานด้วยคำสั่ง curl:
curl -X POST https://deepseek-v4-flash-prod.123456.ap-southeast-1.pai-eas.aliyuncs.com/v1/chat/completions \
-H "Authorization: Bearer YOUR_SERVICE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-v4-flash",
"messages": [
{"role": "user", "content": "What are the key benefits of dedicated GPU inference?"}
],
"max_tokens": 512
}'
หากคุณได้รับการตอบสนองที่สอดคล้องกัน แสดงว่าการนำ Model Unit ของคุณไปใช้พร้อมใช้งานและรองรับปริมาณการใช้งานแล้ว
นอกจากนี้ คุณยังสามารถทดสอบได้โดยตรงจากคอนโซล PAI-EAS ได้อีกด้วย บริการแต่ละบริการที่นำไปใช้จะมี Playground ในตัว ซึ่งคุณสามารถส่งพรอมต์ ปรับพารามิเตอร์ (อุณหภูมิ, top-p, โทเค็นสูงสุด) และดูการตอบสนองแบบสตรีมมิ่งได้ในแบบเรียลไทม์ โดยไม่ต้องเขียนโค้ดใด ๆ

วิธีนี้มีประโยชน์สำหรับการตรวจสอบความถูกต้องอย่างรวดเร็ว การแก้ไขข้อผิดพลาดในการทำงานของพรอมต์ หรือการสาธิตการนำไปใช้ให้กับผู้มีส่วนได้ส่วนเสียก่อนที่จะนำไปผสานรวมเข้ากับแอปพลิเคชันของคุณ
ตอนนี้ มาถึงช่วงที่สนุกแล้ว เราจะทำการทดสอบประสิทธิภาพของตัวเลือกการนำไปใช้ทั้งหมดสี่แบบด้วยภาระงานเดียวกัน และเปรียบเทียบผลลัพธ์
เราใช้สคริปต์ทดสอบประสิทธิภาพตามมาตรฐานซึ่งจะวัด:
ทดสอบภาระงาน:
นี่คือสคริปต์ทดสอบประสิทธิภาพที่เราใช้ คุณสามารถปรับเปลี่ยนเพื่อใช้ในการทดสอบของคุณเองได้:
import asyncio
import time
import statistics
from dataclasses import dataclass
from typing import List
import aiohttp
import numpy as np
@dataclass
class BenchmarkResult:
concurrency: int
total_requests: int
ttft_ms: List[float]
tpot_ms: List[float]
tps: List[float]
total_tokens: int
duration_sec: float
@property
def avg_ttft(self) -> float:
return statistics.mean(self.ttft_ms)
@property
def p99_ttft(self) -> float:
return np.percentile(self.ttft_ms, 99)
@property
def avg_tps(self) -> float:
return statistics.mean(self.tps)
@property
def avg_tpot(self) -> float:
return statistics.mean(self.tpot_ms)
@property
def throughput_tpm(self) -> float:
return (self.total_tokens / self.duration_sec) * 60
async def send_request(session, endpoint, api_key, prompt, max_tokens):
headers = {
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json"
}
payload = {
"model": "deepseek-v4-flash",
"messages": [{"role": "user", "content": prompt}],
"max_tokens": max_tokens,
"stream": True
}
start_time = time.time()
first_token_time = None
token_count = 0
last_token_time = start_time
async with session.post(endpoint, headers=headers, json=payload) as response:
async for line in response.content:
line = line.decode('utf-8').strip()
if line.startswith('data: '):
chunk = line[6:]
if chunk == '[DONE]':
break
# แยกวิเคราะห์ SSE และนับจำนวนโทเค็น
token_count += 1
if first_token_time is None:
first_token_time = time.time()
last_token_time = time.time()
end_time = time.time()
ttft = (first_token_time - start_time) * 1000 if first_token_time else 0
generation_time = (last_token_time - first_token_time) if first_token_time else 0
tps = token_count / generation_time if generation_time > 0 else 0
tpot = generation_time / token_count * 1000 if token_count > 0 else 0
return ttft, tpot, tps, token_count
async def run_benchmark(endpoint, api_key, concurrency, duration_sec=300):
# พรอมต์บริบทยาว (ประมาณ 2,048 โทเค็น)
prompt = "Explain the history of artificial intelligence..." * 50
max_tokens = 1024
results = []
start_time = time.time()
request_count = 0
async with aiohttp.ClientSession() as session:
while time.time() - start_time < duration_sec:
tasks = [
send_request(session, endpoint, api_key, prompt, max_tokens)
for _ in range(concurrency)
]
batch_results = await asyncio.gather(*tasks, return_exceptions=True)
for r in batch_results:
if isinstance(r, Exception):
continue
ttft, tpot, tps, tokens = r
results.append((ttft, tpot, tps, tokens))
request_count += 1
total_tokens = sum(r[3] for r in results)
return BenchmarkResult(
concurrency=concurrency,
total_requests=request_count,
ttft_ms=[r[0] for r in results],
tpot_ms=[r[1] for r in results],
tps=[r[2] for r in results],
total_tokens=total_tokens,
duration_sec=duration_sec
)
# Run benchmarks at different concurrency levels
async def main():
endpoint = "https://your-endpoint.aliyuncs.com/v1/chat/completions"
api_key = "your-api-key"
for concurrency in [1, 4, 8, 16, 32, 64]:
print(f"\n=== Benchmarking at concurrency={concurrency} ===")
result = await run_benchmark(endpoint, api_key, concurrency)
print(f"Total requests: {result.total_requests}")
print(f"Throughput: {result.throughput_tpm:.0f} TPM")
print(f"Avg TTFT: {result.avg_ttft:.1f}ms")
print(f"P99 TTFT: {result.p99_ttft:.1f}ms")
print(f"Avg TPS: {result.avg_tps:.1f} tok/s")
print(f"Avg TPOT: {result.avg_tpot:.1f}ms")
if __name__ == "__main__":
asyncio.run(main())

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

| การทำงานพร้อมกัน | TTFT เฉลี่ย | P99 TTFT | TPS เฉลี่ย | ปริมาณงาน (TPM) |
|---|---|---|---|---|
| 1 | 245 มิลลิวินาที | 890 มิลลิวินาที | 42.3 | 2,540 |
| 4 | 312 มิลลิวินาที | 1,240 มิลลิวินาที | 38.7 | 9,280 |
| 8 | 485 มิลลิวินาที | 2,100 มิลลิวินาที | 31.2 | 14,960 |
| 16 | 920 มิลลิวินาที | 4,500 มิลลิวินาที | 18.5 | 17,760 |
| 32 | 1,850 มิลลิวินาที | 8,200 มิลลิวินาที | 9.8 | 18,816 |
ข้อสังเกต: ที่การทำงานพร้อมกันต่ำ Token API จะเร็วพอสมควร แต่เมื่อการทำงานพร้อมกันเพิ่มขึ้น เวลาในการตอบสนองจะเพิ่มขึ้นอย่างมาก พูลที่ใช้ร่วมกันไม่สามารถรองรับปริมาณงานสูงได้โดยไม่ต้องรอคิว ปริมาณงานจะคงที่อยู่ที่ประมาณ 18K TPM

| การทำงานพร้อมกัน | TTFT เฉลี่ย | P99 TTFT | TPS เฉลี่ย | ปริมาณงาน (TPM) |
|---|---|---|---|---|
| 1 | 180 มิลลิวินาที | 420 มิลลิวินาที | 48.5 | 2,910 |
| 4 | 195 มิลลิวินาที | 380 มิลลิวินาที | 46.2 | 11,090 |
| 8 | 210 มิลลิวินาที | 450 มิลลิวินาที | 44.8 | 21,500 |
| 16 | 245 มิลลิวินาที | 520 มิลลิวินาที | 41.3 | 39,600 |
| 32 | 310 มิลลิวินาที | 680 มิลลิวินาที | 36.7 | 70,300 |
ข้อสังเกต: PTU ให้ความสม่ำเสมอของความหน่วงที่ดีขึ้นอย่างเห็นได้ชัด ความจุที่รับประกันหมายความว่าจะไม่มีปัญหาเรื่องการต่อคิวโดยไม่คาดคิด ปริมาณงานจะเพิ่มขึ้นตามสัดส่วนเชิงเส้นจนถึงขีดจำกัดของระดับที่จองไว้ TTFT ของ P99 ยังคงต่ำกว่า 700 มิลลิวินาที แม้จะมีคำขอพร้อมกันถึง 32 รายการก็ตาม

| การทำงานพร้อมกัน | TTFT เฉลี่ย | P99 TTFT | TPS เฉลี่ย | ปริมาณงาน (TPM) |
|---|---|---|---|---|
| 1 | 95 มิลลิวินาที | 180 มิลลิวินาที | 95.2 | 5,710 |
| 4 | 102 มิลลิวินาที | 195 มิลลิวินาที | 94.8 | 22,750 |
| 8 | 118 มิลลิวินาที | 225 มิลลิวินาที | 93.5 | 44,880 |
| 16 | 145 มิลลิวินาที | 280 มิลลิวินาที | 91.2 | 87,550 |
| 32 | 195 มิลลิวินาที | 380 มิลลิวินาที | 87.6 | 168,200 |
| 64 | 310 มิลลิวินาที | 620 มิลลิวินาที | 79.3 | 304,100 |
ข้อสังเกต: Model Unit เด่นกว่าในทุกตัวชี้วัด TTFT เร็วกว่า Token API ถึง 3 เท่า เมื่อมีการใช้งานพร้อมกันจำนวนมาก TPS ยังคงเสถียรแม้มีภาระงานหนัก ปริมาณงานสูงสุด 3.04 แสน TPM นั้นสูงกว่าที่ Token API สามารถทำได้ถึง 16 เท่า และอย่าลืมว่านี่คือการมี SLA รับประกัน ไม่ใช่แบบพยายามอย่างเต็มความสามารถ

| การทำงานพร้อมกัน | TTFT เฉลี่ย | P99 TTFT | TPS เฉลี่ย | ปริมาณงาน (TPM) |
|---|---|---|---|---|
| 1 | 85 มิลลิวินาที | 160 มิลลิวินาที | 105.0 | 6,300 |
| 4 | 92 มิลลิวินาที | 175 มิลลิวินาที | 102.5 | 24,600 |
| 8 | 105 มิลลิวินาที | 200 มิลลิวินาที | 98.3 | 47,200 |
| 16 | 130 มิลลิวินาที | 250 มิลลิวินาที | 92.1 | 88,300 |
| 32 | 180 มิลลิวินาที | 340 มิลลิวินาที | 82.5 | 158,400 |
ข้อสังเกต: Bare Metal ทำได้ดีกว่า Model Unit ในการทำงานพร้อมกันในระดับต่ำ เนื่องจากสามารถเข้าถึง GPU ได้โดยตรงและการปรับแต่งที่กำหนดเอง แต่ความแตกต่างนั้นมีไม่มาก (10-15%) เมื่อเทียบกันแล้ว ค่าใช้จ่ายในการดำเนินงานนั้นเยอะกว่ามาก

| การนำไปใช้ | ต้นทุนรายเดือน* | TPM สูงสุด | ความหน่วงเฉลี่ย (P50) | ต้นทุนโดยเปรียบเทียบต่อ 1 ล้านโทเค็น |
|---|---|---|---|---|
| Token API | เปลี่ยนแปลงได้ (ขยายขนาดเชิงเส้น) | ประมาณ 1.9 หมื่น | 1,850 มิลลิวินาที | 1x (เกณฑ์มาตรฐาน) |
| PTU | ประมาณ 1.5 เท่าของ Model Unit | ประมาณ 7 หมื่น | 310 มิลลิวินาที | ประมาณ 2 เท่าของ Token API |
| Model Unit (MU1 จำนวน 4 ยูนิต) | คงที่ (ช่วงกลาง) | ประมาณ 3.04 แสน | 195 มิลลิวินาที | ประมาณ 0.3 เท่าของ Token API |
| Bare Metal (8x H200) | คล้ายกับ Model Unit | ประมาณ 1.58 แสน | 180 มิลลิวินาที | ประมาณ 0.3 เท่าของ Token API |
*ที่ปริมาณการใช้งานต่อเนื่อง 500 ล้านโทเค็นต่อวัน โดยไม่รวมค่าใช้จ่ายของทีมสำหรับ Bare Metal ค่าใช้จ่ายทั้งหมดเป็นค่าประมาณที่ได้จากแหล่งข้อมูลสาธารณะ
ข้อมูลเชิงลึกที่สำคัญ: Model Unit ให้ปริมาณงานสูงกว่า Token API ถึง 16 เท่า ในราคาต่อโทเค็นที่ต่ำกว่าถึงหนึ่งในสาม พร้อมด้วยความหน่วงที่เร็วกว่าประมาณ 10 เท่า ไม่ใช่แค่ถูกกว่าเท่านั้น ในระดับการผลิต ผลลัพธ์ที่ได้ดีกว่าในทุกแง่มุมที่สามารถวัดได้

หลังจากทดสอบตัวเลือกทั้งหมดสี่แบบด้วยเกณฑ์มาตรฐานเดียวกันแล้ว นี่คือแผนผังการตัดสินใจที่เราหวังว่าจะมีตั้งแต่แรก
เราวกกลับมาพูดถึงสตาร์ทอัพฟินเทคของซาราห์กันอีกครั้ง
หลังจากได้เห็นผลลัพธ์ด้านประสิทธิภาพแล้ว การตัดสินใจของเธอก็ชัดเจน
Token API เหมาะมากสำหรับโปรโตไทป์ แต่จะมีค่าใช้จ่ายต่อเดือนสูงกว่าประมาณ 2 เท่าเมื่อเทียบกับ Model Unit เมื่อพิจารณาจากขนาดที่คาดการณ์ไว้ PTU น่าจะเป็นตัวเลือกที่เหมาะสมในราคาประมาณ 60-70% ของต้นทุน Token API แต่จะเกินกว่าระดับที่จองไว้ภายในหนึ่งไตรมาส Bare Metal ถือว่าปัดตกไปได้เลย เพราะทีมของเธอมีวิศวกรทั้งหมด 12 คน และไม่มีใครอยากผลัดเวรดูคลัสเตอร์ GPU ตอนตี 3
พวกเขาจึงเลือก Model Unit MU1 จำนวน 4 ยูนิต นำไปใช้บน PAI-EAS โดยใช้ DeepSeek V4-Flash พร้อมจุดตรวจสอบที่ปรับแต่งเองสำหรับโดเมนของแต่ละยูนิต
ผลลัพธ์หลังจากผ่านการใช้งานมาหนึ่งเดือน:
บทเรียนที่ได้คืออะไร อย่าดูแค่ราคาที่ติดไว้เพียงอย่างเดียว ให้พิจารณาต้นทุนทั้งหมดอย่างครบถ้วน ซึ่งรวมถึงค่าใช้จ่ายในการดำเนินงานของทีม ต้นทุนค่าเสียโอกาส และความเสี่ยงที่ประสิทธิภาพการทำงานจะลดลงเมื่อภาระงานสูงขึ้น เมื่อพิจารณาในภาพรวมแล้ว Model Unit ไม่ได้เป็นเพียงตัวเลือกที่ถูกที่สุดในการใช้งานวงกว้างเท่านั้น แต่ยังเป็นตัวเลือกเดียวที่ให้ประสิทธิภาพ ความสามารถในการคาดการณ์ และความอุ่นใจไปพร้อม ๆ กัน
พร้อมที่จะนำ DeepSeek V4-Flash ไปใช้แล้วหรือยัง นี่คือแหล่งข้อมูลที่คุณต้องการ:
การทดสอบประสิทธิภาพนี้ดำเนินการในสภาพแวดล้อมที่มีการควบคุม โดยใช้ภาระงานจำลอง ผลลัพธ์ที่ได้ในโลกแห่งความเป็นจริงจะแตกต่างกันไปโดยขึ้นอยู่กับ:
ตัวเลขราคาเป็นตัวเลขประมาณการโดยอ้างอิงจากแหล่งข้อมูลสาธารณะที่มีในเวลาที่เขียนบทความนี้ อาจมีส่วนลดตามปริมาณที่ซื้อ เงื่อนไขตามภูมิภาค และราคาโปรโมชัน ควรตรวจสอบค่าใช้จ่ายกับผู้จัดการบัญชี Alibaba Cloud ของคุณก่อนทำการตัดสินใจทุกครั้ง
มีคำถามเกี่ยวกับการนำ DeepSeek V4-Flash ไปใช้บน Alibaba Cloud หรือไม่ ทีม AI Infra SA ดำเนินการประเมินผลเป็นประจำทุกสัปดาห์ ติดต่อเราผ่านแบบฟอร์มขอข้อมูล MU ที่ลิงก์ด้านบน
บทความต้นฉบับเป็นภาษาอังกฤษ ดูบทความต้นฉบับที่นี่
DeepSeek V4-Flash trên quy mô lớn: Hướng dẫn triển khai dựa trên điểm chuẩn
Deploy OpenClaw di Alibaba Cloud ECS dengan Integrasi Telegram
143 posts | 4 followers
FollowRegional Content Hub - July 7, 2025
Regional Content Hub - July 28, 2025
Regional Content Hub - April 22, 2024
Regional Content Hub - January 13, 2025
Regional Content Hub - December 22, 2025
Pum - January 18, 2023
143 posts | 4 followers
Follow
Qwen
Full-range, open-source, multimodal, and multi-functional
Learn More
Alibaba Cloud Model Studio
A one-stop generative AI platform to build intelligent applications that understand your business, based on Qwen model series such as Qwen-Max and other popular models
Learn More
Alibaba Cloud for Generative AI
Accelerate innovation with generative AI to create new business success
Learn More
AgentBay
Multimodal cloud-based operating environment and expert agent platform, supporting automation and remote control across browsers, desktops, mobile devices, and code.
Learn MoreMore Posts by Regional Content Hub