panghu960

很实在的复盘，补两个我自己踩过的点。

1. embedding 换代其实不用停机全量重建。前提是原文一定单独存了一份（只存向量不存文本才是真死路）。做法：新向量加一列或新索引命名空间，写入端先双写，读取端临时老列兜底，再起个限速后台任务按批回填历史（每批几十到几百条，放在凌晨，别和白天检索抢资源），回填完切检索、下掉老列。维度不同也一样，老索引留到切完再删。我这么迁过一次，全程没有停机窗口，2G 机器也扛得住，关键是每批之间 sleep 。

2. 2G 这台机器要盯两个隐形上限。一是 HNSW 索引基本常驻内存，doubao vision 维度不低，M 和 efConstruction 别照教程默认值拉满，内存紧就调小，或者上量化/磁盘型索引，然索引一大 swap 就开始抖——云盘 IOPS 有硬上限，swap 和数据库抢同一块盘的时候延迟很难看，swap 只能兜底不能当内存用。二是 ecs.e-c1m1 是突发性能实例，CPU 有积分基线，短峰没事，持续高负载会被限速；你把计算全甩给外部 API 、本地只做存储检索这个架构正好避开了，但以后要是想省钱把 rerank 挪回本地长跑，先查一下实例积分还剩多少。

另外状态资产记得偶尔做一次恢复演练，能 restore 回来的备份才算数。

分三层看，别先被代办报价吓到：官备案本身不花钱，几千块是帮你整理材料的代办费。

1 ） App 备案（工信部，上架硬门槛）
只要上国内应用商店，不管是不是 AI ，都得先办 App 备案，跟网站 ICP 备案一个路子：在你服务器所在云厂商（阿里云/腾讯云这些）的备案系统免费提交，填主体信息、包名、签名证书指纹，平台初审后管局审核，一般几周到二十个工作日，办下来在 App 设置里挂备案号。这个自己办完全免费。

2 ） AI 部分：调用已备案模型，不用你自己做大模型备案，但应用本身要登记
你这种通过 API 直接调 DeepSeek 这类已备案模型、自己不训练不改造的情况，走的是「生成式人工智能应用/功能登记」，向属地省级网信办提交，材料比大模型案轻：应用主体、调用哪个模型（模型方备案号）、双方服务协议、你自己的内容审核和投诉处置安排。普通的提示词编排、RAG 不影响这个路径；但如果对模型做实质性微调、或对输出做二次改造成自己控制的服务，可能被要求改走完整的大模型备案。
另外还有算法备案：面向公众的生成合成类功能需要算法备案，应用商店审核时会查 beian.cac.gov.cn 的备案截图。实操中可以用模型提供方已有的「生成合成类」算法备案加上双方合作协议（协议里写明算法名称和备案编号），不一定要你自己作为主体再备一次——材料要向模型方要，并提前问商店认不认。

3 ）应用商店才是真正的守门员
华为、小米这些的 AI/深度合成类目，上架时通常要：生成内容显式标识、算法备案截图（或合作方的加协议）、部分情况要安全评估报告。建议直接看目标商店最新的资质审核文档，再打电话问客服你这个功能形态具体要哪几样，各地网信办和各商店尺度不完全一样。还有一提前确认：AI 对话类应用有些商店只接受企业主体，个人开发者可能得先注册公司，这个以商店答复为准。

省钱路径：先从模型方拿到备案号和正式服务协议； App 备案自己免费办；登记材料按属地网信办清单自己写（主要是内容安全制度、拦截词库、投诉入口），代办不是必须的。想先跑起来的话，也可以第一版先上不含 AI 对话的工具功能过审，登记完成后再加 AI 模块更新。

这种给熟人用、跑真实业务数据的小系统，建议就别再绕海外了，国内轻量加备案是最省心的，腾讯轻量本身稳定性没问题，身边跑了四五年的一大把。单和迁移时注意几点：

1. 新人优惠同一个实名只能享受一次，直接上 3 年最长档；到期续费基本恢复原价，差价很大。轻量和 CVM/ECS 不一样，是月流量包加带宽峰值限速，低价档带宽峰值普遍不高，下单页看清楚（一般几 Mbps ），表单 CRUD 加少量人够用，但附件图片别走服务器带宽，放对象存储。
2. 国内机器必须域名备案，域名和服务器在同一家提交，顺利的话一到两周；备案前域名不能开 80/443 ，先用 IP 加非标端口把部署调好，备案期间继续用现在的 CF 隧道顶着。备案完记得补公安备案。
3. 2C2G 跑 Go 加 MySQL 够，但 MySQL 8 默认配置吃内存，把 innodb_buffer_pool_size 压到 512M 左右给后端留余量，NAS 上那套容器别原样都搬过去。
4. 每天 mysqldump 导出到对象存储低频存储，或者开轻量的自动快照；出入库是正经业务数据，备份比服务器值钱。

如果只有两三个人用、不想等备案，香港轻量能免备案，但晚高峰回程会抖；你说各地挺多人用，还是国内加备案。

这种「报告文件 + 长期病程记录 + 还要喂 AI 」的需求，不太建议硬塞进 Bitwarden：它的安全笔记和附件是为小条目设计的，大量 PDF 、影像和长期记录既不好检索，也没法做趋势。我更建议分两层。

1 ）检查报告原件（ PDF 、影像、化验单照片）用 Cryptomator 。开源、端到端零知识加密，在本地建一个 vault 挂成普通文件夹，文件照常往里放，再把这个 vault 目录丢进任意网盘（坚果云 / OneDrive / iCloud / Google Drive ）同步，云端看到的只有加密块，网盘方拿不到明文；本地用时它就是个解密的文件夹，回顾、打开都正常。

2 ）文字病程、用药、指标记录用 Joplin （开源，支持 Markdown 、表格、附件，自带端到端加密，能走 WebDAV / 网盘同步）；喜欢自己组织的话用 Obsidian 也行，把整个笔记库放进 Cryptomator vault 再同步。数值类（血压、血糖、体重）想做趋势，就用 Joplin 表格或单独一个 CSV 放进 vault ，本地随便画图分析。

喂 AI 这点要单独提醒：本地加密只保护存储和同步，一旦把解密后的内容发给云端大模型，明文就出了这层保护，而检查报告里通常带姓名、证件号、就诊号、医院名。在意隐私就两条路：在本地解密后喂本地模型（ Ollama 之类，全程不出本机）；或者发云端前先手工脱敏，把身份标识去掉。

最后零知识加密意味着主密码丢了数据就找不回，主密码和恢复码一定单独存好，vault 再留一份离线备份。

这更像不是模型单点慢，而是 harness 的 agentic 循环在放大延迟。你那个改 3 行代码花 3 分半的例子，时间基本不在生成那 3 行上，而在每一步之间：改一个文件 → 重新读上下文/读图 → 再思考 → 再动下一个文件。每一轮 agent 都要把累积的对话和工具结果重新 prefill 一遍，步数越多、上下文越长，这段前缀被重复计算的次数就越多，所以总时长近似随「步数 × 每轮上下文长度」往上涨，而不是跟产出的代码量走。zcode 默认如果更激进（更少自检、批量改、积极压缩上下文），同样模型同样任务轮次能少一大截，体感自然快。

想确认是不是这个原因，别只看墙上时钟：跑的时候记两个数，一次任务总共走了多少个工具/思考步骤，以及每轮发出去的 prompt token （ usage 里有）。如果这两个都明显比 zcode 高，慢就来自 harness 的编排而不是模型本身。

配置上能马上试的：这类小改动直接要求「一次性改完、不要逐文件自检」，关掉或调低额外读图和反复校对 readme ，再看步骤数掉没掉。

权重是同一份，差异基本不在模型本身，而在推理栈和默认参数，主要看这几处：

1. 量化精度。第三方为了吞吐和成本，常会上比官方更激进的量化（ FP8/W8A8 甚至更低比特）。同一条 prompt ，低比特在长链推理、数学、代码上更容易掉点；而且即使 temp=0 ，不同 kernel 的数值也对不齐。这通常才“感觉变笨”的来源，不是模型被换了。

2. 默认参数和开关。上下文上限、max_tokens 、思考/推理强度、function call 的解析各家默认值不一样，有些还会在外面再套一层路由或改写。比较前先确认用的是同一组参数，否则比的是配置不是模型。

3. 缓存。前缀缓存是命中率问题：第三方池子小、多租户共享策略不同，命中率可能更低，长 prompt 的费用和首字延迟差别主要出在这。

4. 延迟要拆开看：TTFT （看 prefill 和排队）和 decode tok/s （看有没有被别的请求挤 batch ）是两件事，高峰期请求被路由到满载实例时，平均速度能差几倍。

真要选别靠体感：固定一套 prompt （含长前缀、工具调用、代码题），同参数各跑一二十条，按返回的 usage 和计时去比 TTFT 、每秒 token 、计费 token 数。另外分清“厂商部署版”（自己拿权重搭的）和“中转站”（转一道官方或别家接口），后者多一跳还可能悄悄换源，差异最不可控。

补一个上面没人提的层面：脱敏、.env 、两台电脑都是在做"数据分类"，但还有一层是"边界放在哪"。

"引导 AI 不要读某些文件"、写在 system prompt 里的禁令都不是安全边界——模型会被提示注入、会被自己生成的脚本带歪，它解析 .env 时一旦让值进了上下文就已经发出去了，靠模型自觉不可靠。边界要做在模型外面：工具白名单（哪些路径、命令、域名能碰，由代码强制拒绝），出网统一走代理白名单，密钥由运行时注到工具调用、模型永远拿不到原值。artiga033 说的"解析脚本不让值进上下文"方向对，但得是代码保证，而不是模型这次表现好。

另外对话历史本身也是敏感数据，还会被整段反复发给模型方，这是中转站之外的另一条出口；在意的话让对话落在自己的库。我做 openmuse-standalone （自托管个人 agent ），我是开发者，这也是我做它的原因之一。没条件搞两台电脑的，单台用独立 OS 用户或容器做边界，也比只靠提示词强。

你这几条里真正卡住产品的是第 4+5 条（蓝牙耳机 + 后台一直收声），不是模型：iOS 后台持续开麦克风基本不给权限（后台音频会话能放不能收），Android 可以挂前台服务，代价是发热和耗电，所以市面上的口语翻译产品都退化成「点一下说」。另外蓝牙耳机走 SCO 通道，采样率常常只有 8/16k ，窄带对语音识别是实打实的损失——而你是练英语，自己说的句子先被识别错，反馈本身就是错的，这点比译文质量更要命；真要一直戴着，优先挑麦克风好的耳机，或者干脆用手机麦。你说的不用同传水平、说完一句自动出英文」其实很好满足：本地 VAD 切句 + 离线识别 + 离线翻译 + TTS 回读，一句一句跑，不联网也不按时长计费，模型是一次性下载。挑的时候只看两点：能不能真离线（决定要不要梯子、会不会按分钟收钱），能不能自动切句（决定要不要一直开着麦）。声明：我自己在做离线同传 App （ NoNetPlay ，我是开发者），但它是给两个人面对面来回说话用的，不是后台常开练口语这个形态，你这个需求它并不合适；上面是我自己踩过的坑，供你选产品时参考。

先别在 workbuddy 里调，直接用 curl 打那个 OpenAI 兼容口，喂同一份长上下文，只看两件事：第一个 token 多久到、流有没有中途停。1 ）超时多半来自前者：125B 在 A6000 上还吃内存分层，prefill 很慢，拿引擎报的 prefill t/s 除一下上下文长度，几十秒不奇怪；而不少编排层的超时算的是整轮请求的墙钟（默认常见 60s ），不管你是不是在流式输出。把上下文砍到 4k 试一次，立刻好就是超时预算的问题，不是模型崩。2“调 tools 有概率崩”和“某位置必崩”不是一回事：工具调用是模型吐 JSON 、客户端自己拼流式 delta ，拼歪或者停在半个对象上客户端不会报错，只是一直等，看起来就是超时。先看原始响应的 finish_reason 和 tool_calls 有没有闭合。我做自托管 agent （ openmuse-standalone ，我是开发者）时把每步事件先落到自己的库再推前端，读的一方设“多久没新事件算断”而不是“多久没跑完算断”，这类假死好定位很多。