OpenRouter Fusion API
(openrouter.ai)- เริ่มต้นจากการค้นพบว่าเมื่อ สังเคราะห์ (synthesize) ผลลัพธ์จากหลายโมเดลเข้าด้วยกัน สามารถให้ประสิทธิภาพเหนือกว่าโมเดลเดี่ยวอย่างชัดเจน
- แนวทาง การไตร่ตรองแบบหลายโมเดล (multi-model deliberation) ที่ให้ โมเดลผู้เชี่ยวชาญ หลายตัววิเคราะห์พรอมป์ต์เดียวกันแบบขนาน แล้วให้ judge model สังเคราะห์ผลเพื่อเขียนคำตอบสุดท้าย
- โมเดลในพาเนลจะทำ การค้นหาเว็บ และ การดึงข้อมูลเว็บ โดยเปิดใช้งานไว้ พร้อม วิเคราะห์แบบขนาน จากนั้น judge model จะสรุปเป็นการวิเคราะห์เชิงโครงสร้างของ ฉันทามติ, ความขัดแย้ง, ความสอดคล้องบางส่วน, มุมมองเชิงลึกเฉพาะตัว, จุดบอด
- ค่าเริ่มต้นคือ พรีเซ็ต Quality และสามารถสลับไปใช้พรีเซ็ต Budget เพื่อใช้โมเดลที่ถูกกว่า หรือกำหนดพาเนลและผู้ตัดสินใหม่ทั้งหมดผ่านฟิลด์ fusion plugin
- เหมาะกับงาน วิจัย, การวิจารณ์โดยผู้เชี่ยวชาญ หรือสถานการณ์ที่ต้นทุนจากคำตอบผิดสูงกว่าต้นทุนการสร้างคำตอบเพิ่มเติม
- เนื่องจากมีการเรียกใช้ทั้งสมาชิกทุกตัวในพาเนลและ judge ค่าบริการต่อคำขอจึงคิดแบบ รวมค่าการสร้างคำตอบ (completion) ของแต่ละตัว ไม่ใช่แบบโมเดลเดี่ยว
วิธีการทำงาน
- เป็นวิธีเปลี่ยนพรอมป์ต์เดียวให้กลายเป็น การไตร่ตรองแบบหลายโมเดล ขนาดเล็ก
- พาเนลของโมเดลผู้เชี่ยวชาญจะวิเคราะห์พรอมป์ต์แบบขนาน โดยเปิดใช้ web search และ web fetch
- judge model จะสังเคราะห์คำตอบจากพาเนล แล้วสร้างการวิเคราะห์แบบมีโครงสร้างเป็น ฉันทามติ (consensus), ความขัดแย้ง (contradictions), การครอบคลุมบางส่วน (partial coverage), มุมมองเชิงลึกเฉพาะตัว (unique insights), จุดบอด (blind spots)
- จากการวิเคราะห์เชิงโครงสร้างนี้ judge model จะเขียนคำตอบสุดท้าย
องค์ประกอบและการตั้งค่าของพาเนล
- พาเนลเริ่มต้นใช้ พรีเซ็ต Quality
- หากต้องการสมาชิกที่ราคาถูกกว่า สามารถสลับไปใช้ พรีเซ็ต Budget ได้
- สามารถ override พาเนลและผู้ตัดสินได้ทั้งหมดผ่านฟิลด์
analysis_modelsและmodelของ fusion plugin
- แนะนำให้ใช้เมื่อโมเดลเดี่ยวไม่เพียงพอ
- เหมาะกับ งานวิจัย, การวิจารณ์โดยผู้เชี่ยวชาญ หรือโดเมนที่ต้นทุนของคำตอบผิดสูงกว่าต้นทุนการสร้างคำตอบเพิ่มเติม
ราคาและข้อจำกัด
- เนื่องจากมีการเรียกใช้ทั้งสมาชิกทุกตัวในพาเนลและ judge ค่าบริการต่อคำขอจึงคิดจาก ผลรวมของ completion แต่ละตัว ไม่ใช่ตามเกณฑ์โมเดลเดี่ยว
- สามารถตรวจสอบว่าโมเดลใดถูกเรียกใช้จริงได้ในหน้า Activity
- ขีดจำกัดคอนเท็กซ์จะแตกต่างกันไปตามโมเดลที่เลือก
พรีเซ็ตใช้ 6 โมเดล
- คุณภาพสูงสุด: Claude Opus, OpenAI GPT, Google Gemini Pro
- ต้นทุนต่ำสุด: Google Gemini Flash, DeepSeek V4 Flash, MoonshotAI Kimi
ประกาศที่เกี่ยวข้อง: "Fusion ก้าวข้ามประสิทธิภาพระดับ frontier"
- เป็นเครื่องมือที่สังเคราะห์ผลลัพธ์จากหลายโมเดลเพื่อให้เหนือกว่าประสิทธิภาพของโมเดลเดี่ยว โดยสามารถเลือกได้เองทั้ง พาเนลของโมเดลที่เข้าร่วม และ judge model ที่ใช้หลอมรวมผลลัพธ์ แล้วเรียกใช้ได้เหมือนโมเดลเดี่ยว
- จากการวัดผล 100 งาน deep research ของ เกณฑ์มาตรฐาน DRACO พบว่าพาเนลทำได้ดีกว่าแต่ละโมเดลเดี่ยวอย่างสม่ำเสมอ
- การหลอมรวม Fable 5 + GPT-5.5 ได้ 69.0% สูงกว่าโมเดลเดี่ยวทุกตัว รวมถึง Fable 5 เดี่ยว (65.3%)
- พาเนลต้นทุนต่ำ (Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro) ใช้ ต้นทุน 50% แต่ทำคะแนนห่างจาก Fable 5 ไม่ถึง 1% และเหนือกว่า GPT-5.5 กับ Opus 4.8
- พรอมป์ต์จะถูก ส่งแบบขนาน ไปยังโมเดลในพาเนล จากนั้น judge จะวิเคราะห์จุดที่เห็นพ้อง ความขัดแย้ง มุมมองเชิงลึกเฉพาะตัว และจุดบอด แล้วโมเดลที่ถูกเรียกใช้จะเขียนคำตอบสุดท้ายบนพื้นฐานดังกล่าว
- ไปป์ไลน์ทั้งหมดทำงานแบบ server-side จึงใช้งานได้ในลักษณะเดียวกับการเรียกโมเดลเดี่ยว
- แม้แต่กรณีที่นำ Opus 4.8 มา หลอมรวมกับตัวเอง ก็ยังได้ 65.5% เพิ่มขึ้น 6.7 จุดจากการใช้เดี่ยว (58.8%) ยืนยันผลของขั้นตอน synthesis เอง
- พบ ความเสี่ยงของการปนเปื้อน ที่โมเดลในพาเนลอาจค้นหาเกณฑ์การให้คะแนนทางออนไลน์ จึงมีตัวเลือกตั้งค่าเพียงบรรทัดเดียวเพื่อบล็อกรายการยกเว้นของ web search และ web fetch
- มี 4 วิธีในการใช้งาน: Chatroom (ไม่ต้องเขียนโค้ด), Model slug (แทนที่สตริง), Server tool (ควบคุมได้สูงสุด), Plugin (กำหนดพาเนล)
- ไม่ใช่ตัวแทนแบบ drop-in ของ Fable, ยังไม่รวม งานแบบ long-horizon ที่ Fable เด่น และในการเขียนโค้ดเหมาะกับการใช้เป็นเครื่องมือเรียกใช้แบบเลือกเฉพาะกรณี
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เมื่อหลายเดือนก่อนฉันลองทำ Fusion ด้วย MCP ที่ใช้ OpenRouter แนวคิดคืออยากมี “คณะผู้เชี่ยวชาญ” ไว้ให้ไปถามตอนที่ Claude ตัน
หลังจากลองทดสอบและทำเบนช์มาร์กเยอะมาก ก็พบว่าการให้โมเดลหนึ่งประเมินคำตอบของอีกโมเดล ไม่ได้ให้คำตอบที่ดีกว่าอย่างแท้จริง สุดท้ายมันก็เหมือนถามว่า “คำตอบนี้คล้ายกับคำตอบที่คุณจะตอบเองแค่ไหน” และรอบเพิ่มหรือวิธีแก้แบบ “ชัดเจนอยู่แล้ว” ที่ผุดขึ้นมา ก็แทบไม่ต่างจากการเพิ่มอุณหภูมิ เจอวิธีแก้อยู่บ้าง แต่ค่าใช้จ่ายแพงเกินเหตุ ถ้าวิธีนี้เริ่มได้รับความสนใจมากขึ้น ฉันอาจปล่อยของฉันออกมาด้วย
ของฉันจะระบุชัดเจนให้มันหาปัญหาตามระดับความรุนแรง แล้วส่งปัญหาเหล่านั้นผ่านคณะโมเดลตัดสิน ก่อนจะให้แก้เฉพาะสิ่งที่เกินค่า threshold ที่กำหนดในคำตอบต้นฉบับ สิ่งที่ทำให้ผลดีขึ้นมากคือให้โมเดลตัดสินประเมินแยกกันระหว่างแกน ความจริง กับแกน “มีประโยชน์/ควรแก้ไหม” เพราะถ้าบังคับให้หาปัญหา สุดท้ายมันจะกลายเป็นการจับผิดเรื่องเล็กน้อย และแกนความจริงก็ยังดีกว่าสำหรับประเมินโมเดลตรวจจับปัญหาที่เหมาะกับงานของฉัน วิธีนี้ถูกนำไปใช้บางส่วนกับการสร้างคำอธิบายแบบนี้: https://hanzirama.com/character/%E6%9D%A5#explain — ตอนนี้เว็บไซต์นี้กลายเป็นผลพลอยได้เล็ก ๆ จากระบบประเมิน LLM ของฉันไปแล้ว ถ้าต้องการคุณภาพสูงสุด ก็น่าจะต้องตรึงผู้ให้บริการบน OpenRouter ไว้
:exactoอย่างเดียว โดยเฉพาะกับโมเดล open-weight ยังทำให้ได้ผลลัพธ์ที่ดีและทำซ้ำได้ยากอยากรู้เหมือนกันว่ามีคนอื่นรู้สึกไหมว่า ถ้าหลอกให้ LLM เข้าโหมด “ฉันเหนือกว่า” ได้ มันจะนิสัยเสียขึ้นพอตัว
ตอนนี้สถานการณ์ต่างจากเมื่อ 2 ปีก่อนโดยสิ้นเชิง เลยน่ากลับไปดูอีกที [0] https://github.com/Ceroxylon/konsensis
ในแอปของฉันเคยทดสอบโมเดลตัดสินสองตัว ตัวแรกเป็นโมเดลตัดสินสำหรับโมเดลปรับเรซูเม่ โดยเอาเรซูเม่ผลลัพธ์ไปเทียบกับเรซูเม่ต้นฉบับและประกาศงาน แล้วให้คะแนนความเหมาะสมกับความซื่อสัตย์เต็ม 10 คะแนน ซึ่งทำงานได้ดีและมีประโยชน์ ส่วนตัวที่สองเป็นโมเดลรีวิวสำหรับแพลตฟอร์มบอตเทรดดิ้ง LLM โดยใช้ตรวจทานการตัดสินใจของโมเดลหลัก ในกรณีนี้เพราะบอตต้องจัดการกับความกำกวม มันอาจให้โทษมากกว่าประโยชน์ เว้นแต่จะจับความผิดพลาดชัด ๆ ได้ เช่น ตัดสินจากราคาของแท่งเทียนผิด หรือ BUY ทั้งที่ควรเป็น SELL อย่างแรกคือมันเพิ่มความหน่วงในการตัดสินใจ จาก 30 วินาทีเป็น 60 วินาทีสำหรับ Gemma 4 31B หรือก็คูณสองไปเลย อีกอย่างคือโมเดลรีวิวนี้ทำงานเฉพาะกับการตัดสินใจ BUY/SELL ไม่ทำกับ HOLD ดังนั้นเพราะความหน่วงและต้นทุน มันอาจทำให้บอตระวังตัวเกินไปแทนที่จะเพิ่มจำนวนการเทรด เลยคิดว่าถ้าคำตอบตรวจสอบได้ไม่ง่าย ก็ควรใช้โมเดลที่ดีกว่าเพื่อทำให้จบในรอบเดียว มากกว่าจะใช้โมเดลรีวิว ถ้าเป็นอย่างนั้นก็เริ่มไม่ชัดว่าทำไมต้องมีโมเดลตัดสิน และทำไมไม่ให้เอเจนต์ตัวเดิมรีวิวตัวเอง แถมพอไปอ่านข้อความการให้เหตุผลของโมเดลสาย reasoning อย่าง Gemma 4 ก็จะเห็นว่ามันรีวิวตัวเองอยู่แล้ว มันเหมือนพยายามเต็มที่อยู่แล้ว ดังนั้นการทบทวนซ้ำจึงไม่ค่อยเพิ่มข้อมูลอะไร เป็นการทดลองที่น่าสนใจ แต่ต้องประเมินเป็นกรณีไป
ฉันเคยมีพรอมป์ต์ที่ใช้แนวนี้โดยใช้แค่ Claude Code
มาทบทวนปัญหาด้านสถาปัตยกรรมกัน เปิดเอเจนต์ 10 ตัว ให้แต่ละตัวสร้าง persona ของตัวเอง จากนั้นให้รีวิว
_api.goและเขียนรีวิวลงreviews/-review.mdให้แต่ละเอเจนต์อ่านสรุปหน้าของแต่ละรีวิว แล้วตอบกลับรีวิวที่ตัวเองต้องการ 3 อันแบบ round-robin พร้อมเขียนลงresponse/--response.mdจากนั้นให้เขียนคำโต้แย้งต่อคำตอบเหล่านั้นลงrebuttals/-rebuttal.mdสุดท้ายให้แต่ละเอเจนต์เปิดเอเจนต์ใหม่ขึ้นมาอีกตัวเพื่อตรวจทานรีวิว คำตอบ และคำโต้แย้งของตัวเอง แล้วสรุปผลลงfindings/-findings.mdจากนั้นให้อีกเอเจนต์หนึ่งรวมผลทั้งหมดและเขียนลงreview-findings.mdโดยให้มีเวอร์ชันที่กระชับด้วย วิธีนี้ใช้ได้ดีทั้งกับโมเดลแถวหน้าและโมเดลที่โฮสต์ในเครื่อง ล่าสุดที่ฉันใช้คือ Qwen 3.5คุณตรวจดูไฟล์ที่สร้างขึ้นทั้งหมดเพื่อเช็กว่าไม่มี hallucination หรือดูแค่ไฟล์ผลลัพธ์ฉบับย่อสุดท้าย? สงสัยด้วยว่าเจตนาคือให้ hallucination จากหลายเอเจนต์มาหักล้างกันเองจนสุดท้ายเหลือแต่ความจริงหรือเปล่า และเคยเห็นไหมว่าเวอร์ชันสุดท้ายมีอะไรผิดหนัก ๆ ค่าใช้จ่ายก็ดูน่ากังวล แต่ถ้าใช้โมเดลที่โฮสต์ในเครื่องก็น่าจะเบาเรื่องนั้นลงได้ อย่างไรก็ตาม โมเดลที่โฮสต์ในเครื่องยังมีปัญหากับการรันคำสั่งบนเครื่องหรือการเข้าถึงอินเทอร์เน็ตอยู่ไม่ใช่หรือ? ถ้าใช่ แปลว่ามันทำงานโดยอาศัยแค่บริบทของไฟล์นั้น ๆ โดยไม่อ้างอิงส่วนอื่นของโปรเจกต์หรือเปล่า
บริบทพื้นหลังอยู่ที่นี่: Surpassing Frontier Performance with Fusion
https://news.ycombinator.com/item?id=48525392
ที่ UI ดูดีกว่านิดหน่อยคือ https://openrouter.ai/fusion เอง Fusion API ของ OpenRouter จะส่งคำขอไปยังหลายโมเดลพร้อมกัน แล้วให้โมเดลตัดสินนำคำตอบมารวมเป็นคำตอบสุดท้าย บอกกันว่าวิธีนี้ใช้เวลามากขึ้น แต่เพิ่มประสิทธิภาพได้มาก อย่างน้อยก็ในเบนช์มาร์ก deep research ที่พวกเขาทดสอบไว้พอสมควร พรีเซ็ต Budget ประกอบด้วยโมเดลที่ถูกกว่าจำนวน 3 ตัว และในเบนช์มาร์กนั้นให้ผลใกล้เคียง Fable แต่มีค่าใช้จ่ายเพียงครึ่งเดียว พรีเซ็ต Quality ประกอบด้วยโมเดลราคาแพง 3 ตัว ชนะ Fable ได้ แต่มีค่าใช้จ่ายเป็น 2 เท่าของ Fable กราฟพาเรโต: https://openrouter.ai/blog/images/blog/fusion-benchmark-cost... ที่น่าสนใจคือแม้จะหลอมรวมโมเดลเดียวกันกับตัวเอง ประสิทธิภาพก็ยังเพิ่มขึ้น 2xOpus4.8 ให้ผลใกล้เคียง Fable ในเบนช์มาร์ก แต่มีค่าใช้จ่ายเป็น 2 เท่าของ Fable ถ้าผสมโมเดลต่างชนิดกันก็ยังได้ประโยชน์เพิ่มอีกเล็กน้อย ดูเหมือนว่าประโยชน์หลักจะมาจาก การคำนวณเพิ่มในช่วงทดสอบ อยากเห็นงานวิจัยเพิ่มเติม โดยเฉพาะกับโมเดลราคาถูกที่เพิ่งออกมาอย่าง DSV4 เมื่อนำมาหลอมรวมกับตัวเองหรือกับ Mimo และอยากเห็นการแลกเปลี่ยนระหว่างการหลอมรวมซึ่งเป็นการคำนวณแบบขนานในช่วงทดสอบ กับการเพิ่มปริมาณ reasoning หรือการเพิ่มจำนวนเทิร์นด้วย
โดยพื้นฐานแล้วมันคือการ สุ่มตัวอย่างจากพื้นที่ผลลัพธ์ที่เป็นไปได้ให้มากขึ้น ถ้าโมเดลมีโอกาสทำงานบางอย่างสำเร็จ 60% ก็แค่สุ่มตัวอย่าง 5–10 ครั้งแล้วทำอะไรอย่างเสียงข้างมากขึ้นมาได้ พอความแม่นยำของโมเดลสูงขึ้นในโจทย์ที่รวมผลลัพธ์ได้ง่าย วิธีนี้ก็ถูกใช้น้อยลง แต่ถ้ามีตัวตัดสินที่ซับซ้อนขึ้น คือ LLM ที่มีความสามารถ การสุ่มตัวอย่างพื้นที่ผลลัพธ์เพิ่มแล้วคัดเอาส่วนที่ดีออกมาก็ยังเพิ่มประสิทธิภาพได้อยู่
สำหรับผม ฟังดูเหมือน Gemini จะอ่อนกว่าในงานนั้น แต่เก่งกว่าในการโน้มน้าวโมเดลตัดสินให้เชื่อวิธีแก้ของตัวเอง และที่ว่า พาเนล Opus 4.8 สองตัว ได้ผลแทบจะตรงกับ Fable 5 ตัวเดียวเป๊ะ ๆ ก็ชวนให้สงสัยเหมือนกัน มีทางรู้ไหมว่า Anthropic แอบทำอะไรทำนองนี้อยู่เบื้องหลังหรือเปล่า?
ผมลองประเมินแบบเร็ว ๆ เพื่อดูว่ามันต่างเชิงคุณภาพอย่างไรจากการเรียก Opus 4.7 หรือ GPT 5.5 โดยตรง
ตามคาด Fusion ช้ากว่า 7 เท่าและแพงกว่า 4 เท่า ไม่ได้ตั้งใจจะวิจารณ์นะ ผมมองว่า Fusion อยู่ในหมวด “ใช้เมื่อจำเป็นเท่านั้น” https://3fpi5avcqq.evvl.io/
ไอเดียหลักน่าจะเป็นการใช้ Fusion กับโมเดลที่ง่ายและถูกกว่านี้
เลยอยากรู้ว่าเวอร์ชันของพวกเขาจะทนแค่ไหนในการใช้งานจริง
ผมคิดเรื่องนี้มามาก และถ้าจะทำให้เข้าใจง่ายก็อาจมองแต่ละโมเดลเป็น การกระจายทรงระฆัง บนองค์ความรู้ของมนุษย์ ซึ่งแต่ละโมเดลก็มีการกระจายต่างกัน
ถ้าใช้หลายโมเดล คุณสามารถเปลี่ยนการกระจายของอีกโมเดลได้ด้วยข้อความที่อยู่นอกโค้งเดิม แต่พอคิดอีกที ก็สงสัยว่า SFP กับ reinforcement learning ได้เปลี่ยนการกระจายข้อความตั้งต้นไปมากพอหรือยัง จนผลลัพธ์รวมของโมเดลต่าง ๆ จะกลายเป็นสิ่งที่ดีกว่าเดิมได้จริง หรือสุดท้ายก็เป็นแค่ ห้องเสียงสะท้อน กันแน่ ตอนนี้ยังพิสูจน์ไม่ได้ แต่ผมเชื่อว่าไม่ใช่อย่างนั้น
ในเชิงผลลัพธ์เชิงประสบการณ์กับ Fusion ผมเอาคำถามเดียวกับที่ใช้กับ Fable ไปลองบน OpenRouter Fusion แล้วผลกลับแย่กว่า
Fable ดูเหมือนจะเข้าถึงชั้นของความรู้/ความฉลาดที่ลึกพอสมควร ไม่ได้แค่ตอบให้ดูสมเหตุสมผล แต่ยังเสนอการจัดลำดับความสำคัญของสิ่งที่ต้องแก้ และเสนอให้ตัดบางข้อทิ้ง ซึ่งสำหรับผมถือว่าสมเหตุสมผลมาก ขณะที่ Fusion ให้ความรู้สึกเหมือนเอาคำตอบประเภทเดียวกับที่โมเดลล้ำสมัยก่อนยุค Fable เคยให้ มาทำให้หลากหลายขึ้นเล็กน้อย และจากการทดสอบที่จำกัดมากเท่าที่ผมทำได้ตอนที่ยังเข้าถึง Fable อยู่ มันยังไปไม่ถึง ความลึก แบบที่ Fable แตะได้
ช่วงสุดสัปดาห์ ผมได้แรงบันดาลใจจากโมเดล OpenRouter Fusion ใหม่ เลยลองทำดูว่าจะรันสิ่งนี้ใน Claude Code ได้ไหม และจะทำให้คนอื่นลองใช้ได้ง่ายไหม
สิ่งที่ทำขึ้นคือ claude-fusion-launcher — รัน Claude Code บนพาเนลของโมเดล แทนที่จะเป็นโมเดลเดี่ยว และแสดงค่าใช้จ่ายด้วย https://github.com/smorinlabs/claude-fusion-launcher
สงสัยว่าการให้โมเดลเดียวกันสร้างซ้ำหลายครั้งด้วยพรอมป์ต์เดิม แต่ใช้อุณหภูมิสูงขึ้น จะเทียบเท่ากับการรันคนละโมเดลหรือไม่
ผมสงสัยว่าความแปรผันที่สัมผัสได้ระหว่างโมเดล frontier ต่าง ๆ ส่วนหนึ่งค่อนข้างมากอาจมาจากความสุ่มเมื่ออุณหภูมิไม่เป็นศูนย์ โมเดลเหมือนถูกฝึกให้คืนรายการเป็นจำนวนกลม ๆ ที่ดูดี เช่น 5, 10, 15 อาจเป็นเพราะการรบกวนจากการเรียนรู้จากเอกสารการตลาดด้วย นอกจากนี้ recall ในบริบทขนาดใหญ่ก็ยังห่างไกลจาก 100% ดังนั้นถ้าในโค้ดมีบั๊ก 27 จุด ไม่ว่าจะใช้หลายโมเดลหรือเรียกโมเดลเดิมซ้ำหลายรอบ แต่ละรอบอาจเจอ ปัญหา 10 ข้อ ที่ต่างกันจากใน 27 ข้อนั้น
สงสัยว่ามีงานวิจัยอย่างเป็นทางการในด้านนี้หรือไม่ ฉันเองก็เคยลองแนวทางลักษณะนี้ในแบบดัดแปลงมาแล้ว แต่ก็พูดอย่างมั่นใจได้ยากว่าผลลัพธ์ดีกว่า
กังวลว่ามันอาจคล้ายกับการไปถามที่ปรึกษา 2-3 คนแยกกันถึงกลยุทธ์ที่เหมาะสมที่สุดสำหรับธุรกิจ ไม่ค่อยแน่ใจว่าการเอาคำตอบมารวมกันจะได้สิ่งที่ดีกว่าอย่างมีนัยสำคัญจริงหรือไม่
ฉันก็เปิดตัวฟีเจอร์คล้ายกันนี้ใน TrustedRouter แบบโอเพนซอร์ส พร้อมใช้ การเข้ารหัสแบบต้นทางถึงปลายทาง ด้วย: https://trustedrouter.com/