TL;DR

Phần 2 của series về AI Agent Swarms. Phần 1 đã cover kiến trúc cơ bản, K2.6 specs, MuonClip và PARL. Bài này đi vào ba thứ thiết thực hơn: hạ tầng Mooncake giải thích tại sao 300 agent song song không sụp, swarm hoạt động từng bước ra sao, và tại sao Kimi K2.6 + Claude Opus 4.8 là combo tối ưu cho production workload.

Mooncake - Hạ Tầng Đằng Sau Kimi

Weights của mô hình chỉ là một nửa câu chuyện. Hệ thống serving chúng là nửa còn lại - và đây là lý do K2.6 có thể duy trì 300 parallel agent mà không bị sụp.

Platform serving của Moonshot có tên Mooncake, được mô tả trong infrastructure paper 2024. Thiết kế khác thường ở điểm này: LLM inference truyền thống chạy prefill (xử lý input prompt) và decode (generate tokens) trên cùng GPU instance. Mooncake disaggregate chúng thành cluster riêng biệt:

  • Prefill cluster: xử lý initial prompt processing, scale độc lập cho long-context inputs.
  • Decode cluster: xử lý token generation, tối ưu cho throughput và latency.

KV cache - intermediate attention state giúp autoregressive generation hiệu quả - được quản lý như first-class system resource. Mooncake xây distributed KV cache trải trên GPU VRAM, CPU DRAM, và SSD, với transfer engine tùy chỉnh để di chuyển cache giữa các node.

Tại sao điều này quan trọng với Agent Swarm

Khi 300 sub-agent chạy đồng thời, mỗi agent generate KV cache riêng. Trong kiến trúc truyền thống, đó là áp lực GPU memory khổng lồ và scheduling conflicts. Với disaggregated cache của Mooncake:

  • KV cache của sub-agent đã hoàn thành có thể evict sang DRAM hoặc SSD và recall khi cần.
  • Prefill cluster xử lý system prompt (thường rất lớn) cho từng sub-agent độc lập.
  • Scheduler tối đa hóa overall throughput trong khi vẫn giữ per-agent latency SLO.

"Compared to the baseline method, Mooncake can achieve up to a 525% increase in throughput in certain simulated scenarios while adhering to SLOs." - Mooncake paper. Dưới real workloads: Kimi xử lý 75% requests nhiều hơn, phục vụ hơn 100 tỷ token mỗi ngày trên hàng nghìn node.

PD Disaggregation ở scale 128 GPU

LMSYS đã publish một deployment case study cho Kimi K2 sử dụng Prefill-Decode Disaggregation trên 128 H200 GPU qua SGLang Router:

  • SGLang Router: lightweight service cho dynamic service discovery của prefill và decode node.
  • Expert Parallelism: 384 expert của K2 phân tán trên các node, routing ở network level.
  • OME (Open Model Engine): Kubernetes-native orchestration cho serving layer.

Đây là stack chạy K2 family ở production scale - và là template nếu bạn self-host K2.6.

Swarm Hoạt Động Từng Bước

Bước 1: Task decomposition

Orchestrator phân tích task và xây dependency graph: subtask nào độc lập và có thể chạy song song, subtask nào phụ thuộc vào output trước.

Ví dụ với task "research 100 công ty YC và tạo sector analysis": orchestrator xác định 100 research task độc lập, rồi 1 aggregation task, rồi 1 synthesis task. Layer đầu tiên là fully parallelizable.

Bước 2: Spawn specialist agent

Orchestrator spawn sub-agent chuyên biệt theo domain dựa trên subtask type:

  • Web research agents: search + browser tools
  • Data analysis agents: Python execution + spreadsheet tools
  • Writing agents: synthesis và document generation
  • Fact-checker agents: cross-referencing và validation

Mỗi sub-agent hoạt động trong bounded local context riêng. Nó xử lý một scoped task, produce structured output, và exit. Local context không mang mọi thứ orchestrator biết - chỉ những gì sub-agent đó cần. Đây là cách K2.6 tránh overflow trên task có thể lấp đầy context window của một agent trong vài phút.

Bước 3: Parallel execution theo waves

Các agent thực thi theo wave. Wave đầu tiên xử lý các task hoàn toàn độc lập. Khi kết quả về, orchestrator launch wave thứ hai trên các task phụ thuộc vào output của wave đầu, cứ thế tiếp tục cho đến khi dependency graph được giải quyết xong.

K2.6 hỗ trợ đến 300 sub-agent và 4.000 coordinated step mỗi session. Orchestrator giám sát thực thi real-time, detect agent bị fail hoặc stall, và tự động gán lại task của chúng. Fault tolerance này mới làm cho các autonomous run 12+ giờ có thể thực hiện được mà không cần người theo dõi.

Bước 4: Aggregation và output

Khi tất cả sub-agent hoàn thành, orchestrator tổng hợp kết quả thành deliverable cuối cùng: document, spreadsheet, website, slide deck. Nó synthesize qua các agent output thay vì concatenate, nên kết quả mạch lạc về mặt cấu trúc.

Một điều đáng lưu ý: cấu trúc swarm cũng là câu trả lời của Kimi cho context window problem. Policy tường minh của K2.6: một khi context window vượt ngưỡng, chỉ giữ lại round tool-related messages gần nhất. Swarm làm policy này bền vững trên những task horizon rất dài.

Kiến Trúc Kimi × Claude Opus 4.8

Không có mô hình đơn lẻ nào là đáp án đúng cho mọi layer của swarm.

  • Kimi K2.6 được xây cho horizontal scale - parallel execution trên hàng trăm agent, autonomous run dài, bulk processing tiết kiệm chi phí.
  • Claude Opus 4.8 được xây cho judgment - planning, nuanced reasoning, và tự phát hiện lỗi của mình.

Chúng bổ sung nhau về mặt cấu trúc, và khoảng trống mỗi bên để lại gần như khớp với điểm mạnh của bên kia.

Pattern kết hợp

[User Goal]
      |
[Claude Opus 4.8 - Planner]
  Phân rã mục tiêu thành task spec có cấu trúc
  Xác định subtask song song vs tuần tự
  Định nghĩa success criteria cho mỗi subtask
      |
[Kimi K2.6 Agent Swarm - Executor]
  Nhận structured task spec
  Spawn đến 300 specialized sub-agent
  Chạy song song trên các tool call
  Trả về structured results
      |
[Claude Opus 4.8 - Verifier]
  Review output của Kimi theo success criteria
  Flag failures, gaps, inconsistencies
  Synthesize final deliverable

Tại sao Claude cho planning và verification?

Thay đổi underrated nhất trong Opus 4.8 là cải thiện về honesty: Opus 4.8 ít bỏ qua lỗi trong code mình viết hơn ~4 lần so với tiền nhiệm. Trong agentic system, false confidence là failure mode thảm khốc. Một orchestrator nói "completed" khi thực ra chưa xong sẽ cascade lỗi qua 300 downstream agent. Xu hướng của Claude trong việc flag uncertainty và bắt lỗi của chính mình mid-task làm cho nó là anchor đúng cho các layer mà sai là đắt giá.

Opus 4.8 cũng hỗ trợ context window 1M token, điều này quan trọng cho verification pass khi bạn kéo output từ 50+ parallel research agent vào một review context duy nhất.

Tại sao Kimi cho execution?

Agent Swarm của K2.6 hỗ trợ đến 300 parallel sub-agent và 4.000 coordinated tool step mỗi session - đó là hành vi được train vào mô hình, không phải application-layer wrapper. Token economics cũng quan trọng ở scale: K2.6 chạy ở mức giá thấp hơn đáng kể so với frontier closed-source model.

Kết Phần 2

Mooncake giải thích được tại sao 300 agent song song không làm sập hệ thống - disaggregated KV cache là điều kiện cần. Swarm theo wave là cách dependency graph được giải quyết theo đúng thứ tự, không cần hand-code logic. Và Kimi + Claude là sự phân chia labor tự nhiên: scale ở execution layer, judgment ở planning và verification layer.

Phần 3 đi vào 4 pattern kiến trúc cụ thể, prompt template cho orchestrator và sub-agent, và 7 guardrail không thể thiếu nếu bạn muốn swarm chạy được lúc 3 giờ sáng không có người theo dõi.

via Mooncake infrastructure paper & Kimi K2.5 technical paper (PARL)