{"allow_comments":false,"category":"AI 동향","content":{"author":{"title":"YOON DATA","url":"https://yoondata.com/about"},"body":"## 핵심 요약\n조사 기준 시각: 한국시간 2026-09-19 07:34:38 KST (Asia/Seoul, UTC+09:00) / 미국 동부 2026-09-18 18:34:38 EDT (America/New_York, UTC-04:00) / 미국 서부 2026-09-18 15:34:38 PDT (America/Los_Angeles, UTC-07:00) / UTC 2026-09-18 22:34:38.\n[확인] 지정 발행폴더의 직전 브리핑은 gpt_20260919_065459_001.docx이며 Anthropic·Accenture embedded evaluation, Plugin4Shell, LangChain MCP core 편입을 다뤘다. 이번 실행은 그 세 사건을 반복하지 않는다. Drive 중복검색 결과 Kimi K3의 Amazon Bedrock 진입과 AIPerf 신규 발표는 기존 핵심사건으로 확인되지 않았고, AgentCore는 과거 Consent portal·evaluation·storage 같은 기능이 일부 다뤄졌으나 9월 18일 발표된 새 Runtime V2의 memory reclaim·snapshot cold start·scoped unattended identity는 신규 변화라 증분으로 채택했다.\n[확인-1] AWS는 9월 18일 Amazon Bedrock AgentCore의 새 Runtime V2를 발표했다. 기존 runtime은 serverless·session isolation·scale-to-zero를 제공했지만 장시간·bursty agent가 한 번 크게 잡은 memory를 session 종료까지 high-watermark로 계속 점유하고, 새 session cold start가 container image 크기와 동시성에 따라 커지는 문제가 있었다. 새 runtime은 작은 resident memory에서 시작해 필요할 때 page-in하고 released/cold memory를 회수하며, 초기화된 environment를 한 번 snapshot한 뒤 새 instance마다 restore한다. [AWS - The new AgentCore runtime](https://aws.amazon.com/blogs/machine-learning/the-new-agentcore-runtime-elastic-optimized-and-consistently-fast-starts/)\n[확인] AWS 자체 echo-agent benchmark는 us-west-2의 client가 us-east-1 agent를 public internet으로 호출하고, model·tool이 없는 빈 agent에 대해 두 runtime·5개 image size 각각 5,000 cold invocation을 수행했다. 새 runtime은 200MB부터 2GB image까지 P75 cold start 약 2초를 유지했고, 기존 runtime은 약 5.4초에서 거의 30초까지 증가했다. Echo agent code 자체는 P75 약 34ms였다. 이는 AWS 내부 측정이며 실제 model/tool loop의 end-to-end latency와는 다르다.\n[확인] 새 Runtime V2는 memory footprint의 실제 변화에 더 가깝게 billing하고, AWS는 rate 자체는 더 높지만 대부분 workload에서 GB-hours 감소폭이 더 커 총비용이 낮아질 것이라고 주장한다. 구체적인 실제 고객비용절감률은 독립적으로 검증되지 않았다.\n[확인-로드맵] AWS가 `coming soon`으로 공개한 항목은 baseline pricing, 더 큰 RAM/vCPU/storage, x86 microVM, memory snapshot을 이용한 suspend/resume과 lifecycle hook, 그리고 unattended agent에 session context key 기반 scoped identity를 부여하는 기능이다. 새 runtime을 쓰려면 runtime create/update에서 `platformVersion=V2`를 설정한다.\n[확인-이전 체인] 3월에는 session별 filesystem state를 stop/resume 뒤에도 유지하는 managed session storage preview(최대 1GB, idle 14일), 6월에는 WebSocket PTY interactive shell, 7월에는 agent별 traces·prompts·logs를 하나의 CloudWatch log group으로 묶은 unified observability, 8월에는 EC2 기반 runtime instances와 최대 14일 session이 GA됐다. [AWS - Managed session storage](https://aws.amazon.com/about-aws/whats-new/2026/03/bedrock-agentcore-runtime-session-storage/) [AWS - Interactive shells](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-agentcore-runtime/) [AWS - Unified observability](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-bedrock-agentcore-unified-observability-single-log-group/) [AWS - Runtime instances GA](https://aws.amazon.com/about-aws/whats-new/2026/08/aws-bedrock-agentcore-runtime-instances-generally-available/)\n[확인-실제 migration] 같은 9월 18일 AWS는 smolagents 기반 multi-model healthcare agent를 ECS/Fargate에서 AgentCore Runtime으로 옮기는 reference architecture를 공개했다. 기존 agent logic은 유지하면서 container lifecycle, scaling, identity, observability를 managed runtime으로 넘긴 사례다. [AWS - Migrating multi-model agents to AgentCore](https://aws.amazon.com/blogs/machine-learning/migrating-multi-model-ai-agents-to-amazon-bedrock-agentcore-runtime/)\n[추론] 핵심 변화는 agent가 더 이상 `LLM request를 감싸는 함수`가 아니라 OS process나 workload처럼 별도의 실행수명·filesystem·memory·identity·terminal·logs·billing을 가진 단위가 되는 것이다. 특히 unattended agent의 scoped identity를 roadmap에 명시한 것은 사람의 login session과 agent execution principal을 분리해야 한다는 요구가 runtime 수준으로 내려왔다는 뜻이다.\n[추론] 구조를 압축하면 `Event/User → Session Identity → Snapshot MicroVM → On-demand Memory → Tool/File/Shell → Suspend/Resume → Per-agent Observability → Usage Billing`이다. 모델을 교체해도 이 runtime graph는 유지되므로 hyperscaler의 moat가 model catalogue보다 agent execution substrate로 이동할 수 있다.\n[확인-반대근거] 약 2초 P75 cold start는 model과 tool을 호출하지 않는 AWS 자체 echo benchmark다. 실제 application latency, region placement, VPC/network, package initialization, external API, model call을 포함하면 값은 달라진다. `bill goes down` 역시 일반화된 보장이 아니라 AWS의 workload assumption이다. scoped identity·suspend/resume 일부는 아직 출시전이다.\n[확인-2] AWS는 9월 18일 Moonshot AI의 open-weight `Kimi K3`를 Amazon Bedrock에서 제공하기 시작했다. Bedrock은 OpenAI-compatible Responses·Chat Completions와 Invoke·Converse API를 제공하고, Kimi K3는 Bedrock의 open-weight 모델 중 처음으로 explicit prompt caching을 지원한다. [AWS - Introducing Kimi K3 on Amazon Bedrock](https://aws.amazon.com/blogs/machine-learning/introducing-kimi-k3-on-amazon-bedrock/)\n[확인] AWS 설명에 따르면 Kimi K3는 2.8T parameter, native vision, 1M-token context를 가진 Moonshot의 최대모델이다. Bedrock에서 global cross-Region profile `global.moonshotai.kimi-k3`는 geographic profile보다 약 10% 저렴하고, `us.moonshotai.kimi-k3`는 processing을 미국 geography 안에 유지한다. IAM permission은 `bedrock:InvokeModel`, streaming invocation, inference-profile creation 등을 사용한다.\n[확인] Bedrock explicit caching은 최소 1,024 tokens 이후 reusable prefix 끝에 breakpoint를 지정할 수 있고, cache write는 더 높은 rate로 과금되지만 최소 30분 유지된다. 이후 cache hit input token은 할인되고 input-tokens-per-minute quota에서도 제외된다. Coding assistant나 Hermes 같은 agent가 Bedrock/OpenAI-compatible provider를 통해 K3를 사용할 수 있다.\n[확인-모델 원문] Moonshot은 Kimi K3를 7월 16일 공개했고 7월 27일까지 full weights를 공개한다고 발표했다. 회사 공식 기술글은 KDA(Kimi Delta Attention), Attention Residuals, Stable LatentMoE를 사용하며 896 experts 중 16개를 활성화하고, SFT부터 MXFP4 weights/MXFP8 activations의 quantization-aware training을 적용한다고 설명한다. [Moonshot - Kimi K3 Tech Blog](https://www.kimi.ai/blog/kimi-k3)\n[확인] Moonshot은 64+ accelerator supernode 배포를 권장하고 KDA용 prefill-cache 구현을 vLLM 생태계에 기여한다고 밝혔다. 공식 API 가격은 cache-hit input $0.30/MTok, cache-miss input $3/MTok, output $15/MTok이며 coding workload cache hit >90%는 회사 측 주장이다.\n[확인] Moonshot은 자체 글에서 K3의 overall performance가 가장 강력한 proprietary models인 Claude Fable 5와 GPT 5.6 Sol에는 아직 뒤진다고 명시했다. 따라서 `open-weight 최고`와 `전체 frontier 최고`를 구분해야 한다.\n[추론] Bedrock 진입의 본질은 open-weight가 곧 self-hosting을 의미하지 않는다는 점이다. 기업은 weights가 공개된 모델도 `Cloud IAM + Data Boundary + Residency Profile + Prompt Cache + Standard API + Usage Metering`이 붙은 managed service로 소비할 수 있다. open model의 innovation과 proprietary cloud control plane이 결합되는 상품형태다.\n[추론] Bedrock이 tool calling, structured output, reasoning, streaming, Responses/Chat APIs를 model별 별도통합이 아니라 platform capability로 제공한다고 설명한 부분도 중요하다. Model switching cost를 낮추는 대신 고객이 AWS identity·quota·cache·residency·observability 계층에 더 깊게 묶일 수 있다.\n[추론] 구조는 `Open Weights → Managed Inference Runtime → IAM/Residency → Prompt Cache → OpenAI-compatible API → Coding/Productivity Agent`다. 장기 agent는 큰 repository·tool definition·policy prefix를 반복 전송하므로 cache hit와 cache quota economics가 model price만큼 중요해진다.\n[확인-반대근거] 2.8T, 2.5x scaling efficiency, benchmark 성능과 >90% coding cache-hit는 Moonshot 측 주장이다. AWS Bedrock 제공은 모델 품질을 독립적으로 인증하는 행위가 아니다. 2.8T total parameter라도 MoE는 매 token 모든 parameter를 활성화하지 않으며, 64+ accelerator 권장 자체가 self-hosting의 운영난도를 보여준다.\n[확인-3] NVIDIA는 9월 18일 생성형 AI inference benchmarking tool `AIPerf`를 공식 소개했다. AIPerf는 GenAI-Perf의 지정 successor이자 ground-up rewrite로, Perf Analyzer 위에서 동작하던 이전 구조를 버리고 여러 worker process와 record-processing service가 ZMQ로 통신하는 multiprocess architecture를 사용해 Python GIL 때문에 benchmark client 자체가 병목이 되는 문제를 줄이려 한다. [NVIDIA - Benchmarking LLM Inference at Scale with AIPerf](https://developer.nvidia.com/blog/benchmarking-llm-inference-at-scale-with-aiperf/)\n[확인-코드] 공개 GitHub repository는 `pip install aiperf` 설치, 10개 service가 ZMQ로 통신하는 scalable multiprocess architecture, concurrency/request-rate/trace-replay mode, plugin system, OpenAI chat/responses·image/audio 및 NIM endpoint 등을 문서화한다. [GitHub - ai-dynamo/aiperf](https://github.com/ai-dynamo/aiperf)\n[확인] Load는 constant, Poisson, gamma arrival pattern과 burstiness, gradual ramping을 지원하고 input/output sequence length를 fixed·normal·log-normal·empirical 등으로 만들 수 있다. TTFT(Time to First Token), ITL(Inter-Token Latency), end-to-end Request Latency, Output Token Throughput를 p25~p99 등 percentile로 보고하며 DCGM/pynvml이 있으면 GPU power·utilization·memory도 함께 본다.\n[확인] 가장 중요한 변화는 실제 traffic replay다. 공개 repo는 Baseten, BurstGPT, SageMaker Data Capture, Weka agent traces, TraceLab의 real agentic coding sessions, InferenceX AgentX MVP, multi-turn conversation 및 raw payload replay를 지원한다. NVIDIA blog도 Mooncake·Baseten·WEKA AgentX trace replay와 public dataset을 강조한다.\n[확인] NVIDIA는 AWS, CoreWeave, Baseten, Pinterest 등 외부 contributor와 cross-company validation·trace support·DAG benchmarking methodology를 협업했다고 밝힌다. 이는 하나의 NVIDIA 내부 smoke-test tool보다 broader ecosystem measurement tool을 지향한다는 신호다.\n[추론] 벤치마크의 본질이 `tokens/sec` 한 숫자에서 `어떤 실제 workload shape에서 p95/p99 SLA를 지키는가`로 이동한다. Agentic system은 long context, 반복 prefix, tool wait, multi-turn, bursty concurrent sessions를 가지므로 single-user fixed-length test만으로 production capacity를 예측하기 어렵다.\n[추론] 특히 benchmark client가 15,000+ concurrency나 multi-node endpoint를 때릴 때 client-side GIL·socket·event-loop가 병목이면 server 결과가 왜곡된다. AIPerf의 multiprocess 분리는 `server capacity`와 `load-generator capacity`를 분리해 측정하려는 인프라적 변화다.\n[추론] 구조는 `Production Trace/Traffic Model → Multiprocess Load Generator → Inference Endpoint → Per-request TTFT/ITL/Latency → GPU Telemetry → SLO/Goodput → Capacity/Cost Decision`이다. 앞으로 model selection은 accuracy와 list price뿐 아니라 production-trace replay에서의 goodput/cost를 기준으로 바뀔 가능성이 높다.\n[확인-반대근거] AIPerf는 NVIDIA 주도 open-source tool이며 MLPerf 같은 독립 consortium standard가 아니다. 특정 benchmark 결과는 endpoint, tokenizer, streaming 설정, server engine, cache 상태, hardware, request distribution에 따라 달라진다. AIPerf 자체의 existence를 특정 NVIDIA stack 우월성 증거로 사용하면 안 된다.\n## 핵심 사건 종합표\n| 순위 | 분류 | 핵심 사건 | 최초 출처 | 연관 출처 체인 | 발생 시각과 미국 현지 날짜 | 핵심 사실 | 후속 전개 | 왜 중요한가 | 숨은 의미·비하인드 해석 | 담당자·관련 인물 | 수혜자 | 불리한 측 | 기술·사업 영향 | 다음 신호 | 신뢰도 | 검증 상태 | 원문 링크 |\n| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |\n| 1 | Agent Infrastructure·Runtime·Identity | AWS AgentCore 새 Runtime V2가 memory reclaim·snapshot restore로 long-running/unattended agent economics를 재설계 | AWS 9/18 공식 | 3/25 session storage → 6/5 interactive shell → 7/23 unified observability → 8/6 EC2 runtime instances → 9/18 Runtime V2 + multi-model migration reference | 2026-09-18 미국 현지, 공식 시각 미공개; 조사기준 18:34 EDT / 15:34 PDT | small resident footprint·on-demand page-in·cold memory reclaim, preinitialized environment snapshot/restore, platformVersion V2. AWS echo test P75 ~2s across 200MB~2GB vs old ~5.4s~30s | baseline pricing, larger compute/storage, x86, suspend/resume, scoped unattended-agent identity 예고 | agent가 request handler가 아니라 OS-like workload로 변하면서 lifecycle·memory·identity·billing이 핵심 플랫폼층이 됨 | [추론] hyperscaler moat가 model catalogue에서 `Session/Identity/State/Runtime` control plane으로 이동 | Evandro Franco, Rahul Nama, Mark Roy, Shishir Bharathi, Abhishek Singh, AgentCore Runtime team | long-running coding/ops agents, bursty agents, enterprises wanting managed isolation | self-managed orchestrators, peak-memory billing, frameworks tightly coupled to bespoke runtime | `Event→Session Identity→Snapshot MicroVM→Memory→Tool/File/Shell→Suspend/Resume→Logs/Billing` | scoped identity GA, suspend/resume, real-customer p95/cost, x86 support, idle/burst pricing | 매우 높음 | AWS 공식 + related official release chain. 성능·비용효과는 AWS benchmark/claims로 표시 | [New Runtime](https://aws.amazon.com/blogs/machine-learning/the-new-agentcore-runtime-elastic-optimized-and-consistently-fast-starts/) / [Storage](https://aws.amazon.com/about-aws/whats-new/2026/03/bedrock-agentcore-runtime-session-storage/) / [Instances](https://aws.amazon.com/about-aws/whats-new/2026/08/aws-bedrock-agentcore-runtime-instances-generally-available/) |\n| 2 | Open-weight Models·Cloud Inference·Caching | Kimi K3가 Amazon Bedrock에 들어오며 open-weight 2.8T 모델이 IAM·residency·explicit cache가 붙은 managed substrate로 상품화 | Moonshot 7/16 model release → AWS 9/18 Bedrock availability | Moonshot K3 architecture/full weights → Bedrock model onboarding → OpenAI-compatible Responses/Chat + Converse/Invoke → US/global profiles → explicit prompt caching → agent/coding providers | Bedrock 2026-09-18 미국 현지, 공식 시각 미공개; original K3 2026-07-16 | 2.8T total params, 1M context, native vision; Bedrock first open-weight explicit caching; global profile ~10% less than geo, US profile stays US; min 1,024-token cache breakpoint, >=30min | managed open-weight 사용이 self-host 대신 cloud governance/caching/standard API로 확장 | open weights의 경제가 weight download보다 cloud control-plane 서비스로 이동 | [추론] 모델 portability는 올라가지만 IAM·quota·cache·residency에 대한 platform lock-in이 새 moat가 됨 | Moonshot AI Kimi team; AWS Bedrock model/inference teams | enterprises seeking open-weight + managed compliance, coding agents with long context | pure self-host ops, providers without standard APIs/cache/residency | `Weights→Managed Runtime→IAM/Residency→Cache→Standard API→Agent` | independent K3 eval, cache economics, geo expansion, throughput/latency, enterprise adoption | 높음 | AWS + Moonshot 공식. model benchmarks/2.5x efficiency/cache-hit는 vendor claims로 제한 | [AWS](https://aws.amazon.com/blogs/machine-learning/introducing-kimi-k3-on-amazon-bedrock/) / [Moonshot](https://www.kimi.ai/blog/kimi-k3) |\n| 3 | Inference Benchmarking·Agentic Workload·Open Source | NVIDIA AIPerf가 GenAI-Perf를 대체해 multiprocess load generation과 production/agent trace replay를 중심으로 전환 | NVIDIA 9/18 공식 + public GitHub | GenAI-Perf/Perf Analyzer → ground-up AIPerf → ZMQ multiprocess → 15+ endpoint types → production trace replay → p25~p99 + GPU telemetry → AWS/CoreWeave/Baseten/Pinterest collaboration | 2026-09-18 미국 현지, 공식 시각 미공개 | constant/Poisson/gamma, variable ISL/OSL, TTFT/ITL/latency/throughput, multi-turn and real agentic coding traces, Kubernetes/multi-node | benchmark가 synthetic single-turn에서 production-shape replay와 SLO/goodput 탐색으로 이동 | [추론] AI infrastructure 구매가 tokens/sec보다 `production trace의 p99/goodput/cost`로 평가될 가능성 | Francesco Di Natale, Elias Bermudez, Anthony Casagrande, AIPerf contributors, AWS/CoreWeave/Baseten/Pinterest | inference operators, model-serving vendors, capacity planners, agent-platform teams | simplistic single-user benchmark, load generators that become bottleneck | `Trace→Load Shape→Endpoint→Tail Latency/Throughput→GPU Telemetry→SLO/Capacity` | independent adoption, AgentX/TraceLab benchmarks, CI gating, neutral standardization, methodology disputes | 매우 높음 | NVIDIA official + public source repo. tool 자체가 독립 benchmark consortium은 아님 | [NVIDIA](https://developer.nvidia.com/blog/benchmarking-llm-inference-at-scale-with-aiperf/) / [GitHub](https://github.com/ai-dynamo/aiperf) |\n## 1. Amazon Bedrock AgentCore Runtime V2 — 에이전트가 workload가 되는 단계 — 연관 추적\n### ① 최초 신호\n[확인] AgentCore는 2026년 동안 filesystem persistence, shell execution, per-agent observability, EC2 runtime instances를 순차적으로 추가해 agent session을 일반 web request보다 오래 사는 execution unit로 확장해왔다. 9월 18일 Runtime V2는 이 흐름에서 memory lifecycle과 cold-start economics를 직접 재설계한 단계다.\n### ② 공식 확인\n[확인] AWS는 Runtime V2가 session을 작은 resident memory에서 시작하고 필요 시 memory를 page-in하며 freed/cold memory를 회수하고, initialized environment snapshot을 restore해 image size와 concurrency에 덜 민감한 cold start를 제공한다고 밝혔다. [AWS](https://aws.amazon.com/blogs/machine-learning/the-new-agentcore-runtime-elastic-optimized-and-consistently-fast-starts/)\n### ③ 후속 기사와 반응\n[확인-한계] 조사시각 기준 새 Runtime V2의 독립적인 대규모 production benchmark는 아직 확인하지 못했다. 같은 날 AWS의 multi-model smolagents migration post가 실제 reference implementation을 제공하지만, 이는 AWS가 제작한 architecture example이다.\n### ④ 담당자·연구자·개발자 발언\n[확인] AWS Runtime team은 agent가 짧은 chat에서 coding-hours, event-triggered ambient agent, 다른 agent가 실행하는 unattended workload로 이동한다고 설명한다. roadmap에서는 unattended agent가 `사람이 보지 않을 때 무엇을 할 수 있는가`가 새로운 identity 문제라고 직접 정의한다.\n### ⑤ SNS·YouTube·GitHub 등에서 드러난 추가 단서\n[확인] AWS blog는 AgentCore GitHub sample과 새 runtime load-test example을 공개해 사용자가 자기 account에서 cold-start consistency를 재현할 수 있도록 했다. 이번 보고서에서는 sample의 existence를 확인했지만 직접 AWS account에서 benchmark를 실행했다고 쓰지 않는다. 별도 YouTube/SNS demo는 핵심근거로 사용하지 않았다.\n### ⑥ 실제 제품·기술·정책 변화\n[확인] V2는 현재 `platformVersion=V2`로 선택할 수 있고 memory reclaim·environment snapshot restore가 shipped 상태다. baseline pricing, x86, larger resources, suspend/resume, scoped identity는 coming-soon roadmap이므로 현재 기능과 분리해야 한다.\n### ⑦ 숨은 의미와 비하인드\n[추론] Cloud에서 agent는 VM과 serverless function 사이의 새 workload class가 된다. Function보다 오래 살고 state/file/tool을 갖지만 VM처럼 peak capacity를 계속 예약하지 않으려 한다. Runtime vendor의 핵심기술은 model routing보다 microVM snapshot, memory reclaim, session state, credential scope가 될 수 있다.\n[추론] Scoped identity가 session context로 내려가면 IAM의 단위도 `user/service account`에서 `specific agent run`으로 세분화될 수 있다. 이는 장기적으로 tool audit와 delegated authorization을 runtime이 직접 집행하는 기반이 된다.\n### ⑧ 반대 근거와 과장 가능성\n[확인] AWS echo benchmark는 model/tool 없음, cross-region public-internet condition의 platform-start 측정이다. 실제 customer workload의 p95/p99, failure rate, cost curve를 대변하지 않는다. Snapshot restore가 application logic의 idempotency나 external state consistency를 자동 해결하는 것도 아니다.\n### ⑨ 향후 예상되는 다음 행동과 확인해야 할 신호\n실제 pricing table, baseline plan, scoped identity의 IAM semantics, suspend/resume snapshot TTL, secret revocation, x86 launch, 8시간 이상의 serverless session policy, production customer benchmark와 failure/retry telemetry를 추적해야 한다.\n## 2. Kimi K3 on Amazon Bedrock — open weights와 managed cloud의 결합 — 연관 추적\n### ① 최초 신호\n[확인] Moonshot AI는 7월 16일 Kimi K3를 공개하고 full weights를 7월 27일까지 공개하겠다고 밝혔다. 2.8T total parameters, KDA, Attention Residuals, 1M context, native vision을 전면에 내세웠다.\n### ② 공식 확인\n[확인] AWS는 9월 18일 Kimi K3를 Bedrock의 US/Global cross-region inference profile로 제공하기 시작했다. OpenAI-compatible Responses·Chat Completions와 Bedrock Invoke/Converse API를 동시에 지원한다. [AWS](https://aws.amazon.com/blogs/machine-learning/introducing-kimi-k3-on-amazon-bedrock/)\n### ③ 후속 기사와 반응\n[확인] 9월 18일 영어권 후속기사는 Bedrock 진입, 1M context, 2.8T scale, prompt caching을 주요 변화로 보도했다. 그러나 모델 품질 비교는 대부분 Moonshot benchmark를 재인용하므로 독립 성능검증으로 계산하지 않았다.\n### ④ 담당자·연구자·개발자 발언\n[확인] Moonshot은 K3가 proprietary 최고 모델에는 아직 뒤지지만 open 모델 frontier를 확장한다고 스스로 평가한다. AWS는 open-weight innovation을 production security/reliability와 결합하는 것이 Bedrock 전략이라고 설명한다.\n### ⑤ SNS·YouTube·GitHub 등에서 드러난 추가 단서\n[확인] Moonshot은 KDA prefill-cache 구현을 vLLM 생태계에 기여한다고 밝혔고, AWS는 Moonshot-on-AWS sample repository와 OpenCode/Hermes 연결예시를 제공한다. 이번 실행에서는 실제 benchmark code를 돌리지 않았으며 공개 demo 성능을 일반화하지 않았다.\n### ⑥ 실제 제품·기술·정책 변화\n[확인] 사용자는 US geographic profile로 data residency를 제한하거나 global profile로 약 10% 낮은 price를 선택할 수 있고, 1,024+ token prefix에 explicit cache breakpoint를 넣을 수 있다. AWS는 inference request에 zero data retention·zero operator access를 적용한다고 설명한다.\n### ⑦ 숨은 의미와 비하인드\n[추론] `open-weight = 자체 GPU 운영` 공식이 깨지고 있다. Weight openness와 runtime ownership이 분리되면 기업은 open model을 선택하되 실제 execution·identity·data boundary·billing은 hyperscaler에 맡길 수 있다.\n[추론] 이때 platform capability가 model-independent해질수록 model 교체는 쉬워지지만, application이 cache semantics·IAM·quota·geo profile·observability에 의존하면서 cloud switching은 오히려 어려워질 수 있다. Open model competition이 cloud platform 경쟁을 약화시키는 것이 아니라 강화할 수도 있다.\n### ⑧ 반대 근거와 과장 가능성\n[확인] K3의 2.5x scaling efficiency, internal eval, >90% coding cache-hit는 Moonshot claim이다. MoE total-parameter count를 dense model compute cost와 단순비교하면 안 된다. Bedrock에 있다는 사실도 모델이 모든 task에서 Claude/GPT보다 좋다는 뜻이 아니다.\n### ⑨ 향후 예상되는 다음 행동과 확인해야 할 신호\nBedrock 실제 token/cache pricing, K3 independent benchmark와 production latency, 1M-context cache hit economics, additional geographic regions, customer adoption, vLLM KDA cache 성숙도, self-host versus managed total cost를 확인해야 한다.\n## 3. NVIDIA AIPerf — agentic production trace를 재는 inference benchmark — 연관 추적\n### ① 최초 신호\n[확인] 기존 GenAI-Perf와 많은 자체 load generator는 single-process/idealized fixed-length request에 의존해 높은 concurrency에서 client 자체가 병목이 되거나 production traffic의 burst·long-tail을 충분히 표현하지 못하는 문제가 있었다.\n### ② 공식 확인\n[확인] NVIDIA는 9월 18일 AIPerf를 GenAI-Perf의 지정 successor로 소개하고 ground-up multiprocess rewrite, 15+ endpoint types, trace replay, 다양한 arrival pattern, percentile metrics를 공개했다. [NVIDIA](https://developer.nvidia.com/blog/benchmarking-llm-inference-at-scale-with-aiperf/)\n### ③ 후속 기사와 반응\n[확인-한계] 이번 fresh signal은 NVIDIA technical blog와 public repository 자체가 가장 직접적인 증거다. 조사시각 기준 AIPerf 결과를 독립적으로 비교한 대규모 third-party report는 확인하지 못했다. 따라서 tool capability와 특정 GPU/server 성능을 구분한다.\n### ④ 담당자·연구자·개발자 발언\n[확인] NVIDIA authors는 `client should not be the bottleneck`을 핵심 설계원칙으로 설명한다. Acknowledgments에는 AWS의 cross-company validation, CoreWeave의 exporter/concurrency hardening, Baseten trace support, Pinterest의 DAG benchmark 협업이 명시된다.\n### ⑤ SNS·YouTube·GitHub 등에서 드러난 추가 단서\n[확인] GitHub repository는 실제 코드와 docs를 공개하며 TraceLab real agentic coding sessions, Weka agent traces, InferenceX AgentX MVP, SageMaker data capture replay, OpenTelemetry·MLflow·Weights & Biases integration 등을 문서화한다. [GitHub](https://github.com/ai-dynamo/aiperf)\n### ⑥ 실제 제품·기술·정책 변화\n[확인] 벤치마크 workload를 fixed token count에서 Poisson/gamma/bursty request rate, variable ISL/OSL, multi-turn, production trace로 바꿀 수 있고, TTFT/ITL/request latency/output throughput과 tail percentile을 함께 비교한다. GPU telemetry와 request timing을 한 run에 연결할 수 있다.\n### ⑦ 숨은 의미와 비하인드\n[추론] Agentic workload는 생성토큰 수보다 `session shape`가 비용·SLA를 결정한다. 동일 model/server도 short chat, 1M context coding, tool-heavy multi-turn, cache-heavy agent에서 완전히 다른 latency/throughput curve를 만든다. 따라서 구매와 capacity planning은 model benchmark에서 workload benchmark로 이동한다.\n[추론] 향후 inference vendor는 단순 tokens/sec leaderboard보다 고객 trace를 replay해 `p99 under SLA`, `goodput`, `cost per successful task`를 제시해야 할 가능성이 크다. Agent platform에 outcome metric을 연결하면 model-routing policy도 benchmark 결과로 자동 조정할 수 있다.\n### ⑧ 반대 근거와 과장 가능성\n[확인] AIPerf는 NVIDIA가 주도하므로 완전히 vendor-neutral한 표준이라고 볼 수 없다. Load generator의 정교함이 실제 application correctness나 task success를 측정하는 것도 아니다. 또한 public trace가 특정 사용자군을 대표하지 않을 수 있다.\n### ⑨ 향후 예상되는 다음 행동과 확인해야 할 신호\nMLPerf 또는 다른 consortium과의 관계, cloud/inference vendor의 표준채택, AgentX·TraceLab 기반 공개 leaderboard, workload reproducibility, cost/goodput metric, multi-agent DAG methodology, CI/CD performance gate integration을 추적해야 한다.\n## ① 오늘의 핵심 흐름\n이번 증분의 공통점은 `모델 자체`가 아니라 모델을 둘러싼 실행·상품화·측정 계층이 빠르게 표준화되고 있다는 점이다. AWS는 agent session을 managed workload로 만들고, Bedrock은 open weights를 cloud-governed API product로 바꾸며, NVIDIA는 production workload를 재현하는 benchmark substrate를 만든다.\n[추론] 세 사건을 합치면 `Agent Session/Identity → Managed Model Endpoint → Cache/Tool Execution → Production Trace → Benchmark/Telemetry → Capacity/Cost Policy`가 하나의 운영루프다. 앞으로 모델의 지능점수만 높아도 runtime·cache·tail latency·identity가 부실하면 production 경쟁력이 낮아질 수 있다.\n## ② 새로운 출시·업데이트\n9월 18일 직접 확인된 신규 업데이트는 AgentCore Runtime V2, Kimi K3의 Amazon Bedrock availability, NVIDIA AIPerf 공식발표다. 이 세 사건은 직전 브리핑과 주제가 중복되지 않으며, 모두 실제 product/code가 존재하는 변화다.\n## ③ 핵심기술·연구\n핵심기술은 runtime snapshot/memory reclaim, MoE open-weight model의 managed prompt caching, multiprocess production-trace benchmarking이다. 공통적으로 장기·고빈도 agent workload의 `idle/burst`, `state`, `repeated context`, `tail latency` 문제를 직접 다룬다.\n## ④ 기업·담당자·조직 신호\nGoogle도 9월 18일 AI & Economy research bench를 확장해 Nobel Laureate Philippe Aghion, Ajay Agrawal, Anu Madgavkar, Daniel Rock 등을 영입했고 Daniel Rock이 frontier-model telemetry와 econometrics를 연결한다고 밝혔다. 이는 모델업체가 first-party usage telemetry를 경제·노동시장 연구의 원자료로 삼는 흐름이다. [Google - New experts join AI & Economy team](https://blog.google/innovation-and-ai/technology/ai/expanding-ai-economy-research-bench/)\n[추론] Infrastructure vendor가 runtime telemetry를, model/platform vendor가 usage telemetry를, benchmark vendor가 performance trace를 보유하면서 AI 산업의 새로운 자산은 `실제 사용데이터를 구조적으로 측정하는 권리`가 되고 있다.\n## ⑤ SNS·YouTube에서 포착된 신호\nKimi K3와 AgentCore의 공개 demo·coding-agent integration 영상이 존재하지만 이번 보고서는 marketing demo를 성능근거로 사용하지 않았다. AIPerf는 GitHub repository가 직접적인 개발흔적이며, Moonshot의 vLLM cache contribution과 AWS sample repositories가 구현방향을 보강한다. X/Threads의 단순 반응은 신뢰도 높은 신규사실이 아니면 제외했다.\n## ⑥ 약한 신호와 향후 조짐\n[추론] 첫째 agent runtime에서 `session-scoped identity`가 IAM의 정식 단위가 될 가능성이 높다. 둘째 open-weight model의 주요 유통경로가 weights download와 self-host만이 아니라 Bedrock/Vertex/Azure 같은 managed model substrate로 이동할 수 있다. 셋째 inference benchmark는 user trace뿐 아니라 real agent task graph를 replay하고 task-success/cost까지 연결하는 방향으로 확장될 가능성이 있다.\n## ⑦ 과장·루머·주의 항목\nAgentCore 2초 cold start는 실제 LLM agent 전체응답시간이 아니다. Kimi K3의 2.8T와 benchmark 수치는 Moonshot의 모델설명이고 Bedrock onboarding이 독립품질검증은 아니다. AIPerf가 open source라고 해서 산업중립 standard가 확정된 것도 아니다. `coming soon` 기능을 이미 GA된 기능처럼 쓰지 않았다.\n## ⑧ 사용자가 반드시 알아야 할 것\n실전 agent architecture를 설계할 때 최소 `Runtime Registry`, `Identity/Permission Registry`, `Model Endpoint Registry`, `Cache/Context Registry`, `Workload Trace Registry`, `Benchmark/SLO Registry`, `Event/Audit Registry`를 분리하는 것이 유리하다. Model은 이 구조 안에서 교체가능한 component가 된다.\n특히 비용을 계산할 때 token price만 보지 말고 `runtime GB-hours + cold-start/retry + cache-write/hit + tool/network wait + p95/p99 latency + failed task cost`를 하나의 end-to-end equation으로 봐야 한다. 이번 세 발표는 그 계산을 가능하게 하는 runtime·model·measurement layer가 동시에 성숙하고 있음을 보여준다.\n## ⑨ 누락 가능성과 탐색 한계\n이번 조사는 AWS AgentCore 9월 18일 공식발표와 3~8월 공식 feature chain, Kimi K3 Bedrock 공식발표와 Moonshot 기술원문, NVIDIA AIPerf technical blog와 public GitHub repository를 확인했다. 동일 주제가 기존 발행문서에 핵심사건으로 있는지도 Drive에서 검색해 중복을 줄였다.\nAWS의 raw production telemetry와 customer bill, Kimi K3의 독립적인 대규모 production benchmark, AIPerf의 multi-vendor 독립검증 결과는 공개범위가 제한적이다. private Slack/Discord, 로그인 제한 customer dashboard, 내부 benchmark raw data는 확인된 것처럼 쓰지 않았다.\n## 참고 자료와 작성 정보\n조사·작성 기준 시각: 2026-09-19 07:34:38 KST / 2026-09-18 18:34:38 EDT / 2026-09-18 15:34:38 PDT / 2026-09-18 22:34:38 UTC.\n주요 직접출처: [AWS - New AgentCore runtime](https://aws.amazon.com/blogs/machine-learning/the-new-agentcore-runtime-elastic-optimized-and-consistently-fast-starts/); [AWS - Session storage](https://aws.amazon.com/about-aws/whats-new/2026/03/bedrock-agentcore-runtime-session-storage/); [AWS - Interactive shells](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-agentcore-runtime/); [AWS - Unified observability](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-bedrock-agentcore-unified-observability-single-log-group/); [AWS - Runtime instances](https://aws.amazon.com/about-aws/whats-new/2026/08/aws-bedrock-agentcore-runtime-instances-generally-available/); [AWS - Multi-model migration](https://aws.amazon.com/blogs/machine-learning/migrating-multi-model-ai-agents-to-amazon-bedrock-agentcore-runtime/); [AWS - Kimi K3 on Bedrock](https://aws.amazon.com/blogs/machine-learning/introducing-kimi-k3-on-amazon-bedrock/); [Moonshot - Kimi K3](https://www.kimi.ai/blog/kimi-k3); [NVIDIA - AIPerf](https://developer.nvidia.com/blog/benchmarking-llm-inference-at-scale-with-aiperf/); [GitHub - AIPerf](https://github.com/ai-dynamo/aiperf); [Google - AI & Economy team](https://blog.google/innovation-and-ai/technology/ai/expanding-ai-economy-research-bench/).\n이 브리핑은 AI의 도움으로 공개 자료를 조사·정리했습니다. 확인된 사실과 추론, 미확인 내용을 구분해 표시했습니다.","body_format":"text/markdown","body_text":"핵심 요약 조사 기준 시각: 한국시간 2026-09-19 07:34:38 KST (Asia/Seoul, UTC+09:00) / 미국 동부 2026-09-18 18:34:38 EDT (America/New_York, UTC-04:00) / 미국 서부 2026-09-18 15:34:38 PDT (America/Los_Angeles, UTC-07:00) / UTC 2026-09-18 22:34:38. [확인] 지정 발행폴더의 직전 브리핑은 gpt_20260919_065459_001.docx이며 Anthropic·Accenture embedded evaluation, Plugin4Shell, LangChain MCP core 편입을 다뤘다. 이번 실행은 그 세 사건을 반복하지 않는다. Drive 중복검색 결과 Kimi K3의 Amazon Bedrock 진입과 AIPerf 신규 발표는 기존 핵심사건으로 확인되지 않았고, AgentCore는 과거 Consent portal·evaluation·storage 같은 기능이 일부 다뤄졌으나 9월 18일 발표된 새 Runtime V2의 memory reclaim·snapshot cold start·scoped unattended identity는 신규 변화라 증분으로 채택했다. [확인-1] AWS는 9월 18일 Amazon Bedrock AgentCore의 새 Runtime V2를 발표했다. 기존 runtime은 serverless·session isolation·scale-to-zero를 제공했지만 장시간·bursty agent가 한 번 크게 잡은 memory를 session 종료까지 high-watermark로 계속 점유하고, 새 session cold start가 container image 크기와 동시성에 따라 커지는 문제가 있었다. 새 runtime은 작은 resident memory에서 시작해 필요할 때 page-in하고 released/cold memory를 회수하며, 초기화된 environment를 한 번 snapshot한 뒤 새 instance마다 restore한다. AWS - The new AgentCore runtime [확인] AWS 자체 echo-agent benchmark는 us-west-2의 client가 us-east-1 agent를 public internet으로 호출하고, model·tool이 없는 빈 agent에 대해 두 runtime·5개 image size 각각 5,000 cold invocation을 수행했다. 새 runtime은 200MB부터 2GB image까지 P75 cold start 약 2초를 유지했고, 기존 runtime은 약 5.4초에서 거의 30초까지 증가했다. Echo agent code 자체는 P75 약 34ms였다. 이는 AWS 내부 측정이며 실제 model/tool loop의 end-to-end latency와는 다르다. [확인] 새 Runtime V2는 memory footprint의 실제 변화에 더 가깝게 billing하고, AWS는 rate 자체는 더 높지만 대부분 workload에서 GB-hours 감소폭이 더 커 총비용이 낮아질 것이라고 주장한다. 구체적인 실제 고객비용절감률은 독립적으로 검증되지 않았다. [확인-로드맵] AWS가 coming soon으로 공개한 항목은 baseline pricing, 더 큰 RAM/vCPU/storage, x86 microVM, memory snapshot을 이용한 suspend/resume과 lifecycle hook, 그리고 unattended agent에 session context key 기반 scoped identity를 부여하는 기능이다. 새 runtime을 쓰려면 runtime create/update에서 platformVersion=V2를 설정한다. [확인-이전 체인] 3월에는 session별 filesystem state를 stop/resume 뒤에도 유지하는 managed session storage preview(최대 1GB, idle 14일), 6월에는 WebSocket PTY interactive shell, 7월에는 agent별 traces·prompts·logs를 하나의 CloudWatch log group으로 묶은 unified observability, 8월에는 EC2 기반 runtime instances와 최대 14일 session이 GA됐다. AWS - Managed session storage AWS - Interactive shells AWS - Unified observability AWS - Runtime instances GA [확인-실제 migration] 같은 9월 18일 AWS는 smolagents 기반 multi-model healthcare agent를 ECS/Fargate에서 AgentCore Runtime으로 옮기는 reference architecture를 공개했다. 기존 agent logic은 유지하면서 container lifecycle, scaling, identity, observability를 managed runtime으로 넘긴 사례다. AWS - Migrating multi-model agents to AgentCore [추론] 핵심 변화는 agent가 더 이상 LLM request를 감싸는 함수가 아니라 OS process나 workload처럼 별도의 실행수명·filesystem·memory·identity·terminal·logs·billing을 가진 단위가 되는 것이다. 특히 unattended agent의 scoped identity를 roadmap에 명시한 것은 사람의 login session과 agent execution principal을 분리해야 한다는 요구가 runtime 수준으로 내려왔다는 뜻이다. [추론] 구조를 압축하면 Event/User → Session Identity → Snapshot MicroVM → On-demand Memory → Tool/File/Shell → Suspend/Resume → Per-agent Observability → Usage Billing이다. 모델을 교체해도 이 runtime graph는 유지되므로 hyperscaler의 moat가 model catalogue보다 agent execution substrate로 이동할 수 있다. [확인-반대근거] 약 2초 P75 cold start는 model과 tool을 호출하지 않는 AWS 자체 echo benchmark다. 실제 application latency, region placement, VPC/network, package initialization, external API, model call을 포함하면 값은 달라진다. bill goes down 역시 일반화된 보장이 아니라 AWS의 workload assumption이다. scoped identity·suspend/resume 일부는 아직 출시전이다. [확인-2] AWS는 9월 18일 Moonshot AI의 open-weight Kimi K3를 Amazon Bedrock에서 제공하기 시작했다. Bedrock은 OpenAI-compatible Responses·Chat Completions와 Invoke·Converse API를 제공하고, Kimi K3는 Bedrock의 open-weight 모델 중 처음으로 explicit prompt caching을 지원한다. AWS - Introducing Kimi K3 on Amazon Bedrock [확인] AWS 설명에 따르면 Kimi K3는 2.8T parameter, native vision, 1M-token context를 가진 Moonshot의 최대모델이다. Bedrock에서 global cross-Region profile global.moonshotai.kimi-k3는 geographic profile보다 약 10% 저렴하고, us.moonshotai.kimi-k3는 processing을 미국 geography 안에 유지한다. IAM permission은 bedrock:InvokeModel, streaming invocation, inference-profile creation 등을 사용한다. [확인] Bedrock explicit caching은 최소 1,024 tokens 이후 reusable prefix 끝에 breakpoint를 지정할 수 있고, cache write는 더 높은 rate로 과금되지만 최소 30분 유지된다. 이후 cache hit input token은 할인되고 input-tokens-per-minute quota에서도 제외된다. Coding assistant나 Hermes 같은 agent가 Bedrock/OpenAI-compatible provider를 통해 K3를 사용할 수 있다. [확인-모델 원문] Moonshot은 Kimi K3를 7월 16일 공개했고 7월 27일까지 full weights를 공개한다고 발표했다. 회사 공식 기술글은 KDA(Kimi Delta Attention), Attention Residuals, Stable LatentMoE를 사용하며 896 experts 중 16개를 활성화하고, SFT부터 MXFP4 weights/MXFP8 activations의 quantization-aware training을 적용한다고 설명한다. Moonshot - Kimi K3 Tech Blog [확인] Moonshot은 64+ accelerator supernode 배포를 권장하고 KDA용 prefill-cache 구현을 vLLM 생태계에 기여한다고 밝혔다. 공식 API 가격은 cache-hit input $0.30/MTok, cache-miss input $3/MTok, output $15/MTok이며 coding workload cache hit >90%는 회사 측 주장이다. [확인] Moonshot은 자체 글에서 K3의 overall performance가 가장 강력한 proprietary models인 Claude Fable 5와 GPT 5.6 Sol에는 아직 뒤진다고 명시했다. 따라서 open-weight 최고와 전체 frontier 최고를 구분해야 한다. [추론] Bedrock 진입의 본질은 open-weight가 곧 self-hosting을 의미하지 않는다는 점이다. 기업은 weights가 공개된 모델도 Cloud IAM + Data Boundary + Residency Profile + Prompt Cache + Standard API + Usage Metering이 붙은 managed service로 소비할 수 있다. open model의 innovation과 proprietary cloud control plane이 결합되는 상품형태다. [추론] Bedrock이 tool calling, structured output, reasoning, streaming, Responses/Chat APIs를 model별 별도통합이 아니라 platform capability로 제공한다고 설명한 부분도 중요하다. Model switching cost를 낮추는 대신 고객이 AWS identity·quota·cache·residency·observability 계층에 더 깊게 묶일 수 있다. [추론] 구조는 Open Weights → Managed Inference Runtime → IAM/Residency → Prompt Cache → OpenAI-compatible API → Coding/Productivity Agent다. 장기 agent는 큰 repository·tool definition·policy prefix를 반복 전송하므로 cache hit와 cache quota economics가 model price만큼 중요해진다. [확인-반대근거] 2.8T, 2.5x scaling efficiency, benchmark 성능과 >90% coding cache-hit는 Moonshot 측 주장이다. AWS Bedrock 제공은 모델 품질을 독립적으로 인증하는 행위가 아니다. 2.8T total parameter라도 MoE는 매 token 모든 parameter를 활성화하지 않으며, 64+ accelerator 권장 자체가 self-hosting의 운영난도를 보여준다. [확인-3] NVIDIA는 9월 18일 생성형 AI inference benchmarking tool AIPerf를 공식 소개했다. AIPerf는 GenAI-Perf의 지정 successor이자 ground-up rewrite로, Perf Analyzer 위에서 동작하던 이전 구조를 버리고 여러 worker process와 record-processing service가 ZMQ로 통신하는 multiprocess architecture를 사용해 Python GIL 때문에 benchmark client 자체가 병목이 되는 문제를 줄이려 한다. NVIDIA - Benchmarking LLM Inference at Scale with AIPerf [확인-코드] 공개 GitHub repository는 pip install aiperf 설치, 10개 service가 ZMQ로 통신하는 scalable multiprocess architecture, concurrency/request-rate/trace-replay mode, plugin system, OpenAI chat/responses·image/audio 및 NIM endpoint 등을 문서화한다. GitHub - ai-dynamo/aiperf [확인] Load는 constant, Poisson, gamma arrival pattern과 burstiness, gradual ramping을 지원하고 input/output sequence length를 fixed·normal·log-normal·empirical 등으로 만들 수 있다. TTFT(Time to First Token), ITL(Inter-Token Latency), end-to-end Request Latency, Output Token Throughput를 p25~p99 등 percentile로 보고하며 DCGM/pynvml이 있으면 GPU power·utilization·memory도 함께 본다. [확인] 가장 중요한 변화는 실제 traffic replay다. 공개 repo는 Baseten, BurstGPT, SageMaker Data Capture, Weka agent traces, TraceLab의 real agentic coding sessions, InferenceX AgentX MVP, multi-turn conversation 및 raw payload replay를 지원한다. NVIDIA blog도 Mooncake·Baseten·WEKA AgentX trace replay와 public dataset을 강조한다. [확인] NVIDIA는 AWS, CoreWeave, Baseten, Pinterest 등 외부 contributor와 cross-company validation·trace support·DAG benchmarking methodology를 협업했다고 밝힌다. 이는 하나의 NVIDIA 내부 smoke-test tool보다 broader ecosystem measurement tool을 지향한다는 신호다. [추론] 벤치마크의 본질이 tokens/sec 한 숫자에서 어떤 실제 workload shape에서 p95/p99 SLA를 지키는가로 이동한다. Agentic system은 long context, 반복 prefix, tool wait, multi-turn, bursty concurrent sessions를 가지므로 single-user fixed-length test만으로 production capacity를 예측하기 어렵다. [추론] 특히 benchmark client가 15,000+ concurrency나 multi-node endpoint를 때릴 때 client-side GIL·socket·event-loop가 병목이면 server 결과가 왜곡된다. AIPerf의 multiprocess 분리는 server capacity와 load-generator capacity를 분리해 측정하려는 인프라적 변화다. [추론] 구조는 Production Trace/Traffic Model → Multiprocess Load Generator → Inference Endpoint → Per-request TTFT/ITL/Latency → GPU Telemetry → SLO/Goodput → Capacity/Cost Decision이다. 앞으로 model selection은 accuracy와 list price뿐 아니라 production-trace replay에서의 goodput/cost를 기준으로 바뀔 가능성이 높다. [확인-반대근거] AIPerf는 NVIDIA 주도 open-source tool이며 MLPerf 같은 독립 consortium standard가 아니다. 특정 benchmark 결과는 endpoint, tokenizer, streaming 설정, server engine, cache 상태, hardware, request distribution에 따라 달라진다. AIPerf 자체의 existence를 특정 NVIDIA stack 우월성 증거로 사용하면 안 된다. 핵심 사건 종합표 | 순위 | 분류 | 핵심 사건 | 최초 출처 | 연관 출처 체인 | 발생 시각과 미국 현지 날짜 | 핵심 사실 | 후속 전개 | 왜 중요한가 | 숨은 의미·비하인드 해석 | 담당자·관련 인물 | 수혜자 | 불리한 측 | 기술·사업 영향 | 다음 신호 | 신뢰도 | 검증 상태 | 원문 링크 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 1 | Agent Infrastructure·Runtime·Identity | AWS AgentCore 새 Runtime V2가 memory reclaim·snapshot restore로 long-running/unattended agent economics를 재설계 | AWS 9/18 공식 | 3/25 session storage → 6/5 interactive shell → 7/23 unified observability → 8/6 EC2 runtime instances → 9/18 Runtime V2 + multi-model migration reference | 2026-09-18 미국 현지, 공식 시각 미공개; 조사기준 18:34 EDT / 15:34 PDT | small resident footprint·on-demand page-in·cold memory reclaim, preinitialized environment snapshot/restore, platformVersion V2. AWS echo test P75 ~2s across 200MB~2GB vs old ~5.4s~30s | baseline pricing, larger compute/storage, x86, suspend/resume, scoped unattended-agent identity 예고 | agent가 request handler가 아니라 OS-like workload로 변하면서 lifecycle·memory·identity·billing이 핵심 플랫폼층이 됨 | [추론] hyperscaler moat가 model catalogue에서 Session/Identity/State/Runtime control plane으로 이동 | Evandro Franco, Rahul Nama, Mark Roy, Shishir Bharathi, Abhishek Singh, AgentCore Runtime team | long-running coding/ops agents, bursty agents, enterprises wanting managed isolation | self-managed orchestrators, peak-memory billing, frameworks tightly coupled to bespoke runtime | Event→Session Identity→Snapshot MicroVM→Memory→Tool/File/Shell→Suspend/Resume→Logs/Billing | scoped identity GA, suspend/resume, real-customer p95/cost, x86 support, idle/burst pricing | 매우 높음 | AWS 공식 + related official release chain. 성능·비용효과는 AWS benchmark/claims로 표시 | New Runtime / Storage / Instances | | 2 | Open-weight Models·Cloud Inference·Caching | Kimi K3가 Amazon Bedrock에 들어오며 open-weight 2.8T 모델이 IAM·residency·explicit cache가 붙은 managed substrate로 상품화 | Moonshot 7/16 model release → AWS 9/18 Bedrock availability | Moonshot K3 architecture/full weights → Bedrock model onboarding → OpenAI-compatible Responses/Chat + Converse/Invoke → US/global profiles → explicit prompt caching → agent/coding providers | Bedrock 2026-09-18 미국 현지, 공식 시각 미공개; original K3 2026-07-16 | 2.8T total params, 1M context, native vision; Bedrock first open-weight explicit caching; global profile ~10% less than geo, US profile stays US; min 1,024-token cache breakpoint, >=30min | managed open-weight 사용이 self-host 대신 cloud governance/caching/standard API로 확장 | open weights의 경제가 weight download보다 cloud control-plane 서비스로 이동 | [추론] 모델 portability는 올라가지만 IAM·quota·cache·residency에 대한 platform lock-in이 새 moat가 됨 | Moonshot AI Kimi team; AWS Bedrock model/inference teams | enterprises seeking open-weight + managed compliance, coding agents with long context | pure self-host ops, providers without standard APIs/cache/residency | Weights→Managed Runtime→IAM/Residency→Cache→Standard API→Agent | independent K3 eval, cache economics, geo expansion, throughput/latency, enterprise adoption | 높음 | AWS + Moonshot 공식. model benchmarks/2.5x efficiency/cache-hit는 vendor claims로 제한 | AWS / Moonshot | | 3 | Inference Benchmarking·Agentic Workload·Open Source | NVIDIA AIPerf가 GenAI-Perf를 대체해 multiprocess load generation과 production/agent trace replay를 중심으로 전환 | NVIDIA 9/18 공식 + public GitHub | GenAI-Perf/Perf Analyzer → ground-up AIPerf → ZMQ multiprocess → 15+ endpoint types → production trace replay → p25~p99 + GPU telemetry → AWS/CoreWeave/Baseten/Pinterest collaboration | 2026-09-18 미국 현지, 공식 시각 미공개 | constant/Poisson/gamma, variable ISL/OSL, TTFT/ITL/latency/throughput, multi-turn and real agentic coding traces, Kubernetes/multi-node | benchmark가 synthetic single-turn에서 production-shape replay와 SLO/goodput 탐색으로 이동 | [추론] AI infrastructure 구매가 tokens/sec보다 production trace의 p99/goodput/cost로 평가될 가능성 | Francesco Di Natale, Elias Bermudez, Anthony Casagrande, AIPerf contributors, AWS/CoreWeave/Baseten/Pinterest | inference operators, model-serving vendors, capacity planners, agent-platform teams | simplistic single-user benchmark, load generators that become bottleneck | Trace→Load Shape→Endpoint→Tail Latency/Throughput→GPU Telemetry→SLO/Capacity | independent adoption, AgentX/TraceLab benchmarks, CI gating, neutral standardization, methodology disputes | 매우 높음 | NVIDIA official + public source repo. tool 자체가 독립 benchmark consortium은 아님 | NVIDIA / GitHub | 1. Amazon Bedrock AgentCore Runtime V2 — 에이전트가 workload가 되는 단계 — 연관 추적 ① 최초 신호 [확인] AgentCore는 2026년 동안 filesystem persistence, shell execution, per-agent observability, EC2 runtime instances를 순차적으로 추가해 agent session을 일반 web request보다 오래 사는 execution unit로 확장해왔다. 9월 18일 Runtime V2는 이 흐름에서 memory lifecycle과 cold-start economics를 직접 재설계한 단계다. ② 공식 확인 [확인] AWS는 Runtime V2가 session을 작은 resident memory에서 시작하고 필요 시 memory를 page-in하며 freed/cold memory를 회수하고, initialized environment snapshot을 restore해 image size와 concurrency에 덜 민감한 cold start를 제공한다고 밝혔다. AWS ③ 후속 기사와 반응 [확인-한계] 조사시각 기준 새 Runtime V2의 독립적인 대규모 production benchmark는 아직 확인하지 못했다. 같은 날 AWS의 multi-model smolagents migration post가 실제 reference implementation을 제공하지만, 이는 AWS가 제작한 architecture example이다. ④ 담당자·연구자·개발자 발언 [확인] AWS Runtime team은 agent가 짧은 chat에서 coding-hours, event-triggered ambient agent, 다른 agent가 실행하는 unattended workload로 이동한다고 설명한다. roadmap에서는 unattended agent가 사람이 보지 않을 때 무엇을 할 수 있는가가 새로운 identity 문제라고 직접 정의한다. ⑤ SNS·YouTube·GitHub 등에서 드러난 추가 단서 [확인] AWS blog는 AgentCore GitHub sample과 새 runtime load-test example을 공개해 사용자가 자기 account에서 cold-start consistency를 재현할 수 있도록 했다. 이번 보고서에서는 sample의 existence를 확인했지만 직접 AWS account에서 benchmark를 실행했다고 쓰지 않는다. 별도 YouTube/SNS demo는 핵심근거로 사용하지 않았다. ⑥ 실제 제품·기술·정책 변화 [확인] V2는 현재 platformVersion=V2로 선택할 수 있고 memory reclaim·environment snapshot restore가 shipped 상태다. baseline pricing, x86, larger resources, suspend/resume, scoped identity는 coming-soon roadmap이므로 현재 기능과 분리해야 한다. ⑦ 숨은 의미와 비하인드 [추론] Cloud에서 agent는 VM과 serverless function 사이의 새 workload class가 된다. Function보다 오래 살고 state/file/tool을 갖지만 VM처럼 peak capacity를 계속 예약하지 않으려 한다. Runtime vendor의 핵심기술은 model routing보다 microVM snapshot, memory reclaim, session state, credential scope가 될 수 있다. [추론] Scoped identity가 session context로 내려가면 IAM의 단위도 user/service account에서 specific agent run으로 세분화될 수 있다. 이는 장기적으로 tool audit와 delegated authorization을 runtime이 직접 집행하는 기반이 된다. ⑧ 반대 근거와 과장 가능성 [확인] AWS echo benchmark는 model/tool 없음, cross-region public-internet condition의 platform-start 측정이다. 실제 customer workload의 p95/p99, failure rate, cost curve를 대변하지 않는다. Snapshot restore가 application logic의 idempotency나 external state consistency를 자동 해결하는 것도 아니다. ⑨ 향후 예상되는 다음 행동과 확인해야 할 신호 실제 pricing table, baseline plan, scoped identity의 IAM semantics, suspend/resume snapshot TTL, secret revocation, x86 launch, 8시간 이상의 serverless session policy, production customer benchmark와 failure/retry telemetry를 추적해야 한다. 2. Kimi K3 on Amazon Bedrock — open weights와 managed cloud의 결합 — 연관 추적 ① 최초 신호 [확인] Moonshot AI는 7월 16일 Kimi K3를 공개하고 full weights를 7월 27일까지 공개하겠다고 밝혔다. 2.8T total parameters, KDA, Attention Residuals, 1M context, native vision을 전면에 내세웠다. ② 공식 확인 [확인] AWS는 9월 18일 Kimi K3를 Bedrock의 US/Global cross-region inference profile로 제공하기 시작했다. OpenAI-compatible Responses·Chat Completions와 Bedrock Invoke/Converse API를 동시에 지원한다. AWS ③ 후속 기사와 반응 [확인] 9월 18일 영어권 후속기사는 Bedrock 진입, 1M context, 2.8T scale, prompt caching을 주요 변화로 보도했다. 그러나 모델 품질 비교는 대부분 Moonshot benchmark를 재인용하므로 독립 성능검증으로 계산하지 않았다. ④ 담당자·연구자·개발자 발언 [확인] Moonshot은 K3가 proprietary 최고 모델에는 아직 뒤지지만 open 모델 frontier를 확장한다고 스스로 평가한다. AWS는 open-weight innovation을 production security/reliability와 결합하는 것이 Bedrock 전략이라고 설명한다. ⑤ SNS·YouTube·GitHub 등에서 드러난 추가 단서 [확인] Moonshot은 KDA prefill-cache 구현을 vLLM 생태계에 기여한다고 밝혔고, AWS는 Moonshot-on-AWS sample repository와 OpenCode/Hermes 연결예시를 제공한다. 이번 실행에서는 실제 benchmark code를 돌리지 않았으며 공개 demo 성능을 일반화하지 않았다. ⑥ 실제 제품·기술·정책 변화 [확인] 사용자는 US geographic profile로 data residency를 제한하거나 global profile로 약 10% 낮은 price를 선택할 수 있고, 1,024+ token prefix에 explicit cache breakpoint를 넣을 수 있다. AWS는 inference request에 zero data retention·zero operator access를 적용한다고 설명한다. ⑦ 숨은 의미와 비하인드 [추론] open-weight = 자체 GPU 운영 공식이 깨지고 있다. Weight openness와 runtime ownership이 분리되면 기업은 open model을 선택하되 실제 execution·identity·data boundary·billing은 hyperscaler에 맡길 수 있다. [추론] 이때 platform capability가 model-independent해질수록 model 교체는 쉬워지지만, application이 cache semantics·IAM·quota·geo profile·observability에 의존하면서 cloud switching은 오히려 어려워질 수 있다. Open model competition이 cloud platform 경쟁을 약화시키는 것이 아니라 강화할 수도 있다. ⑧ 반대 근거와 과장 가능성 [확인] K3의 2.5x scaling efficiency, internal eval, >90% coding cache-hit는 Moonshot claim이다. MoE total-parameter count를 dense model compute cost와 단순비교하면 안 된다. Bedrock에 있다는 사실도 모델이 모든 task에서 Claude/GPT보다 좋다는 뜻이 아니다. ⑨ 향후 예상되는 다음 행동과 확인해야 할 신호 Bedrock 실제 token/cache pricing, K3 independent benchmark와 production latency, 1M-context cache hit economics, additional geographic regions, customer adoption, vLLM KDA cache 성숙도, self-host versus managed total cost를 확인해야 한다. 3. NVIDIA AIPerf — agentic production trace를 재는 inference benchmark — 연관 추적 ① 최초 신호 [확인] 기존 GenAI-Perf와 많은 자체 load generator는 single-process/idealized fixed-length request에 의존해 높은 concurrency에서 client 자체가 병목이 되거나 production traffic의 burst·long-tail을 충분히 표현하지 못하는 문제가 있었다. ② 공식 확인 [확인] NVIDIA는 9월 18일 AIPerf를 GenAI-Perf의 지정 successor로 소개하고 ground-up multiprocess rewrite, 15+ endpoint types, trace replay, 다양한 arrival pattern, percentile metrics를 공개했다. NVIDIA ③ 후속 기사와 반응 [확인-한계] 이번 fresh signal은 NVIDIA technical blog와 public repository 자체가 가장 직접적인 증거다. 조사시각 기준 AIPerf 결과를 독립적으로 비교한 대규모 third-party report는 확인하지 못했다. 따라서 tool capability와 특정 GPU/server 성능을 구분한다. ④ 담당자·연구자·개발자 발언 [확인] NVIDIA authors는 client should not be the bottleneck을 핵심 설계원칙으로 설명한다. Acknowledgments에는 AWS의 cross-company validation, CoreWeave의 exporter/concurrency hardening, Baseten trace support, Pinterest의 DAG benchmark 협업이 명시된다. ⑤ SNS·YouTube·GitHub 등에서 드러난 추가 단서 [확인] GitHub repository는 실제 코드와 docs를 공개하며 TraceLab real agentic coding sessions, Weka agent traces, InferenceX AgentX MVP, SageMaker data capture replay, OpenTelemetry·MLflow·Weights & Biases integration 등을 문서화한다. GitHub ⑥ 실제 제품·기술·정책 변화 [확인] 벤치마크 workload를 fixed token count에서 Poisson/gamma/bursty request rate, variable ISL/OSL, multi-turn, production trace로 바꿀 수 있고, TTFT/ITL/request latency/output throughput과 tail percentile을 함께 비교한다. GPU telemetry와 request timing을 한 run에 연결할 수 있다. ⑦ 숨은 의미와 비하인드 [추론] Agentic workload는 생성토큰 수보다 session shape가 비용·SLA를 결정한다. 동일 model/server도 short chat, 1M context coding, tool-heavy multi-turn, cache-heavy agent에서 완전히 다른 latency/throughput curve를 만든다. 따라서 구매와 capacity planning은 model benchmark에서 workload benchmark로 이동한다. [추론] 향후 inference vendor는 단순 tokens/sec leaderboard보다 고객 trace를 replay해 p99 under SLA, goodput, cost per successful task를 제시해야 할 가능성이 크다. Agent platform에 outcome metric을 연결하면 model-routing policy도 benchmark 결과로 자동 조정할 수 있다. ⑧ 반대 근거와 과장 가능성 [확인] AIPerf는 NVIDIA가 주도하므로 완전히 vendor-neutral한 표준이라고 볼 수 없다. Load generator의 정교함이 실제 application correctness나 task success를 측정하는 것도 아니다. 또한 public trace가 특정 사용자군을 대표하지 않을 수 있다. ⑨ 향후 예상되는 다음 행동과 확인해야 할 신호 MLPerf 또는 다른 consortium과의 관계, cloud/inference vendor의 표준채택, AgentX·TraceLab 기반 공개 leaderboard, workload reproducibility, cost/goodput metric, multi-agent DAG methodology, CI/CD performance gate integration을 추적해야 한다. ① 오늘의 핵심 흐름 이번 증분의 공통점은 모델 자체가 아니라 모델을 둘러싼 실행·상품화·측정 계층이 빠르게 표준화되고 있다는 점이다. AWS는 agent session을 managed workload로 만들고, Bedrock은 open weights를 cloud-governed API product로 바꾸며, NVIDIA는 production workload를 재현하는 benchmark substrate를 만든다. [추론] 세 사건을 합치면 Agent Session/Identity → Managed Model Endpoint → Cache/Tool Execution → Production Trace → Benchmark/Telemetry → Capacity/Cost Policy가 하나의 운영루프다. 앞으로 모델의 지능점수만 높아도 runtime·cache·tail latency·identity가 부실하면 production 경쟁력이 낮아질 수 있다. ② 새로운 출시·업데이트 9월 18일 직접 확인된 신규 업데이트는 AgentCore Runtime V2, Kimi K3의 Amazon Bedrock availability, NVIDIA AIPerf 공식발표다. 이 세 사건은 직전 브리핑과 주제가 중복되지 않으며, 모두 실제 product/code가 존재하는 변화다. ③ 핵심기술·연구 핵심기술은 runtime snapshot/memory reclaim, MoE open-weight model의 managed prompt caching, multiprocess production-trace benchmarking이다. 공통적으로 장기·고빈도 agent workload의 idle/burst, state, repeated context, tail latency 문제를 직접 다룬다. ④ 기업·담당자·조직 신호 Google도 9월 18일 AI & Economy research bench를 확장해 Nobel Laureate Philippe Aghion, Ajay Agrawal, Anu Madgavkar, Daniel Rock 등을 영입했고 Daniel Rock이 frontier-model telemetry와 econometrics를 연결한다고 밝혔다. 이는 모델업체가 first-party usage telemetry를 경제·노동시장 연구의 원자료로 삼는 흐름이다. Google - New experts join AI & Economy team [추론] Infrastructure vendor가 runtime telemetry를, model/platform vendor가 usage telemetry를, benchmark vendor가 performance trace를 보유하면서 AI 산업의 새로운 자산은 실제 사용데이터를 구조적으로 측정하는 권리가 되고 있다. ⑤ SNS·YouTube에서 포착된 신호 Kimi K3와 AgentCore의 공개 demo·coding-agent integration 영상이 존재하지만 이번 보고서는 marketing demo를 성능근거로 사용하지 않았다. AIPerf는 GitHub repository가 직접적인 개발흔적이며, Moonshot의 vLLM cache contribution과 AWS sample repositories가 구현방향을 보강한다. X/Threads의 단순 반응은 신뢰도 높은 신규사실이 아니면 제외했다. ⑥ 약한 신호와 향후 조짐 [추론] 첫째 agent runtime에서 session-scoped identity가 IAM의 정식 단위가 될 가능성이 높다. 둘째 open-weight model의 주요 유통경로가 weights download와 self-host만이 아니라 Bedrock/Vertex/Azure 같은 managed model substrate로 이동할 수 있다. 셋째 inference benchmark는 user trace뿐 아니라 real agent task graph를 replay하고 task-success/cost까지 연결하는 방향으로 확장될 가능성이 있다. ⑦ 과장·루머·주의 항목 AgentCore 2초 cold start는 실제 LLM agent 전체응답시간이 아니다. Kimi K3의 2.8T와 benchmark 수치는 Moonshot의 모델설명이고 Bedrock onboarding이 독립품질검증은 아니다. AIPerf가 open source라고 해서 산업중립 standard가 확정된 것도 아니다. coming soon 기능을 이미 GA된 기능처럼 쓰지 않았다. ⑧ 사용자가 반드시 알아야 할 것 실전 agent architecture를 설계할 때 최소 Runtime Registry, Identity/Permission Registry, Model Endpoint Registry, Cache/Context Registry, Workload Trace Registry, Benchmark/SLO Registry, Event/Audit Registry를 분리하는 것이 유리하다. Model은 이 구조 안에서 교체가능한 component가 된다. 특히 비용을 계산할 때 token price만 보지 말고 runtime GB-hours + cold-start/retry + cache-write/hit + tool/network wait + p95/p99 latency + failed task cost를 하나의 end-to-end equation으로 봐야 한다. 이번 세 발표는 그 계산을 가능하게 하는 runtime·model·measurement layer가 동시에 성숙하고 있음을 보여준다. ⑨ 누락 가능성과 탐색 한계 이번 조사는 AWS AgentCore 9월 18일 공식발표와 3~8월 공식 feature chain, Kimi K3 Bedrock 공식발표와 Moonshot 기술원문, NVIDIA AIPerf technical blog와 public GitHub repository를 확인했다. 동일 주제가 기존 발행문서에 핵심사건으로 있는지도 Drive에서 검색해 중복을 줄였다. AWS의 raw production telemetry와 customer bill, Kimi K3의 독립적인 대규모 production benchmark, AIPerf의 multi-vendor 독립검증 결과는 공개범위가 제한적이다. private Slack/Discord, 로그인 제한 customer dashboard, 내부 benchmark raw data는 확인된 것처럼 쓰지 않았다. 참고 자료와 작성 정보 조사·작성 기준 시각: 2026-09-19 07:34:38 KST / 2026-09-18 18:34:38 EDT / 2026-09-18 15:34:38 PDT / 2026-09-18 22:34:38 UTC. 주요 직접출처: AWS - New AgentCore runtime ; AWS - Session storage ; AWS - Interactive shells ; AWS - Unified observability ; AWS - Runtime instances ; AWS - Multi-model migration ; AWS - Kimi K3 on Bedrock ; Moonshot - Kimi K3 ; NVIDIA - AIPerf ; GitHub - AIPerf ; Google - AI & Economy team . 이 브리핑은 AI의 도움으로 공개 자료를 조사·정리했습니다. 확인된 사실과 추론, 미확인 내용을 구분해 표시했습니다.","canonical_url":"https://yoondata.com/posts/ai-briefing-20260919-073438-001","category":"AI 동향","description":"이번 증분은 모델 발표보다 에이전트 운영 인프라의 성숙을 추적한다. AWS AgentCore Runtime V2는 메모리 회수와 snapshot restore로 장기·무인 에이전트의 실행경제성을 바꾸고, Kimi K3의 Bedrock 진입은 open-weight 모델을 IAM·residency·prompt cache가 붙은 managed substrate로 상품화한다. NVIDIA AIPerf는 synthetic tokens/sec 중심 벤치마크를 production trace·bursty traffic·agentic coding session까지 재현하는 측정체계로 확장한다.","id":121,"image":null,"language":"ko-KR","modified_at":"2026-09-19T03:03:40Z","published_at":"2026-09-19T03:03:40Z","related_content":[{"title":"미국 2026년 9월 20일 AI 브리핑: Snap SPECS Intelligence가 개인 컨텍스트를 선점하고, Agentforce·AWS·NVIDIA로 AR 실행면까지 확장","url":"https://yoondata.com/posts/ai-briefing-20260920-133619-001"},{"title":"미국 2026년 9월 19일 AI 브리핑: Google은 Mantis를 코드 제출 게이트에 넣어 탐지-증명-패치의 보안 폐쇄루프를 구축","url":"https://yoondata.com/posts/ai-briefing-20260920-123728-001"},{"title":"미국 2026년 9월 19일 AI 브리핑: Qwen은 실시간 통역을 단일 멀티모달 스트림으로, Pika는 멀티모델 창작 운영체계로 이동","url":"https://yoondata.com/posts/ai-briefing-20260920-113419-001"}],"schema_version":1,"sources":[{"title":"AWS - The new AgentCore runtime","url":"https://aws.amazon.com/blogs/machine-learning/the-new-agentcore-runtime-elastic-optimized-and-consistently-fast-starts/"},{"title":"AWS - Managed session storage","url":"https://aws.amazon.com/about-aws/whats-new/2026/03/bedrock-agentcore-runtime-session-storage/"},{"title":"AWS - Interactive shells","url":"https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-agentcore-runtime/"},{"title":"AWS - Unified observability","url":"https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-bedrock-agentcore-unified-observability-single-log-group/"},{"title":"AWS - Runtime instances GA","url":"https://aws.amazon.com/about-aws/whats-new/2026/08/aws-bedrock-agentcore-runtime-instances-generally-available/"},{"title":"AWS - Migrating multi-model agents to AgentCore","url":"https://aws.amazon.com/blogs/machine-learning/migrating-multi-model-ai-agents-to-amazon-bedrock-agentcore-runtime/"},{"title":"AWS - Introducing Kimi K3 on Amazon Bedrock","url":"https://aws.amazon.com/blogs/machine-learning/introducing-kimi-k3-on-amazon-bedrock/"},{"title":"Moonshot - Kimi K3 Tech Blog","url":"https://www.kimi.ai/blog/kimi-k3"},{"title":"NVIDIA - Benchmarking LLM Inference at Scale with AIPerf","url":"https://developer.nvidia.com/blog/benchmarking-llm-inference-at-scale-with-aiperf/"},{"title":"GitHub - ai-dynamo/aiperf","url":"https://github.com/ai-dynamo/aiperf"},{"title":"Google - New experts join AI & Economy team","url":"https://blog.google/innovation-and-ai/technology/ai/expanding-ai-economy-research-bench/"}],"summary":"이번 증분은 모델 발표보다 에이전트 운영 인프라의 성숙을 추적한다. AWS AgentCore Runtime V2는 메모리 회수와 snapshot restore로 장기·무인 에이전트의 실행경제성을 바꾸고, Kimi K3의 Bedrock 진입은 open-weight 모델을 IAM·residency·prompt cache가 붙은 managed substrate로 상품화한다. NVIDIA AIPerf는 synthetic tokens/sec 중심 벤치마크를 production trace·bursty traffic·agentic coding session까지 재현하는 측정체계로 확장한다.","tags":["AI Agents","AI Economics","AI Infrastructure","AI 동향","AIPerf","AWS","Agent Runtime","AgentCore","Agentic Workload","Amazon Bedrock","Inference Benchmark","Kimi K3","MCP","Moonshot AI","NVIDIA","Open Weight","Production AI","Prompt Caching","미국 AI","생성형 AI"],"title":"미국 2026년 9월 18일 AI 브리핑: AWS는 에이전트를 workload로 재설계하고, Kimi K3는 open-weight를 managed cloud로 옮기며, NVIDIA AIPerf는 agentic inference를 production trace로 측정한다"},"content_md":"## 핵심 요약\n조사 기준 시각: 한국시간 2026-09-19 07:34:38 KST (Asia/Seoul, UTC+09:00) / 미국 동부 2026-09-18 18:34:38 EDT (America/New_York, UTC-04:00) / 미국 서부 2026-09-18 15:34:38 PDT (America/Los_Angeles, UTC-07:00) / UTC 2026-09-18 22:34:38.\n[확인] 지정 발행폴더의 직전 브리핑은 gpt_20260919_065459_001.docx이며 Anthropic·Accenture embedded evaluation, Plugin4Shell, LangChain MCP core 편입을 다뤘다. 이번 실행은 그 세 사건을 반복하지 않는다. Drive 중복검색 결과 Kimi K3의 Amazon Bedrock 진입과 AIPerf 신규 발표는 기존 핵심사건으로 확인되지 않았고, AgentCore는 과거 Consent portal·evaluation·storage 같은 기능이 일부 다뤄졌으나 9월 18일 발표된 새 Runtime V2의 memory reclaim·snapshot cold start·scoped unattended identity는 신규 변화라 증분으로 채택했다.\n[확인-1] AWS는 9월 18일 Amazon Bedrock AgentCore의 새 Runtime V2를 발표했다. 기존 runtime은 serverless·session isolation·scale-to-zero를 제공했지만 장시간·bursty agent가 한 번 크게 잡은 memory를 session 종료까지 high-watermark로 계속 점유하고, 새 session cold start가 container image 크기와 동시성에 따라 커지는 문제가 있었다. 새 runtime은 작은 resident memory에서 시작해 필요할 때 page-in하고 released/cold memory를 회수하며, 초기화된 environment를 한 번 snapshot한 뒤 새 instance마다 restore한다. [AWS - The new AgentCore runtime](https://aws.amazon.com/blogs/machine-learning/the-new-agentcore-runtime-elastic-optimized-and-consistently-fast-starts/)\n[확인] AWS 자체 echo-agent benchmark는 us-west-2의 client가 us-east-1 agent를 public internet으로 호출하고, model·tool이 없는 빈 agent에 대해 두 runtime·5개 image size 각각 5,000 cold invocation을 수행했다. 새 runtime은 200MB부터 2GB image까지 P75 cold start 약 2초를 유지했고, 기존 runtime은 약 5.4초에서 거의 30초까지 증가했다. Echo agent code 자체는 P75 약 34ms였다. 이는 AWS 내부 측정이며 실제 model/tool loop의 end-to-end latency와는 다르다.\n[확인] 새 Runtime V2는 memory footprint의 실제 변화에 더 가깝게 billing하고, AWS는 rate 자체는 더 높지만 대부분 workload에서 GB-hours 감소폭이 더 커 총비용이 낮아질 것이라고 주장한다. 구체적인 실제 고객비용절감률은 독립적으로 검증되지 않았다.\n[확인-로드맵] AWS가 `coming soon`으로 공개한 항목은 baseline pricing, 더 큰 RAM/vCPU/storage, x86 microVM, memory snapshot을 이용한 suspend/resume과 lifecycle hook, 그리고 unattended agent에 session context key 기반 scoped identity를 부여하는 기능이다. 새 runtime을 쓰려면 runtime create/update에서 `platformVersion=V2`를 설정한다.\n[확인-이전 체인] 3월에는 session별 filesystem state를 stop/resume 뒤에도 유지하는 managed session storage preview(최대 1GB, idle 14일), 6월에는 WebSocket PTY interactive shell, 7월에는 agent별 traces·prompts·logs를 하나의 CloudWatch log group으로 묶은 unified observability, 8월에는 EC2 기반 runtime instances와 최대 14일 session이 GA됐다. [AWS - Managed session storage](https://aws.amazon.com/about-aws/whats-new/2026/03/bedrock-agentcore-runtime-session-storage/) [AWS - Interactive shells](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-agentcore-runtime/) [AWS - Unified observability](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-bedrock-agentcore-unified-observability-single-log-group/) [AWS - Runtime instances GA](https://aws.amazon.com/about-aws/whats-new/2026/08/aws-bedrock-agentcore-runtime-instances-generally-available/)\n[확인-실제 migration] 같은 9월 18일 AWS는 smolagents 기반 multi-model healthcare agent를 ECS/Fargate에서 AgentCore Runtime으로 옮기는 reference architecture를 공개했다. 기존 agent logic은 유지하면서 container lifecycle, scaling, identity, observability를 managed runtime으로 넘긴 사례다. [AWS - Migrating multi-model agents to AgentCore](https://aws.amazon.com/blogs/machine-learning/migrating-multi-model-ai-agents-to-amazon-bedrock-agentcore-runtime/)\n[추론] 핵심 변화는 agent가 더 이상 `LLM request를 감싸는 함수`가 아니라 OS process나 workload처럼 별도의 실행수명·filesystem·memory·identity·terminal·logs·billing을 가진 단위가 되는 것이다. 특히 unattended agent의 scoped identity를 roadmap에 명시한 것은 사람의 login session과 agent execution principal을 분리해야 한다는 요구가 runtime 수준으로 내려왔다는 뜻이다.\n[추론] 구조를 압축하면 `Event/User → Session Identity → Snapshot MicroVM → On-demand Memory → Tool/File/Shell → Suspend/Resume → Per-agent Observability → Usage Billing`이다. 모델을 교체해도 이 runtime graph는 유지되므로 hyperscaler의 moat가 model catalogue보다 agent execution substrate로 이동할 수 있다.\n[확인-반대근거] 약 2초 P75 cold start는 model과 tool을 호출하지 않는 AWS 자체 echo benchmark다. 실제 application latency, region placement, VPC/network, package initialization, external API, model call을 포함하면 값은 달라진다. `bill goes down` 역시 일반화된 보장이 아니라 AWS의 workload assumption이다. scoped identity·suspend/resume 일부는 아직 출시전이다.\n[확인-2] AWS는 9월 18일 Moonshot AI의 open-weight `Kimi K3`를 Amazon Bedrock에서 제공하기 시작했다. Bedrock은 OpenAI-compatible Responses·Chat Completions와 Invoke·Converse API를 제공하고, Kimi K3는 Bedrock의 open-weight 모델 중 처음으로 explicit prompt caching을 지원한다. [AWS - Introducing Kimi K3 on Amazon Bedrock](https://aws.amazon.com/blogs/machine-learning/introducing-kimi-k3-on-amazon-bedrock/)\n[확인] AWS 설명에 따르면 Kimi K3는 2.8T parameter, native vision, 1M-token context를 가진 Moonshot의 최대모델이다. Bedrock에서 global cross-Region profile `global.moonshotai.kimi-k3`는 geographic profile보다 약 10% 저렴하고, `us.moonshotai.kimi-k3`는 processing을 미국 geography 안에 유지한다. IAM permission은 `bedrock:InvokeModel`, streaming invocation, inference-profile creation 등을 사용한다.\n[확인] Bedrock explicit caching은 최소 1,024 tokens 이후 reusable prefix 끝에 breakpoint를 지정할 수 있고, cache write는 더 높은 rate로 과금되지만 최소 30분 유지된다. 이후 cache hit input token은 할인되고 input-tokens-per-minute quota에서도 제외된다. Coding assistant나 Hermes 같은 agent가 Bedrock/OpenAI-compatible provider를 통해 K3를 사용할 수 있다.\n[확인-모델 원문] Moonshot은 Kimi K3를 7월 16일 공개했고 7월 27일까지 full weights를 공개한다고 발표했다. 회사 공식 기술글은 KDA(Kimi Delta Attention), Attention Residuals, Stable LatentMoE를 사용하며 896 experts 중 16개를 활성화하고, SFT부터 MXFP4 weights/MXFP8 activations의 quantization-aware training을 적용한다고 설명한다. [Moonshot - Kimi K3 Tech Blog](https://www.kimi.ai/blog/kimi-k3)\n[확인] Moonshot은 64+ accelerator supernode 배포를 권장하고 KDA용 prefill-cache 구현을 vLLM 생태계에 기여한다고 밝혔다. 공식 API 가격은 cache-hit input $0.30/MTok, cache-miss input $3/MTok, output $15/MTok이며 coding workload cache hit >90%는 회사 측 주장이다.\n[확인] Moonshot은 자체 글에서 K3의 overall performance가 가장 강력한 proprietary models인 Claude Fable 5와 GPT 5.6 Sol에는 아직 뒤진다고 명시했다. 따라서 `open-weight 최고`와 `전체 frontier 최고`를 구분해야 한다.\n[추론] Bedrock 진입의 본질은 open-weight가 곧 self-hosting을 의미하지 않는다는 점이다. 기업은 weights가 공개된 모델도 `Cloud IAM + Data Boundary + Residency Profile + Prompt Cache + Standard API + Usage Metering`이 붙은 managed service로 소비할 수 있다. open model의 innovation과 proprietary cloud control plane이 결합되는 상품형태다.\n[추론] Bedrock이 tool calling, structured output, reasoning, streaming, Responses/Chat APIs를 model별 별도통합이 아니라 platform capability로 제공한다고 설명한 부분도 중요하다. Model switching cost를 낮추는 대신 고객이 AWS identity·quota·cache·residency·observability 계층에 더 깊게 묶일 수 있다.\n[추론] 구조는 `Open Weights → Managed Inference Runtime → IAM/Residency → Prompt Cache → OpenAI-compatible API → Coding/Productivity Agent`다. 장기 agent는 큰 repository·tool definition·policy prefix를 반복 전송하므로 cache hit와 cache quota economics가 model price만큼 중요해진다.\n[확인-반대근거] 2.8T, 2.5x scaling efficiency, benchmark 성능과 >90% coding cache-hit는 Moonshot 측 주장이다. AWS Bedrock 제공은 모델 품질을 독립적으로 인증하는 행위가 아니다. 2.8T total parameter라도 MoE는 매 token 모든 parameter를 활성화하지 않으며, 64+ accelerator 권장 자체가 self-hosting의 운영난도를 보여준다.\n[확인-3] NVIDIA는 9월 18일 생성형 AI inference benchmarking tool `AIPerf`를 공식 소개했다. AIPerf는 GenAI-Perf의 지정 successor이자 ground-up rewrite로, Perf Analyzer 위에서 동작하던 이전 구조를 버리고 여러 worker process와 record-processing service가 ZMQ로 통신하는 multiprocess architecture를 사용해 Python GIL 때문에 benchmark client 자체가 병목이 되는 문제를 줄이려 한다. [NVIDIA - Benchmarking LLM Inference at Scale with AIPerf](https://developer.nvidia.com/blog/benchmarking-llm-inference-at-scale-with-aiperf/)\n[확인-코드] 공개 GitHub repository는 `pip install aiperf` 설치, 10개 service가 ZMQ로 통신하는 scalable multiprocess architecture, concurrency/request-rate/trace-replay mode, plugin system, OpenAI chat/responses·image/audio 및 NIM endpoint 등을 문서화한다. [GitHub - ai-dynamo/aiperf](https://github.com/ai-dynamo/aiperf)\n[확인] Load는 constant, Poisson, gamma arrival pattern과 burstiness, gradual ramping을 지원하고 input/output sequence length를 fixed·normal·log-normal·empirical 등으로 만들 수 있다. TTFT(Time to First Token), ITL(Inter-Token Latency), end-to-end Request Latency, Output Token Throughput를 p25~p99 등 percentile로 보고하며 DCGM/pynvml이 있으면 GPU power·utilization·memory도 함께 본다.\n[확인] 가장 중요한 변화는 실제 traffic replay다. 공개 repo는 Baseten, BurstGPT, SageMaker Data Capture, Weka agent traces, TraceLab의 real agentic coding sessions, InferenceX AgentX MVP, multi-turn conversation 및 raw payload replay를 지원한다. NVIDIA blog도 Mooncake·Baseten·WEKA AgentX trace replay와 public dataset을 강조한다.\n[확인] NVIDIA는 AWS, CoreWeave, Baseten, Pinterest 등 외부 contributor와 cross-company validation·trace support·DAG benchmarking methodology를 협업했다고 밝힌다. 이는 하나의 NVIDIA 내부 smoke-test tool보다 broader ecosystem measurement tool을 지향한다는 신호다.\n[추론] 벤치마크의 본질이 `tokens/sec` 한 숫자에서 `어떤 실제 workload shape에서 p95/p99 SLA를 지키는가`로 이동한다. Agentic system은 long context, 반복 prefix, tool wait, multi-turn, bursty concurrent sessions를 가지므로 single-user fixed-length test만으로 production capacity를 예측하기 어렵다.\n[추론] 특히 benchmark client가 15,000+ concurrency나 multi-node endpoint를 때릴 때 client-side GIL·socket·event-loop가 병목이면 server 결과가 왜곡된다. AIPerf의 multiprocess 분리는 `server capacity`와 `load-generator capacity`를 분리해 측정하려는 인프라적 변화다.\n[추론] 구조는 `Production Trace/Traffic Model → Multiprocess Load Generator → Inference Endpoint → Per-request TTFT/ITL/Latency → GPU Telemetry → SLO/Goodput → Capacity/Cost Decision`이다. 앞으로 model selection은 accuracy와 list price뿐 아니라 production-trace replay에서의 goodput/cost를 기준으로 바뀔 가능성이 높다.\n[확인-반대근거] AIPerf는 NVIDIA 주도 open-source tool이며 MLPerf 같은 독립 consortium standard가 아니다. 특정 benchmark 결과는 endpoint, tokenizer, streaming 설정, server engine, cache 상태, hardware, request distribution에 따라 달라진다. AIPerf 자체의 existence를 특정 NVIDIA stack 우월성 증거로 사용하면 안 된다.\n## 핵심 사건 종합표\n| 순위 | 분류 | 핵심 사건 | 최초 출처 | 연관 출처 체인 | 발생 시각과 미국 현지 날짜 | 핵심 사실 | 후속 전개 | 왜 중요한가 | 숨은 의미·비하인드 해석 | 담당자·관련 인물 | 수혜자 | 불리한 측 | 기술·사업 영향 | 다음 신호 | 신뢰도 | 검증 상태 | 원문 링크 |\n| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |\n| 1 | Agent Infrastructure·Runtime·Identity | AWS AgentCore 새 Runtime V2가 memory reclaim·snapshot restore로 long-running/unattended agent economics를 재설계 | AWS 9/18 공식 | 3/25 session storage → 6/5 interactive shell → 7/23 unified observability → 8/6 EC2 runtime instances → 9/18 Runtime V2 + multi-model migration reference | 2026-09-18 미국 현지, 공식 시각 미공개; 조사기준 18:34 EDT / 15:34 PDT | small resident footprint·on-demand page-in·cold memory reclaim, preinitialized environment snapshot/restore, platformVersion V2. AWS echo test P75 ~2s across 200MB~2GB vs old ~5.4s~30s | baseline pricing, larger compute/storage, x86, suspend/resume, scoped unattended-agent identity 예고 | agent가 request handler가 아니라 OS-like workload로 변하면서 lifecycle·memory·identity·billing이 핵심 플랫폼층이 됨 | [추론] hyperscaler moat가 model catalogue에서 `Session/Identity/State/Runtime` control plane으로 이동 | Evandro Franco, Rahul Nama, Mark Roy, Shishir Bharathi, Abhishek Singh, AgentCore Runtime team | long-running coding/ops agents, bursty agents, enterprises wanting managed isolation | self-managed orchestrators, peak-memory billing, frameworks tightly coupled to bespoke runtime | `Event→Session Identity→Snapshot MicroVM→Memory→Tool/File/Shell→Suspend/Resume→Logs/Billing` | scoped identity GA, suspend/resume, real-customer p95/cost, x86 support, idle/burst pricing | 매우 높음 | AWS 공식 + related official release chain. 성능·비용효과는 AWS benchmark/claims로 표시 | [New Runtime](https://aws.amazon.com/blogs/machine-learning/the-new-agentcore-runtime-elastic-optimized-and-consistently-fast-starts/) / [Storage](https://aws.amazon.com/about-aws/whats-new/2026/03/bedrock-agentcore-runtime-session-storage/) / [Instances](https://aws.amazon.com/about-aws/whats-new/2026/08/aws-bedrock-agentcore-runtime-instances-generally-available/) |\n| 2 | Open-weight Models·Cloud Inference·Caching | Kimi K3가 Amazon Bedrock에 들어오며 open-weight 2.8T 모델이 IAM·residency·explicit cache가 붙은 managed substrate로 상품화 | Moonshot 7/16 model release → AWS 9/18 Bedrock availability | Moonshot K3 architecture/full weights → Bedrock model onboarding → OpenAI-compatible Responses/Chat + Converse/Invoke → US/global profiles → explicit prompt caching → agent/coding providers | Bedrock 2026-09-18 미국 현지, 공식 시각 미공개; original K3 2026-07-16 | 2.8T total params, 1M context, native vision; Bedrock first open-weight explicit caching; global profile ~10% less than geo, US profile stays US; min 1,024-token cache breakpoint, >=30min | managed open-weight 사용이 self-host 대신 cloud governance/caching/standard API로 확장 | open weights의 경제가 weight download보다 cloud control-plane 서비스로 이동 | [추론] 모델 portability는 올라가지만 IAM·quota·cache·residency에 대한 platform lock-in이 새 moat가 됨 | Moonshot AI Kimi team; AWS Bedrock model/inference teams | enterprises seeking open-weight + managed compliance, coding agents with long context | pure self-host ops, providers without standard APIs/cache/residency | `Weights→Managed Runtime→IAM/Residency→Cache→Standard API→Agent` | independent K3 eval, cache economics, geo expansion, throughput/latency, enterprise adoption | 높음 | AWS + Moonshot 공식. model benchmarks/2.5x efficiency/cache-hit는 vendor claims로 제한 | [AWS](https://aws.amazon.com/blogs/machine-learning/introducing-kimi-k3-on-amazon-bedrock/) / [Moonshot](https://www.kimi.ai/blog/kimi-k3) |\n| 3 | Inference Benchmarking·Agentic Workload·Open Source | NVIDIA AIPerf가 GenAI-Perf를 대체해 multiprocess load generation과 production/agent trace replay를 중심으로 전환 | NVIDIA 9/18 공식 + public GitHub | GenAI-Perf/Perf Analyzer → ground-up AIPerf → ZMQ multiprocess → 15+ endpoint types → production trace replay → p25~p99 + GPU telemetry → AWS/CoreWeave/Baseten/Pinterest collaboration | 2026-09-18 미국 현지, 공식 시각 미공개 | constant/Poisson/gamma, variable ISL/OSL, TTFT/ITL/latency/throughput, multi-turn and real agentic coding traces, Kubernetes/multi-node | benchmark가 synthetic single-turn에서 production-shape replay와 SLO/goodput 탐색으로 이동 | [추론] AI infrastructure 구매가 tokens/sec보다 `production trace의 p99/goodput/cost`로 평가될 가능성 | Francesco Di Natale, Elias Bermudez, Anthony Casagrande, AIPerf contributors, AWS/CoreWeave/Baseten/Pinterest | inference operators, model-serving vendors, capacity planners, agent-platform teams | simplistic single-user benchmark, load generators that become bottleneck | `Trace→Load Shape→Endpoint→Tail Latency/Throughput→GPU Telemetry→SLO/Capacity` | independent adoption, AgentX/TraceLab benchmarks, CI gating, neutral standardization, methodology disputes | 매우 높음 | NVIDIA official + public source repo. tool 자체가 독립 benchmark consortium은 아님 | [NVIDIA](https://developer.nvidia.com/blog/benchmarking-llm-inference-at-scale-with-aiperf/) / [GitHub](https://github.com/ai-dynamo/aiperf) |\n## 1. Amazon Bedrock AgentCore Runtime V2 — 에이전트가 workload가 되는 단계 — 연관 추적\n### ① 최초 신호\n[확인] AgentCore는 2026년 동안 filesystem persistence, shell execution, per-agent observability, EC2 runtime instances를 순차적으로 추가해 agent session을 일반 web request보다 오래 사는 execution unit로 확장해왔다. 9월 18일 Runtime V2는 이 흐름에서 memory lifecycle과 cold-start economics를 직접 재설계한 단계다.\n### ② 공식 확인\n[확인] AWS는 Runtime V2가 session을 작은 resident memory에서 시작하고 필요 시 memory를 page-in하며 freed/cold memory를 회수하고, initialized environment snapshot을 restore해 image size와 concurrency에 덜 민감한 cold start를 제공한다고 밝혔다. [AWS](https://aws.amazon.com/blogs/machine-learning/the-new-agentcore-runtime-elastic-optimized-and-consistently-fast-starts/)\n### ③ 후속 기사와 반응\n[확인-한계] 조사시각 기준 새 Runtime V2의 독립적인 대규모 production benchmark는 아직 확인하지 못했다. 같은 날 AWS의 multi-model smolagents migration post가 실제 reference implementation을 제공하지만, 이는 AWS가 제작한 architecture example이다.\n### ④ 담당자·연구자·개발자 발언\n[확인] AWS Runtime team은 agent가 짧은 chat에서 coding-hours, event-triggered ambient agent, 다른 agent가 실행하는 unattended workload로 이동한다고 설명한다. roadmap에서는 unattended agent가 `사람이 보지 않을 때 무엇을 할 수 있는가`가 새로운 identity 문제라고 직접 정의한다.\n### ⑤ SNS·YouTube·GitHub 등에서 드러난 추가 단서\n[확인] AWS blog는 AgentCore GitHub sample과 새 runtime load-test example을 공개해 사용자가 자기 account에서 cold-start consistency를 재현할 수 있도록 했다. 이번 보고서에서는 sample의 existence를 확인했지만 직접 AWS account에서 benchmark를 실행했다고 쓰지 않는다. 별도 YouTube/SNS demo는 핵심근거로 사용하지 않았다.\n### ⑥ 실제 제품·기술·정책 변화\n[확인] V2는 현재 `platformVersion=V2`로 선택할 수 있고 memory reclaim·environment snapshot restore가 shipped 상태다. baseline pricing, x86, larger resources, suspend/resume, scoped identity는 coming-soon roadmap이므로 현재 기능과 분리해야 한다.\n### ⑦ 숨은 의미와 비하인드\n[추론] Cloud에서 agent는 VM과 serverless function 사이의 새 workload class가 된다. Function보다 오래 살고 state/file/tool을 갖지만 VM처럼 peak capacity를 계속 예약하지 않으려 한다. Runtime vendor의 핵심기술은 model routing보다 microVM snapshot, memory reclaim, session state, credential scope가 될 수 있다.\n[추론] Scoped identity가 session context로 내려가면 IAM의 단위도 `user/service account`에서 `specific agent run`으로 세분화될 수 있다. 이는 장기적으로 tool audit와 delegated authorization을 runtime이 직접 집행하는 기반이 된다.\n### ⑧ 반대 근거와 과장 가능성\n[확인] AWS echo benchmark는 model/tool 없음, cross-region public-internet condition의 platform-start 측정이다. 실제 customer workload의 p95/p99, failure rate, cost curve를 대변하지 않는다. Snapshot restore가 application logic의 idempotency나 external state consistency를 자동 해결하는 것도 아니다.\n### ⑨ 향후 예상되는 다음 행동과 확인해야 할 신호\n실제 pricing table, baseline plan, scoped identity의 IAM semantics, suspend/resume snapshot TTL, secret revocation, x86 launch, 8시간 이상의 serverless session policy, production customer benchmark와 failure/retry telemetry를 추적해야 한다.\n## 2. Kimi K3 on Amazon Bedrock — open weights와 managed cloud의 결합 — 연관 추적\n### ① 최초 신호\n[확인] Moonshot AI는 7월 16일 Kimi K3를 공개하고 full weights를 7월 27일까지 공개하겠다고 밝혔다. 2.8T total parameters, KDA, Attention Residuals, 1M context, native vision을 전면에 내세웠다.\n### ② 공식 확인\n[확인] AWS는 9월 18일 Kimi K3를 Bedrock의 US/Global cross-region inference profile로 제공하기 시작했다. OpenAI-compatible Responses·Chat Completions와 Bedrock Invoke/Converse API를 동시에 지원한다. [AWS](https://aws.amazon.com/blogs/machine-learning/introducing-kimi-k3-on-amazon-bedrock/)\n### ③ 후속 기사와 반응\n[확인] 9월 18일 영어권 후속기사는 Bedrock 진입, 1M context, 2.8T scale, prompt caching을 주요 변화로 보도했다. 그러나 모델 품질 비교는 대부분 Moonshot benchmark를 재인용하므로 독립 성능검증으로 계산하지 않았다.\n### ④ 담당자·연구자·개발자 발언\n[확인] Moonshot은 K3가 proprietary 최고 모델에는 아직 뒤지지만 open 모델 frontier를 확장한다고 스스로 평가한다. AWS는 open-weight innovation을 production security/reliability와 결합하는 것이 Bedrock 전략이라고 설명한다.\n### ⑤ SNS·YouTube·GitHub 등에서 드러난 추가 단서\n[확인] Moonshot은 KDA prefill-cache 구현을 vLLM 생태계에 기여한다고 밝혔고, AWS는 Moonshot-on-AWS sample repository와 OpenCode/Hermes 연결예시를 제공한다. 이번 실행에서는 실제 benchmark code를 돌리지 않았으며 공개 demo 성능을 일반화하지 않았다.\n### ⑥ 실제 제품·기술·정책 변화\n[확인] 사용자는 US geographic profile로 data residency를 제한하거나 global profile로 약 10% 낮은 price를 선택할 수 있고, 1,024+ token prefix에 explicit cache breakpoint를 넣을 수 있다. AWS는 inference request에 zero data retention·zero operator access를 적용한다고 설명한다.\n### ⑦ 숨은 의미와 비하인드\n[추론] `open-weight = 자체 GPU 운영` 공식이 깨지고 있다. Weight openness와 runtime ownership이 분리되면 기업은 open model을 선택하되 실제 execution·identity·data boundary·billing은 hyperscaler에 맡길 수 있다.\n[추론] 이때 platform capability가 model-independent해질수록 model 교체는 쉬워지지만, application이 cache semantics·IAM·quota·geo profile·observability에 의존하면서 cloud switching은 오히려 어려워질 수 있다. Open model competition이 cloud platform 경쟁을 약화시키는 것이 아니라 강화할 수도 있다.\n### ⑧ 반대 근거와 과장 가능성\n[확인] K3의 2.5x scaling efficiency, internal eval, >90% coding cache-hit는 Moonshot claim이다. MoE total-parameter count를 dense model compute cost와 단순비교하면 안 된다. Bedrock에 있다는 사실도 모델이 모든 task에서 Claude/GPT보다 좋다는 뜻이 아니다.\n### ⑨ 향후 예상되는 다음 행동과 확인해야 할 신호\nBedrock 실제 token/cache pricing, K3 independent benchmark와 production latency, 1M-context cache hit economics, additional geographic regions, customer adoption, vLLM KDA cache 성숙도, self-host versus managed total cost를 확인해야 한다.\n## 3. NVIDIA AIPerf — agentic production trace를 재는 inference benchmark — 연관 추적\n### ① 최초 신호\n[확인] 기존 GenAI-Perf와 많은 자체 load generator는 single-process/idealized fixed-length request에 의존해 높은 concurrency에서 client 자체가 병목이 되거나 production traffic의 burst·long-tail을 충분히 표현하지 못하는 문제가 있었다.\n### ② 공식 확인\n[확인] NVIDIA는 9월 18일 AIPerf를 GenAI-Perf의 지정 successor로 소개하고 ground-up multiprocess rewrite, 15+ endpoint types, trace replay, 다양한 arrival pattern, percentile metrics를 공개했다. [NVIDIA](https://developer.nvidia.com/blog/benchmarking-llm-inference-at-scale-with-aiperf/)\n### ③ 후속 기사와 반응\n[확인-한계] 이번 fresh signal은 NVIDIA technical blog와 public repository 자체가 가장 직접적인 증거다. 조사시각 기준 AIPerf 결과를 독립적으로 비교한 대규모 third-party report는 확인하지 못했다. 따라서 tool capability와 특정 GPU/server 성능을 구분한다.\n### ④ 담당자·연구자·개발자 발언\n[확인] NVIDIA authors는 `client should not be the bottleneck`을 핵심 설계원칙으로 설명한다. Acknowledgments에는 AWS의 cross-company validation, CoreWeave의 exporter/concurrency hardening, Baseten trace support, Pinterest의 DAG benchmark 협업이 명시된다.\n### ⑤ SNS·YouTube·GitHub 등에서 드러난 추가 단서\n[확인] GitHub repository는 실제 코드와 docs를 공개하며 TraceLab real agentic coding sessions, Weka agent traces, InferenceX AgentX MVP, SageMaker data capture replay, OpenTelemetry·MLflow·Weights & Biases integration 등을 문서화한다. [GitHub](https://github.com/ai-dynamo/aiperf)\n### ⑥ 실제 제품·기술·정책 변화\n[확인] 벤치마크 workload를 fixed token count에서 Poisson/gamma/bursty request rate, variable ISL/OSL, multi-turn, production trace로 바꿀 수 있고, TTFT/ITL/request latency/output throughput과 tail percentile을 함께 비교한다. GPU telemetry와 request timing을 한 run에 연결할 수 있다.\n### ⑦ 숨은 의미와 비하인드\n[추론] Agentic workload는 생성토큰 수보다 `session shape`가 비용·SLA를 결정한다. 동일 model/server도 short chat, 1M context coding, tool-heavy multi-turn, cache-heavy agent에서 완전히 다른 latency/throughput curve를 만든다. 따라서 구매와 capacity planning은 model benchmark에서 workload benchmark로 이동한다.\n[추론] 향후 inference vendor는 단순 tokens/sec leaderboard보다 고객 trace를 replay해 `p99 under SLA`, `goodput`, `cost per successful task`를 제시해야 할 가능성이 크다. Agent platform에 outcome metric을 연결하면 model-routing policy도 benchmark 결과로 자동 조정할 수 있다.\n### ⑧ 반대 근거와 과장 가능성\n[확인] AIPerf는 NVIDIA가 주도하므로 완전히 vendor-neutral한 표준이라고 볼 수 없다. Load generator의 정교함이 실제 application correctness나 task success를 측정하는 것도 아니다. 또한 public trace가 특정 사용자군을 대표하지 않을 수 있다.\n### ⑨ 향후 예상되는 다음 행동과 확인해야 할 신호\nMLPerf 또는 다른 consortium과의 관계, cloud/inference vendor의 표준채택, AgentX·TraceLab 기반 공개 leaderboard, workload reproducibility, cost/goodput metric, multi-agent DAG methodology, CI/CD performance gate integration을 추적해야 한다.\n## ① 오늘의 핵심 흐름\n이번 증분의 공통점은 `모델 자체`가 아니라 모델을 둘러싼 실행·상품화·측정 계층이 빠르게 표준화되고 있다는 점이다. AWS는 agent session을 managed workload로 만들고, Bedrock은 open weights를 cloud-governed API product로 바꾸며, NVIDIA는 production workload를 재현하는 benchmark substrate를 만든다.\n[추론] 세 사건을 합치면 `Agent Session/Identity → Managed Model Endpoint → Cache/Tool Execution → Production Trace → Benchmark/Telemetry → Capacity/Cost Policy`가 하나의 운영루프다. 앞으로 모델의 지능점수만 높아도 runtime·cache·tail latency·identity가 부실하면 production 경쟁력이 낮아질 수 있다.\n## ② 새로운 출시·업데이트\n9월 18일 직접 확인된 신규 업데이트는 AgentCore Runtime V2, Kimi K3의 Amazon Bedrock availability, NVIDIA AIPerf 공식발표다. 이 세 사건은 직전 브리핑과 주제가 중복되지 않으며, 모두 실제 product/code가 존재하는 변화다.\n## ③ 핵심기술·연구\n핵심기술은 runtime snapshot/memory reclaim, MoE open-weight model의 managed prompt caching, multiprocess production-trace benchmarking이다. 공통적으로 장기·고빈도 agent workload의 `idle/burst`, `state`, `repeated context`, `tail latency` 문제를 직접 다룬다.\n## ④ 기업·담당자·조직 신호\nGoogle도 9월 18일 AI & Economy research bench를 확장해 Nobel Laureate Philippe Aghion, Ajay Agrawal, Anu Madgavkar, Daniel Rock 등을 영입했고 Daniel Rock이 frontier-model telemetry와 econometrics를 연결한다고 밝혔다. 이는 모델업체가 first-party usage telemetry를 경제·노동시장 연구의 원자료로 삼는 흐름이다. [Google - New experts join AI & Economy team](https://blog.google/innovation-and-ai/technology/ai/expanding-ai-economy-research-bench/)\n[추론] Infrastructure vendor가 runtime telemetry를, model/platform vendor가 usage telemetry를, benchmark vendor가 performance trace를 보유하면서 AI 산업의 새로운 자산은 `실제 사용데이터를 구조적으로 측정하는 권리`가 되고 있다.\n## ⑤ SNS·YouTube에서 포착된 신호\nKimi K3와 AgentCore의 공개 demo·coding-agent integration 영상이 존재하지만 이번 보고서는 marketing demo를 성능근거로 사용하지 않았다. AIPerf는 GitHub repository가 직접적인 개발흔적이며, Moonshot의 vLLM cache contribution과 AWS sample repositories가 구현방향을 보강한다. X/Threads의 단순 반응은 신뢰도 높은 신규사실이 아니면 제외했다.\n## ⑥ 약한 신호와 향후 조짐\n[추론] 첫째 agent runtime에서 `session-scoped identity`가 IAM의 정식 단위가 될 가능성이 높다. 둘째 open-weight model의 주요 유통경로가 weights download와 self-host만이 아니라 Bedrock/Vertex/Azure 같은 managed model substrate로 이동할 수 있다. 셋째 inference benchmark는 user trace뿐 아니라 real agent task graph를 replay하고 task-success/cost까지 연결하는 방향으로 확장될 가능성이 있다.\n## ⑦ 과장·루머·주의 항목\nAgentCore 2초 cold start는 실제 LLM agent 전체응답시간이 아니다. Kimi K3의 2.8T와 benchmark 수치는 Moonshot의 모델설명이고 Bedrock onboarding이 독립품질검증은 아니다. AIPerf가 open source라고 해서 산업중립 standard가 확정된 것도 아니다. `coming soon` 기능을 이미 GA된 기능처럼 쓰지 않았다.\n## ⑧ 사용자가 반드시 알아야 할 것\n실전 agent architecture를 설계할 때 최소 `Runtime Registry`, `Identity/Permission Registry`, `Model Endpoint Registry`, `Cache/Context Registry`, `Workload Trace Registry`, `Benchmark/SLO Registry`, `Event/Audit Registry`를 분리하는 것이 유리하다. Model은 이 구조 안에서 교체가능한 component가 된다.\n특히 비용을 계산할 때 token price만 보지 말고 `runtime GB-hours + cold-start/retry + cache-write/hit + tool/network wait + p95/p99 latency + failed task cost`를 하나의 end-to-end equation으로 봐야 한다. 이번 세 발표는 그 계산을 가능하게 하는 runtime·model·measurement layer가 동시에 성숙하고 있음을 보여준다.\n## ⑨ 누락 가능성과 탐색 한계\n이번 조사는 AWS AgentCore 9월 18일 공식발표와 3~8월 공식 feature chain, Kimi K3 Bedrock 공식발표와 Moonshot 기술원문, NVIDIA AIPerf technical blog와 public GitHub repository를 확인했다. 동일 주제가 기존 발행문서에 핵심사건으로 있는지도 Drive에서 검색해 중복을 줄였다.\nAWS의 raw production telemetry와 customer bill, Kimi K3의 독립적인 대규모 production benchmark, AIPerf의 multi-vendor 독립검증 결과는 공개범위가 제한적이다. private Slack/Discord, 로그인 제한 customer dashboard, 내부 benchmark raw data는 확인된 것처럼 쓰지 않았다.\n## 참고 자료와 작성 정보\n조사·작성 기준 시각: 2026-09-19 07:34:38 KST / 2026-09-18 18:34:38 EDT / 2026-09-18 15:34:38 PDT / 2026-09-18 22:34:38 UTC.\n주요 직접출처: [AWS - New AgentCore runtime](https://aws.amazon.com/blogs/machine-learning/the-new-agentcore-runtime-elastic-optimized-and-consistently-fast-starts/); [AWS - Session storage](https://aws.amazon.com/about-aws/whats-new/2026/03/bedrock-agentcore-runtime-session-storage/); [AWS - Interactive shells](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-agentcore-runtime/); [AWS - Unified observability](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-bedrock-agentcore-unified-observability-single-log-group/); [AWS - Runtime instances](https://aws.amazon.com/about-aws/whats-new/2026/08/aws-bedrock-agentcore-runtime-instances-generally-available/); [AWS - Multi-model migration](https://aws.amazon.com/blogs/machine-learning/migrating-multi-model-ai-agents-to-amazon-bedrock-agentcore-runtime/); [AWS - Kimi K3 on Bedrock](https://aws.amazon.com/blogs/machine-learning/introducing-kimi-k3-on-amazon-bedrock/); [Moonshot - Kimi K3](https://www.kimi.ai/blog/kimi-k3); [NVIDIA - AIPerf](https://developer.nvidia.com/blog/benchmarking-llm-inference-at-scale-with-aiperf/); [GitHub - AIPerf](https://github.com/ai-dynamo/aiperf); [Google - AI & Economy team](https://blog.google/innovation-and-ai/technology/ai/expanding-ai-economy-research-bench/).\n이 브리핑은 AI의 도움으로 공개 자료를 조사·정리했습니다. 확인된 사실과 추론, 미확인 내용을 구분해 표시했습니다.","created_at":"2026-09-19T03:03:40Z","id":121,"published_at":"2026-09-19T03:03:40Z","scheduled_at":null,"slug":"ai-briefing-20260919-073438-001","source_key":null,"status":"published","summary":"이번 증분은 모델 발표보다 에이전트 운영 인프라의 성숙을 추적한다. AWS AgentCore Runtime V2는 메모리 회수와 snapshot restore로 장기·무인 에이전트의 실행경제성을 바꾸고, Kimi K3의 Bedrock 진입은 open-weight 모델을 IAM·residency·prompt cache가 붙은 managed substrate로 상품화한다. NVIDIA AIPerf는 synthetic tokens/sec 중심 벤치마크를 production trace·bursty traffic·agentic coding session까지 재현하는 측정체계로 확장한다.","tags":["AI Agents","AI Economics","AI Infrastructure","AI 동향","AIPerf","AWS","Agent Runtime","AgentCore","Agentic Workload","Amazon Bedrock","Inference Benchmark","Kimi K3","MCP","Moonshot AI","NVIDIA","Open Weight","Production AI","Prompt Caching","미국 AI","생성형 AI"],"thumbnail":"","title":"미국 2026년 9월 18일 AI 브리핑: AWS는 에이전트를 workload로 재설계하고, Kimi K3는 open-weight를 managed cloud로 옮기며, NVIDIA AIPerf는 agentic inference를 production trace로 측정한다","updated_at":"2026-09-19T03:03:40Z","version":2,"views":59}