mirror of
https://github.com/hanzoai/papers.git
synced 2026-10-29 07:34:31 +00:00
zeekayandHanzo Dev
e57d01a884
Every measured constant in hanzo-dormant-agents came from bench lanes that have since been re-run, and two of them from a lane that was deleted. The paper is the last consumer to be corrected and the one where it matters most. The pooled row was the problem. Section 6 reported 37.54 ms for "a command dispatched into a container that is already up" and built a paragraph on it — "pooling collapses most of the gap, and is the only tier that matters at fleet scale" — which the conclusion then turned into policy: pool the expensive boundary so a fleet pays the pooled number in steady state. That row was docker exec, on a runtime this system does not use. The runtime it does use has no exec, no attach and no pool. Every call boots. So the table is hanzo-vm now: 309 ms cold, 335 p95, and 311 ms from a checkpoint — which is the same number, because a checkpoint carries the filesystem an earlier run left and the kernel boots either way. The pooling paragraph is replaced by what is true: there is no warm tier, the published resume figures elsewhere are memory snapshots and ours is not, and setting the two side by side would claim a mechanism by borrowing its name. The cost of not having it is stated instead — about 3x on a whole agent call. Section 6 also said our figure "compares favourably to the published cold-start figures". At 309 ms it does not: it is slower than the under-200 ms published for Firecracker sandboxes, faster than the container platforms, and all of those were taken by their authors on their own hardware. The paper says that now, including that quoting their hardware back at them is not a defence. The rest are re-measurements: a goroutine spawns in 125 ns (the 187 was a fresh binary's first run, which is 1.65x its own steady state), a million wake in 107 ms, a V8 context is 0.13 ms, an isolate 0.35 ms, wazero 7.8 us, goja 2.4 us, gpython 25.0 us. The isolation ratio is 2377x, not 1016x. Rebuilt: 12 pages, no stale figure survives in the PDF. Co-authored-by: Hanzo Dev <[email protected]>
50 lines
2.9 KiB
TeX
50 lines
2.9 KiB
TeX
\section{Limits}
|
|
\label{sec:limits}
|
|
|
|
\paragraph{\rGoPer{} bytes is a floor and will be quoted as a forecast.}
|
|
This is the most likely misuse of the paper. The measured goroutine holds a
|
|
place and nothing else. A working agent holds a conversation, a tool schema, and
|
|
whatever it has retrieved --- kilobytes to megabytes --- and that term dominates
|
|
\rGoPer{}\,bytes by three to four orders of magnitude. The correct reading is
|
|
narrow and still useful: \emph{the platform's own per-agent overhead is
|
|
negligible}, so a fleet's memory is the agents' data and not the runtime's
|
|
bookkeeping. Any capacity claim that multiplies \rGoPer{}\,bytes by a population
|
|
is wrong, including if we make it.
|
|
|
|
\paragraph{One host, one architecture.}
|
|
Every number is from one Apple M-series laptop. The goroutine and SQLite results
|
|
should port to any 64-bit platform with the same Go and SQLite versions --- they
|
|
measure allocator and file-format behaviour, not silicon --- but the microVM
|
|
figure will not: \rVm{}\,ms is a hypervisor boot on macOS, and a native Linux
|
|
host with KVM does not pay the same costs. It is therefore likely
|
|
\emph{pessimistic} for our own cold-start row. We have not measured it natively
|
|
and do not claim the better number.
|
|
|
|
\paragraph{History is the term that grows.}
|
|
A dormant agent stays \rFleetPer{}\,bytes forever. Its transcript does not. At a
|
|
retained 2\,KiB per call, a fleet serving a billion calls a month accumulates
|
|
roughly 22\,TB over twelve months \modeled{} --- which eventually exceeds
|
|
compute, and is the one line in the model with no ceiling. A platform built on
|
|
this decomposition must have a retention policy before it needs one; the cheap
|
|
dormant agent is what makes the expensive transcript easy to overlook.
|
|
|
|
\paragraph{Resume assumes the state is reachable.}
|
|
\rFleetResume{}\,ms is an in-process read from a local file. An agent whose state
|
|
lives on another node pays a network round trip instead, and the design that
|
|
makes this rare --- pinning an agent's tenant to a writer, as the companion
|
|
paper describes~\cite{unifiedtenant} --- has its own failure modes on failover.
|
|
The measurement is of the storage layer, not of a distributed system.
|
|
|
|
\paragraph{The in-process runtimes are not a boundary against a hostile tenant.}
|
|
Stated in \S\ref{sec:code} and repeated because it is the one place where taking
|
|
the cheap rung would be a security error rather than an economy: goja and
|
|
gpython run in the host address space. Where the tenant is adversarial, the third
|
|
rung is the only correct one, and its price is the price.
|
|
|
|
\paragraph{What we did not measure.}
|
|
Scheduler behaviour under contention at a million runnable (rather than parked)
|
|
goroutines; garbage-collection pause time at that heap; SQLite behaviour under
|
|
concurrent writers across many tenants; and the end-to-end latency of a real
|
|
agent turn, which is dominated by the model call and would tell you nothing about
|
|
the primitives this paper is about.
|