API โมเดล Hy3 แบบไม่เซ็นเซอร์

การถกเถียงว่า "ควรใช้โมเดลไหน" ส่วนใหญ่พูดถึงเพดาน: ตัวไหนเขียนโค้ดได้ดีที่สุด แก้โจทย์คณิตศาสตร์ที่ยากที่สุด ชนะการรันเอเจนต์ที่ยาวที่สุด ไปป์ไลน์ที่มีโครงสร้างไม่ได้ทำงานแบบนั้น งานที่ดึงฟิลด์จากเอกสารแสนฉบับต่อวันไม่ต้องการโมเดลที่เก่งกาจครั้งเดียว — มันต้องการโมเดลที่ถูกต้องในรูปทรงเดิมทุกครั้ง และไม่เคยคืนย่อหน้ามาในที่ที่ควรเป็นออบเจ็กต์ JSON นั่นคือคุณสมบัติที่ Hy3-W8A16 มีอยู่ตรงนี้เพื่อสิ่งนั้น

01Hy3 คืออะไร และมาจากไหน

Hy3 คือโมเดลให้เหตุผลและทำงานเชิงเอเจนต์แบบน้ำหนักเปิดจากทีม Hunyuan ของ Tencent ปล่อยออกมาแบบเต็มเมื่อ 6 กรกฎาคม 2026 ภายใต้สัญญาอนุญาตแบบผ่อนปรน โดยเผยแพร่น้ำหนักบน Hugging Face มันสืบสายจากงาน Mixture-of-Experts ก่อนหน้าของ Tencent ที่ชื่อ Hunyuan-Large เชิงสถาปัตยกรรมมันเป็น MoE แบบเบาบาง: พารามิเตอร์รวม 295 พันล้าน โดยราว 21 พันล้านตัวทำงานต่อโทเค็น ผ่านการเราต์แบบ top-8 บนผู้เชี่ยวชาญ 192 ตัว อยู่บนทรานสฟอร์มเมอร์ 80 ชั้นพร้อม grouped-query attention บวกกับชั้นทำนายหลายโทเค็นขนาด 3.8B แยกต่างหากสำหรับ speculative decoding คอนเท็กซ์ดั้งเดิมคือ 256K — ตรงกับ 262,144 โทเค็นที่เราเปิดให้ใช้พอดี ไม่ใช่การตัดทอนจากอะไรที่ใหญ่กว่า และไม่ใช่การยืดด้วย rope จากอะไรที่เล็กกว่า

อัตราส่วนความเบาบางนั้นคือตัวเลขสำคัญสำหรับคนที่จ่ายเป็นรายโทเค็น: Hy3 แบกความรู้ของโมเดล 295B ไว้ ขณะที่ทำการคำนวณราวเท่ากับโมเดล 21B ต่อการเดินหน้าหนึ่งครั้ง นั่นก็เป็นเหตุผลที่เราจ่ายไหวในการให้บริการมันที่ 8 บิตแทนที่จะบีบให้หนักกว่านั้น — บิลด์ 8 บิตของโมเดลที่เบาบางขนาดนี้ยังใส่ลงเครื่องได้และยังรันเร็วบนคลัสเตอร์ GPU ของเราเอง

Tencent รายงานว่ามันเก่งเรื่องอะไร

ตารางการประเมินที่ Tencent เผยแพร่วางจุดแข็งของ Hy3 ไว้ที่การค้นหาเชิงเอเจนต์ การประสานทูล และการดึงข้อมูลจากคอนเท็กซ์ยาว มากกว่าที่การเขียนโค้ดล้วน ๆ ตัวเลขที่พวกเขารายงาน:

เราแสดงแท่งที่อ่อนไว้โดยตั้งใจ Hy3 ตามหลัง GLM-5.2 ด้านการเขียนโค้ด ในการเปรียบเทียบของ Tencent เอง — 78.0 ต่อ 84.2 บน SWE-bench Verified และ 28.0 ต่อ 46.2 บน DeepSWE ถ้างานของคุณคือวิศวกรรมซอฟต์แวร์หลายไฟล์แบบอัตโนมัติ ให้อ่านดัชนีงานวิจัยโมเดลที่เหลือก่อน ถ้างานคือการอ่านข้อความแล้วปล่อยโครงสร้างออกมา โปรไฟล์นี้ใกล้เคียงอุดมคติ

ตัวเลขที่สำคัญที่สุดสำหรับงานไปป์ไลน์คือตัวเลขด้านความน่าเชื่อถือ: Tencent รายงานอัตราการหลอน (hallucination) ของ Hy3 ที่ 5.4% ลดจาก 12.5% ในรุ่นก่อน โดยข้อผิดพลาดด้านสามัญสำนึกลดจาก 25.4% เหลือ 12.7% หลักการเทรนที่พวกเขาระบุไว้ — ตอบเมื่อมีหลักฐาน และบอกตรง ๆ เมื่อไม่มี — คือนิสัยที่คุณอยากได้พอดีในโมเดลดึงข้อมูล ซึ่งไม่เช่นนั้นจะแต่งค่าที่ดูน่าเชื่อขึ้นมาให้ฟิลด์ที่ต้นฉบับไม่เคยเอ่ยถึง

ตัวเลขทั้งหมดในหัวข้อนี้เป็นตัวเลขที่ Tencent รายงานจากการทดสอบของพวกเขาเอง การตรวจสอบโดยบุคคลที่สามอย่างอิสระยังไม่เสร็จสิ้น ณ เวลาที่เขียน ให้ถือเป็นทิศทาง ไม่ใช่ข้อยุติ

02W8A16 หมายความว่าอย่างไร และทำไมจึงสำคัญกับเอาต์พุตแบบมีโครงสร้าง

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

ระดับ	มันทำอะไร	ความเที่ยง
3BIT-REAP	น้ำหนัก 3 บิตบวก REAP ซึ่งเป็นวิธีตัดผู้เชี่ยวชาญที่ลบผู้เชี่ยวชาญ MoE ซึ่งถูกเราต์ไปหาน้อยออกก่อนการควอนไทซ์	บีบอัดมากที่สุด
W4A16-AUTOROUND-REAP	น้ำหนัก 4 บิต / แอกทิเวชัน 16 บิต ผ่าน AutoRound — การปัดเศษที่เรียนรู้ได้ซึ่งกู้ความแม่นยำคืนจากการปัดไปยังค่าที่ใกล้ที่สุดแบบตรงไปตรงมา — บวกการตัดแบบ REAP	ระดับกลาง
W8A16	น้ำหนัก 8 บิต / แอกทิเวชัน 16 บิต ไม่มีการตัด ไม่มีการซ่อมด้วยการปัดเศษที่เรียนรู้ได้ — แค่แบกน้ำหนักไว้ที่ความละเอียดสองเท่า	สูงที่สุด

การเลื่อนไหลจากการควอนไทซ์เจ็บตรงไหนจริง ๆ

REAP และ AutoRound กู้คืนสิ่งที่การบีบอัดแบบตรงไปตรงมาสูญเสียไปได้เกือบหมด — แต่คำว่า "เกือบ" ทำงานหนักในประโยคนั้น และเศษที่เหลือไม่ได้ตกลงมาอย่างเท่าเทียม การควอนไทซ์บิตต่ำทำให้ส่วนหางเสื่อม: การตัดสินใจที่ความน่าจะเป็นต่ำและความเฉพาะเจาะจงสูง ในร้อยแก้วมันแทบมองไม่เห็น คำคุณศัพท์ที่ต่างออกไปก็ยังเป็นประโยคที่ดีอยู่ ในเอาต์พุตแบบมีโครงสร้างมันคือทั้งหมดของเกม เพราะสคีมาคือห่วงโซ่ยาวของการตัดสินใจที่ความน่าจะเป็นต่ำ ซึ่งแต่ละข้อต้องถูกต้องเป๊ะ:

• ไวยากรณ์ระดับโทเค็น วงเล็บปีกกาปิด เครื่องหมายจุลภาค อัญประกาศ แต่ละอันคือหนึ่งโทเค็น และโทเค็นผิดเพียงตัวเดียวทำให้คำตอบทั้งก้อนใช้ไม่ได้
• วินัยของ enum สคีมาของคุณบอกว่า "status" ต้องเป็นหนึ่งใน "open" | "closed" | "pending" โมเดลที่เลื่อนไหลคืน "Open" หรือ "pending review" — ใกล้เคียงในเชิงความหมาย แต่ไม่ถูกต้องทั้งคู่
• วินัยของชนิดข้อมูล ฟิลด์ number กลับมาเป็น "1,240" ฟิลด์ boolean กลับมาเป็น "yes" ทั้งคู่ถูกแยกวิเคราะห์เป็นสตริงและไม่ผ่านสคีมา
• ค่าคงที่ส่วนหางยาว คำนามเฉพาะที่พบได้ยาก รหัสชิ้นส่วน ชื่อสารเคมี อักษรที่ไม่ใช่ละติน วันที่ที่ต้องเป๊ะ — ล้วนอยู่ในย่านความน่าจะเป็นต่ำที่น้ำหนักบิตต่ำทำให้พร่าพอดี

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

03เอาต์พุตแบบมีโครงสร้าง: json_schema และ response_format

Hy3 รองรับทั้งสองครึ่งของพื้นผิวเอาต์พุตแบบมีโครงสร้าง — ควรระบุให้ชัด เพราะเรื่องนี้ไม่ได้เป็นสากลทั้งชุดโมเดล:

โมเดล	response_format	json_schema
Hy3 · W8A16	ได้	ได้
MiMo-V2.5-Pro · W8A16	ได้	ได้
inkling · W4A16-AUTOROUND-REAP	ได้	ไม่ได้
Laguna-S-2.1 · W4A16-AUTOROUND-REAP	ไม่ได้	ไม่ได้

ความต่างระหว่างสองกลไกนี้สำคัญกว่าที่คนคิด response_format: {"type": "json_object"} ขอแค่ JSON ที่ถูกต้อง ไม่มากไปกว่านั้น — โมเดลเป็นคนเลือกรูปทรงเอง การเรียกสองครั้งจึงคืน {"name": ...} กับ {"full_name": ...} ได้และถูกต้องทั้งคู่ ส่วน json_schema กำหนดรูปทรงไว้ล่วงหน้า: ชื่อฟิลด์ ชนิดข้อมูล enum รายการฟิลด์ที่จำเป็น การซ้อนกัน นั่นคือสัญญาที่คุณเขียนโค้ดอิงได้

ตัวอย่างการเรียกขั้นต่ำบนภาษาถิ่นที่เข้ากันได้กับ OpenAI:

POST /v1/chat/completions

{
  "model": "Hy3-W8A16",
  "messages": [
    {"role": "system", "content": "Extract fields from the incident report. Use null for anything not stated."},
    {"role": "user", "content": "<report text>"}
  ],
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "incident",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "severity":  {"type": "string", "enum": ["low","medium","high","critical"]},
          "component": {"type": "string"},
          "occurred_at": {"type": ["string","null"], "description": "ISO-8601"},
          "affected_users": {"type": ["integer","null"]},
          "indicators": {
            "type": "array",
            "items": {"type": "object", "properties": {
              "kind":  {"type": "string", "enum": ["ip","domain","hash","cve"]},
              "value": {"type": "string"}
            }, "required": ["kind","value"]}
          }
        },
        "required": ["severity","component","occurred_at","affected_users","indicators"]
      }
    }
  }
}

ข้อสังเกตเชิงปฏิบัติ

• ทำให้ทุกฟิลด์เป็น required และอนุญาต null ฟิลด์ที่เป็นทางเลือกชวนให้เกิดการตกหล่นแบบเงียบ ๆ ส่วนฟิลด์ที่จำเป็นแต่รับค่า null ได้จะบังคับให้ระบุ "ไม่ปรากฏ" อย่างชัดเจน ซึ่งเป็นข้อมูลที่คุณเอาไปทำอะไรต่อได้
• enum ดีกว่าสตริงอิสระ ตรงไหนที่คุณปิดชุดค่าได้ ให้ปิด — เป็นการเปลี่ยนแปลงที่ให้ผลมากที่สุดต่ออัตราผ่านจริงของสคีมา
• อยู่ใต้เพดานเอาต์พุต 16,384 โทเค็น อาร์เรย์ที่ไม่จำกัดขอบเขตจะถูกตัดกลางออบเจ็กต์ ให้จำกัดความยาวอาร์เรย์ หรือแบ่งอินพุตเป็นชิ้น
• อย่าตัดข้อความระบบทิ้ง สคีมาจำกัดรูปทรง แต่พรอมป์ยังคุมความหมาย — อะไรนับเป็น "critical" วันที่ไหนชนะเมื่อมีสองวัน จะแปลงหน่วยให้เป็นมาตรฐานหรือไม่
• ตรวจสอบความถูกต้องอยู่ดี การรองรับสคีมาช่วยยกอัตราผ่าน แต่ไม่ได้ทดแทนตัวตรวจสอบและคิว dead-letter

04ทำไม "ไม่เซ็นเซอร์" จึงเป็นคุณสมบัติด้านความน่าเชื่อถือ ไม่ใช่แค่ด้านเนื้อหา

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

ยังมีเหตุผลที่สองซึ่งเป็นเชิงกลไกกว่า การปฏิเสธคือการละเมิดสคีมา โมเดลที่ถูกกรองแล้วปฏิเสธ ไม่ได้คืนออบเจ็กต์ของคุณพร้อมธง "unavailable" — มันคืนร้อยแก้ว "ฉันช่วยเรื่องคำขอนี้ไม่ได้" สตริงนั้นไม่ใช่ออบเจ็กต์ incident มันไม่ผ่านตัวตรวจสอบของคุณและไปตกอยู่ในคิว dead-letter ข้าง ๆ ข้อผิดพลาดการแยกวิเคราะห์ของจริง ซึ่งตอนนี้คุณต้องมานั่งแยกการปฏิเสธเชิงนโยบายออกจากความผิดรูปที่แท้จริง

แย่กว่านั้น การปฏิเสธมีสหสัมพันธ์กับเนื้อหา แทนที่จะกระจายแบบสุ่ม ถ้า 4% ของคลังข้อมูลคุณเป็นรายงานเหตุการณ์ด้านความปลอดภัย และโมเดลปฏิเสธเสียส่วนใหญ่ คุณไม่ได้เสียปริมาณงาน 4% อย่างสม่ำเสมอ — คุณเสียไปทั้งหมวด และแดชบอร์ดที่สร้างบนข้อมูลนั้นก็รายงานต่ำกว่าจริงอย่างเงียบ ๆ ในเรื่องที่มันมีอยู่เพื่อเปิดเผยพอดี รูโหว่ที่มีรูปทรงตามหมวดหมู่แพงกว่าสัญญาณรบกวนที่สม่ำเสมอ เพราะไม่มีอะไรมาเตือน เอาเส้นทางการปฏิเสธออก แล้วสิ่งที่เหลือ — ความผิดรูป การถูกตัดกลางคัน ข้อความที่กำกวม — จะไม่มีสหสัมพันธ์กับหัวข้อ และจึงวัดได้

05คอนเท็กซ์ เพดานเอาต์พุต และวิธีจัดงบทั้งสอง

ทุกโมเดลบนเกตเวย์ใช้ขีดจำกัดเดียวกัน:

คอนเท็กซ์เป็นงบร่วม: พรอมป์บวกเอาต์พุตต้องใส่ลงใน 262,144 ด้วยกัน เพดานอินพุตในทางปฏิบัติต่อการเรียกหนึ่งครั้งจึงอยู่ราว 245,000 โทเค็น คร่าว ๆ คือราว 180,000 คำภาษาอังกฤษ สำหรับงานที่มีโครงสร้าง เพดานเอาต์พุต 16,384 โทเค็นคือขีดจำกัดที่แข็งกว่าและเป็นตัวที่ทำคนตกใจ — สคีมาที่ปล่อยหนึ่งออบเจ็กต์ต่อหนึ่งเรกคอร์ดจะชนเพดานนี้นานก่อนที่หน้าต่างจะเต็ม มีสองรูปแบบที่ใช้รับมือได้:

• อินพุตกว้าง เอาต์พุตแคบ ดันสัญญาทั้งฉบับ เอกสารยื่น หรือช่วงล็อกทั้งช่วงเข้าไปในคอนเท็กซ์ แล้วขอออบเจ็กต์กะทัดรัดอันเดียว โทเค็นอินพุตราคาเป็นหนึ่งในสี่ของโทเค็นเอาต์พุต โครงสร้างราคาจึงให้รางวัลกับการอ่านเยอะและเขียนน้อย
• แบ่งชิ้นตามขอบเขตของเรกคอร์ด ไม่ใช่ตามจำนวนไบต์ แบ่งตรงที่โมเดลมองเห็นรอยต่อได้ เรกคอร์ดที่ถูกตัดกลางประโยคจะให้ออบเจ็กต์ที่ผิดอย่างมั่นใจ แทนที่จะเป็นความล้มเหลวที่เห็นได้ชัด

จุดแข็งด้านการดึงข้อมูลจากคอนเท็กซ์ยาวที่ Hy3 ถูกรายงานไว้ — 73.4 บน AA-LCR และการกระโดดจาก 42.9% เป็น 75.1% บนการเรียกคืนบทสนทนายาว MRCR — คือความสามารถที่รูปแบบแรกพึ่งพาพอดี และเป็นทักษะคนละอย่างกับการเขียนได้ดี

06ราคาพื้น และเลขคณิตของไปป์ไลน์จริง

Hy3 อยู่ที่ $0.50 ต่อโทเค็นอินพุตหนึ่งล้านโทเค็น และ $2.00 ต่อโทเค็นเอาต์พุตหนึ่งล้านโทเค็น — ราคาพื้นของชุดโมเดล ใช้ร่วมกับ MiMo-V2.5, MiMo-V2.5-Pro, DeepSeek-V4-Flash-0731 และ MiniMax-M3 คิดผ่านโหลดตัวอย่าง:

ลักษณะงาน	อินพุต / ครั้ง	เอาต์พุต / ครั้ง	ต้นทุน / ครั้ง	ต่อ 1M ครั้ง
การดึงฟิลด์	1,200	300	$0.0012	$1,200
การจำแนกเอกสาร	3,000	120	$0.0018	$1,800
สรุปเอกสารยาวลงเป็นสคีมา	40,000	900	$0.0218	$21,800
การวิเคราะห์เต็มหน้าต่าง	240,000	2,000	$0.1240	$124,000

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

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

07สามภาษาถิ่น API หนึ่งโมเดล

Hy3 เข้าถึงได้บนทั้งสามภาษาถิ่นของเกตเวย์ พร้อมการสตรีมในทุกแบบ โมเดลเดียวกัน น้ำหนักเดียวกัน ขีดจำกัดเดียวกัน — เลือกอันที่ตรงกับ SDK ที่คุณมีอยู่แล้ว

เอนด์พอยต์	ภาษาถิ่น	ใช้เมื่อ
/v1/chat/completions	OpenAI	คุณมี OpenAI SDK, LangChain หรือ LlamaIndex อยู่แล้ว ชี้ base URL มาที่นี่ แล้วเปลี่ยน model id
/v1/messages	Anthropic	คุณใช้ Anthropic SDK และอยากได้คอนเท็นต์บล็อกโดยไม่ต้องมีชั้นแปลง
/v1/responses	Responses	คุณต้องการรูปแบบคำขอที่ใหม่กว่าพร้อมเอาต์พุตที่ระบุชนิดและสถานะฝั่งเซิร์ฟเวอร์

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

เอกสารอ้างอิงคำขอและคำตอบฉบับเต็ม รายการพารามิเตอร์ ความหมายของการสตรีม และเพลย์กราวด์แบบโต้ตอบ อยู่ในเอกสาร API

08การเลือกระหว่างโมเดล W8A16 ทั้งสามตัว

มีสามโมเดลอยู่บนระดับความเที่ยงสูงสุด ทุกตัวอยู่ที่ราคาพื้น การเลือกส่วนใหญ่ขึ้นกับโมดัลลิตี:

โมเดล	วิชัน	json_schema	ราคา เข้า / ออก	เลือกมันเพื่อ
Hy3 · W8A16	ไม่ได้	ได้	$0.50 / $2.00	ไปป์ไลน์ข้อความล้วนแบบมีโครงสร้าง การประสานทูล การดึงข้อมูลจากคอนเท็กซ์ยาว
MiMo-V2.5-Pro · W8A16	ไม่ได้	ได้	$0.50 / $2.00	งานข้อความล้วนที่คุณต้องการการจูนระดับ Pro ของตระกูล MiMo
MiMo-V2.5 · W8A16	ได้	ได้	$0.50 / $2.00	อะไรก็ตามที่มีรูปภาพ — เอกสารสแกน ภาพหน้าจอ ภาพถ่าย

ถ้าส่วนใดของอินพุตคุณเป็นรูปภาพ การตัดสินใจก็จบแล้ว: Hy3 เป็นข้อความล้วน — ส่ง PDF ที่สแกนมา ภาพหน้าจอ และภาพถ่ายไปที่ MiMo-V2.5 ส่วนที่อินพุตเป็นข้อความจริง ๆ โปรไฟล์ของ Hy3 ทั้งการใช้ทูลเชิงเอเจนต์ การเรียกคืนจากคอนเท็กซ์ยาว และอัตราการหลอนที่รายงานไว้ต่ำ สอดคล้องกับงานไปป์ไลน์โดยตรงที่สุด และเพราะทั้งสามตัวราคาเท่ากัน ให้รันสคีมาของคุณกับสองตัวบนเรกคอร์ดจริงสักไม่กี่ร้อยรายการแล้วเทียบอัตราการแยกวิเคราะห์สำเร็จ นั่นตัดสินได้ดีกว่าตารางใด ๆ รวมถึงตารางนี้

09Hy3 พิสูจน์คุณค่าของมันตรงไหน

• การดึงฟิลด์ปริมาณสูง สัญญา เอกสารยื่น รายงานเหตุการณ์ บทถอดความ บันทึกทางคลินิก บันทึกศาล — ที่ไหนก็ตามที่ผลลัพธ์คือออบเจ็กต์ระบุชนิดหนึ่งอันต่อเอกสาร และปริมาณงานทำให้การลองใหม่แพง
• การจำแนกและการเราต์ในสเกลใหญ่ เอาต์พุตแบบ enum ปิด ซึ่งคุณค่าทั้งหมดของโมเดลคือการไม่คิดหมวดที่สิบเก้าขึ้นมาเอง
• คลังข้อมูลด้านความปลอดภัยและข่าวกรองภัยคุกคาม รายงานมัลแวร์ การเปิดเผยช่องโหว่ และตัวอย่างฟิชชิง — เป็นวัสดุที่ทำให้โมเดลซึ่งถูกกรองสะดุดไปสู่การปฏิเสธ และเป็นที่ที่รูโหว่รูปทรงตามหมวดหมู่ทำลายจุดประสงค์ทั้งหมด
• เอเจนต์ที่เรียกใช้ทูลและต้องไม่ค้าง ความเที่ยงระดับ 8 บิตของอาร์กิวเมนต์หมายความว่า JSON ที่ส่งให้ฟังก์ชันของคุณแยกวิเคราะห์ผ่าน การเรียกทูลที่เละคือเอเจนต์ที่ค้าง ไม่ใช่แค่คำตอบที่แย่ลงนิดหน่อย
• การวิเคราะห์เอกสารยาวให้ออกมาเป็นโครงสร้าง ใส่เอกสารยื่นทั้งฉบับเข้าไป ได้ออบเจ็กต์กะทัดรัดออกมาหนึ่งอัน
• การคัดกรองเนื้อหาและงานวิจัยเชิงนโยบาย การติดป้ายวัสดุที่โมเดลซึ่งถูกกรองปฏิเสธจะอ่าน เป็นปัญหาค้างคาของงานความไว้วางใจและความปลอดภัย โมเดลที่ไม่ถูกกรองพร้อมสคีมาแบบเข้มงวดแก้ปัญหานั้นได้ตรง ๆ

และตรงไหนที่มันไม่เหมาะ: อะไรก็ตามที่มีรูปภาพ (ใช้ MiMo-V2.5) และวิศวกรรมซอฟต์แวร์หลายไฟล์แบบอัตโนมัติ ซึ่งตารางของ Tencent เองวาง Hy3 ไว้ตามหลัง GLM-5.2 บน SWE-bench Verified และตามหลังอยู่มากบน DeepSWE

ตัวเลขเบนช์มาร์กเป็นตัวเลขที่ Tencent รายงาน รวมถึงตัวเลขของคู่แข่งด้วย การตรวจสอบอย่างอิสระยังไม่เสร็จสิ้น ณ เวลาที่เขียน ตัวเลขต้นทุนคำนวณจากอัตรา $0.50 / $2.00 ที่เราประกาศไว้ ไม่มีตัวเลขใดในหน้านี้ที่เป็นเบนช์มาร์กที่ Shannon รันเองหรือเป็นการประมาณการ

10คำถามที่พบบ่อย

---

แหล่งอ้างอิง: Tencent Hunyuan model cards · Hy3 repository · Hunyuan-Large: An Open-Source MoE Model (arXiv 2411.02265) · VentureBeat coverage of the Hy3 release เบนช์มาร์กของโมเดลฐานเป็นตัวเลขที่ Tencent รายงานและยังเป็นการชั่วคราวระหว่างรอการตรวจสอบอย่างอิสระ Shannon AI ดำเนินการโดย Shannon Lab LLC รัฐนิวเม็กซิโก สหรัฐอเมริกา