Vitalik Buterin 用本地模型 Qwen 3.8 Flash Next 编排、远程前沿模型作为工具调用，结合 zkAPI 与 Tor 三层隐私方案，完成基于个人健康与旅行数据的个性化饮食和运动推荐实验。他指出 Tor 对逐请求去关联优化不足、延迟高出 10-100 倍，Qwen 3.8 Flash Next 仅 20-30 TPS 偏慢，且给远程模型的数据越少、能获得的帮助也越有限。
Doing a bit of a self-experiment.
Goal: use my personal health and travel data to provide personalized diet and exercise recommendations for me, using frontier models but in a way that avoids leaking to them any private information.
Strategy: use a local model (Qwen 3.8 Flash Next) to orchestrate, and use powerful remote models as a tool call to benefit from higher-level thinking and knowledge that the local model does not have.
Three-layer approach to privacy:
Avoid leaking personally identifiable information, or leaking my identity through writing style -> local model writes the queries to the frontier model, not me
Avoid leaking who I am through the payment channel -> zkAPI
Avoid leaking who I am through networking / IP -> Tor
You need all three (and finally we have all three, at least to some extent)
A skill file teaches the local model when and how to construct minimally-data-revealing requests to remote models. Use zkAPI-wrapped-with-Tor as a CLI tool.
And everything works! I got the recommendations back, info from frontier models helped to improve them.
Main deficiencies:
- Tor is really not optimized for request-by-request de-linking, which is the only form of network-layer privacy that really makes sense in today's world (long-running identifiers are too fragile). Probably not private enough, and latency 10-100x higher than it could be, at the same time.
- The skill file's request construction strategies are definitely far from optimal.
- Qwen 3.8 Flash Next is still too slow for comfort. It's comfortably running at 20-30 TPS, but it would only really start to feel fast at 100+
- There is a tradeoff: the more careful you are about what data you give to a remote model, the less it can help you
来源：vitalik.eth · x.com