得看存什么。6G如果是内存，对一些本地工具来说还行；1T硬盘对普通文档、表格、代码基本够用。但如果存视频、图纸、日志、备份，1T很快就满。更靠谱的做法是按实际用量估：先统计现有数据量，加上年增长，再乘以2到3倍保留余量。另外别忘了备份会占一份空间，快照、版本历史也要吃容量。直接问6G 1T够不够，不如先列清楚数据类型和增长预期。

就是把信息按需加载，而不是一次性全塞进上下文。系统先识别用户意图，再决定调用哪些skill或工具，无关模块不激活、不取数据、不占token。比如用户问财务问题，只加载财务相关技能；问代码问题，只触发工程模块。这样能省token，也减少模型被无关信息干扰导致的幻觉。实现上需要一个好路由层，能根据关键词、历史对话和任务类型动态匹配技能，否则该调用的没调出来，反而误事。

本质上是规模化采购加流量套利。中转站集中采购大量账号或企业套餐，拿到比个人开发者低的单价，再拆卖；有些会把请求路由到成本更低的区域或集群；还有的是做缓存复用，把常见问题结果存起来直接返回。但要注意，这种模式有隐患：账号可能被封、响应稳定性差、数据经过第三方有合规风险。如果项目对延迟和隐私敏感，建议直接走官方渠道；如果只是实验性质，中转站能省点钱。

还有下降空间，但边际收益会递减。看得见的路径：模型压缩、量化、蒸馏出小模型；推理侧做KV Cache复用、动态批处理、投机采样；基础设施用更密的算力和更优的调度。但真正的成本大头是业务侧的无脑调用，比如长上下文塞垃圾、反复重试、不分流复杂任务。接下来成本下降更多来自工程化，而不是单纯等模型降价。建议先把自己的调用链路审计一遍，别盯着厂商价格表。

不能一刀切。垂域模型在边界清晰、数据封闭的场景里确实更稳，比如医疗诊断、法律文书、工业质检，这些领域需要严格术语和可控输出。但代价是通用能力下降，换个场景就拉胯。通用大模型胜在迁移快、脑洞多，适合探索性任务。关键不在模型本身，而在于你有没有高质量领域数据做微调或RAG。数据质量不行，垂域模型照样胡说；数据做得好，通用模型加知识库也能打。选型时把准确率和成本放在一起看，别为了一点提升牺牲可维护性。

FDE是落地交付角色，OPC是组织形态，两者不是一回事但互相成就。FDE把AI能力拆成可复用的业务系统，降低实施门槛；OPC则靠少量人加AI杠杆运营公司。没有FDE把复杂需求工程化，OPC就是空中楼阁。反过来，OPC的轻量化交付需求也会倒逼FDE做更标准化、可配置的方案。

这种text sent OK但用户看不到的现象很像是服务端收到了但没下发，或者被风控、通道策略拦截了。你已经排除了常见客户端问题，建议走两个方向：一是抓服务端下行队列日志，看这条消息有没有进待投递队列；二是联系微信开放平台技术支持，确认账号或应用维度有没有被限制下发。多账号同时出现，基本能判定是平台侧策略变化，不是单点问题。

当然可以，但别乱换。不同模型API格式、鉴权、部署方式不一样，各自写Harness很正常。问题是提示词模板、采样参数、评分器、超时重试这些不一致的话，分数就没法横向比。建议底层复用统一的评测框架，只在模型适配层做差异。专项测试比如安全、Agent、RAG可以独立Harness，但评分标准要对齐。

参数量摆在那，千亿模型每次前向反向都要过一遍所有参数，还得存梯度、优化器状态和激活值。数据量也大，几千亿token要反复扫多轮。Transformer的注意力计算复杂度跟序列长度平方成正比，长上下文尤其烧钱。再加上分布式训练几千张卡同步梯度、通信、故障恢复，这些都不是线性开销。预训练完了还要微调、对齐、RLHF，每一轮都是钱。

别光看用户量。核心交易链路先做单库垂直拆分，按订单、支付、库存这些域拆出去，配合读写分离和缓存，能撑很久。分布式是万不得已才上的，跨库事务、幂等、对账这些坑会把你埋了。真要上，得满足几个硬指标：核心写入持续几万TPS、热点表过几亿、单库多TB，或者必须多活。支付扣款这种强一致场景，宁可多拆库也别轻易分布式。