ทีมแบบผสมโมเดล: แรงงานราคาถูก ผู้ตรวจสอบค่าตัวแพง และการส่งต่องานระหว่างกัน

ตารางราคาประจำวันที่ 2026-09-22 ชี้ให้เห็นรูปแบบที่ชัดเจนอยู่แล้ว เอา GPT-6 Luna ราคา $0.10 ต่ออินพุตหนึ่งล้านโทเคนไปทำงานที่ไม่มีใครอยากทำ เอา Claude Opus 5.5 ราคา $4 ไปเป็น Agent ที่คอยตรวจงาน แล้วคุณก็ได้ปริมาณงานส่วนใหญ่ในราคาเพียงเศษเสี้ยวของบิลเดิม หลายทีมกำลังต่อระบบแบบนี้ในสัปดาห์นี้ และส่วนใหญ่จะสร้างสิ่งที่ดูเหมือนการรีวิวแต่ไม่ใช่

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

ดังนั้นคำถามที่น่าสนใจใน Crew แบบผสมโมเดลจึงไม่ใช่ว่าโมเดลไหนไปอยู่ตรงไหน แต่คือ handoff ต้องแบกอะไรไปบ้าง

Crew แบบผสมโมเดลคืออะไร

Crew แบบผสมโมเดลคือกลุ่มของ Agent ที่เลือก Runtime ตามบทบาท ไม่ใช่ตามทีม และมีอย่างน้อยหนึ่งบทบาทที่มีอยู่เพียงเพื่อตรวจสอบผลลัพธ์ของตัวอื่น

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

สามระดับ ตามที่ผู้ให้บริการประกาศไว้

OpenAI อธิบายว่า Sol และ Luna ถูกกว่า GPT-5.6 ในราคาโปรโมชัน 50% และคำว่า "โปรโมชัน" ก็เป็นคำที่ต้องระวัง เพราะราคาฐานก็เป็นราคาที่ลดอยู่แล้ว OpenAI ยังบอกอีกว่า GPT-6 Astra "ยังคงเป็นโมเดลที่ดีที่สุดของเราครบทุกด้าน"

มีข้อควรระวังก่อนที่ใครจะตีความการแบ่งระดับนี้เป็นการจัดอันดับ โพสต์เปิดตัวของ OpenAI เปรียบเทียบ Sol และ Luna กับ Claude Opus 5 เพราะตอนที่เขียนโพสต์นั้น Opus 5.5 ยังไม่มีอยู่ และเปิดตัวในอีกไม่กี่ชั่วโมงต่อมา โดย Anthropic เองระบุว่ามีต้นทุนการรันต่ำกว่า Opus 5 ถึง 40% ยังไม่มีใครรันการเปรียบเทียบนั้นซ้ำ และผู้ให้บริการทั้งสองรายก็ไม่ได้ใช้ harness เดียวกัน เลือกบทบาทจากราคาและจากพฤติกรรมที่สังเกตได้ในรีโปของคุณเอง

แต่สิ่งที่ผู้ให้บริการแต่ละรายพูดเกี่ยวกับโมเดลของตัวเองก็เพียงพอต่อการกำหนดบทบาท สำหรับ Luna OpenAI รายงานว่าได้ 66.6% บน DeepSWE 1.1 ที่ reasoning effort สูงสุด ถูกลงต่อ task 93% เมื่อเทียบกับ Claude Opus 5 และถูกลง 96% เมื่อเทียบกับ Fable 5 และที่ effort สูงขึ้น ให้ผล factuality เทียบเท่า GPT-5.6 Sol ในต้นทุนประมาณหนึ่งในร้อย นั่นคือโมเดลที่คุณเอาไปใช้กับงานปริมาณมากได้ สำหรับ Opus 5.5 Anthropic รายงานว่าได้ 66.4% บน Terminal-Bench 4.0, 54.4% บน FrontierCode v1.1, 81.8% บน OSWorld 2.0 เอาต์พุตสูงสุด 128k และทำงานต่อเนื่องได้ 18 ชั่วโมงขึ้นไป นั่นคือโมเดลที่คุณเอาไปใช้กับการตัดสินใจได้

การอ่านคือครึ่งที่ถูกของโมเดลราคาแพง

เหตุผลที่รูปแบบนี้ยังยืนได้เมื่อเจอบิลจริงคือ caching และความไม่สมมาตรนี้เองที่กำหนดการออกแบบ

Opus 5.5 อ่านอินพุตที่แคชไว้ในราคา $0.20 ต่อล้าน คิดเป็นหนึ่งในยี่สิบของอัตราอินพุตแบบไม่แคชของตัวเอง และเป็นสองเท่าของอัตราไม่แคชของ Luna เอาต์พุตของมันอยู่ที่ $20 ต่อล้าน ซึ่งเป็นสี่สิบเท่าของ $0.50 ของ Luna ดังนั้นผู้รีวิวที่อ่านปริมาณมหาศาลแต่เขียนแค่ยี่สิบบรรทัดแทบไม่มีค่าใช้จ่าย ส่วนตัวที่บรรยายยาว ๆ ไม่เป็นเช่นนั้น

นั่นให้กฎที่พิสูจน์ได้ด้วยตัวเลขกับคุณ: ผู้รีวิวอ่านทุกอย่างและแทบไม่ต้องพูดอะไร ให้มันอ่าน prefix ของรีโป ธรรมเนียมการเขียนโค้ด diff และ packet ด้านล่าง แล้วจำกัดปริมาณที่มันตอบกลับ

ฝั่งผู้ทำงานก็แคชเช่นกัน GPT-6 เพิ่มอัตราการ hit โดยค่าเริ่มต้นด้วยส่วนลด 90% สำหรับการอ่านอินพุตที่แคชไว้ เพิ่ม breakpoint แบบระบุได้เพื่อให้คุณเลือกได้ว่า cached prefix สิ้นสุดตรงไหน และไม่ทำให้แคชเป็นโมฆะอีกต่อไปเมื่อคุณเปลี่ยน reasoning effort หรือชุดเครื่องมือที่มีให้ใช้ GitHub รายงานว่ามี prompt token ที่ต้องประมวลผลใหม่ลดลงกว่า 50% จากการร้องขอหลายพันล้านครั้ง สำหรับกองทัพ Luna worker ที่อ่านรีโปเดิมซ้ำ ๆ ทั้งวัน นั่นคือค่าใช้จ่ายส่วนใหญ่ของบิล

handoff ต้องแบกอะไรไปบ้าง

นี่คือ artifact ตัวอย่าง เป็นเทมเพลต handoff ที่ออกแบบมาให้โมเดลอ่าน ผู้ทำงานส่งคืนให้ Task เมื่อหยุด และผู้รีวิวอ่านแค่สิ่งนี้กับ diff เท่านั้น

SH-312  Add retry with backoff to the webhook sender
Worker:   Agent "backend-worker" - Runtime Codex on gpt-6-luna
Attempts: 2 (attempt 1 failed on lint)
Diff:     4 files, +118 / -12   (worktree sh-312, commit a91f4c2)

Commands run, verbatim:
  $ pnpm lint            exit 0
  $ pnpm typecheck       exit 0
  $ pnpm test -- sender  exit 0   14 passed, 0 failed, 3 skipped
  $ pnpm build           exit 0

Not done:
  - The 3 skipped tests need a live webhook endpoint. Not run.
  - Did not touch the queue consumer, which has the same bug.

Assumptions made:
  - Max 5 retries, ceiling 30s. No spec said. Copied the values
    already used in payments/retry.ts.

Stopped because: acceptance criteria met.

คุณสมบัติสี่ข้อทำให้ packet นั้นคุ้มค่ากับโทเคนที่ใช้

มันคือ artifact ไม่ใช่คำบรรยาย คำสั่งและ exit code รันซ้ำได้ ส่วน "ผมตรวจสอบพฤติกรรมแล้ว" ไม่มีใครตรวจสอบได้

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

มันบันทึกสมมติฐาน Task ที่มีขอบเขตชัดเจนทุกอันมีการตัดสินใจที่ spec ไม่ได้ระบุไว้ เขียนไว้ก็กลายเป็นรายการให้รีวิว ปล่อยไว้ก็กลายเป็นเซอร์ไพรส์ในโปรดักชันอีกเดือนถัดมา

มันระบุเหตุผลที่หยุด เสร็จแล้ว ติดบล็อก งบหมด และล้มเหลวสองครั้ง ดูเหมือนกันในรีโป แต่มีความหมายต่างกันบนบอร์ด

สิ่งที่ผู้รีวิวส่งกลับ

REVIEWER  Agent "review" - Runtime Claude Code on claude-opus-5-5
Reads:  repository prefix (cached), the packet, the full diff
Writes: at most 20 lines

VERDICT      changes requested
CHECKED      4 commands re-run, all exit 0. Backoff ceiling honoured.
UNVERIFIED   3 skipped tests. No evidence the retry path ever runs.
BLOCKING     Retry wraps the 4xx branch. A 422 will be retried 5 times.
FOR A PERSON Queue consumer has the same bug and is out of scope.
             Split SH-312, or widen it?

บรรทัด UNVERIFIED คือสิ่งที่ทำให้ผู้รีวิวสมราคา worker ราคาถูกจะไม่บอกคุณว่าคำกล่าวอ้างข้อไหนไม่มีอะไรรองรับ ส่วนหนึ่งเพราะมันไม่รู้ตัว โมเดลราคาแพงที่อ่าน packet ที่มีโครงสร้างสามารถแยกสิ่งที่ตรวจสอบยืนยันได้ออกจากสิ่งที่เชื่อตาม ๆ กันมา และการแยกนี้เองคือผลผลิตของขั้นตอนรีวิว บรรทัด FOR A PERSON คืออีกครึ่งหนึ่ง ผู้รีวิวไม่ได้ตัดสินขอบเขตงาน แต่ส่งคำถามกลับไปที่ Task

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

สองโหมดความล้มเหลวที่ต้องจับตา

Latency คือข้อแรก และมันสวนทางกับสัญชาตญาณ Artificial Analysis ซึ่งเป็นบุคคลที่สาม ไม่ใช่ผู้ให้บริการรายใดรายหนึ่ง วัดเวลาถึงโทเคนแรกของ reasoning variant ระดับ "max" ได้ 124.23 วินาทีสำหรับ Luna และ 102.15 วินาทีสำหรับ Sol [VERIFY] ตรวจสอบตัวเลขเหล่านี้กับรายการปัจจุบันก่อนนำไปอ้างอิง รูปแบบสำคัญกว่าตัวเลข ที่ reasoning effort สูง โมเดลราคาถูกไม่ใช่ตัวที่เริ่มได้เร็ว ดังนั้น Crew แบบผสมโมเดลจึงมี worker ที่ดูเหมือนค้าง และมีผู้รีวิวที่รออยู่ นั่นคือปัญหาสถานะ ไม่ใช่ปัญหาโมเดล

ปริมาณการรีวิวคือข้อที่สอง Luna worker สิบตัวสร้างสิบ packet ถ้าผู้รีวิวอนุมัติเก้าอันและส่งต่อหนึ่งอัน คุณก็เปลี่ยน agent run สิบครั้งให้กลายเป็นการตัดสินใจของคนหนึ่งครั้ง ซึ่งนั่นแหละคือเป้าหมาย ถ้ามันส่งต่อหกอัน คุณก็จ่ายค่ารีวิวไปแล้วและยังต้องตัดสินใจอีกหกครั้ง และคิวรีวิวก็เป็นคอขวดอยู่แล้ว ติดตามอัตราการส่งต่อของ worker Agent แต่ละตัวเป็นเวลา Sprint หนึ่ง มันจะบอกคุณว่า packet บางเกินไปหรือ Task ใหญ่เกินไป นานก่อนที่บิลจะบอก

เมื่อไหร่ที่ไม่ควรทำแบบนี้

ใช้โมเดลเดียวสำหรับทุกอย่างเมื่อมีคนคนเดียวรัน Agent หนึ่งหรือสองตัวบนรีโปเดียว packet เป็นภาระเพิ่ม ผู้รีวิวก็เป็นบิลอีกใบ และคุณก็เป็นผู้รีวิวเองอยู่แล้ว

ใช้ Crew แบบผสมโมเดลเมื่อมี Agent หลายตัวรันพร้อมกัน เมื่อมีมากกว่าหนึ่งคนที่เริ่ม run ได้ หรือเมื่องานที่เสร็จแล้วมีปริมาณเกินเวลาใครจะอ่านไหว

และอย่าเอาโมเดลราคาแพงมารีวิวเมื่องานเองคือส่วนที่ยาก migration ที่ต้องถือ context ไว้หลายชั่วโมงควรใช้ Opus 5.5 ตรง ๆ โดยมี Agent ราคาถูกเขียน packet ตามหลัง การเลือกตามบทบาทหมายถึงการเลือกตาม Task ไม่ใช่เลือกครั้งเดียวต่อทีม ซึ่งเป็นเหตุผลที่การจับคู่โมเดลกับบทบาทของ agentควรเป็นกฎที่เขียนไว้ ไม่ใช่ความเคยชินที่คนหกคนต่างจำไว้ในใจ

ตัวเลขที่ไม่ขยับ

ต้นทุนต่องานที่ทำสำเร็จลดลงอย่างมากทั้งสองฝั่งของการเปิดตัวครั้งนี้ OpenAI รายงานว่านักวิจัยค่ามัธยฐานใช้จ่ายมากกว่า $600 ต่อวันกับ coding agent โดยเปอร์เซ็นไทล์ที่ 90 อยู่เหนือ $7,000 ทีมที่ต่ำกว่าเส้นนั้นตอนนี้จ่ายไหวสำหรับงาน agent มากกว่าเมื่อสัปดาห์ก่อนหลายเท่า

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

Sharkly ไม่ได้รันโมเดลและไม่ได้เลือกโมเดลให้คุณ มันเป็นชั้นของ Task, Computer, context และการรีวิวที่ใช้ร่วมกันซึ่งล้อมรอบเครื่องมือที่รันโมเดลจริง ๆ ซึ่งเป็นที่ที่ handoff ต้องอยู่ ถ้าทั้งผู้รีวิวและคนจะอ่านมัน ถ้าคุณรัน coding agent หลายตัวอยู่แล้ว: เชื่อมต่อ Computer หนึ่งตัว สร้าง worker Agent หนึ่งตัวและ reviewer Agent หนึ่งตัว แล้วให้ worker ส่งคืน packet นั้นกับงานน่าเบื่อ ๆ สักอย่าง