속성:Evidence note
자료에서 확인할 수 있는 점이나 한계를 적습니다.
p
Exact repository-local final and bridge lock directories are ignored so their owner.json files do not falsify the runner's post-lock clean-tree assertion. +
Logical FlashAttention paths were symlinks into serve-glm51/.venv. Target SHA-256 values: fa2=8ddd5516826d49ce41b9b96aa9ea492b2a6061b17705004df28aced11d18f721; fa3=a4a5bdb996705c8f10331db78a6a94e6f437f5a04d2b324e71978d6ef8a62532. Targets were regular but user-writable mode 0664. +
The runner resolved repository-visible extension paths before enforcing the repository-root boundary; the failure happened before bundle creation and before any CUDA generation. +
The runtime package contained 2,251 tracked files plus 985 ignored non-cache paths, including vendored Python/CUDA headers/kernels and 13 native extensions. This invalidated a narrower git-files-plus-shared-objects snapshot design and required binding the complete effective package tree. +
Machine-readable evidence that target-generation inventory slots are hardware-null while target-bound calibration and final cells enforce hardware identity. +
B200-2 rehashed four pinned model/tokenizer manifests: 27 declared files, 29,742,199,921 bytes; semantic preflight validation passed before GPU collection. +
Pre-run documentation snapshot used to identify and clarify the wording tension between B200 bridge-only performance evidence and hardware-null model-semantic generation calibration. +
Changed only pipeline_code_sha256 to use a package-relative file-tree digest. Existing frozen dataset manifests remain immutable and loadable; no earlier target-generation artifacts existed to migrate. +
The pane showed a concatenated command token and command-not-found. Immediate checks showed no global lock owner and no GPU compute application; the append-only run ID remained unused. +
Uses the absolute lexical .venv/bin/python path for both origin probe and generation child. Focused runner tests, pre-commit, a full 553,835,742-byte snapshot/import smoke, and the exact B200-2 safe-path calibration CLI help command passed. +
The append-only bundle is status=failed/rejected_incomplete. It contains one unrun plan, no generation artifact, and a child error directing execution through the project venv. Immediate post-failure GPU process inventory was empty. +
The append-only a02 bundle is rejected_incomplete. vLLM resolved the pinned offline Qwen model and reached SyncMPClient construction, then ZMQ rejected a TMPDIR-derived IPC name longer than sockaddr_un.sun_path. Immediate GPU process inventory was empty. +
Verification: official USENIX page and abstract; confidence=high.
Canonical title: PMR: Proactive Memory Reclamation for Mobile Devices
Question: How can mobile memory reclamation avoid foreground stalls caused by shrinking and dirty-page writeback?
Context: Reactive Android reclamation couples page shrinking with storage work on the latency-critical path.
Method: PMR proactively shrinks pages, decouples shrink from writeback, and batches unmapping/writeback in storage-friendly form.
Evaluation: workloads=applications on real mobile devices; baselines=Android memory reclamation; metrics=response time; results=up to 43.6% improvement
Interpretation: Reclamation latency falls when dirty work is predicted, separated, and shaped for the storage device.
Reusable lesson: Move reclaim preparation off the demand path and batch device-facing cleanup.
Applicability: Memory-constrained mobile systems with flash-backed swapping/writeback.
Limits: Reported evaluation is mobile/Android-specific; energy and flash-wear effects were not in the accessible abstract. +
Verification: official USENIX page and abstract; confidence=medium.
Canonical title: PMR: Fast Application Response via Parallel Memory Reclaim on Mobile Devices
Question: How can mobile memory reclamation avoid foreground stalls caused by shrinking and dirty-page writeback?
Context: Reactive Android reclamation couples page shrinking with storage work on the latency-critical path.
Method: PMR proactively shrinks pages, decouples shrink from writeback, and batches unmapping/writeback in storage-friendly form.
Evaluation: workloads=applications on real mobile devices; baselines=Android memory reclamation; metrics=response time; results=up to 43.6% improvement
Interpretation: Reclamation latency falls when dirty work is predicted, separated, and shaped for the storage device.
Reusable lesson: Move reclaim preparation off the demand path and batch device-facing cleanup.
Applicability: Memory-constrained mobile systems with flash-backed swapping/writeback.
Limits: Reported evaluation is mobile/Android-specific; energy and flash-wear effects were not in the accessible abstract. +
Bibliographic paper record. +
Bibliographic paper record. +
Verification: arXiv abstract/full-text excerpts and DOI metadata; confidence=medium.
Canonical title: POD-Attention: Unlocking Full Prefill-Decode Overlap for Faster LLM Inference
Question: Can prefill and decode attention execute concurrently on the same GPU SMs instead of interfering or running sequentially?
Context: Prefill is compute-heavy and decode memory-heavy, but conventional attention kernels do not co-reside efficiently.
Method: POD-Attention co-schedules prefill and decode attention on each SM with adjustable resource allocation and integrates with Sarathi-Serve.
Evaluation: workloads=mixed prefill/decode LLM serving in Sarathi-Serve; baselines=non-overlapped/coarse-overlap attention; metrics=attention speedup and serving throughput; results=up to 59% attention speedup, 28% mean; up to 22% offline throughput
Interpretation: Complementary attention phases can share SM resources productively with a purpose-built fused scheduler.
Reusable lesson: Fuse and partition complementary kernels at the SM level rather than only batching at request level.
Applicability: GPU LLM serving that mixes ongoing decode with new prompt prefill.
Limits: Requires custom attention kernels and careful resource partitioning; gains depend on prefill/decode mix. +
Verification: arXiv abstract/full-text excerpts and DOI metadata; confidence=high.
Canonical title: POD-Attention: Unlocking Full Prefill-Decode Overlap for Faster LLM Inference
Question: Can prefill and decode attention execute concurrently on the same GPU SMs instead of interfering or running sequentially?
Context: Prefill is compute-heavy and decode memory-heavy, but conventional attention kernels do not co-reside efficiently.
Method: POD-Attention co-schedules prefill and decode attention on each SM with adjustable resource allocation and integrates with Sarathi-Serve.
Evaluation: workloads=mixed prefill/decode LLM serving in Sarathi-Serve; baselines=non-overlapped/coarse-overlap attention; metrics=attention speedup and serving throughput; results=up to 59% attention speedup, 28% mean; up to 22% offline throughput
Interpretation: Complementary attention phases can share SM resources productively with a purpose-built fused scheduler.
Reusable lesson: Fuse and partition complementary kernels at the SM level rather than only batching at request level.
Applicability: GPU LLM serving that mixes ongoing decode with new prompt prefill.
Limits: Requires custom attention kernels and careful resource partitioning; gains depend on prefill/decode mix. +
Verification: official_abstract; confidence=medium.
Canonical title: Polymorphic Error Correction
Question: Can one redundancy budget flexibly protect memory against different fault models while also providing strong integrity authentication?
Context: Fixed ECC allocates check bits to one correction profile; secure memory also needs a MAC within tight metadata budgets.
Method: Polymorphic Error Correction reinterprets the same redundancy across fault models, combining an inline MAC with iterative correction.
Evaluation: workloads=64-byte cache lines; 40-bit DDR5 channels; multiple memory fault models; baselines=fixed ECC plus MAC designs; metrics=fault correction; detection probability; MAC width; results=near-100% detection; up to 60-bit MAC; supports multiple correction modes
Interpretation: Redundancy can be encoded for multiple operating points instead of hard-wiring one reliability/security tradeoff.
Reusable lesson: Make protection metadata polymorphic so systems can adapt correction strength and authentication without changing storage overhead.
Applicability: Secure DDR5 memory systems combining ECC and integrity checks.
Limits: Assumes a MAC+ECC secure-memory setting; performance, iteration latency, and all fault assumptions were not verified from full text. +
Bibliographic paper record. +