问题
在笔记本上跑本地 LLM 推理的开发者会遇到两类配置痛点：一是缺少外部/基于策略的温控限流，机器“烫到能灼伤皮肤”，而固定算力上限在某些场景下又会造成非线性、灾难性的性能下降（HN 讨论）；二是上下文窗口配置过于手动，如 ollama 默认只有 2048，用户必须自己显式设置 num_ctx（GitHub Issue，得分 78、9 条评论，还提供了 API options 和 Modelfile 的临时解法）。目前大家只能靠手动限流和手动设参数这类 kludge 维持。
目标用户
在配置勉强够用的笔记本上运行本地 LLM 推理的开发者或极客用户；属于小众但活跃的群体（本地推理社区，如 ollama 用户），付费意愿整体偏低。
解决方案
- 运行时温控限流：基于温度传感器策略动态调节推理负载，替代固定算力上限，避免非线性的性能坍塌 - 动态上下文配置：根据可用内存自动决定 num_ctx 等参数，免手动设置 - 策略可调：提供“性能优先/温度优先/均衡”几档外部策略旋钮 - AI 角色：利用本地传感器与内存状态数据做自适应调度决策，非生成式 AI 功能
为什么是现在
本地 LLM 推理在笔记本上越来越普及，但现有工具（如 ollama）尚未解决运行时温控与动态上下文配置问题，社区（GitHub Issue 78 分）已明确表达需求。
MVP 范围
首版只做：读取温度传感器与内存状态，动态调节推理并发/负载，并自动设置 num_ctx。首版不做：跨设备云端管理、多机集群调度、与闭源推理引擎的深度集成。
风险
- 技术风险：温度-性能关系是非线性的，策略设计不当反而劣化体验 - 平台依赖：需要依赖 ollama 等现有推理框架的接口与参数（如 num_ctx），上游变更会导致适配成本 - 竞争风险：上游工具（如 ollama）可能直接内置该功能，吞掉独立产品空间 - 商业化风险：目标用户付费意愿低，开源社区期望免费
已有产品
| 产品 | 定位 | 价格 |
|---|---|---|
| Ollama | 主流本地 LLM 运行时，其 Issue 中的温控与动态上下文问题尚未解决，既是竞品也是可依附平台。 | — |
信号证据
这张卡片依据的原始讨论。摘录保持原文，点“原文”查看上下文。
Hacker News · Launch HN9月30日痛点
“External/policy-based throttling for temperature control. Unthrottled, my laptop bottom goes skin-burn hot. But fixed compute caps can have non-linearly dreadful performance impacts in particular cases.”
External/policy-based throttling for temperature control is missing, so laptops overheat while fixed compute caps cause non-linear performance degradation.原文
GitHub Issues · ollama/ollama11月4日功能请求▲ 789 条评论
“Context size should be determined dynamically at runtime based on the amount of memory available.”
Context window size in ollama is largely manual and defaults to 2048 unless explicitly specified, requiring users to configure num_ctx themselves.原文