openrouter,已经冲了，按量付费，全模型可用。

@sentinelK #5

1. 我应该可以选择用哪些模型，组成一个模型池。不会发生 opus 花我几十美金的情况。

2. 余额透支这个情况在哪里都会有，不是什么问题。至于你说的这些，都是可控因素，只是需要程序对其进行异常处理而已。

3. “自然也没有权利和义务决断你的消费选择，更不会对结果负责”，这说法从何而来呢？我就是为了让他替我分类选择模型才用的他，如果他不能替我做消费选择，那我用他干嘛？如果你指的是他选择了错误的模型，那这是 app 本身这个功能有问题。

4. 我不觉得用 token 为单位有什么问题，如果我发送一个大文档，那我就会有预判这次提问会消耗很多的 token 。
- token 的本质是 gpu 算力，即便改为 request 也是 token 统一打包之后的结果，价格不会有什么变化，甚至更贵。比如 iphone,有人觉得 256 、512 、1T 的存储太贵了，根本不符合市场价，这就是类似 request 打包后统一定价的结果，——消费者不需要管 ios 的开发成本，模具的开发成本，研发成本，所有价格都体现在了存储上。
- request 和 token 也是一样的，token 更细粒度的让你知道钱花在了哪儿，request 方式将中间的过程省去，直接给你打包后的价格。

@PerFectTime 不会的，印度不过春节

@sentinelK op 应该说的是分类选择模型，比如快速问答类的用 chat ，分析文档的用 pro ，生成图片时用 gemini

@lynn1su #4 所有云的本质都是 vm 或者容器

有个问题想问，经常看到有人说构建知识图谱，有些不明白。是指保留下来自己突发的灵感么？这样是不是只要放同一文件夹就行了，毕竟灵感也没有多到需要分类整理的地步；如果是指自己学习之后的总结，这不是保存在大脑中记住就好？怕哪天丢了可以放收藏夹，或者直接问 gpt ？

@Livid 推广或分享创造

我有一台联通的物理服务器和一台法国的物理服务器，也有很多云主机。

至于哪个划算，得看你是做什么。如果跑的东西很轻量，那么云主机就够；当配置要求上到 8c16g 的时候就可以考虑用物理服务器了，长期下来价格便宜不少。但是记得要考虑网络问题，不知道你是国内还是国外，国外不需要考虑带宽（最低都是无限流量的 Gbps 口），但需要考虑电费；国内反过来的。

至于托管商方面，国内如果在意延迟，那就得放在一二线城市运营商机房，如果在乎费用，就托管到三四线城市的。国外得看你位置，每个国家都有本地的 colocation 供应商，就和我们的腾讯阿里一样，得谷歌找找

@gowk 封禁就代表公司明确不允许这种事情发生，任何通过技术手段绕过该限制都属于故意违规。

@jedeft 作为公司的运维一员，可以明确的说，任何除公司提供的远程方案以外都属于违规，开掉你不用赔钱，尤其是万一出事之后。

尤其是 tailscale 组网，相当于你的机器作为网关，允许外部网络连接。我不知道你们公司什么性质，如果有合规要求，那么你的操作导致公司涉及向境外传输数据（因为 tailscal 是境外的）。

至于其他的向日葵，仍然是允许了国内其他企业访问你的机器。如果密码一旦泄漏，或者第三方有漏洞（参考宝塔面板事件），你的机器则会变成公司内部的肉鸡，进而将整个公司内网搞瘫痪。

请找你们的 IT 部门确认方案。

我对产品本身没什么兴趣，但是对维护、搭建这个产品有兴趣。。。

（我是 ops ）

linux nvdia 驱动装了么？是说 nvdia-smi 识别不到第二张卡还是系统的 lspci 也没有？

@8355 哦哦，我们倒是无所谓，不存在掉链子什么的，没来就没来了。

@lshero #10 经常见，无所谓。

@DejavuMoe #16 一个是自建的 SLA 达不到，而邮箱又是个关键的服务，哪天掉了影响很大；另一个是邮件在很多时候都可以用来当作证据的，但如果这服务是你自己搭的，那么就没办法作为证据了。

谁家好人 linux 用中文呀。。（ bushi ）

对于 k8s 和 docker ，发展过程大致是这样的：

1. 起初，dev 编写代码，编译成可执行程序传给 ops ，然后 ops 手动将程序 scp 上传至 Linux 服务器，并且安装所需的各种依赖环境，比如 jdk 1.7, nodejs 14 。对于一台新上线的机器，程序要部署上去还得考虑什么运行用户组、文件夹权限等问题。更恶心的在于，app A 的运行依赖 jdk1.7,app B 依赖 jdk 1.8,两者有冲突，得想办法解冲突。

2. 后来人们想，我们需要一种方式，把某个 app 和它运行所需要的环境全部打包起来，和外部隔离，这样不管里面要 jdk 1.7 还是 1.8,都能跑在任意 linux 环境中。于是，docker 诞生了，他不但做到了环境的隔离，还实现了环境的精简，——如果某个 app 只依赖 jdk1.7,那么这个 image 中只有 jdk1.7 这个依赖，其他什么都没有。

3. docker 发展到一定程度后人们发现，很多时候一套系统会依赖多个 container,比如前端一个容器，后端一个容器，还有个 mysql 数据库。此时，docker compose 诞生了，他可以让你在机器内部虚空创建一个网络，将这三个容器放在同一内部网络下连接在一起，运行时只需要 docker compose up 就可以启动一组 app.

4. 当 docker compose 里面的容器足够多且功能完善，比如，有的提供存储服务，有的提供监控服务，有的提供网络服务。那么此时，compose 的这些 app 内部，形成了一个功能完善的自治系统，内部和外部完全没关系。但遇到了另一个麻烦，这些儿容器太多了，compose 已经乱如麻绳了，此时 k8s 出现了。

5. k8s 的内部就是由多个容器为基础，组成的一个独立的自治系统，并且具有高可用、分布式等各种特点。需要 nfs ？ pod 来提供；需要 metrics ？ sidecar 进去监控每一个 pod ；你可以通过 yaml 文件定义各种配置，比如哪个 app 需要运行在所有节点上，比如 prometheus ；也可以定义 app A 和 B 跑在不同节点上，比如数据服务和业务；之前在 compose 的各种环境变量都可以放入 configmap 的一种 yaml 里，从这里加载进去。需要 ssl 证书也可以起个 k8s 版的 cerbot,给内部所有的 app 共享这个证书。

---

对于 devops：

devops 是用来解决传统开发模式上 dev 和运维协作问题的，比如 dev 开发完代码，本地编译，部署到生产环境。devops 将这一系列操作用 pipeline 连接起来，标准化的同时解决了安全性问题（比如谁手欠改错环境了。。。）


对于上面的 k8s 阶段，意味着会产生大量的 image,这些 image 有些是后端，有些是中间件，有些是前端。一个完整的对外服务可能后面有十来个微服务来提供的。此时如果再按照传统模式手动编译、制作 image 、上传到 harbor （自建的 docker hub ）太麻烦了，根本来不及。

此时 pipeline 派上用场了，比如 jenkins ，和 github 对接，当某个 pr 合并后，自动触发 jenkins pipeline 启动这个流程，他会按照你定义的流程去打包并分发这个 image. devops 就是去用来实现这个流程的。

试试安装一个新版本微信

https://chromewebstore.google.com/detail/ai-exporter-save-chatgpt/kagjkiiecagemklhmhkabbalfpbianbe

已经有了，并且不只支持 gemini 和 md 这一种。这个插件 4.7 评分，是经过认证的。