TL;DR
이번 기간에는 Agent의 긴 추론과 지속적 실행을 감당하기 위한 메모리 관리, 지침 진화, 실행 환경 모듈화가 함께 부상했습니다. WikiSkill은 실패 기록과 누적 지식을 스킬 파일과 분리해 보존하고, 지침 수정이 성능을 낮추면 되돌리면서도 실패 원인은 남기는 구조를 사용하며 지식 계층을 끄면 평균 점수가 약 4분의 1 하락했다고 전해졌습니다. 모델 측면에서는 GLM 5.3 Flash의 Vision 성능과 정밀도 설정을 둘러싼 재현성 점검이 이어졌고, vLLM은 KV Cache·분리형 서빙·Expert Parallelism을 여러 가속기에서 다루는 serving stack으로 조명됐습니다. 우주 분야에서는 Falcon Heavy의 탐사 임무와 지속 가능한 에너지 외에 위성·Geoengineering이 필요하다는 기후 대응 구상이 함께 확산됐습니다.
𝕏 실시간 트렌드 토픽
🔥 Falcon Heavy 발사와 우주 기반 기후공학 구상포스트 2
Falcon Heavy와 Falcon 9의 우주 임무가 Psyche, Europa Clipper, GOES-U, PACE, SPHEREx로 이어진 가운데, 지속 가능한 에너지 만으로는 극심한 멸종 사건을 막기 어렵다는 우주 기반 기후공학 구상이 함께 제기됐습니다. 구상에는 지구 온도 제어용 위성과 달의 Mass Driver를 활용해 지구-태양 Lagrange Point에 위성을 배치하는 방식이 포함됐습니다.
세부 내용 보기
- Falcon Heavy 관련 인용문에는 금속이 풍부한 소행성 Psyche, 목성의 위성 Europa로 향하는 Europa Clipper, NOAA의 기상 예보 개선을 위한 GOES-U가 등장하며, Falcon 9 임무로는 지구 해양·대기를 연구하는 NASA PACE와 우주 역사 지도를 만드는 SPHEREx가 함께 열거됐습니다.
- 기후 대응 구상은 지속 가능한 에너지 전환만으로는 약 1억 년 주기의 극심한 멸종 사건을 막기 어렵다고 보고, 온도를 제어하는 우주 위성을 지구 밖에 배치하는 입력·처리 구조를 상정합니다.
- 구체적으로 달의 Mass Driver가 지구-태양 Lagrange Point로 위성을 발사하고, 해당 위성이 약 10억 년 동안 지구 온난화를 해결할 수 있다는 내용이 인용됐습니다.
- 탐사선 발사와 기후 제어 위성 구상이 한 흐름에 놓이면서, 우주 인프라의 역할이 탐사·관측에서 행성 규모 환경 제어로 넓어지는 방향을 드러냈습니다.
원문 트윗 2개 보기
Elon Musk
Falcon Heavy launches exploration misison
Falcon Heavy sent Psyche toward a metal-rich asteroid, Europa Clipper to Jupiter’s Moon, and GOES-U into transfer orbit to improve NOAA’s weather forecasting. Falcon 9 launched NASA’s PACE mission to study Earth’s ocean and atmosphere and SPHEREx to map the history of the
Elon Musk
Extremely severe extinction events happen every 100M years or so and just switching to sustainable energy will not be enough to stop them. Space satellites to control temperature and massive geo-engineering will be needed or it will be game over. https:// grok.com/share/bGVnYWN5 _dfaad20f-6716-42a3-a2c2-f4e2f2f0cb26 …
And that is, of course, how it will be done. Sentient satellites, launched into Earth-Sun Lagrange points by mass drivers on the Moon, can solve global warming for ~1B years.
📈 Agent 추론 확장과 실패 지식의 영속화포스트 6
긴 사고를 사용하는 Agent의 메모리 비용, 실패한 지침을 반복해서 다시 만드는 문제, 실행 환경을 모듈화하는 Harness 설계가 한 흐름으로 묶였습니다. WikiSkill은 원시 Trace·누적 지식·현재 스킬을 분리해 지침은 되돌리되 실패에서 얻은 이해는 남기는 구조를 제시했고, 지식 계층을 제거하면 평균 점수가 약 4분의 1 하락했다고 전해졌습니다.
세부 내용 보기
- 긴 Reasoning Agent는 전체 Trace를 Full Attention으로 메모리에 유지하므로 어려운 문제일수록 메모리 부담이 커집니다. Test-Time Scaling 논문은 장시간 사고를 수행하는 Agent의 효율을 높이는 문제를 겨냥한 자료로 공유됐습니다.
- WikiSkill의 반복 과정은 Agent 실행, 실패 Trace 판독, 지침 수정, 별도 검증 세트 평가, 점수 하락 시 파일 복귀 순서로 작동합니다. 원시 Trace와 누적 지식 문서는 삭제하지 않고, 스킬 파일만 성능에 따라 되돌립니다.
- 초기 지침이 모호해 거부된 사실과 그 이유를 지식 문서에 남기면 다음 라운드가 같은 실패를 피하고 더 구체적인 규칙을 작성할 수 있습니다. 지식 계층을 끈 실험에서는 평균 점수가 약 4분의 1 낮아졌습니다.
- DeepSeek Harness는 모델·도구·세션 동작·Runtime 구성요소를 Plugin으로 교체하는 MIT 라이선스 개발자 프리뷰이며, 모델·Agent Loop·도구·권한·상태·Sandbox를 독립적으로 바꾸는 실행 계층을 지향합니다. 한편 최소 Harness와 자체 Eval Loop를 선호하는 실무 의견도 함께 공유됐습니다.
Persistent Agent를 현재 바로 운영하기에는 실패 원인과 전체 상황을 충분히 파악하지 못했다는 우려가 제기됐습니다. 장시간 Trace와 반복 실행을 관리하지 못하면 같은 실패가 누적될 수 있다는 문제의식입니다.
원문 트윗 2개 보기
Akshay
Google just dropped a banger paper. If you write or curate skills for your agents, this one is for you. (bookmark it) Agent skills are just folders holding the instructions an agent follows for a task, and people increasingly let agents write those instructions themselves. The loop is simple. Run the agent on some tasks, read the runs that failed, rewrite the instructions, and keep the rewrite only if the score goes up on a held-out validation set. That last check matters, because an edit that quietly makes the agent worse would pile up over time. So the system always applies the edit, tests it, and reverts the file if the score drops. Here is where it breaks. Working out why the agent failed is the expensive part, since it means reading full traces and comparing failed runs against successful ones. But that diagnosis never gets written down. The only thing saved is the new instruction text it produced. So when that instruction reverts, the finding behind it goes too. The next round reads the same failures, reaches the same conclusion, and often proposes the fix that already lost, with no memory that it was ever tried. WikiSkill fixes this by splitting the one folder into three: 1. Raw traces, written once and never touched. 2. A wiki of accumulated knowledge, holding what keeps breaking, what has worked, and every edit tried so far with the reason it passed or failed. Nothing here is ever deleted. 3. The skills themselves, reverted whenever an edit makes things worse. So the instructions can roll back, but the understanding behind them never does. Their own example makes it click. An early skill gets rejected for being too vague, and instead of vanishing, that rejection is logged. The next round reads the log, sees the vague version failed, and writes a concrete rule in its place. That one gets accepted. Same failure, same analysis, but the second attempt starts from knowing what already did not work. The authors confirm this is where most of the gain comes from by turning the knowledge layer off. The average score drops by about a quarter. Two other results are worth the read on their own. Smaller models with evolved skills beat much larger models running without any, and skills evolved by one model transfer across families, sometimes working better than the ones a model wrote for itself. Paper → https:// arxiv.org/abs/2608.27454 I wrote about a related idea (GEPA) earlier, which improves a model by having it reflect on its own mistakes in plain language and rewrite its prompt, with no weight updates involved. The detailed article is quoted below.
Banger paper from Stanford on efficient test-time scaling. If you run agents that think for a long time, this one is worth your time. (bookmark it) Long reasoning keeps the entire trace in memory through full attention. This means that the hardest problems, the ones that need
➖ vLLM의 가속기별 Serving Stack 확장포스트 1
vLLM 관련 PyTorchCon NA 2026 세션이 모델 실행 자체보다 Attention, KV Cache, 분리형 Serving, Expert Parallelism을 포함한 전체 Serving Stack을 초점으로 삼았습니다. TPU, Trainium, Arm, IBM Spyre 등 여러 가속기에서 동일한 실행 계층을 구성하는 방향이 공유됐습니다.
세부 내용 보기
- 세션은 Attention과 KV Cache 시스템, Disaggregated Serving, Expert Parallelism, 가속기 이식성을 하나의 Serving Stack 안에서 다룹니다. 입력 요청을 모델에 전달하는 단계뿐 아니라 캐시·병렬화·하드웨어 배치까지 실행 경로에 포함한 구성입니다.
- vLLM의 적용 대상은 TPU, Trainium, Arm, IBM Spyre로 열거됐으며, 특정 GPU 한 종류에 고정하지 않고 서로 다른 가속기에서 Runtime을 운용하는 방향이 강조됐습니다.
- PyTorchCon NA 2026에는 Red Hat, Amazon, IBM, Huawei, NVIDIA, Google, Meta, BAAI, Fujitsu Labs, MistralAI 등 소속 연사들이 참여하는 일정으로 안내됐습니다.
- Serving 성능의 관심사가 모델 선택만이 아니라 KV Cache 관리, 작업 분리, Expert Parallelism, 하드웨어 이식성을 함께 조정하는 시스템 설계로 이동한 사례입니다.
📈 GLM 5.3 Flash의 Vision 성능과 평가 재현성포스트 4
GLM 5.3 Flash를 둘러싸고 Vision 작업의 약점, 모델별 전문화, 정밀도 설정, 평가 세트의 신뢰성이 연속해서 문제로 떠올랐습니다. 직접 실행한 결과와 다른 사용자의 사례가 엇갈리면서 API 여부와 Native Precision, 비공개 이미지 세트가 결과 차이를 만들 수 있는 조건으로 거론됐습니다.
세부 내용 보기
- 한 사례는 GLM 5.3 Flash가 Aerial·Satellite Image와 작물 이미지에서 Vision 성능이 낮다고 평가했지만, 다른 사용자는 자신의 경험과 다르다며 직접 실행에 들어갔습니다. 모델마다 Coding과 Computer Vision 등 전문 영역이 달라질 수 있다는 해석도 붙었습니다.
- 재현 과정에서는 API 사용 여부, 실행한 Precision, Thinking 설정, 테스트에 사용한 이미지 목록을 맞춰야 합니다. Sentdex는 Full Native Precision으로 실행했다고 밝히고 라벨이 없는 추가 이미지를 찾아 동일한 조건에서 시험하려 했습니다.
- Together AI의 비교 인용문에는 GLM-5.3 Flash가 GLM-5.3보다 17배 저렴하고, GLM-5.3은 첫 시도 성능이 더 강하다는 비용·성능 차이가 담겼습니다. Flash는 Image Editing 작업에도 사용됐습니다.
- 작은 탐지 항목이 많은 평가에서 결과가 한쪽으로 치우쳤을 가능성과 실제 사용 결과에 비해 Eval이 부정확할 수 있다는 의심이 제기돼, 모델 비교에서 공개 데이터·정밀도·실행 경로를 함께 고정해야 하는 상황입니다.
공유된 Vision 평가가 실제 사용 경험을 안정적으로 반영하지 못할 수 있다는 의문이 제기됐습니다. 작은 탐지 항목의 처리와 평가 데이터의 편향 가능성이 결과를 왜곡했을 수 있다는 입장입니다.
원문 트윗 2개 보기
Harrison Kinsley
Alright I'm tired of being linked this example and saying repeatedly it's not my experience with GLM 5.3 Flash. So I ran it myself. @skalskip92 what precision are you running GLM 5.3 Flash here? Are you using an API? Can I just download all your examples unlabled somewhere?
as expected, GLM 5.3 Flash is pretty bad at vision interesting how different models end up specializing in completely different things some are great at coding, others at computer vision no AGI yet, I guess 1/n aerial and satellite images, crops link: https:// playground.roboflow.com/share/2719d4fc -b3ee-4819-b2bc-3ba20e5213fe …
Harrison Kinsley
A couple quick changes to make: image editing done with... you guessed it: GLM 5.3 Flash
Deciding should you use GLM-5.3 or GLM-5.3 Flash? GLM-5.3 Flash is 17x cheaper. GLM-5.3 is stronger on the first try. So which one should actually be your default? We mapped it out, read more in the blog x.com/itsjustmarky/s…
➖ AI 생성 글과 인간적 문체의 거부감포스트 1
AI가 만든 글을 읽을 때 인위적이고 열정이 없으며 인간적인 맥락과 단절됐다고 느낀다는 실무자의 경험이 공유됐습니다. 글쓰기 품질의 평균 수준과 별개로, AI 생성 흔적에 대한 독자의 즉각적인 거부감이 사람의 문장 구성 능력에 상대적 가치를 줄 수 있다는 관점입니다.
세부 내용 보기
- AI 생성 글을 접하면 내용의 품질을 따지기 전에 가짜처럼 느껴져 읽기를 거부하게 된다는 개인적 경험이 제시됐습니다. 문제의 원인으로 열정의 부재와 인간적인 요소와의 단절감이 거론됐습니다.
- 반대 인용문은 인간이 작성한 글이나 코드도 대부분 품질이 낮으며, AI가 대다수 사람에게 개선이 될 수 있다고 봅니다. 원문에서는 이 관점과 AI 생성 글에 대한 즉각적인 거부감이 맞부딪힙니다.
- AI 생성 글이 늘어나는 환경에서는 사람이 직접 단어를 엮고 문장을 다듬는 능력이 차별점이 될 수 있다는 전망이 나왔지만, 당사자도 이에 대한 해결책은 아직 모른다고 밝혔습니다.
- 논점은 AI 사용 여부의 단순한 효율 비교보다 문체의 진정성, 독자의 정서적 반응, 인간이 직접 쓴 글의 희소성이 글의 수용을 좌우할 수 있다는 문제로 모였습니다.
AI 생성 글에 대한 거부감이 문장의 진정성과 인간적 맥락을 평가하는 기준으로 작동하며, 사람이 직접 쓴 글의 상대적 가치를 높일 수 있다는 입장입니다.
인간이 작성한 글도 대체로 품질이 낮기 때문에 AI가 대다수 사용자의 결과물을 개선할 수 있다는 반론입니다.
➖ Attention 구조와 행렬 연산의 하드웨어 경로포스트 2
Self-Attention과 Cross-Attention의 차이를 비교하는 Interactive 자료와, PyTorch의 행렬 곱셈 한 줄이 실리콘의 연산으로 이어지는 과정을 설명하는 영상이 공유됐습니다. 고수준 코드와 칩 설계 사이의 연결을 시각적으로 이해하려는 기술 학습 흐름입니다.
세부 내용 보기
- Self-Attention과 Cross-Attention 비교 자료는 같은 입력 내부의 관계와 서로 다른 입력 사이의 정보 결합을 구분하는 시각적 학습 경로를 제공합니다.
- PyTorch에서 `c = a @ b`를 실행하면 코드의 행렬 곱셈이 칩 내부의 연산으로 이어지며, 공유된 영상은 Chip Design부터 Die에 이르는 용어와 광학 식각 과정을 4분 안에 연결합니다.
- 영상은 빛의 파장보다 짧은 구조를 식각하는 방식까지 포함해, Python 코드 한 줄을 실제 반도체 구조와 연산 장치의 관점으로 확장합니다.
- 두 자료는 모델 내부의 Attention 연산과 하드웨어에서 실행되는 행렬 연산을 각각 시각화해, AI 소프트웨어와 가속기 구현 사이의 처리 경로를 이해하는 데 초점을 맞춥니다.
원문 트윗 2개 보기
Yun-Ta Tsai
There's a lot of jargon from chip design to the actual die on the board. This 4-min video explains everything you need to know, including how light etches structures shorter than its wavelength. Made by Grok @bot . Enjoy!
I made a video about what happens when you execute `c = a @ b` in PyTorch, from the code to silicon. Hopefully it will help you appreciate that simple line of code more. Made by Grok @bot. Enjoy! x.com/yunta_tsai/sta…
Tom Yeh
Self-Attention vs Cross-Attention interactive diagram. Open https:// byhand.ai/self-vs-cross
용어 해설
- 추론 시점 스케일링(Test-Time Scaling)
- — 모델의 파라미터를 다시 학습하지 않고 추론 단계에서 더 많은 계산이나 사고 단계를 투입해 어려운 문제의 답을 개선하는 방식입니다. 긴 추론을 사용하는 Agent에서는 생성된 전체 사고 기록을 어떻게 저장하고 다시 참조하는지가 메모리 사용량과 비용을 좌우합니다.
- KV 캐시(KV Cache)
- — Transformer가 이전 토큰의 Key와 Value를 저장해 다음 토큰 생성 때 같은 계산을 반복하지 않도록 하는 메모리 구조입니다. 긴 문맥과 동시 요청이 늘면 캐시 용량과 관리 방식이 serving 처리량을 결정하는 핵심 요소가 됩니다.
- 분리형 서빙(Disaggregated Serving)
- — 모델 serving 과정의 서로 다른 작업을 독립적인 구성요소나 장치로 나누는 운영 방식입니다. vLLM 관련 세션에서는 attention, KV Cache, 하드웨어별 실행을 분리해 가속기 종류와 시스템 구성에 맞게 확장하는 맥락으로 사용됐습니다.
- Agent 스킬(Agent Skills)
- — Agent가 특정 작업을 수행할 때 따르는 지침을 담은 폴더 또는 파일 묶음입니다. 작업 실행 기록에서 실패 원인을 읽고 지침을 수정한 뒤 검증 점수가 낮아지면 되돌리는 반복 과정으로 개선되지만, 실패에서 얻은 지식을 별도 보존하지 않으면 같은 실수를 반복하게 됩니다.
- Cross-Attention
- — 한 시퀀스의 Query가 다른 시퀀스의 Key와 Value를 참조하도록 만드는 Attention 방식입니다. Self-Attention이 같은 시퀀스 안의 토큰 관계를 계산하는 것과 달리, 서로 다른 입력 사이의 정보를 결합하는 데 쓰이며 이번 기간에는 두 구조를 비교하는 Interactive 자료가 공유됐습니다.
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
