有几个难点：
1. [未来的不确定性] 即使对于现在的小模型，也只有少部分电脑能单机运行（显存要求高）。一段时间后，可能会出现，任何值得跑的模型都需要 20G 显存的情况，那么这个分布式工具可能就白做了。（甚至如果用虚拟货币来简化中间结算的话，假设没有合法问题，也可能会有暴雷跑路的风险）
2. [当前市场的不确定性] 用量小的，试着玩的，大概率不会为此付费。需求用量大的，能创造价值的，可能考虑自己买机器和显卡，或者会使用云服务。分布式的市场可能存在，但不是特别明显，只能做出来试试看结果。
3. [技术问题] 生成出来的内容的加密保护和完整性验证。
- 用户花钱生成出来的结果，归属权是花钱的人，所以制造的机器不能有权利看到内容，要在没有可查看的临时文件的情况下给结果加密，传给付费者，也就是要修改模型生成的代码，支持新模型和更新老模型的成本略高。
- 完整性其实是最麻烦的，如果乙方的 GPU 有问题，生成出来的图片质量有问题，这东西没法用算法来判断（因为本来就可能 10 台机器会生成 10 个不同的结果），甚至可能让人来判断都不好判断（不知道是算法的锅还是显卡的锅）。难道可以让甲方给乙方的结果打分？数据量大且平均分低的可能就是显卡的锅了？

@Felldeadbird #46 擦。吸尘器的问题，我家戴森也有这个病。。。充了几天的电，强力模式只能用一秒，然后什么模式都不能用，只能拿去充电。
不过最近天气暖和了好像又好了。

个人玩的较多的：

indie：
哈迪斯（之前 switch 上也有，也玩了很久）
爬山模拟器 celeste （之前 switch 上也有，也玩了很久）
Circuit Superstars （简直是为掌机设计的游戏，却不支持 switch ，sd 圆梦）
Art of rally （也是十分适合掌机的赛车游戏，就是操控精度低的话有点难度）
Guns, Gore and Cannoli 2 （ switch 也有的掌机游戏，但不支持 steam cloud ，换机器存档就重来）

大游戏：
forza horizon 5 （ 40fps 很稳，游戏启动时间较长但是 sd 可以随时睡眠唤醒，在 sd 上把主线玩完了）
brotato
dirt2 （但现在 steam 上买不到了）
BeamNG （对，在 PC 上 3080 都勉强的游戏，在 sd 上玩的挺舒服的）
wreckfest （还行，但感觉 pc 大屏幕更舒服）

模拟器：
emudeck cemu 的塞尔达（可以开挂降低难度）
emudeck retroarch 和 yuzu 的炸弹人
emudeck pcxs2 的 GranTurismo 4

固态硬盘盒基本 2 个点要注意：
1. 主控，性能相关。即使不在意性能，有些主控发热大，即使壳子散热好仍然会很烫。具体型号自己调研。
2. 壳子，金属外壳（散热），要有导热硅胶，且不是抽屉结构（抽屉+导热硅胶等于没有）。

好奇为什么当时国内各平台不让直播这个？版权问题？但炸了后第一时间新闻都出来了？

投资这东西，手上本金少的话，搏大的才能赚到你付出的机会成本，但潜在回报率那么高的话就成了赌博，不推荐。
不赌博。积累资源，做足功课，全身心的投入，可能能跑赢大盘一点点。
如果本金不多的话，赚得也不多，浪费这个精力没意思。

建议是学习学习微观和宏观经济学，知道不同的周期把钱放哪儿比较好，然后适当关注经济新闻，学会大概判断在哪个周期。买一些稳定的产品，偶尔能小赚一点，万一亏也亏不了多少。

感觉是因为苹果丐版性价比其实挺高的，吸引到那批价格敏感型消费者了，然后把人勾引来了，发现升配价格高于预期，就不开心了。这不也没见他们吐槽 mac pro 一台几十万，也没见他们吐槽升级 8TB 硬盘的价格么。

考虑买 surface ，甚至买 xps13 的人，不是这类人群。他们看到价格后就毫无感情的去看别的选项去了。

当然，强绑定苹果生态的，可能也会抱怨几句，然后买个丐版，外接个 SSD 之类的。

按现在的技术，可能能做一些比较简单的，比如训练一些企业专用的客服机器人，并且需要所有挖矿机器都有至少 12G/24G/32G 显存。比如把那些 4090 用起来，激励一批手动给显卡加焊内存的人。

解决了，最后发现是需要添加个 ServiceEntry ，把 internal-service-com(FQDN) 添加到 dns 里去。
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
name: testapi
namespace: fortune
spec:
hosts:
- "<my-fqdn>"
location: MESH_INTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: DNS
然后 virtual service 的规则，在 outbound handler 是可以正常处理请求的。

更新一下，又不理解了，看 jimmysong 的文档，东西网关 outbound handler 规则，route 和 endpoint 都在的，但是没法像文档里说的一样进行路由。
唯一的区别是，他说的是向 host=ratings.default.svc.cluster.local 的请求，我设定的路由是向自定义域名的 host=internal.service.com 这样的。pod 里就显示 dns 解析问题了。

发现这就是官网上说的 mesh gateway （东西向），但是是 experimental feature ，需要开启 CRD 才能用。
但 CRD 的 github 链接又 404 了。。。

```
Note that this document uses the Gateway API to configure internal mesh (east-west) traffic, i.e., not just ingress (north-south) traffic. Configuring internal mesh traffic is an experimental feature of the Gateway API, currently under development and pending upstream agreement. Make sure to install the experimental CRDs before using the Gateway API:
$ kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=v0.6.1" | kubectl apply -f -
```

@lidashuang #4 你意思是用 gateway=mesh 把路由规则发布到每个 pod 的 sidecar envoy 里？这个已经做到了。
但测试发现这些路由规则是请求进入 service/pod 时(inbound)才能触发的。（本来以为可以 outbound 时就能使用这些路由规则）
所以我需要在 pod 里先请求到某个 service （任何一个 service ），在那个 service 的 inbound 处理那儿，才能使用这些路由规则。就让这个请求多了一步。
理想的情况：请求者 pod 发出请求 -> 自己 sidecar 路由规则 -> 目标 service ，就完成请求了。
现在只能找到的路线：请求者 pod 发出请求 -> **集群内任何 service** -> 那个 service pod 的 sidecar 路由规则 -> 目标 service 。
这个请求就多绕去了一个 pod 。有点失去了 mesh 的意义，我们之前用的统一 envoy gateway 就是这么工作的。

@ermeow #3 对，就是 path->service 的基本功能。
发现 virtual service 定义给 sidecar 的规则是放在 sidecar 的 ingress 里的？（不是 egress outbound ，有没有什么方法能 outbound 时就触发规则？）
如果 pod 里发出的请求想触发这些规则，就得先发给某个 pod 的 sidecar ingress 才行，然后才能通过规则找到真正的目标 service 。
*所以我想如果真的只能在 inbound 时使用规则，那请求 pod 自己的 sidecar inbound ，算是最小化路径了。

@tanxnative #1
virtual service
```
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: httpbin-vs
spec:
hosts:
- "testapi.host.com"
gateways:
- mesh
http:
- match:
- uri:
prefix: /status
- uri:
prefix: /anything
- uri:
prefix: /headers
route:
- destination:
host: httpbin.default.svc.cluster.local
port:
number: 5000
```
`curl -H 'Host: testapi.host.com' http://any-other-service.default/anything`是可以的

`curl -H 'Host: testapi.host.com' http://172.16.153.111.default/anything`是可以的（ IP 是任何自己 service 的 cluster ip ）

但是

`curl -H 'Host: testapi.host.com' http://10.73.3.111/anything` 就不行了（ IP 是自己 pod 的 ip ）
报错`curl: (7) Failed to connect to 10.73.3.111 port 80 after 0 ms: Connection refused`

尝试请求传说中 sidecar http inbound 端口也不行：
`curl -H 'Host: testapi.host.com' http://127.0.0.1:15001/anything`
`curl: (56) Recv failure: Connection reset by peer`

BBA 只能说不丢面子，毕竟车不一定贵，4S 店保养价格是统一的贵。
LZ 当老板的还是干销售的？
写代码的打工人好像不需要吧？能想到最大的好处是大部分小区看门大爷会给 BBA 直接放行。

@littlesubgirl #60
@digimoon #63
之前配置是 3700x+1070ti ，没超频，插专门测功率的插座上测试的，开机后什么都不干大约 120w ，vmware 虚拟机开一个后会再多一些。

游戏 pc 待机一般 100w 以上，一天 2.4 度电，假设 1 元，一年待机电费也要 350 。真实还要加上硬盘,跑服务的功耗。
估计两年多花的电费够你买个入门专用 nas 了。

不追求 3A 高画质，steamdeck 真的很不错的，追求 pc 游戏仪式感可以插显示器玩。

什么电视？很多电视即使是游戏模式，延迟也大的不适合玩游戏的哦。

request 决定 pod 被分配到哪个 node 上，32 核的机器，cpu request 之和到 32 就不会编排新 pod 了。
limit 决定单个 pod 最多能用多少。
cpu limit 建议至少 1 ，不然相当于被强制限速。
然后用 CPU request 来设计 pod 的分布，一般是按启动后稳定下来的 CPU 使用量估算，防止把 node 撑爆。