Qwen3.6-Max-Preview: โมเดลรุ่นถัดไปที่ยกระดับการเขียนโค้ดแบบเอเจนต์และความรู้เกี่ยวกับโลก

 (qwen.ai)
2 คะแนน โดย GN⁺ 10 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผู้สืบทอดจาก Qwen3.6-Plus โดยเมื่อเทียบกับรุ่นก่อนหน้า ได้ปรับปรุง การเขียนโค้ดแบบเอเจนต์ พร้อมทั้งเสริมความแข็งแกร่งด้านความรู้เกี่ยวกับโลกและความสามารถในการทำตามคำสั่ง
  • ทำ คะแนนสูงสุด ใน 6 เบนช์มาร์กการเขียนโค้ดหลัก ยืนยันการยกระดับประสิทธิภาพของเอเจนต์เขียนโค้ดอย่างมาก
  • รองรับฟีเจอร์ preserve_thinking ซึ่งใช้วิธีเก็บกระบวนการคิดจากเทิร์นก่อนหน้าไว้ในข้อความระหว่างงานแบบเอเจนต์
  • ในเบนช์มาร์กด้านความรู้เกี่ยวกับโลกมีการปรับปรุง เช่น SuperGPQA +2.3, QwenChineseBench +5.3 และด้านการทำตามคำสั่งทำได้ ToolcallFormatIFBench +2.8
  • สามารถทดสอบแบบโต้ตอบได้ใน Qwen Studio และจะเรียกใช้งานผ่าน API ของ Alibaba Cloud Model Studio ด้วย qwen3.6-max-preview

การปรับปรุงหลัก

  • เมื่อเทียบกับ Qwen3.6-Plus ความสามารถด้าน การเขียนโค้ดแบบเอเจนต์ ดีขึ้นอย่างมาก: SkillsBench +9.9, SciCode +6.3, NL2Repo +5.0, Terminal-Bench 2.0 +3.8
  • เสริม ความรู้เกี่ยวกับโลก (world knowledge): SuperGPQA +2.3, QwenChineseBench +5.3
  • ปรับปรุง การทำตามคำสั่ง (instruction following): ToolcallFormatIFBench +2.8
  • ทำคะแนนสูงสุดใน 6 เบนช์มาร์กการเขียนโค้ดหลัก: SWE-bench Pro, Terminal-Bench 2.0, SkillsBench, QwenClawBench, QwenWebBench, SciCode

คุณลักษณะของโมเดลและแนวทางการเข้าถึง

  • เป็น โมเดลโฮสต์แบบปิดเฉพาะ ที่ให้บริการผ่าน Alibaba Cloud Model Studio
  • ปรับปรุงประสิทธิภาพของเอเจนต์ในโลกจริง (real-world agent) และ ความน่าเชื่อถือของความรู้ (knowledge reliability)
  • สามารถทดสอบแบบโต้ตอบได้ทันทีใน Qwen Studio
  • ชื่อโมเดลสำหรับ API คือ qwen3.6-max-preview และจะพร้อมใช้งานใน Alibaba Cloud Model Studio API เร็ว ๆ นี้

การใช้งาน API และฟีเจอร์

  • รองรับ โปรโตคอลมาตรฐานอุตสาหกรรม เช่น OpenAI-compatible chat completions และ responses API รวมถึงอินเทอร์เฟซที่เข้ากันได้กับ Anthropic
  • ผ่านฟีเจอร์ preserve_thinking สามารถเก็บ กระบวนการให้เหตุผล (reasoning content) จากเทิร์นก่อนหน้าไว้ได้ และแนะนำให้ใช้กับงานแบบเอเจนต์
  • เมื่อตั้งค่า enable_thinking: True จะสามารถรับเนื้อหาการให้เหตุผลและคำตอบแบบ สตรีมมิงแยกกัน ได้
  • มี Base URL ของ API ให้ตามภูมิภาค: ปักกิ่ง, สิงคโปร์, สหรัฐอเมริกา (เวอร์จิเนีย)

สถานะการพัฒนา

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 10 일 전
ความคิดเห็นจาก Hacker News

  • รู้สึกตลกนิด ๆ ที่คนหมกมุ่นกับการเทียบ SOTA กันอย่างเดียว ผมเคยเห็นกรณีที่ glm 5.1 ทำสิ่งที่ Opus ทำไม่ได้ และก็เคยเจอมันเขียนโค้ดได้ดีกว่าด้วย ยังไม่ได้ลอง qwen max แต่ก็เคยเห็นโมเดล local 122b อ่านเอกสารได้ดีกว่าและประมวลผลได้แม่นยำกว่า สุดท้ายแล้ว benchmark ก็เป็นแค่ส่วนหนึ่งเท่านั้น ในการใช้งานจริงแต่ละโมเดลมี จุดแข็ง ต่างกัน เลยคิดว่าไม่ควรพูดเหมือนกำลังเทียบค้อนกับประแจแบบตัดสินแพ้ชนะกันตรง ๆ

    • ผมใช้ GLM-5.1 ผ่าน pi.dev ของ Ollama Cloud ในโปรเจกต์ส่วนตัวและค่อนข้างพอใจมาก ที่บริษัทก็ใช้ pi.dev, Claude Sonnet และ Opus 4.6 ร่วมกัน Claude Code ก็ดี แต่หลังอัปเดตช่วงหลังต้อง compact บ่อยเกินไปจนไม่สะดวก ตอนใช้ pi.dev ถึงจะไม่มี MCP tool calling แต่การเชื่อมกับ API ก็ทำได้ดีเลยไม่ค่อยติดใจอะไร กลับกันผมรู้สึกว่า GLM-5.1 ทำเว็บได้ดีกว่า Claude Opus และใน แพลตฟอร์มพัฒนาแบบฟูลสแต็ก ที่กำลังทำอยู่ตอนนี้มันก็ทำงานได้ดีมาก
    • GLM 5.1 เป็นโมเดลแรกที่ทำให้ผมรู้สึกจริง ๆ ว่าโมเดลจีนตามทันแล้ว เลยยกเลิกสมัคร Claude Max ไป และพูดตามตรงคือไม่เสียดายเลย พอเห็นว่าคนมีความเห็นต่างกัน ก็รู้สึกว่าตอนนี้เราเข้าสู่ช่วงที่ความต่างด้าน โดเมนและรูปแบบการใช้งาน สำคัญกว่าการมี SOTA ที่เหนือกว่าแบบสัมบูรณ์แล้ว
    • เหตุผลแทบจะอย่างเดียวที่ผมยังใช้ Claude กับ ChatGPT ต่อคือ tool calling มันยังมีฟีเจอร์มีประโยชน์อย่าง skills ด้วย ผมก็ลอง qwen กับ deepseek มาแล้ว แต่บางครั้งแค่ให้มันส่งออกเอกสารยังทำได้ไม่ดีเลย เลยสงสัยว่าคนอื่นจัดการงานเอกสารหรือ Excel ด้วยเครื่องมือพวกนี้กันยังไง ถ้าเป็นไปได้ผมก็อยากย้ายเหมือนกัน
    • เมื่อไม่กี่เดือนก่อน Qwen3-Coder สร้างโค้ด Rust ได้ดีกว่า Claude Opus หรือ Google Gemini มาก โดยเฉพาะโค้ดที่ใช้ vector extension ของ Rust บน x86-64 ได้ด้วย ตรงนี้น่าประทับใจมาก ผมเรียกใช้มันผ่าน harness อย่าง Zed editor หรือ trae CLI แล้วทึ่งจริง ๆ
    • คะแนน benchmark ของโมเดลเดี๋ยวนี้โดยรวมก็ใกล้กันมากและช่องว่างก็เล็ก ถ้าเป็นแบบนี้ผมว่าการเลือกจากเกณฑ์อื่นสมเหตุสมผลกว่า สำหรับผมถ้า ปลั๊กอิน JetBrains ออกมาดีพอ ผมพร้อมย้ายไปเจ้าไหนก็ได้ทันที

  • ที่บริษัทผมใช้ Claude Code ต่อเนื่องมาหลายเดือนแล้ว และไม่นานมานี้ก็ใช้กับโปรเจกต์เว็บไซต์ส่วนตัวเล็ก ๆ ได้ดีมากด้วย สุดสัปดาห์ก่อนเพิ่งลอง self-hosting เป็นครั้งแรก เลยสงสัยว่ามีใครที่ลองใช้ CC หรือ Codex มามากพอแล้ว และหาคอนฟิกแบบโฮสต์เองที่น่าพอใจได้หรือยัง ผมลองหลายแบบบนเครื่อง 32GB DDR5, AMD 7800X3D, RTX 4090, Windows กับ WSL โดยทดสอบการจับคู่ ollama, docker desktop model runner, pi-coding-agent, opencode กับ Gemma 4, Qwen, GLM-5.1 หลายชุด RAM พื้นฐานก็ใช้ไปเยอะอยู่แล้วเลยรันโมเดลดี ๆ อย่าง Gemma4-31B ไม่ได้ บน Windows ล้วน ๆ ปัญหาเรื่อง path ของไฟล์เพี้ยนบ่อย ส่วนการรัน pi หรือ opencode บน WSL แล้วให้โมเดลทำงานผ่าน docker desktop นั้นสำเร็จได้ระดับหนึ่ง แต่ประสิทธิภาพที่สัมผัสได้จริงก็ช้ากว่า CC มาก และในแง่ความสมบูรณ์ของเครื่องมือก็รู้สึกว่า CC harness ดีกว่ามาก ผมเสียเวลากับการเซ็ตอัปไปเยอะเกินจนยังไม่ได้ใช้งานจริงนานนัก แต่ก็ยังเป็นการทดลองที่สนุก

    • น่าจะลองใช้ โมเดล MoE แล้ว offload การอนุมานไปที่ CPU ดู ตัวอย่างเช่น Gemma 4 26b-a4b หรือ qwen3.6 35b-a3b RAM 32GB จะตึงหน่อยถ้าเปิดแอปอื่นด้วย แต่ถ้ามี system RAM พอก็รันได้ดีทีเดียว จะย้ายบางเลเยอร์ขึ้น GPU ก็ได้ แต่กับโมเดล MoE และ llama.cpp เคยมีปัญหาอยู่เหมือนกัน แต่ถ้าเอา KV cache ไว้บน GPU จะได้ความเร็วค่อนข้างดีและยังรักษา context window ได้ระดับเหมาะสม ผมเห็นผลที่น่าประทับใจมากบนเครื่อง local อีกอย่างขอแนะนำอย่างแรงให้ clone llama.cpp มาบน WSL2 โดยตรง แล้วให้ frontier model อย่าง Claude Code ช่วยติดตั้งและจูนให้ แอปที่ครอบอยู่บน llama.cpp มักไม่ได้เปิดเผย option กับ flag ทั้งหมด แค่ตั้ง flag ผิดตัวเดียวก็ทำให้ context cache ใช้ไม่ได้และประสิทธิภาพพังหนักได้ ถ้าบิลด์จาก source เอง เวลามีปัญหาก็เปิดดูโค้ดจริงได้ทันที ด้วยเครื่องสเปกนั้นน่าจะได้อย่างน้อย 20~40tok/s บน Gemma 4 ซึ่งพอใช้งานจริงได้สบาย และ qwen3.6 มี active parameter แค่ 3b อาจเร็วกว่าอีก
    • ปัญหาที่คุณเจออยู่ตอนนี้น่าจะมาจาก VRAM ไม่พอ จนโหลดทั้งโมเดลขึ้นพร้อมกันไม่ได้ ลอง llmfit ดูสักครั้งก็น่าสนใจ

  • ผมกังวลว่าทิศทางของวงการนี้จะเป็นแบบ ปล่อยของฟรีก่อนเพื่อสร้างชื่อ แล้วค่อยเปลี่ยนทั้งหมดเป็น proprietary ทีหลัง ถึงอย่างนั้นก็ยังอยากให้มี open weights ออกมาต่อไป ถ้าวันไหนไม่มีใครปล่อย open weights เลยคงรู้สึกหดหู่มาก ถ้าโลกเป็นแบบนั้น คนทั่วไปก็น่าจะยิ่งถือครอง compute ของตัวเองได้ยากขึ้น

    • ผมว่ามันเป็นการเหมารวมเกินไปหน่อย โมเดลจากอเมริกาหลายตัวก็ปิดมาตั้งแต่แรกอยู่แล้ว ในทางกลับกันโมเดลนอกอเมริกา โดยเฉพาะ โมเดลจีน กลับเปิดกว่าตั้งแต่ช่วงต้นเสียอีก บางเจ้าในจีนด้วยซ้ำเริ่มแบบ proprietary แล้วค่อยเปิดทีหลัง และ Qwen รุ่นใหญ่บางตัวก็เป็นแบบนั้น
    • ผมมองว่านี่เหมือนการขยับเชิงยุทธศาสตร์ระดับชาติ คือปล่อยโมเดลฟรีที่ยังแข่งขันได้ออกมาเรื่อย ๆ เพื่อทำลาย moat ที่บริษัทตะวันตกพยายามสร้างด้วยโมเดล proprietary ตราบใดที่เรื่องเล่าที่เป็นประโยชน์ต่อจีนยังคงอยู่ ผมว่าความเป็นไปได้ที่จะหันกลับไปปิดทั้งหมดก็น้อย
    • ในมุมของ ผู้ผลิตชิป เอง การที่เรายังมีสภาพแวดล้อมที่รันโมเดลบนเครื่อง local ได้ก็น่าจะเป็นผลดีต่อพวกเขา
    • เห็นด้วย สำหรับแลบในจีนโอเพนซอร์สน่าจะเป็นเหมือน กลยุทธ์เชิงพาณิชย์ แบบหนึ่ง เพราะพวกเขาไม่มีเครื่องมือการตลาดที่มีประสิทธิภาพมากพอในการโปรโมตโมเดลกับบริการอนุมาน เลยเลือกแนวทางนี้ บทความที่เกี่ยวข้องก็น่าอ่าน
    • ผมรู้สึกว่าโครงสร้างมันก็เป็นแบบนี้มาแต่แรกอยู่แล้ว สุดท้ายมันก็ใกล้เคียง SaaS อยู่ดี ต่างกันแค่ว่าช่วงนี้แพ็กเกจระดับล่างสุดของ frontier lab ดูเหมือนทดลองใช้ฟรีเท่านั้นเอง

  • วันนี้ Kimi K2.6 ก็ออกมาพร้อมกันด้วย เลยรู้สึกว่าเอามาเทียบกันเป็นเรื่องธรรมชาติมาก แค่ดูราคาก็เห็นว่า Qwen คิดค่า input 1.3 ดอลลาร์ output 7.8 ดอลลาร์ แต่ Kimi คิด input 0.95 ดอลลาร์ output 4 ดอลลาร์ เลยดูว่า Qwen แพงกว่า ในโพสต์ประกาศก็มี benchmark ที่ทับกันอยู่แค่สองตัว และทั้ง SWE-Bench Pro กับ Terminal-Bench 2.0 ก็เป็น Kimi ที่ได้สูงกว่า Qwen เล็กน้อย แน่นอนว่าแต่ละโมเดลมีจุดแข็งต่างกันและ benchmark ไม่ใช่ทั้งหมด แต่ถ้าดูแค่ตัวเลข Kimi ก็ดูน่าสนใจกว่า

    • ผมรู้สึกว่าพอราคาโมเดลจีนสูงขึ้น ความน่าสนใจก็ลดลงไปหน่อย และหลังจาก Gemma-4 ออกมาก็คิดว่าโมเดลที่ยังอยู่บนเส้นพาเรโตฟรอนเทียร์มีไม่มากแล้ว ประสบการณ์ใช้งานของผมก็คล้ายกัน และสถิติจาก arena leaderboard ก็น่าเอามาอ้างอิง

  • ความย้อนแย้งของประกาศนี้ผมว่ามันอยู่ในชื่อเองเลย Max-Preview เป็น proprietary และมีแค่บนคลาวด์ สำหรับผม Qwen ที่สำคัญจริง ๆ คือซีรีส์ open weights ที่คนเอาไปรันบนฮาร์ดแวร์ของตัวเอง ผมรัน 32B กับ 72B แบบ local บน dual A4000 อยู่ ช่องว่างกับ Max แบบ hosted ยังมีอยู่ แต่ก็เห็นชัดว่ามันแคบลงทุกครั้งที่มีรุ่นใหม่ออกมา เพราะงั้นคำถามที่น่าสนใจจริง ๆ ไม่ใช่ว่า Max เทียบกับ Opus ยังไง แต่คือเมื่อไร open-weight tier จะทำให้ cloud tier แทบไม่มีความหมายสำหรับงานส่วนใหญ่

  • ระหว่างที่ทุกคนไล่ตาม SOTA กันอยู่ ผมใช้ MiniMax M2.5 รันหลายเซสชันพร้อมกันและทำงานเขียนโค้ดทั้งหมดได้ในราคา 10 ดอลลาร์ต่อเดือน แทบไม่ชนลิมิตเลย

    • ถ้าเป็นงานจริงจัง ผมไม่คิดว่าความต่างระหว่าง 10 ดอลลาร์กับ 100 ดอลลาร์ต่อเดือนจะเป็นเรื่องที่นักพัฒนามืออาชีพส่วนใหญ่ควรลังเล ยกเว้นนักเรียนหรือผู้ใช้ในประเทศรายได้ต่ำอย่างบางกรณี แต่พอเห็น นักพัฒนารายได้สูง ประหยัดค่าทูลมากเกินไปทีไรก็ยังแปลกใจเสมอ ตอนนี้แม้แต่โมเดล SOTA เองก็ยังไว้ใจได้ไม่เต็มที่เกินกว่างานครั้งคราวอยู่แล้ว เพราะฉะนั้นการคอยเฝ้าโมเดลที่ด้อยกว่านั้นเพื่อประหยัด 10~100 ดอลลาร์ต่อเดือนเลยไม่น่าดึงดูดเลย ผมยังสนุกกับการทดลองโมเดล self-hosted กับงานเบา ๆ ที่พังได้ไม่เป็นไร แต่กับงานสำคัญจริงผมไม่อยากเสียเวลาตัวเอง
    • อยากรู้ว่า 10 ดอลลาร์ต่อเดือนนั้นจ่ายผ่านที่ไหน เป็น OpenRouter หรือเปล่า
    • อยากรู้ว่าใช้งานจริงยังไง ใช้ opencode หรือใช้ฟรอนต์เอนด์ตัวอื่น

  • ผมอ่าน เอกสาร context caching ของ Qwen แล้วก็ทดสอบ Opus, Codex และ Qwen ด้วยกัน รู้สึกว่า Qwen แข็งแกร่งกับงานเขียนโค้ดหลายแบบจริง แต่สิ่งที่ผมให้ความสำคัญที่สุดคือพฤติกรรมใน เซสชันยาว ๆ Qwen ชูเรื่อง context window ใหญ่ก็จริง แต่ประสิทธิภาพใน long context จริง ๆ ดูจะขึ้นกับวิธีทำ context caching มาก เอกสารทางการบอกว่ามีทั้ง implicit และ explicit caching แต่ TTL สั้นแค่ระดับไม่กี่นาที และยังมีข้อจำกัดอย่างการจับคู่แบบ prefix กับเงื่อนไขจำนวนโทเค็นขั้นต่ำ ด้วยข้อจำกัดพวกนี้ ในเวิร์กโฟลว์อย่าง coding agent ที่บริบทโตขึ้นเรื่อย ๆ การนำแคชกลับมาใช้ซ้ำอาจไม่ได้ผลดีอย่างที่หวัง เพราะงั้นต่อให้ราคาต่อโทเค็นดูต่ำ แต่ในเซสชันยาว cache hit rate อาจตกและมีการคำนวณซ้ำมากขึ้น จนรู้สึกว่าค่าใช้จ่ายจริงสูงกว่าได้ ถึงอย่างนั้นในงานด้านความปลอดภัยบางอย่างผมก็เคยเห็น Qwen ทำได้ดีกว่า Opus จากประสบการณ์ของผม Qwen ทำงานสั้น ๆ ระดับเมธอดหรือฟังก์ชันได้ดีกว่า Opus มาก แต่ถ้ามองประสบการณ์เขียนโค้ดโดยรวม มันยังให้ความรู้สึกเหมือน ตัวสร้างระดับฟังก์ชัน มากกว่าจะเป็นผู้ช่วยเขียนโค้ด end-to-end แบบอัตโนมัติอย่าง Claude

    • ถึงอย่างนั้นการตัดเซสชันยาว ๆ ให้สั้นลงแล้วเริ่มใหม่ก็ยังเป็น best practice ที่ถูกต้องอยู่ดี ใน Claude Code Best Practices ของ Anthropic ก็แนะนำไว้ว่า "เซสชันใหม่ที่สะอาดพร้อมพรอมป์ที่ดีกว่า แทบจะดีกว่าเซสชันยาวที่มีการแก้สะสมอยู่เสมอ"
    • เท่าที่ผมตรวจล่าสุด context caching มีไว้เพื่อลดค่าใช้จ่ายและ latency เท่านั้น ไม่ได้เปลี่ยนว่าโทเค็นไหนจะถูกสร้างออกมาจริง

  • พอเห็น Qwen เอาไปเทียบกับ Opus 4.5 ก็รู้สึกว่ายากจะรับในแง่เจตนาดี ถึงจะเข้าใจได้ที่ไม่มี Opus 4.7 เพราะใหม่มาก แต่ Opus 4.6 ออกมานานพอสมควรแล้ว

    • สำหรับผม Opus 4.5 คือจุดแรกที่รู้สึกว่าโมเดล ดีพอใช้จริง กับปัญหาหลากหลายแบบ ก่อนหน้านั้นพอเอา AI มาใช้กับงานพัฒนาทีไร เวลาก็หายไปกับ hallucination ตลอดจนไม่คุ้มจะใช้ แต่ถ้าการพัฒนาหยุดอยู่แค่ Opus 4.5 จริง ๆ ผมก็ยังคิดว่าเราคงทำงานจริงได้เร็วขึ้นอีกมหาศาลอยู่ดี ตอนนี้ไม่น่าจะมีทางที่การพัฒนาซอฟต์แวร์จะกลับไปเป็นการเขียนมือทั้งหมดอีกแล้ว เพราะงั้นถ้ามีอะไรที่ให้ระดับใกล้เคียงหรือดีกว่า Opus 4.5 เล็กน้อยในราคาแค่หนึ่งในสิบ สำหรับหลายคนก็น่าดึงดูดมาก แน่นอนว่าสำหรับนักพัฒนาในตะวันตก การจ่ายเกิน 100 ดอลลาร์ต่อเดือนเพื่อใช้ Opus 4.7 ก็ยังคุ้ม เพราะเวลาที่เสียไปกับโมเดลชั้นล่างมีราคาสูงกว่ามาก ในระยะนี้ผมก็ตั้งใจจะจ่ายพรีเมียมต่อไปให้กับโมเดลที่เสียเวลาผมน้อยกว่า และให้ผลลัพธ์ดีกว่าด้วยการแก้พรอมป์น้อยกว่า ขณะเดียวกันความเร็วของการเปลี่ยนแปลงก็น่าทึ่งจริง ๆ เดี๋ยวนี้แม้แต่ โมเดลเปิด ก็มาไกลจนแข่งกับ frontier model เมื่อ 2 ปีก่อนได้แล้ว Qwen 3.6 MoE 35B A3B หรือ Gemma 4 รุ่นใหญ่ก็รันได้บน Macbook แรง ๆ, Strix Halo หรือ GPU 24GB/32GB รุ่นใหม่ ๆ ซึ่งเป็นอุปกรณ์ธรรมดาที่ไม่ได้แพงกว่าโน้ตบุ๊กนักพัฒนายุคก่อน AI มากนัก มันเขียนโค้ดได้ เขียนงานข้อความได้ค่อนข้างดี ใช้เครื่องมือได้ และมี context ยาวพอใช้งานจริง แม้ยังไม่ถึง Opus 4.5 แต่ก็น่าประทับใจมาก ผมเองก็ใช้หลายโมเดลผสมกันอยู่แล้วสำหรับงาน security กับ code review และถึงแม้ในงานพัฒนาซอฟต์แวร์ส่วนใหญ่ผมยังรู้สึกว่า Claude Code กับ Opus ดีที่สุด แต่ก็พร้อมลองใช้ Qwen ด้วยความเต็มใจ โมเดลเล็ก ๆ ของมันก็ทำได้ดีมากเมื่อเทียบกับขนาด เลยคาดหวังกับโมเดลใหญ่เหมือนกัน
    • ถ้าเรื่องเงินไม่ใช่ปัญหาเลย สุดท้ายก็มองแค่ประสิทธิภาพสูงสุดอย่าง Codex 5.4 หรือ Opus 4.7 ได้ แต่สำหรับหลายคน คุณภาพต่อราคาคือปัจจัยใหญ่มาก แม้แต่ผู้สมัคร Claude เองก็มีหลายคนที่ด้วยแรงกดดันด้านค่าใช้จ่ายและปริมาณการใช้งาน ทำให้ไม่สามารถใช้ Opus 4.7 ตลอดเวลาและต้องใช้ Sonnet หรือ Opus รุ่นเก่าแทน ดังนั้นถ้ามองจากเส้นโค้งคุณค่าต่อคุณภาพ การเปรียบเทียบแบบนี้ก็มีความหมายมากพอ
    • ในช่วงไม่กี่เดือนที่ผ่านมา ประสิทธิภาพของ Opus 4.6 แกว่งมากเกินไป จนผมไม่อยากเปลืองโทเค็นไปกับมัน
    • ตอน Sonnet 4.6 ออกมา ผมเปลี่ยนโมเดลหลักจาก Opus ไปเป็น Sonnet เพราะจากที่ใช้จริง Sonnet 4.6 ให้ความรู้สึกใกล้กับ Opus 4.5 มาก 4.6 กับ 4.7 จะดีกว่าก็จริง แต่ในงานส่วนใหญ่ไม่ได้ก้าวกระโดดมากพอ จนตอนนี้การประหยัดค่าใช้จ่ายกลายเป็นทางเลือกที่สมเหตุสมผลเต็มที่แล้ว ถ้าโมเดลที่ถูกกว่านี้ไต่ถึงระดับนั้นได้ก็จะยิ่งสำคัญ และ GLM 5.1 ก็ดูใกล้มากจนผมใช้บ่อย จากมุมนี้การเทียบกับ Opus 4.5 ก็ถือว่าสมเหตุสมผล
    • ผมคิดว่าการเทียบควรเทียบกับ คู่ที่ใกล้เคียงที่สุด และถ้า benchmark มาจากผู้ให้บริการเอง ก็เป็นธรรมดาที่เขาจะเลือกเฉพาะเฟรมเวิร์กที่โมเดลตัวเองทำได้ดีและตัดสิ่งที่เสียเปรียบออกไป สุดท้าย benchmark ที่เชื่อถือได้ก็ควรเป็น benchmark อิสระ

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

    • พูดแบบนั้นเหมือนเป็น ลักษณะเฉพาะของบริษัทจีน ก็ดูแปลกไปหน่อยนะ ผมว่าบริษัทประเทศอื่นก็ไม่ได้ต่างกันเลย
    • Qwen max เป็น cloud only มาตั้งแต่แรกอยู่แล้ว และด้วยขนาดเกิน 1T ค่าใช้จ่ายแพงก็เป็นเรื่องหลีกเลี่ยงยาก
    • ผมอยากถามกลับว่าการขึ้นราคาแรงนั้นต่างจาก บริษัทอเมริกัน ตรงไหน
    • อยากถามว่าสิ่งที่พูดนั้นใช้ได้กับโมเดลอย่าง GLM 5.1, DeepSeek V3.2 หรือ Kimi K2.6 ที่เพิ่งออกมาด้วยหรือเปล่า เพราะดูแล้วมันไม่ค่อยเข้ากับตัวอย่างเหล่านั้นเท่าไร
    • ได้ยินแบบนี้แล้วปฏิกิริยาแรกคือ บริษัทอเมริกัน ก็ชอบลูกไม้นี้มากเหมือนกันไม่ใช่หรือ

  • เรื่องที่น่าสนใจคือ คุณอาจรู้จัก ตระกูลโมเดล Qwen ที่รัน local ได้ทั้งหมด แต่กลับไม่รู้เรื่องโมเดลคลาวด์ของมันเลย ผมเองรู้จักแค่สาย 3.5 กับ 3.6 อยู่ตัวหนึ่ง แล้วชื่อ Plus ก็เพิ่งเคยได้ยินครั้งนี้

    • ถ้าจำไม่ผิด ซีรีส์ Plus มีมาตั้งแต่ตอน Qwen chat เปิดตัวแล้ว อย่างน้อยผมก็จำได้ว่าเคยลองใช้โมเดล Plus เองตั้งแต่ต้นปีที่แล้ว