Gradio 6.26 เพิ่ม gr.Workflow — ประกาศไพป์ไลน์เป็นกราฟของโหนดที่มีชนิด แล้วได้ทั้งแคนวาสลากวางและ REST endpoint ต่อหนึ่งเอาต์พุตในโค้ดบรรทัดเดียว

Hugging Face เผยแพร่บล็อก Wire It, Run It, Deploy It: AI Workflows in Gradio เมื่อวันที่ 25 ส.ค. 2026 โดย Yuvraj Sharma และ Abubakar Abid แนะนำ gr.Workflow ซึ่งเป็นคอมโพเนนต์ใหม่ที่มากับ Gradio 6.26.0 — เวอร์ชันที่ขึ้น PyPI เมื่อ 24 ส.ค. พร้อมแพ็กเกจฝั่งหน้าเว็บชื่อ @gradio/workflowcanvas@0.10.0 ที่ปล่อยวันเดียวกัน

แนวคิดของมันสรุปได้ประโยคเดียว: คุณเขียนฟังก์ชัน Python ที่มี type hint ตามปกติ ส่งเข้า gr.Workflow แล้วได้แคนวาสแบบลากวางที่ต่อโหนดเข้าหากันผ่านพอร์ตที่รู้ชนิดข้อมูล — โดยที่ทุกโหนดกดรันแยกได้และผลลัพธ์กลางทางมองเห็นหมด ไม่ใช่กล่องดำที่ต้องรอจนจบ

import gradio as gr

def your_function(text: str) -> str:
    ...

gr.Workflow(bind=[your_function]).launch()

โหนดสามชนิด และสิ่งที่ต่อเข้ามาเป็น operator ได้

โครงสร้างกราฟใน gr.Workflow แบ่งโหนดเป็นสามประเภท:

• references — โหนดอินพุต จุดที่ข้อมูลเข้าสู่กราฟ
• operators — ขั้นตอนประมวลผล
• subjects — โหนดเอาต์พุต

ส่วนที่น่าสนใจสำหรับคนที่ต้องต่อของเข้าด้วยกันจริงคือ operator ไม่จำกัดแค่ฟังก์ชัน Python ในไฟล์เดียวกัน มันรับได้ทั้ง โมเดลผ่าน Hugging Face Inference Providers, Gradio Space ตัวอื่น ที่เรียกข้ามมาเป็นขั้นตอนหนึ่งในไพป์ไลน์ และ แถวข้อมูลจาก dataset บน Hub นั่นทำให้การประกอบต้นแบบที่ต้องยิงโมเดลหลายตัวต่อกันไม่ต้องเขียน glue code เรียก endpoint เองทีละอัน

กราฟรองรับการแตกงานคู่ขนานแบบ fan-out ด้วย — โหนดหนึ่งกระจายไปหลายสาขาแล้ววิ่งพร้อมกัน ซึ่งเป็นแพตเทิร์นพื้นฐานของงานประเภท “สร้างภาพเดียวกันในห้าสไตล์แล้วเทียบ” หรือ “ยิงคำถามเดียวไปหลายโมเดลแล้วรวมผล”

สำหรับงานที่ต้องใช้ GPU ฟังก์ชันติดเดคอเรเตอร์ @spaces.GPU ได้ตามปกติ เมื่อโหนดนั้นถูกเรียก ZeroGPU จะจอง GPU เฉพาะช่วงที่รัน แล้วคืนทันทีที่เสร็จ — โมเดลการคิดเงินแบบเดิมของ Spaces ยังใช้ได้กับโหนดใน workflow

ทุกเอาต์พุตกลายเป็น REST endpoint โดยไม่ต้องทำอะไรเพิ่ม

จุดที่แยก gr.Workflow ออกจากเครื่องมือลากวางทั่วไปคือฝั่ง API ตามที่บล็อกระบุ เอาต์พุตแต่ละตัวจะกลายเป็น REST endpoint ที่ตั้งชื่อตาม label ของมัน โดยอัตโนมัติ ไม่ต้องตั้งค่าเพิ่ม เรียกได้ทั้งผ่าน Gradio client ฝั่ง Python:

from gradio_client import Client

client = Client("ysharma/gr-workflow-multi-endpoint-API")
print(client.predict("hello there friend", api_name="/word_count"))

และผ่าน HTTP ตรง ๆ:

curl https://ysharma-gr-workflow-multi-endpoint-API.hf.space/gradio_api/call/word_count \
  -H "Content-Type: application/json" \
  -d '{"data": ["hello there friend"]}'

นี่คือความต่างเชิงปฏิบัติที่สำคัญ เครื่องมือ visual pipeline ส่วนใหญ่บังคับให้เลือกทางใดทางหนึ่ง — จะได้ UI ที่คนทั่วไปกดใช้ได้ หรือจะได้ API ที่ระบบอื่นเรียกได้ แต่ไม่ใช่ทั้งคู่จากนิยามเดียวกัน การที่กราฟเดียวเสิร์ฟทั้งแคนวาสให้คนกดเล่นและ endpoint ให้โค้ดเรียก หมายความว่าขั้นตอน “ทำ demo ให้ทีมดู” กับ “เอาไปต่อในระบบจริง” ไม่ต้องเขียนซ้ำสองรอบ

บล็อกแนบเดโมที่เปิดรัน ทำซ้ำ (duplicate) และแก้ต่อได้ห้าตัว: Image Editor Pipeline (ใช้ Qwen-Image-Edit), AI Media Studio (รวม FLUX สร้างภาพ ลบพื้นหลัง แปลงข้อความเป็นเสียง และให้ LLM ตั้งชื่อ), Generative Art Lab (สร้างภาพหลายสไตล์แบบคู่ขนาน), Data Detective (วิเคราะห์ dataset บน Hub ผ่าน Datasets Server API) และ ZeroGPU Animator (ทำวิดีโอด้วย LTX-Video บน GPU)

มุมมอง AI Curator

ตลาดเครื่องมือ “ลากวางแล้วได้ AI pipeline” ไม่ใช่ที่ว่าง — n8n, Flowise, Langflow, Dify และอีกหลายตัวอยู่ตรงนั้นมานานแล้ว คำถามที่ควรถามคือ gr.Workflow ต่างอย่างไร และคำตอบที่ตรงที่สุดคือ ทิศทางการไหลของงาน เครื่องมือกลุ่มเดิมเริ่มจากแคนวาสเป็นแหล่งความจริง แล้วโค้ดเป็นสิ่งที่ export ออกมาทีหลัง (ถ้า export ได้) ส่วน gr.Workflow เริ่มจากฟังก์ชัน Python ที่อยู่ในรีโพและผ่าน code review ตามปกติ แล้วแคนวาสเป็นสิ่งที่งอกออกมาจากมัน

ความต่างนี้ฟังดูเป็นรายละเอียด แต่มันตัดสินว่าเครื่องมือจะรอดจากช่วง prototype หรือไม่ ทีมที่เคยเจอ workflow แบบ JSON ก้อนใหญ่ใน n8n ที่ diff ไม่ได้ merge ไม่ได้ และไม่มีใครกล้าแก้ จะเข้าใจทันทีว่าทำไมการให้ Python เป็นแหล่งความจริงถึงสำคัญ — เพราะเวอร์ชันคอนโทรล เทสต์ และการรีวิวยังทำงานได้ตามปกติ

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

สำหรับบริบทไทยและ SEA จุดที่มีค่าที่สุดน่าจะเป็นเรื่องที่ไม่ค่อยมีใครพูดถึง — ต้นทุนการสื่อสารข้ามสายงาน ทีม AI ในองค์กรไทยจำนวนมากใช้เวลาไปกับการอธิบายให้ฝ่ายธุรกิจเข้าใจว่าระบบทำอะไรอยู่ การมีแคนวาสที่ผู้ไม่ใช่โปรแกรมเมอร์กดรันทีละโหนดแล้วเห็นผลระหว่างทางได้เอง โดยที่วิศวกรไม่ต้องดูแลโค้ดฐานคนละชุด คือการลดต้นทุนตรงนั้นแบบที่แทบไม่ต้องจ่ายอะไรเพิ่ม และเมื่อรวมกับข้อเท็จจริงว่ามันดีพลอยขึ้น Spaces ได้ทันที การทำ internal tool ให้ทีมใช้จึงเหลือระยะทางสั้นมาก

แหล่งข่าว

• Wire It, Run It, Deploy It: AI Workflows in Gradio — Hugging Face Blog
• gradio 6.26.0 — PyPI
• gradio-app/gradio releases — GitHub