로컬 추론 모델은 추론값을 하는가 — gemma4:12b로 thinking ON/OFF를 직접 잰 기록
gemma4:12b의 빈 응답을 패키징 버그로 단정했다가 사실은 추론(thinking) 모델이었음을 뒤늦게 알았다. 추론 ON/OFF로 13문제를 돌려보니 정답은 1개 더 맞혔지만 출력 토큰을 68배, 시간을 19배 더 썼다. 에이전트에서 추론을 언제 켜고 끌지 실측으로 정리한다.
jangwook.net
Kim Jangwook
Personal technical notes on AI agents, automation, developer tools, and the process of building software.
Latest Notes
Recent writing by language
The root page stays intentionally small. Choose a language, then read the full archive and related posts there.
한국어
AI 에이전트, 자동화, 개발 도구, 소프트웨어 제작 과정을 한국어로 기록합니다.
로컬 에이전트가 시스템 프롬프트를 까먹은 이유 — Ollama num_ctx 무음 truncation 실측
로컬 에이전트가 긴 대화에서 갑자기 지시를 무시하길래, 프롬프트 맨 앞에 비밀 코드를 숨기고 길이를 늘여가며 recall을 측정했다. num_ctx를 넘기면 Ollama는 에러 없이 프롬프트 앞쪽을 잘라낸다. 그리고 기본값이 4096이라는 통설도 내 맥북에선 사실과 달랐다.
로컬 LLM의 첫 응답은 왜 가끔 10초씩 걸릴까 — 콜드 스타트(load_duration)를 직접 재봤다
잠깐 쉬었다가 에이전트를 다시 부르면 첫 응답이 유독 굼떴다. Ollama가 응답마다 주는 load_duration을 모델 크기별로 뜯어보니 2GB는 1.5초, 9.6GB는 최대 9.7초였다. keep_alive 하나로 이 콜드 스타트 비용이 어떻게 갈리는지 직접 측정해 정리했다.
English
Personal notes on AI agents, automation, developer tools, and building software.
Does a Local Reasoning Model Earn Its Keep? Measuring thinking ON/OFF on gemma4:12b
I ran 13 questions on gemma4:12b with thinking ON and OFF. Reasoning got one more right while spending 68x the output tokens and 19x the wall-clock.
Why My Local Agent Forgot Its System Prompt — Ollama num_ctx Silent Truncation
My local agent kept ignoring its system prompt on long inputs. Past num_ctx, Ollama silently trims the front of the prompt — no error. I measured where it breaks.
Why a local LLM's first reply sometimes takes 10 seconds — I measured the cold start (load_duration)
After idling, my agent's first reply dragged. I pulled Ollama's load_duration across model sizes: 1.5s for 2GB up to 9.7s for 9.6GB, and split it by keep_alive.
日本語
AIエージェント、自動化、開発ツール、ソフトウェア開発の記録です。
ローカル推論モデルは推論の元が取れるのか — gemma4:12bでthinking ON/OFFを実測した記録
前回の記事でgemma4:12bの空応答をパッケージングのバグと断定した。違った。推論モデルだったのだ。そこで推論ON/OFFで13問を回した。 推論は正解を1つ多く出したが、出力トークンを68倍、時間を19倍消費した。エージェントでいつ点けていつ消すかを実測でまとめる。
ローカルエージェントがシステムプロンプトを忘れた理由 — Ollama num_ctx無言truncationを実測
ローカルエージェントが長い会話で急に指示を無視しはじめた。プロンプトの先頭に秘密コードを隠し、長さを伸ばしながらrecallを測った。 num_ctxを超えるとOllamaはエラーも出さずプロンプトの前方を切り落とす。そして「既定値は4096」という通説も私のMacでは外れていた。
ローカルLLMの最初の応答はなぜ時々10秒もかかるのか — コールドスタート(load_duration)を実測した
少し離れてからエージェントを呼び直すと、最初の応答だけやけに重い。Ollamaが応答ごとに返すload_durationをモデルサイズ別に 分解すると、2GBで1.5秒、9.6GBで最大9.7秒だった。しかも「コールド」には二種類あった。keep_alive一つでこの費用が どう分かれるかを実測してまとめた。
简体中文
记录 AI 代理、自动化、开发工具和软件构建过程。
本地推理模型值回票价吗 — 用gemma4:12b实测thinking开/关的记录
上一篇文章里我把gemma4:12b的空回复断定为打包bug。错了，它其实是推理模型。于是我用推理开/关跑了13道题。 推理多答对了1题，却多花了68倍的输出token和19倍的时间。本文用实测整理在代理里该何时开、何时关。
本地智能体为什么忘了系统提示 — 实测 Ollama num_ctx 的无声截断
本地智能体在长输入下突然无视指令。我把一段秘密代码藏在提示开头，逐步加长输入直到 recall 崩掉。 一旦超过 num_ctx，Ollama 就不报错地砍掉提示前半段。而且"默认值是 4096"这个说法，在我的 MacBook 上是错的。
本地LLM的首次响应为何有时要等10秒 — 我实测了冷启动(load_duration)
离开一会儿再叫回代理，第一条响应就格外迟钝。我把Ollama每次响应都返回的load_duration按模型大小拆开看：2GB是1.5秒， 9.6GB最高9.7秒。而且"冷"原来有两种。keep_alive一个开关如何决定这笔开销，我做了实测整理。