1先算账，再选型

五笔账少一笔就翻车

本地/边缘部署第一个坑是只算模型权重。机器人在客户现场常要语音 ASR + LLM + TTS 同时常驻，加上 ROS/中间件、遥测、看门狗，资源账必须五项全列，并留 20% 余量。

项	内存场景	机器人/边缘对应物
模型权重	4-bit ≈16.1GB / 8-bit ≈29.5GB / BF16 ≈54GB	主模型常驻显存（ASR+LLM+TTS 常同时驻留）
上下文缓存	128K ≈ +11GB；256K ≈ +23GB	多轮对话历史、地图/建图数据、长任务状态
运行缓冲	Prefill 阶段内存突增	并发峰值、视觉帧预处理、点云批处理
辅助模型	草稿模型约 +2GB	唤醒词、VAD、意图分类、安全兜底小模型
系统与其他	macOS + Chrome + Docker	ROS/中间件、驱动、遥测上报、日志、看门狗

纪律：方案里的资源预算必须五项全列，留 20% 余量。演示点亮 ≠ 连续运行 8 小时

2选型决策表

按算力档位定模型档位

边缘算力 → 模型档位原文「统一内存→量化档位」改写

入门 <16GB

3B~8B 小模型

别硬塞大模

中端 16~32GB

4-bit 中型（27B≈16GB）

先砍并发稳了再加

高端 48GB+

8-bit 或更长上下文

别为精度强行上档

服务器上行

BF16 / FP16

余量要足

关键判断：加载成功 ≠ 适合长期使用。持续 Swap 的机器，再高精度也救不了响应速度

3阶梯加档与 Baseline 先行

一次只改一个变量

起步档 → 稳定 → +1 档 → 复测，每档只改一个变量。上下文 8K→16K→32K→64K→128K（仅确有超长需求）；对话轮次 N=3→5→10；并发 1→2→4 每档跑满 30 分钟；传感器帧率 10→15→30 FPS。

判断：「模型支持 262K」是能力参数，不是默认推荐。这句话可直接用作客户沟通话术——提前声明边界，比事后解释翻车强一百倍。

先跑基线再谈优化。一次打开十个优化选项，跑快了不知道是谁的功劳，跑慢了不知道关谁。A/B 六项必须完全一致：输入任务、模型与量化、推理参数、上下文长度、冷/热启动状态、测量口径（同一客户端、同一脚本、≥3 轮取中位数）。别只跑 50 个 token——短任务里加载和热身占比过高，看不出真实持续表现，至少 400~1000 token 或跑完一次真实任务。

4测量边界六字段

这条最该固化

凡是对外报的性能数字，必须带齐六字段：①硬件与系统（型号/显存/系统版本/供电）；②模型与量化（具体仓库+档位，不能只写「27B」）；③加速/辅助策略（投机解码？并发数？）；④工作负载（导航/对话/抓取分开设）；⑤指标范围（首响/处理/生成/端到端分报，不只报一个）；⑥缓存与热身（冷/热启动、缓存命中、跑几轮取什么统计值）。

判断：速度/性能不是硬件参数，是一条测量结果。没有边界的数字没有比较价值。同行报「响应 200ms」，你报「端到端 200ms，条件：XX 设备/4-bit/单路/热启动/30 轮中位数」——后者更保守，但更经得起现场验收。主动标注边界，让方案在客户眼里比同行可信一个档位。

迁移自深度研究 #12（@ai_suxiaole 苏乐《Qwen3.8-27B 本地部署调优指南》）。核心实证：同一 Mac mini M4 Pro 48GB + 同一 Qwen3.8-27B + 同一 DFlash 2 加速，实测 5.9~52.3 tok/s（差 8.9 倍），差异全来自运行时/任务类型/缓存命中/CLI vs HTTP API/冷热启动，非硬件。