Google ใส่ TPU เข้า vLLM สำหรับงาน embedding — เสิร์ฟ Qwen3-Embedding-8B ได้ 83,996 โทเคน/วินาที ที่บริบท 16K พร้อมยืนยัน cosine similarity ≥0.999 เทียบ GPU

งาน embedding เป็นชิ้นส่วนที่ถูกมองข้ามมากที่สุดในสแต็ก RAG — ทุกคนพูดถึงโมเดลตอบคำถาม แต่ต้นทุนจริงของระบบค้นคืนเอกสารขนาดองค์กรมักอยู่ที่การ แปลงเอกสารทั้งคลังเป็นเวกเตอร์ซ้ำ ๆ ไม่ใช่ที่การ generate คำตอบ และเมื่อเอกสารยาวขึ้น มีภาพประกอบ มีตาราง ต้นทุนนั้นก็บานตาม

วันที่ 26 สิงหาคม 2026 Google Cloud ประกาศว่าได้ผลักการรองรับ TPU เข้าไปใน vLLM สำหรับโหมด pooling/embedding โดยตรง — ไม่ใช่ผ่านชั้น proxy หรือ service เฉพาะ แต่เป็น backend ในตัว vLLM ที่เรียกใช้แบบเดียวกับที่รันบน GPU

ตัวเลขที่ประกาศ

• Qwen3-Embedding-8B (ข้อความ): 83,996 total token/s และ 5.13 req/s ที่ความยาวลำดับ 16K+ บน bfloat16 ด้วย tensor_parallel_size=4
• Qwen3-VL-Embedding-8B (มัลติโหมด): ประมวลผลอินพุตได้ 15K+ โทเคน
• ความแม่นเชิงตัวเลข: เป้าหมาย cosine similarity ≥0.999 สำหรับข้อความ และ ≥0.995 สำหรับอินพุตมัลติโหมด เทียบกับผลอ้างอิง

ตัวเลข cosine similarity คือส่วนที่ควรให้น้ำหนักที่สุด และเป็นเหตุผลที่บทความใช้คำว่า enterprise-grade precision — เพราะสำหรับระบบ retrieval การย้าย hardware แล้วเวกเตอร์เพี้ยนแม้เพียงเล็กน้อยแปลว่าดัชนีเดิมทั้งก้อนใช้ไม่ได้ ถ้าคุณ index เอกสารสิบล้านชิ้นไว้บน GPU แล้วสลับมาเสิร์ฟ query บน TPU โดยที่ embedding ไม่ตรงกัน ผลค้นหาจะเสียเงียบ ๆ โดยไม่มี error ขึ้นให้เห็น การประกาศ threshold ที่วัดได้จึงมีค่ากว่าตัวเลข throughput

ใช้ยังไง

API ไม่ต่างจาก vLLM ปกติ — ประกาศ runner เป็น pooling แล้วเรียก embed():

from vllm import LLM

llm = LLM(
    model="Qwen/Qwen3-Embedding-8B",
    runner="pooling",
    tensor_parallel_size=2,
    max_model_len=16384,
)

outputs = llm.embed(prompts)

Google ระบุว่าสูตรการ deploy อย่างเป็นทางการอยู่ในรีโป AI-Hypercomputer บน GitHub และตัวระบบออกแบบให้ผูกกับ Google Kubernetes Engine (GKE) เพื่อ autoscale ข้าม accelerator หลายชนิด — บทความไม่ได้ระบุสถานะ GA หรือ preview ไว้ชัดเจน

สามอย่างที่ต้องแก้เพื่อให้ TPU รันงานนี้ได้

ส่วนที่ผมคิดว่ามีประโยชน์ที่สุดสำหรับคนที่ port โมเดลไปฮาร์ดแวร์อื่นเอง คือรายการอุปสรรคที่ทีมเล่าไว้ตรง ๆ:

1. Hardware-safe vocabulary padding — TPU ต้องการรูปทรงเทนเซอร์ที่จัดตำแหน่งตามข้อกำหนดของฮาร์ดแวร์ ขนาด vocabulary ที่หารไม่ลงตัวจึงต้องถูก pad อย่างระมัดระวัง โดยไม่ทำให้ผลลัพธ์เพี้ยน
2. Materialization hardening — ใช้ lazy-loading ร่วมกับการ pre-warm การคอมไพล์ เพื่อไม่ให้ TPU ต้องคอมไพล์กราฟใหม่กลางทางเวลาเจอ shape ที่ไม่เคยเห็น (ปัญหาคลาสสิกของ XLA)
3. Hybrid StepPool architecture — สถาปัตยกรรมสำหรับจัดการบริบทยาวโดยเฉพาะ ซึ่งเป็นเงื่อนไขที่ทำให้ตัวเลข 16K+ ข้างต้นเป็นไปได้

สองข้อแรกเป็นบทเรียนที่ใช้ได้กับ accelerator ที่ต้องคอมไพล์กราฟล่วงหน้าแทบทุกตัว ไม่ใช่แค่ TPU

มุมมอง AI Curator

ข่าวนี้ไม่หวือหวา แต่มันคือสัญญาณของแนวโน้มที่กำลังชัดขึ้นเรื่อย ๆ ตลอดปีนี้: vLLM กำลังกลายเป็นเลเยอร์กลางที่ผู้ผลิตฮาร์ดแวร์ทุกเจ้าต้องมาต่อ เมื่อสองวันก่อน vLLM v0.28.0 เพิ่งเปิด Kimi-K3 บน ROCm ของ AMD และย้าย bitsandbytes ออกไปเป็นปลั๊กอินนอกทรี วันนี้ Google เอา TPU มาต่อในเส้นทาง pooling — ทิศทางเดียวกันคือ ผู้ให้บริการคลาวด์เลิกพยายามผลักดัน serving stack ของตัวเอง แล้วหันมาลงแรงกับโปรเจกต์โอเพนซอร์สที่นักพัฒนาใช้อยู่แล้ว ซึ่งเป็นข่าวดีสำหรับคนที่ไม่อยากถูกล็อกกับ SDK ของเจ้าใดเจ้าหนึ่ง

จุดที่น่าสังเกตอีกอย่างคือ โมเดลที่ Google เลือกมาโชว์เป็น Qwen ทั้งคู่ ไม่ใช่ Gemini Embedding ของตัวเอง นั่นบอกกลุ่มเป้าหมายชัดเจน — คนที่รันโมเดล open-weight เองอยู่แล้วและกำลังหาที่รันที่ถูกลง ไม่ใช่คนที่จะซื้อ API ของ Google

สำหรับทีมในไทยและอาเซียน มุมที่เป็นประโยชน์ที่สุดคือเรื่อง ต้นทุนการ re-index ธุรกิจไทยจำนวนมากที่ทำ RAG บนเอกสารภายในเจอกำแพงเดียวกันคือ เอกสารเป็น PDF ภาษาไทยผสมตาราง ซึ่งบังคับให้ใช้โมเดล embedding แบบมัลติโหมดและบริบทยาว แล้วต้นทุนก็พุ่ง การมีทางเลือกฮาร์ดแวร์เพิ่มขึ้นหนึ่งเส้นทางที่ รับประกันว่าเวกเตอร์จะตรงกับของเดิม ทำให้การย้ายเพื่อลดต้นทุนกลายเป็นเรื่องที่ทำได้จริง ไม่ต้อง index ใหม่ทั้งคลัง

แต่ต้องเตือนไว้ตรง ๆ สองข้อ: หนึ่ง ตัวเลข throughput ทั้งหมดเป็นตัวเลขที่ Google รายงานเอง ไม่มีการวัดอิสระเทียบกับ H100/H200 ในบทความ ทำให้เทียบต้นทุนต่อโทเคนข้ามฮาร์ดแวร์ไม่ได้จากข้อมูลชุดนี้ สอง TPU ยังผูกกับ Google Cloud เท่านั้น และ region ที่มี TPU รุ่นใหม่ในเอเชียยังจำกัด — สำหรับงานที่มีข้อกำหนดให้ข้อมูลอยู่ในประเทศ นี่ยังไม่ใช่ตัวเลือกที่ใช้ได้ทันที ทางที่ปฏิบัติได้กว่าสำหรับหลายทีมยังคือรัน vLLM บน GPU ในดาต้าเซ็นเตอร์ไทย ซึ่งโค้ดชุดเดียวกันนี้ก็ใช้ได้อยู่แล้ว — ซึ่งก็คือประเด็นทั้งหมดของการที่มันอยู่บน vLLM

แหล่งข่าว

• Enterprise-Grade Precision for Long-Context Multimodal Embedding Inference on Cloud TPU — Google Developers Blog (26 ส.ค. 2026)
• vLLM — GitHub releases
• Qwen/Qwen3-Embedding-8B — Hugging Face