AesCode-8B เปิดตัวเงียบๆ: โมเดล 8B ของ Microsoft เขียนสไลด์และแดชบอร์ดเป็น HTML

ตัวเลขที่น่าสนใจที่สุดในการเปิดตัวครั้งใหม่ของไมโครซอฟต์คือ 1.00 ถ้าไม่ป้อนภาพอ้างอิงให้กับ AesCode-8B — โมเดลขนาด 8 พันล้านพารามิเตอร์ที่เขียนสไลด์ โปสเตอร์ และแดชบอร์ดออกมาเป็น HTML และ CSS ที่แก้ไขได้ — คะแนนด้านภาพของมันจะลดลงหนึ่งคะแนนจากหนึ่งร้อย และถ้าไม่ป้อนภาพอ้างอิงเดียวกันให้กับ Qwen3-VL-8B-Instruct ซึ่งเป็นโมเดลน้ำหนักเปิดที่ AesCode-8B ถูกปรับละเอียดต่อมาจากนั้น คะแนนจะลดลงถึง 19.55 คะแนน ส่วน GPT-5.5 ลดลง 10.04 การเปรียบเทียบนี้เองคือที่อยู่ของผลการวิจัยที่แท้จริง และมันซ่อนอยู่ใต้พาดหัวข่าวที่ไมโครซอฟต์เผยแพร่เช่นกันว่า บนเกณฑ์ให้คะแนน 300 ตัวอย่างของตัวเอง คะแนนรวม 82.94 ของ AesCode-8B เฉือนเอาชนะ GPT-5.5 แบบมีเงื่อนไขภาพอ้างอิงที่ 81.28 และ Claude Opus 4.8 ที่ 80.39 โดยมีรุ่นพี่ที่ใหญ่กว่า AesCode-32B อยู่ที่ 85.89

ไม่มีการประกาศอะไรเกี่ยวกับการเปิดตัวนี้เลย Microsoft ได้คอมมิตน้ำหนักโมเดลบน Hugging Face เมื่อวันที่ 2026-10-07 ภายใต้ Apache 2.0 — AesCode-8B พร้อมกับคู่หูขนาด 32B ที่สร้างด้วยวิธีเดียวกันจาก Qwen3-VL-32B-Instruct — และพุชโค้ดการฝึกและการประเมินไปยัง GitHub ในวันถัดมา ไม่มีโพสต์บล็อกของ Microsoft Research ไม่มีบันทึกการเปิดตัว ไม่มีหน้าผลิตภัณฑ์ และไม่มี preprint: การอ้างอิงใน model card เขียนว่า "Under review" ปี 2027 ซึ่งเป็นตัวยึดตำแหน่งมากกว่าจะเป็นวันที่ ณ วันที่ 2026-10-11 รีโพซิทอรี 8B แสดงยอดดาวน์โหลด 2 ครั้งและมีผู้กดถูกใจ 1 ครั้ง; รีโพซิทอรี GitHub แสดงดาว 1 ดวง ทุกอย่างด้านล่างที่มีตัวเลขกำกับนั้น ไม่ว่าจะเป็นการประทับเวลาที่คุณตรวจสอบได้เองหรือตัวเลขที่ Microsoft รายงานเกี่ยวกับชุดการประเมินของตัวเอง — และความแตกต่างนี้สำคัญกว่าปกติในที่นี้ เพราะไม่มีส่วนใดของโมเดลนี้ที่ถูกวัดโดยคนอื่นเลย

สิ่งที่จัดส่งแล้ว และสิ่งที่ไม่ได้อยู่ในกล่อง

สามวันนิยามรีลีสนี้ และเป็นวันที่ทั้งหมดที่มีอยู่ในนั้น ที่เก็บ Hugging Face สำหรับmicrosoft/AesCode-8Bถูกสร้างขึ้นเมื่อ 2026-09-29 เวตถูกคอมมิตภายใต้ข้อความ "Release AesCode-8B" เมื่อ 03:35 UTC ของวันที่ 2026-10-07 และmicrosoft/AesCode ซึ่งเป็นที่เก็บโค้ดได้เปิดสู่สาธารณะในวันถัดมา 2026-10-08 เมื่อ 23:14 UTC เวต 32B ลงในหน้าต่างคอมมิตเดียวกัน ไม่มีสิ่งใดในระหว่างนั้นถูกประกาศที่ไหนเลย

• น้ำหนัก — ไฟล์ safetensors จำนวนสี่ชาร์ด รวมขนาดทั้งสิ้น 17,543,339,408 ไบต์ ซึ่งคิดออกมาได้ประมาณ 8.8 พันล้านพารามิเตอร์แบบ bf16 ไมโครซอฟต์ติดป้ายโมเดลนี้ว่า 8B ส่วนฟิลด์ size ของ Hugging Face ปัดเป็น 9B นั่นคือการปัดเศษ ไม่ใช่ความไม่สอดคล้องกัน

• สถาปัตยกรรม — การฟայน์ทูนโดยตรงของสูตร Qwen3-VL: Qwen3VLForConditionalGeneration, 36 เลเยอร์ซ่อน, ขนาดซ่อน 4,096, 32 หัวความสนใจพร้อม 8 หัว key-value, คำศัพท์ 151,936 โทเคน และตำแหน่ง mrope แบบสลับ ต้องใช้ transformers 4.57 หรือใหม่กว่า

• บริบทและเอาต์พุต — การรันที่รายงานใช้บริบทขนาด 24,576 โทเค็น โดยมีเอาต์พุตสูงสุด 12,000 โทเค็น สร้างที่อุณหภูมิ 0.8 และ top-p 0.95 จากการโรลเอาต์สามครั้งต่อพรอมต์โดยไม่มีการเลือก คำสั่งให้บริการ vLLM อนุญาตให้มีสองภาพต่อพรอมต์: ภาพอ้างอิง และไม่มีอย่างอื่น เพราะเอาต์พุตเป็นข้อความ

• สัญญาอนุญาต — Apache 2.0 โดยระบุว่าใช้โครงสร้างหลักตามแบบ Qwen3-VL อนุญาตแบบเปิดกว้างเต็มรูปแบบ ไม่มีข้อจำกัดการเข้าถึง ไม่มีภาคผนวกว่าด้วยการใช้งานที่ยอมรับได้

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

• ไม่มีมาให้ในกล่องเช่นกัน — เอนด์พอยต์แบบโฮสต์ใด ๆ เราไม่พบ API ที่ให้บริการ AesCode-8B ที่ไหนเลย และมันก็ไม่อยู่ในแคตตาล็อกของเราเองด้วย จนกว่าจะมีผู้ให้บริการรับไปดูแล การประเมินมันจึงหมายถึงการโหลดเวตลงบน GPU ของคุณเอง

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

ผลลัพธ์ 1.00 คะแนน อธิบาย

นี่คือกลไกเบื้องหลังตัวเลขในย่อหน้าแรก ในระหว่างการฝึก ทุกพรอมป์ต์จะถูกจับคู่กับภาพอ้างอิงที่สร้างขึ้นจากพรอมป์ต์เดียวกันนั้น — การรันของไมโครซอฟต์เองใช้ GPT-Image-2 สำหรับภาพ และ GPT-5.5 เพื่อขยายไอเดียสั้น ๆ ให้เป็นพรอมป์ต์เนื้อหาฉบับละเอียด ภาพอ้างอิงไม่มีอำนาจเหนือเนื้อหา พรอมป์ต์ข้อความยังคงเป็นแหล่งความจริง สิ่งที่ภาพอ้างอิงมอบให้คือเลย์เอาต์และสไตล์ และฟังก์ชันรางวัลถูกสร้างขึ้นเพื่อแยกสองสิ่งนั้นออกจากกัน

ผลที่ตามมาคือ ไพรเออร์เชิงภาพไปลงเอยอยู่ในนโยบายแทนที่จะอยู่ในอินพุต AesCode-8B สูญเสียคะแนน Visual 1.00 คะแนนเมื่อนำเรเฟอเรนซ์ออกระหว่างการอินเฟอเรนซ์ แบ็กโบนของมันเอง ซึ่งประเมินแบบมีเงื่อนไขเรเฟอเรนซ์ที่ 44.72 Visual สูญเสีย 19.55 คะแนนเมื่อไม่มีเรเฟอเรนซ์ GPT-5.5 สูญเสีย 10.04 เวอร์ชันกลั่นของสิ่งนั้น: โมเดลเลิกต้องการภาพ

ครึ่งหลังของผลลัพธ์คือส่วนที่มองข้ามได้ง่าย Microsoft รายงานว่ารางวัลที่อิงกับ reference ทำให้ Visual แบบ prompt-only เพิ่มขึ้นจาก 25.17 เป็น 69.71 — โมเดลที่ไม่เคยเห็น reference ในเวลาทำ inference ก็ยังได้รับประโยชน์จากการที่ได้ถูกฝึกกับสิ่งเหล่านั้น หากคุณวางแผนจะข้ามขั้นตอนการสร้าง reference ในไปป์ไลน์ของคุณเอง นั่นคือตัวเลขที่บอกว่าคุณก็ไม่ควรข้ามมันในการฝึกเช่นกัน

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

ที่ซึ่งรสนิยมซึมเข้าสู่น้ำหนัก

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

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

• เจ็ดช่องทางรางวัลตัวตรวจสอบแบบกำหนดแน่นอนได้หกตัวตรวจสอบสิ่งที่ไม่ต้องตีความ — การประมวลผล ข้อความที่ตรงเป๊ะ ขอบเขต ข้อมูลตารางและแผนภูมิ เลย์เอาต์เชิงความหมาย ช่องว่าง — และ Visual Graph Rubric เฉพาะตัวอย่าง ซึ่งสร้างขึ้นเป็นคำถามใช่/ไม่ใช่ที่ผูกกับกราฟเกี่ยวกับเรขาคณิตและการจัดวาง จะให้คะแนนส่วนที่เหลือ ช่องทางเหล่านี้คือ execution, text, boundary, tablechart, layout, whitespace และ design

• ช่องสัญญาณจะถูกนอร์มัลไลซ์ก่อนที่จะนำมารวมกัน GDPO ทำการนอร์มัลไลซ์แต่ละช่องสัญญาณภายในกลุ่ม rollout ของตน ดังนั้นสัญญาณที่อิงกฎแบบหนาแน่นจึงไม่สามารถกลบสัญญาณภาพแบบเบาบางได้ Microsoft วัดผลนี้ได้ที่ 5.12 คะแนน Visual เหนือกว่า GRPO แบบสเกลาร์ล้วนโดยใช้การตั้งค่าเดียวกัน — เป็นผลที่ผู้ขายรายงาน แต่เป็น ablation ที่เป็นรูปธรรมมากกว่าการกล่าวอ้าง

• การให้คะแนนเกิดขึ้นจากการเรนเดอร์ HTML ของผู้สมัครจะถูกเรนเดอร์ในเบราว์เซอร์ Playwright แบบแซนด์บ็อกซ์โดยบล็อกคำขอภายนอก และฮาร์เนสจะอ่านข้อมูลกลับจาก DOM, สไตล์ที่คำนวณได้, กรอบขอบเขต, สถานะคอนโซล และภาพหน้าจอ ตารางต้องเป็นตาราง HTML; แผนภูมิต้องเป็นสเปก ECharts ข้อจำกัดนี้ทำงานจริง ๆ — มันบังคับให้ผลลัพธ์ออกมาในรูปแบบที่ตัวตรวจสอบสามารถแยกวิเคราะห์ได้

• ตัวสูตรเอง การทำ supervised fine-tuning แบบ cold-start บนตัวอย่างสาธิต 3,000 รายการ ที่อัตราการเรียนรู้ 1e-5 จากนั้นทำ GDPO กับพรอมป์ 7,408 รายการ เป็นเวลา 400 สเต็ป บนเอนจินไฮบริด FSDP-vLLM ของ verl โดยไม่มี critic และไม่มีโมเดลรางวัลที่ฝึกแยกต่างหาก ใช้ AdamW ที่ค่า 5e-6 คงที่ ไม่มี warmup, weight decay 0.01, 128 พรอมป์ต่อสเต็ป โดยแต่ละรายการมี 8 rollout, ค่าสัมประสิทธิ์ KL และ entropy ทั้งคู่เป็น 0.001, พรอมป์และคำตอบถูกจำกัดไว้อย่างละ 8,192 โทเคน การรันที่เผยแพร่ใช้โหนดเดียวที่มี NVIDIA B200 แปดตัว AesCode-32B ใช้สูตรเดียวกันเป็นเวลา 520 สเต็ป

เมื่ออ่านโดยภาพรวม นี่คือบทความด้านการออกแบบรางวัลที่แต่งตัวเป็นประกาศเปิดตัวโมเดล — และนั่นสอดคล้องกับการอ้างอิงที่ระบุว่า “Under review” มากกว่าจะชี้ไปที่ไพรพรินต์

กระดานคะแนน และใครที่รับรองมัน

ทั้งหมดต่อไปนี้คือการประเมินของ Microsoft เอง ซึ่งรายงานไว้ในการ์ดโมเดล จากตัวอย่างอินโฟกราฟิก 300 ตัวอย่าง Rule คือค่าเฉลี่ยของการตรวจสอบ Text, Bound และ Chart เชิงโปรแกรม; Visual คือค่าเฉลี่ยของมิติในเช็กลิสต์ Content, Layout และ Style; Overall คือค่าเฉลี่ยของทั้งสอง คะแนนเป็นค่าเปอร์เซ็นต์ที่เฉลี่ยจากการสร้างสามครั้งต่อพรอมต์ โดยไม่มีการคัดเลือก "Ref." ระบุว่าโมเดลได้รับข้อมูลอ้างอิงที่สร้างขึ้นพร้อมกับพรอมต์หรือไม่

• AesCode-8B พร้อมข้อมูลอ้างอิง — ข้อความ 94.06, ขอบเขต 88.36, แผนภูมิ 87.79, กฎ 90.07; เนื้อหา 86.41, เลย์เอาต์ 87.80, สไตล์ 53.21, ภาพ 75.80; ภาพรวม 82.94

• เมื่อเทียบกับแบ็กโบนของตัวเอง — Qwen3-VL-8B-Instruct ที่ปรับด้วยเงื่อนไขอ้างอิงได้คะแนน Visual 44.72 และ Overall 51.93 นั่นคือการเพิ่มขึ้น 31.1 คะแนนใน Visual และ 31.0 คะแนนใน Overall และเป็นการเปรียบเทียบที่น่าแปลกใจน้อยที่สุดในตาราง เนื่องจากจุดมุ่งหมายทั้งหมดของการฝึกคือครึ่งด้านภาพ

• เมื่อเทียบกับ GPT-5.5 แบบอิงตามข้อมูลอ้างอิง — ภาพรวม 81.28 เนื้อหา 82.44 เลย์เอาต์ 89.93 และสไตล์ 57.91

• เทียบกับ Claude Opus 4.8 แบบกำหนดเงื่อนไขด้วยข้อมูลอ้างอิง — ภาพรวม 80.39 เนื้อหา 86.42 เลย์เอาต์ 89.76

• AesCode-32B แบบปรับเงื่อนไขด้วยข้อมูลอ้างอิง — ข้อความ 95.34, ขอบเขต 97.27, แผนภูมิ 90.37, กฎ 94.33, เลย์เอาต์ 90.58, ภาพ 77.44, โดยรวม 85.89 คะแนนภาพสูงกว่าฐานราก 32B ของตัวเองถึงยี่สิบสองจุดสี่

• เพดานของ Style — ไม่มีโมเดลใดในตารางที่ทำได้เกิน 60 และ 57.91 ของ GPT-5.5 ก็เป็นค่าที่ดีที่สุดในบรรดาโมเดลเหล่านั้น AesCode-8B อยู่ที่ 53.21 คำนิยามของไมโครซอฟต์เองก็ไม่ปรานี: Style จะให้เครดิตกับดีไซน์ก็ต่อเมื่อดีไซน์นั้นไม่ต้องปรับแก้ด้านภาพเพิ่มเติมก่อนส่งมอบ ดังนั้น ในมิติเดียวที่วัดว่ามนุษย์จะส่งมอบหน้านั้นโดยไม่แก้ไขจริงหรือไม่ โมเดล 8B จึงไม่ใช่ผู้นำ

• ความล้มเหลวด้านขอบเขต — ความล้มเหลวร้ายแรงจากอาการล้นกรอบแคนวาสเกิดขึ้นซ้ำใน 4.3% ของตัวอย่าง 300 ชิ้น เทียบกับ 34.7% สำหรับ GPT-5.5 การล้นกรอบ (overflow) คือรูปแบบความล้มเหลวที่ทำให้ HTML ที่สร้างขึ้นใช้งานไม่ได้ ไม่ใช่แค่ดูไม่สวยงาม

ตอนนี้มาถึงส่วนที่สำคัญพอ ๆ กับตาราง ตัวเลขทุกตัวข้างต้นเป็นข้อมูลที่ผู้ขายรายงานเองและยังไม่มีใครทำซ้ำได้ AesCode-8B ไม่ปรากฏบนกระดานจัดอันดับอิสระใด ๆ ที่เราหาเจอ และการเปรียบเทียบกับ GPT-5.5 และ Claude Opus 4.8 ก็ทำบนเกณฑ์การให้คะแนนของ Microsoft กับงานที่โมเดลเหล่านั้นไม่ได้ถูกปรับมาเพื่อทำ ด้วยนิยามของ "Layout" ที่ให้รางวัลเพียงแค่การสร้างหน้าเพจออกมาได้ คะแนน Text 94.06 ไม่ได้หมายความว่าโมเดลนี้ชนะ GPT-5.5 ด้านข้อความ แต่หมายความว่ามันวางป้ายกำกับโดยไม่ขัดกับพรอมป์ต์บนหน้าอินโฟกราฟิก ซึ่งเป็นข้ออ้างที่เล็กกว่ามาก ผลลัพธ์ด้าน Style คือสิ่งที่บ่งบอกว่าเกณฑ์การให้คะแนนไม่ได้ถูกจัดฉากให้เอื้อประโยชน์ต่อ AesCode — ชัยชนะที่ใหญ่ที่สุดบนกระดานคะแนนมาพร้อมกับตัวเลขที่ไม่น่าชื่นชมที่สุดซึ่งตั้งอยู่ติดกัน

สิ่งที่ได้รับการยืนยันแล้ว และสิ่งที่ยังไม่ได้รับการยืนยัน

เนื่องจากสิ่งนี้ถูกปล่อยออกมาอย่างเงียบๆ จึงเป็นเรื่องที่ควรค่าแก่การแยกทั้งสองออกจากกันอย่างชัดเจน

• ยืนยันแล้ว — น้ำหนักโมเดลมีอยู่จริงและดาวน์โหลดได้ภายใต้ Apache 2.0; เวลาปล่อยทั้งสองอยู่ในรีโพซิทอรี; สถาปัตยกรรม จำนวนพารามิเตอร์ ความยาวคอนเท็กซ์ และการตั้งค่าการสุ่ม ล้วนอยู่ในคอนฟิกและโมเดลการ์ดที่เผยแพร่แล้ว; สูตรการฝึกและการออกแบบรางวัลมีเอกสารอธิบายละเอียดเพียงพอที่จะโต้แย้งได้; โค้ด ชุดตัวตรวจสอบ และตัวสร้างรูบริกเป็นสาธารณะ; มีโมเดลคู่หูขนาด 32B อยู่.

• ยังไม่ได้รับการยืนยัน — ตัวเลข benchmark ใด ๆ ก็ตาม จากใครก็ตามที่ไม่ใช่ผู้ขาย เอกสารงานวิจัย ซึ่งเอกสารประกอบเองระบุว่ากำลังอยู่ระหว่างการตรวจสอบ ตัวตนของผู้ตัดสินแบบ vision-language ที่อยู่เบื้องหลังคะแนนครึ่งหนึ่งที่เป็นภาพ ว่าจะมีผู้ให้บริการรายใดโฮสต์มันหรือไม่ ว่า context ขนาด 24,576 โทเคนจะรับไหวบนชุดสไลด์หลายหน้าจริงหรือไม่ เนื่องจากการประเมินที่รายงานไว้อยู่บนหน้าอินโฟกราฟิกเดี่ยว และทุกสิ่งทุกอย่างเกี่ยวกับพฤติกรรมนอกภาษาอังกฤษ — แท็กภาษาใน model card คือ "en" เท่านั้น

ถ้าคุณต้องการรันมัน และค่าใช้จ่ายของมันคือเท่าไร

Qwen3-VL-8B-Instruct — โมเดลที่ AesCode-8B ถูกไฟน์ทูนมา และเป็นการเปรียบเทียบเดี่ยวที่แข็งแกร่งที่สุดที่มีให้ใช้จนกว่าจะมีผู้เผยแพร่ผลลัพธ์ AesCode ที่เป็นอิสระ — เป็นอีกเรื่องหนึ่ง:

เส้นทางสำหรับการให้บริการของ AesCode-8B เองนั้นสั้น และการ์ดโมเดลระบุไว้โดยตรง: vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576 โดยใช้ transformers 4.57 หรือใหม่กว่าสำหรับเส้นทางที่ไม่ใช้ vLLM และโค้ดตัวอย่าง Python ที่รับภาพอ้างอิงแบบไม่บังคับไว้ก่อนข้อความพรอมป์ต์

การคำนวณที่คุณต้องทำเองคือเรื่องหน่วยความจำ น้ำหนัก bf16 ขนาด 17.5 GB ต้องอยู่ร่วมกับ KV cache สำหรับบริบท 24,576 โทเคนและรูปภาพได้ถึงสองรูป ดังนั้นการ์ด 24 GB ใบเดียวจึงเพียงพอในทางเทคนิคสำหรับน้ำหนัก แต่คับแคบจนน่าอึดอัดสำหรับอย่างอื่น; 40-48 GB หรือการ์ด 24 GB สองใบคือขั้นต่ำที่เป็นจริง โมเดลคู่หู 32B เป็นปัญหาคนละระดับ — shard ของมันรวมกันได้ 66.7 GB จึงต้องใช้ tensor parallelism และโหนด multi-GPU เผื่อ renderer ไว้ด้วย: โมเดลส่งออกเอกสาร HTML ที่สมบูรณ์ และคำกล่าวอ้างเรื่องคุณภาพทุกข้อเกี่ยวกับมันล้วนเกิดขึ้นจากการเรนเดอร์เอกสารนั้น ดังนั้นการให้คะแนนเอาต์พุตของคุณเองหมายถึงการตั้ง Playwright โดยบล็อกคำขอภายนอก

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

AesCode-8B ไม่ใช่โมเดลที่ OrcaRouter รูตให้บริการ และเราก็ไม่พบว่ามีที่อื่นโฮสต์มันไว้เช่นกัน ดังนั้นการประเมินผลในตอนนี้จึงหมายถึงการเอาเวตไปรันบนฮาร์ดแวร์ของคุณเอง ส่วนแบ็กโบนของมันเป็นอีกเรื่องหนึ่ง Qwen3-VL-8B-Instruct สามารถรูตผ่าน OrcaRouter ได้แล้ววันนี้ในราคา $0.18 ต่ออินพุตหนึ่งล้านโทเคน และ $0.70 ต่อเอาต์พุตหนึ่งล้านโทเคน โดยมีคอนเท็กซ์ 131,072 โทเคน — ซึ่งทำให้มันเป็นวิธีราคาถูกในการดูว่าเวอร์ชันที่ยังไม่ได้ปรับแต่งของสถาปัตยกรรมนี้ให้ผลอย่างไรกับพรอมป์ต์อินโฟกราฟิกของคุณเอง ก่อนที่คุณจะเสียเวลาหนึ่งสัปดาห์ของ GPU ไปกับการทำตามสูตรของคนอื่นซ้ำ OrcaRouter ส่งต่อราคาตามรายการของผู้ให้บริการโดยบวกเพิ่ม 0% และสลับสำรองระหว่างผู้ให้บริการโดยอัตโนมัติ ดังนั้นการเปรียบเทียบนั้นจึงใช้คีย์เดียวและไม่ต้องมีสัญญาที่สอง หากวันหนึ่ง AesCode-8B ไปอยู่บนผู้ให้บริการที่เรารูต มันจะอยู่ในแคตตาล็อกภายในวันเดียวกัน และหากคุณโฮสต์มันเอง โมเดลที่คุณจะใช้สำรองในโปรดักชันก็คือโมเดลที่อยู่เบื้องหลังเอนด์พอยต์เดียวนี้อยู่แล้ว — ซึ่งเป็นท่าทีที่สมเหตุสมผลสำหรับโมเดลที่เปิดตัวเงียบ ๆ โดยไม่มีการประเมินผลอิสระเลย

ดูอะไรดี

สองเรื่องด้วยกัน และไม่มีเรื่องไหนเลยที่เป็นตารางเบนช์มาร์กอีกอัน

อันแรกคือเปเปอร์ "AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards" ถูกอ้างอิงว่าอยู่ระหว่างการพิจารณาสำหรับปี 2027 ซึ่งอ่านแล้วเหมือนเป็นตัวยึดตำแหน่งที่พิมพ์ลงในรายการ BibTeX มากกว่าจะเป็นกำหนดการ จนกว่าจะมี preprint หรือ camera-ready ปรากฏขึ้น คำอธิบายช่องทางรางวัลข้างต้นก็เป็นเพียงบทสรุปของบทคัดย่อที่ไม่มีใครนอกแล็บสามารถอ่านได้ — และคำถามที่น่าสนใจ เช่น วิธีที่ Visual Graph Rubric จัดการกับกราฟการออกแบบที่ตัวมันเองผิดนั้น จะได้รับคำตอบในเนื้อหาฉบับเต็มเท่านั้น

ข้อที่สองคือการโฮสต์ โมเดล 8.8B ภายใต้ Apache-2.0 ที่สร้าง HTML ที่มีโครงสร้างและตรวจสอบได้นั้นเป็นรูปแบบที่แพลตฟอร์มรับไปใช้พอดี เพราะผลลัพธ์สามารถตรวจสอบได้ในแบบที่ JPEG ทำไม่ได้ ทันทีที่มีคนให้บริการมัน สิ่งนี้ก็ไม่ใช่การตัดสินใจเรื่องการโฮสต์เองอีกต่อไป แต่กลายเป็นการตัดสินใจเรื่องการจัดเส้นทาง — และการเปรียบเทียบต้นทุนก็ไม่เกี่ยวกับชั่วโมง GPU อีกต่อไป

สิ่งที่ไม่ควรคาดหวังคือคำตัดสินที่ชัดเจน สไตล์คือเพดานสำหรับทุกระบบในตารางนั้น รวมถึงระบบนี้ และสไตล์เป็นมิติเดียวที่ถามว่ามนุษย์จะปล่อยหน้าเว็บนี้ตามที่เป็นอยู่หรือไม่ การตีความ AesCode-8B ที่สามารถป้องกันได้นั้นแคบและเป็นจริง: มันเก่งมากในส่วนของงานออกแบบภาพที่เครื่องจักรตรวจสอบได้ อยู่ในระดับกลาง ๆ ในส่วนที่เครื่องจักรตรวจสอบไม่ได้ และมันเป็นโมเดลแบบเปิดน้ำหนักตัวแรกในกลุ่มเฉพาะนี้ที่ช่องว่างระหว่างสองสิ่งนั้นเป็นจุดประสงค์ของการเปิดตัว มากกว่าจะเป็นเรื่องบังเอิญ